DETAILED ACTION
Claims 1-20 are presented for examination.
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 .
Drawings
The drawings Figures 8, 9, and 10 are objected because they contain blurry portions.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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.
Claim 19 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 19 recites the limitation " “The computer-implemented method according to claim 17”. Claim 17 is a system claim which makes 19 indefinite because it is not clear if claim 19 is a method claim or a system claim. For the purpose of examination, claim 19 is interpreted as being dependent on claim 18.
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 18-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to software per se.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claims 1, 12, and 18:
Applying Step 1 of the Subject Matter Eligibility Test (SMET), does the claim as a whole fall within one of the four statutory categories of invention? Yes.
Claims 1 and 12 recite a computing system including a memory and a processor, and therefore fall within the machine category. Claim 18 recites a computer-implemented method, and therefore falls within the process category.
Under Step 2A of the SMET, also known as the Alice/Mayo Test, Prong One, is the claim as a whole directed to a law of nature, a natural phenomenon, or an abstract idea? Yes.
Configuring a ledger to maintain current values, providing access to facilitate coordinated data asset management, obtaining endorsement of a transaction through peer consensus, and instructing a node to apply a trust control based on that endorsement is, at bottom, certifying and guaranteeing the disposition of a transaction between parties. This is a fundamental economic practice and falls within the "certain methods of organizing human activity" grouping commercial interactions such as contracts and agreements, and mitigating risk through certification of a transaction. See MPEP § 2106.04(a)(2). The claim also recites a mental process, since a person could review a proposed change to a data record, check whether the relevant parties agree to it, and decide whether to apply that change based on the agreement reached.
A person can perform this, with or without pen and paper: look at a proposed update to a record, ask around or observe whether others agree with it, and then either apply the update to the record or not depending on that agreement. A small group could do the same thing. One person proposes a change, others weigh in, and whoever keeps the record makes the update once there's agreement. So, the claim covers a process that can be done mentally or by a group of people reaching consensus, which is why it's treated as an abstract idea here.
Applying Step 2A, Prong Two, does the claim recite additional elements that integrate the judicial exception into a practical application? No.
Beyond the abstract idea, the claims recite:
one or more processors;
a memory;
a blockchain framework;
a master data asset ledger;
a plurality of peer nodes;
object codes;
a coordination protocol;
a set of shared smart contracts; and
distributed ledger copies.
None of this integrates the abstract idea into a practical application. Integration can be shown where the claim improves the functioning of a computer or some other technology, but that's not the case here, the processor, memory, and blockchain framework are all claimed generically and only in terms of what they accomplish (maintain a ledger, endorse a transaction, apply a trust control), not how they do it. There's no consensus algorithm actually specified, no particular cryptographic structure, no data structure, and no showing of improved latency, throughput, or fault tolerance anywhere in the claim.
If anything, the specification undercuts an improvement argument, since it describes blockchain, distributed ledgers, smart contracts, and peer consensus as existing technology being brought into the banking/data-management space rather than something applicant improved upon. See, e.g., Spec. ¶ [0148] (describing a "blockchain" as simply "a growing list of records...securely linked together using cryptography"). Using generic computer and network components to gather, organize, and act on information according to their known function isn't enough to show a technical improvement. TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48; Electric Power Group, 830 F.3d at 1353-54.
For these reasons, the claim is not integrated into a practical application.
Applying Step 2B, do the additional elements amount to an inventive concept? No.
Appending well-understood, routine, conventional activity to an abstract idea doesn't supply an inventive concept, even where that activity is described using specialized vocabulary. Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1982-83. Here, the processor, memory, ledger, peer nodes, smart contracts, and object codes are all doing exactly what these components are known to do - storing data, distributing it across nodes, running programmed rules when an event occurs, and reaching agreement among participants - and the specification itself describes these as standard blockchain building blocks rather than as something new (Spec. ¶¶ [0148]-[0153]). Taking the elements together doesn't change this outcome either; they're simply arranged and used in their expected roles.
Because claims 1, 12, and 18 fail Step 2B, the claims as a whole are ineligible and non-statutory under 35 U.S.C. 101.
Regarding claims 2-11, 13-17, 19, and 20:
The dependent claims don't change the analysis above.
Claim 2 recites comparing a newly composed data asset against a current value, checking its quality and integrity, and updating the record - evaluation and record-keeping a person could do.
Claim 3 recites comparing a data asset to a current value, finding no change, and leaving the record alone - again, evaluation.
Claim 4 recites that participants actively submit data assets for entry, which is just organizing who does the submitting.
Claim 5 recites that the ledger and nodes have generic functional layers, without any specifics as to how those layers are actually implemented.
Claim 6 recites that the coordination protocol is defined by business rules reflecting a pattern, model, or schema - a business rule.
Claim 7 limits the ledger states to records of decentralized applications, which is just a field of use.
Claim 8 recites that the object codes are smart contracts triggered by events, which the specification treats as standard blockchain functionality.
Claim 9 limits the framework to a multiparty business network - again, field of use.
Claim 10 recites "algorithmic trust control" using state transition events stored as blocks, but doesn't specify any particular algorithm, so this is still generic blockchain functionality.
Claim 11 recites a "centralized authoritative trust control," which is an organizational concept, not a technical one.
Claim 13 recites that decentralized applications are interconnected via the peer nodes - field of use.
Claim 14 recites managing master data through a platform, described at a high level with no technical detail.
Claim 15 recites that the ledger stores executable smart contracts - conventional blockchain functionality.
Claim 16 recites that the trust protocols include decentralized algorithmic controls and centralized governance controls - an organizational structure.
Claim 17 recites that the centralized controls rely on a controller instructing lower-level nodes - again, organizational hierarchy.
Claim 19 recites the same comparing, validating, and updating steps as claim 2, applied to the method of claim 18.
Claim 20 recites the same comparing and no-update steps as claim 3, applied to the method of claim 18.
Each of these either narrows the abstract idea further, specifies the type of data involved, limits the field of use, or adds a generic blockchain implementation detail. None of them, alone or together, integrate the claim into a practical application or add significantly more than the abstract idea itself. Claims 2-11, 13-17, 19, and 20 are rejected under 35 U.S.C. 101 for the same reasons.
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, 4, 8, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Batra et al. (US Pub.No.2019/0205884) in view of Krishnaswamy et al. (US Pat.No.11765225).
Claim 1. Batra in view of Krishnaswamy discloses A computing system incorporating a network-based asymmetric key and digital signature verification protecting a cryptographic blockchain security framework configuration for enhanced security and trust control through node-based core operations and trust data management, the computing system comprising: one or more processors in communication with a memory; (Batra Par. (0055) "computer system/server 502 may include, but are not limited to, one or more processors or processing units 504, a system memory 506,"))
and program instructions stored by the memory and executable by the one or more processors to perform operations comprising: configuring a blockchain framework, the blockchain framework comprising: a master data asset ledger; (Batra Par. (0050) "a computer program may reside in random access memory ("RAM"), flash memory, read-only memory ("ROM")")) (Par. (0051) "An exemplary storage medium may be coupled to the processor such that the processor may read information from, and write information to, the storage medium.")) (Par. (0023) "The ledger is a sequenced, tamper-resistant record of all state transitions of the blockchain."))
and a plurality of peer nodes; (Batra Par. (0022) "Another type of node is a peer node which receives client submitted transactions, commits the transactions and maintains the state and a copy of the ledger.")
wherein the master data asset ledger is configured to autonomously maintain current values of a set of ledger states, [the master data asset ledger comprising object codes that overlay a coordination protocol of the plurality of peer nodes], and wherein the plurality of peer nodes is collectively configured to maintain distributed ledger copies with a set of shared smart contracts applicable to one or more predetermined events to provide trust control across [virtual services]; (Batra Par. (0023) "State transitions are a result of chaincode invocations (i.e., transactions) submitted by participating parties… Each peer node maintains a copy of the ledger for each channel of which they are a member.")) (Par. (0025) "The current state of the immutable ledger represents the latest values for all keys that are included in the chain transaction log.")) (Par. (0036) "chain code and/or smart contracts… are created according to the customized configuration sought by the participants and can maintain their own state, control its own assets, and receive external information. This code can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain peer nodes.")) (Par. (0030) "a smart contract may be configured to have a published 'private', 'protected' and/or 'public' event(s)… This enables an event-subscription based collaboration and orchestration among smart contracts"))
Batra does not teach; the master data asset ledger comprising object codes that overlay a coordination protocol of the plurality of peer nodes… to provide trust control across virtual services;
However, Krishnaswamy teaches; the master data asset ledger comprising object codes that overlay a coordination protocol of the plurality of peer nodes… to provide trust control across virtual services; (Krishnaswamy Par. (71) "The PRM may configure the policies associated with processing of the consensus protocol, and the nature of the consensus protocol, in a policy database in the vDLT network. Subsequently, policies associated with transactions (such as interactions with any external or other participating entities for endorsements) may be programmed into a policy database at the SCS within a vDLT node.")) (Par. (68) "Smart contracts may be invoked as Smart Contract Execution (SCE) microservices on the vDLT platform")) (Par. (70) "within each vDLT node, the system may further configure policies associated with smart contract processing, which can include interactions with external systems to obtain endorsements for the execution of the smart contract in the vDLT node.")) (Par. (45) "a blockchain-DLT platform 200 is a microservices-based configurable vDLT platform"))
(Examiner's Note: The virtual DLT (vDLT) is interpreted as virtual services)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy because blockchain technology uses tools from cryptology and data security, for example, in terms of message authentication targeted towards tamper-evidence and tamper-resilience. A blockchain may be described as a tamper-evident ledger shared within a network of entities, where the ledger holds a record of transactions of assets between the entities. [Krishnaswamy, para.13]. This motivation applies to the remainder of the claim.
Batra further teaches: providing, through each smart contract of the set of shared smart contracts, service level access to the blockchain framework to facilitate coordinated node-based core operations and trust data asset management of the master data asset ledger and the plurality of peer nodes in accordance with the coordination protocol, the coordinated node-based core operations and trust data asset management comprising (i) obtaining endorsement of one or more transactions through peer consensus of the plurality of peer nodes, and (ii) [instructing one or more peer nodes of the plurality of peer nodes to apply a trust control maintained by the master data asset ledger], the trust control being based on the endorsement of the one or more transactions; (Batra Par. (0021) "Transactions typically must be "endorsed" and only endorsed transactions may be committed and have an effect on the state of the blockchain system.")) (Par. (0042) "the application determines if the specified endorsement policy has been fulfilled before submitting (i.e., did peer nodes necessary for the transaction both endorse).")) (Par. (0044) "the blocks of the transaction are delivered from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions within the block are validated to ensure endorsement policy is fulfilled… each peer node 281-283 appends the block to the channel's chain, and for each valid transaction the write sets are committed to current state database."))
Batra does not teach: instructing one or more peer nodes of the plurality of peer nodes to apply a trust control maintained by the master data asset ledger;
However, Krishnaswamy teaches; instructing one or more peer nodes of the plurality of peer nodes to apply a trust control maintained by the master data asset ledger; (Krishnaswamy Par. (74) "When a transaction request is submitted to a DLT network, the policy database at the DLT network may be queried to determine the vDLT nodes that will participate in the consensus protocol, and to determine the consensus protocol to use across the vDLT nodes. Subsequently, within each vDLT node, the policy database at the SCS may be queried to assist in the execution of the smart contract (such as determining any entities that need to endorse the transaction).")) (Par. (75) "Subsequently the TRM can record the transaction in the local ledger database at the vDLT node."))
Claim 4. Batra in view of Krishnaswamy discloses The computing system according to claim 1, wherein the program instructions are further executable by the one or more processors to facilitate maintenance of the master data asset ledger, wherein the maintenance includes active participation of the plurality of peer nodes to render one or more data assets to be entered to the master data asset ledger; (Batra Par. (0042) "the application determines if the specified endorsement policy has been fulfilled before submitting (i.e., did peer nodes necessary for the transaction both endorse).")) (Par. (0044) "the blocks of the transaction are delivered from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions within the block are validated to ensure endorsement policy is fulfilled… each peer node 281-283 appends the block to the channel's chain, and for each valid transaction the write sets are committed to current state database."))
Claim 8. Batra in view of Krishnaswamy discloses The computing system according to claim 1, wherein the object codes comprise smart contracts that are triggered by events and executed collectively by the plurality of peer nodes; (Batra Par. (0036) "'peer nodes' 281-284, which participate in the blockchain transaction addition and validation process (consensus)… chain code and/or smart contracts… are created according to the customized configuration sought by the participants and can maintain their own state, control its own assets, and receive external information. This code can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain peer nodes.")) (Par. (0030) "a smart contract may be configured to have a published 'private', 'protected' and/or 'public' event(s)… This enables an event-subscription based collaboration and orchestration among smart contracts"))
Claim 18 is similar to claim 1, therefore it is rejected for the same reasons.
Claims 2 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Batra in view of Krishnaswamy, and further in view of Oberhofer et al. (US Pat.No.11822543), Ramathal et al. (US Pat.No.9998286), and Ponzio (US Pat.No.7162450).
Claim 2. Batra in view of Krishnaswamy discloses the features of claim 1. Batra in view of Krishnaswamy does not teach, wherein the program instructions are further executable by the one or more processors to facilitate maintenance of the master data asset ledger, wherein the maintenance includes: passive rendering of one or more data assets to be entered to the master data asset ledger;
However, Oberhofer teaches; passive rendering of one or more data assets to be entered to the master data asset ledger; (Oberhofer Par. (65) "Computer device 100 communicates with one or more source systems 520 through, in this example, cloud computing environment 50. In embodiments, source systems 520 are databases or other sources of data from which computer device 100 receives source records from which MDM system 200 extracts data for use in the creation of a composite view.")) (Par. (100) "MDM system 200, through record API 260, receives the first data used in step 1205. In embodiments, the first data is part of a first data record from a customer database. At step 1215, MDM system 200, through record API 260, receives the second data used in step 1205. In embodiments, the second data is part of a second data record from a third-party subscription service that contains credit history data."))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy in further view of Oberhofer because the computer device creates the composite view from the first data and the second data based on the composite view rules. The computer device physically materializes the composite view on a storage device, preserves the first data record, and preserves the second data record. [Oberhofer, para.8]
Oberhofer does not teach; assessing any changes to the current values of the set of ledger states;
However, Ramathal teaches: assessing any changes to the current values of the set of ledger states; (Ramathal Par. (27) "Based on the updated data, the consensus logic 170 may reconcile the updated data with previously posted data from the blockchain 199 (212). For example, the blockchain 199 may include earlier accumulated values that are affected by the new data provided."))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy in further view of Ramathal because when multiple nodes coordinate to place entries in a record, the parties represented by the multiple nodes may be dependent on other nodes following the consensus operating procedure or terms when creating entries in the record. For example, a consensus operating procedure may include a procedure enforced through a blockchain consensus mechanism. [Ramathal, para.13]. This motivation applies to the remainder of the claim.
Batra in view of Krishnaswamy and Oberhofer does not teach: determining that the one or more data assets include a newly composed data asset that is distinct from the current values of the set of ledger states and based thereon validating content quality and verifying relational integrity of the newly composed data asset to confirm a new value;
However, Ponzio teaches; determining that the one or more data assets include a newly composed data asset that is distinct from the current values of the set of ledger states and based thereon validating content quality and verifying relational integrity of the newly composed data asset to confirm a new value; (Ponzio Par. (10) "The present invention is a business method for determining quality of content of data for a receiver of the data. The business method comprising the following steps: assessing the content of the data using criteria corresponding to a business; assigning a grade as a function of the criteria, the grade indicative of the quality of the content of the data;")) (Par. (112) "The Level IV checks will validate field-to-field relationship within a record. (Ex.--If one field has a specific value, then another field can only have a specified set of values.)")) (Par. (113) "Level V checks will validate the field-to-field relationships in/between different records in the same file."))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy in further view of Ponzio because there is a need to be able to provide controlled inspection, monitoring and analysis of data to provide knowledge about its quality and integrity as the data is shipped between various computer systems and computer networks. [Ponzio, para.8]
Ramathal further discloses; and providing a new data asset entry to the master data asset ledger that modifies a current value of the current values of the set of ledger states with the new value, the providing including removing the current value and validating entry of the new value; (Ramathal Par. (27) "When the consensus logic 170 completes the consensus operating procedure, the consensus logic 170 may generate a block containing the updated data (214)."))
Claim 19 is rejected for the same reason as claim 2.
Claims 3 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Batra in view of Krishnaswamy, and further in view of Oberhofer, Ramathal, and Boothby (US Pat.No.6212529).
Claim 3. Batra in view of Krishnaswamy discloses the features of claim 1. Batra in view of Krishnaswamy does not teach, wherein the program instructions are further executable by the one or more processors to facilitate maintenance of the master data asset ledger, wherein the maintenance includes: passive rendering of one or more data assets [to be entered to the master data asset ledger];
However, Oberhofer teaches; wherein the program instructions are further executable by the one or more processors to facilitate maintenance of the master data asset ledger, wherein the maintenance includes: passive rendering of one or more data assets; (Oberhofer Par. (65) "Computer device 100 communicates with one or more source systems 520 through, in this example, cloud computing environment 50. In embodiments, source systems 520 are databases or other sources of data from which computer device 100 receives source records from which MDM system 200 extracts data for use in the creation of a composite view."))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy in further view of Oberhofer because the computer device creates the composite view from the first data and the second data based on the composite view rules. The computer device physically materializes the composite view on a storage device, preserves the first data record, and preserves the second data record. [Oberhofer, para.8]. This motivation applies to the remainder of the claim.
Oberhofer does not teach; to be entered to the master data asset ledger;
However, Batra teaches; to be entered to the master data asset ledger; (Batra Par. (0023) "The ledger is a sequenced, tamper-resistant record of all state transitions of the blockchain.")
Oberhofer does not teach; assessing any changes to the current values of the set of ledger states;
However, Ramathal teaches; assessing any changes to the current values of the set of ledger states; (Ramathal Par. (27) "Based on the updated data, the consensus logic 170 may reconcile the updated data with previously posted data from the blockchain 199 (212). For example, the blockchain 199 may include earlier accumulated values that are affected by the new data provided.")
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view Krishnaswamy in further view of Ramathal because when multiple nodes coordinate to place entries in a record, the parties represented by the multiple nodes may be dependent on other nodes following the consensus operating procedure or terms when creating entries in the record. For example, a consensus operating procedure may include a procedure enforced through a blockchain consensus mechanism. [Ramathal, para.13]
Oberhofer does not teach; and determining that the one or more data assets are unchanged from the current values of the set of ledger states and based thereon dropping the one or more data assets to be entered without providing a new data asset entry to the master data asset ledger;
However, Boothby teaches; and determining that the one or more data assets are unchanged from the current values of the set of ledger states and based thereon dropping the one or more data assets to be entered without providing a new data asset entry to the master data asset ledger; (Boothby Par. (78) "For each CIG (step 351), synchronizer 15 then compares the records in the CIG to one another, determines their differences, and decides what synchronization action should be taken (step 352) … Synchronization actions with respect to a record include updating, deleting, adding, or not modifying that record."))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy in further view of Boothby because database managers organize the information in a database into records, with each record made up of fields. Fields and records of a database may have many different characteristics depending on the database manager's purpose and utility. [Boothby, para.7]
Claim 20 is rejected for the same reason as claim 3.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Batra in view of Krishnaswamy, and further in view of Ventura et al. (US Pat.No.10789239).
Claim 5. Batra in view of Krishnaswamy discloses the features of claim 1. Batra in view of Krishnaswamy does not explicitly teach The computing system according to claim 1, wherein the master data asset ledger and the plurality of peer nodes each comprise a plurality of layers, wherein the plurality of layers is selected from the group consisting of an access layer, a network layer, a service layer, and a data layer;
However, Ventura teaches; wherein the master data asset ledger and the plurality of peer nodes each comprise a plurality of layers, wherein the plurality of layers is selected from the group consisting of an access layer, a network layer, a service layer, and a data layer; (Ventura Par. (4) "a node computing entity of the plurality of node computing entities and comprising at least one processor, a memory, and a communications interface configured to communicate via at least one network") (Par. (56) "the framework layer 500 provides infrastructure and support services to the application layer 400 and abstracts the file system, distributed ledger network 100, and internode messaging capabilities of the protocol layer 600. For example, the framework layer acts as an intermediary between the services and operations of the applications 402 and the FSM record blocks stored in the ledger.")) (Par. (57) "the framework layer 500 comprises a user manager 502. In an example embodiment, the user manager 502 provides a mechanism for managing (within the memory of the node computing entities 200, 200′) the persistence of user information/data and keys.")) (Par. (55) "The protocol layer 600 may further comprise a local file storage 606. The local file storage 606 may comprise one or more data structures stored locally by a node computing entity 200, 200′… one or more ledger files corresponding to the distributed ledger."))
(Examiner's Note: The communications interface is interpreted as a network layer, the framework layer is interpreted as the service layer, the user manager within the framework layer is interpreted as the access layer, and the protocol layer is interpreted as the data layer)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy in further view of Ventura because The FSM records may further provide intrinsic bi-temporal primitives. For example, a current status of a domain object and a status of the domain object at a particular point in time may be easily determined based on the FSM records. [Ventura, para.22]
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Batra in view of Krishnaswamy, and further in view of Ryan et al. (US Pub.No.2009/0164943).
Claim 6. Batra in view of Krishnaswamy discloses the features of claim 1. Batra in view of Krishnaswamy discloses wherein the program instructions are further executable to define the coordination protocol (Batra Par. (0024) "The ordering-service-node or orderer is a node running the communication service for all nodes and which implements a delivery guarantee, such as atomic or total order broadcast to each of the peer nodes in the system when committing transactions and modifying the world state.")
Batra does not teach; with business rules indicating pattern, model and schema;
However, Ryan teaches; with business rules indicating pattern, model and schema; (Ryan Par. (0004) "Master Data Management.TM. is the process and framework for maintaining a series of business rules and process workflows that will manage this data as it feeds in from multiple sources. Master Data Management.TM. then applies these business rules and process workflows to produce "master" data, which is then fed to all consuming business processes.")) (Par. (0016) "Master data (sometimes referred to as reference data) are facts that define a business entity, facts that may be used to model one or more definitions or view of an entity")) (Par. (0005) "Core to the management of master data is the definition of a data model. The data model serves as the foundation for all business rules and workflow processes within the Master Data Management.TM. framework.")) (Par. (0062) "a schema is selected by selecting a single database, from the selected source, from which tables will be imported into the existing model."))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy in further view of Ryan because entity definitions based on master data provide business consistency and data integrity when multiple systems across an organization (or beyond) identify the same entity differently (e.g., in differing data models). [Ryan, para.0016]
Claims 7 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Batra in view of Krishnaswamy, and further in view of Blankstein et al. (US Pat.No.10880076).
Claim 7. Batra in view of Krishnaswamy discloses the features of claim 1. Batra in view of Krishnaswamy discloses does not teach wherein the set of ledger states comprise records of decentralized applications;
However Blankstein teaches wherein the set of ledger states comprise records of decentralized applications; (Blankstein Par. (13) "Blockchains are decentralized digital ledgers that record information distributed among a network of computers.")) (Par. (19) "New operations are defined in the virtual blockchain layer and are encoded in the metadata of valid blockchain transactions. Accordingly, the underlying blockchain nodes receive and store information about the virtual blockchain transactions")) (Par. (21) "Such a platform can be implemented, for example, for supporting decentralized applications or "DApps.""))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy in further view of Blankstein because blockchain is a distributed digital ledger that allows multiple parties to engage in secure, trusted transactions with one another without an intermediary. The blockchain itself can include a chain of blocks that are linked together cryptographically, with each block in the chain storing one or more transactions and the number of blocks in the chain growing over time. [Blankstein, para.2]
Claim 9. Batra in view of Krishnaswamy discloses the features of claim 1. Batra in view of Krishnaswamy discloses wherein the blockchain framework is further configured to be implemented across a multiparty business network (Batra Par. (0003) "In a workflow involving multiple organizations, there is no single system or entity that can manage and control the entire workflow processes, end-to-end, in general."))
Batra does not teach; incorporating decentralized applications
However, Blankstein teaches; incorporating decentralized applications; (Blankstein Par. (21) "Such a platform can be implemented, for example, for supporting decentralized applications or "DApps.""))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy in further view of Blankstein because blockchain is a distributed digital ledger that allows multiple parties to engage in secure, trusted transactions with one another without an intermediary. The blockchain itself can include a chain of blocks that are linked together cryptographically, with each block in the chain storing one or more transactions and the number of blocks in the chain growing over time. [Blankstein, para.2]
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Batra in view of Krishnaswamy, and further in view of Filipek et al. (US Pat.No.11683173).
Claim 10. Batra in view of Krishnaswamy discloses the features of claim 1. Batra in view of Krishnaswamy discloses The computing system according to claim 1, wherein the endorsement of one or more transactions through peer consensus of the plurality of peer nodes [comprises algorithmic trust control] using a set of state transition events stored as blocks within the blockchain framework; (Batra Par. (0021) "Transactions typically must be "endorsed" and only endorsed transactions may be committed and have an effect on the state of the blockchain system.")) (Par. (0042) "the application determines if the specified endorsement policy has been fulfilled before submitting (i.e., did peer nodes necessary for the transaction both endorse).")) (Par. (0023) "State transitions are a result of chaincode invocations (i.e., transactions) submitted by participating parties… The ledger includes a blockchain (also referred to as a chain) which is used to store an immutable, sequenced record in blocks."))
Batra does not teach; comprises algorithmic trust control
However, Filipek teaches; comprises algorithmic trust control; (Filipek Par. (18) "the peers may execute a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks")
(Examiner's Note: The distributed consensus protocol is interpreted as algorithmic trust control)
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy in further view of Filipek each peer maintains a copy of the database records and no single peer can modify the database records without a consensus being reached among the distributed peers. [Filipek, para.18]
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Batra in view of Krishnaswamy, and further in view of Bhamidipati et al. (US Pub.No.2021/0019740).
Claim 11. Batra in view of Krishnaswamy discloses the features of claim 1. Batra in view of Krishnaswamy does not teach wherein the trust control comprises a centralized authoritative trust control.
However, Bhamidipati teaches; wherein the trust control comprises a centralized authoritative trust control; (Bhamidipati Par. (0159) "the validation or authorization process for blocks on the ledger is determined by a centralized control of a cluster of trusted nodes. In this case, the centralized control may be a trusted node, such as Certificate Authority 110, authorized to attest and sign the transaction blocks to validate them and validation by miners may not be needed."))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy in further view of Bhamidipati because the blockchain ledger may be different from a conventional blockchain in that there is a centralized clearing house, e.g. authorized central control for validation. [Bhamidipati, para.0167]
Claim 12 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Batra and further in view of Swarnam et al. (US Pub.No.2021/0183480), Blankstein, and Knuhtsen et al. (US Pub.No.2021/0083844).
Claim 12. Batra discloses A computing system incorporating blockchain framework configuration for trust control for node-based core operations and trust data asset management, the computing system comprising: one or more processors in communication with a memory; (Batra Par. (0055) "computer system/server 502 may include, but are not limited to, one or more processors or processing units 504, a system memory 506, and a bus that couples various system components including system memory 506 to processor 504."))
Batra does not teach; and program instructions stored by the memory and executable by the one or more processors to perform operations comprising: configuring a computing network comprising a partially decentralized blockchain framework, wherein the blockchain framework comprises a plurality of peer nodes configured with dedicated services to collectively execute a set of trust protocols to endorse disposition of a transaction in a centrally maintained master ledger;
However, Swarnam teaches: and program instructions stored by the memory and executable by the one or more processors to perform operations comprising: configuring a computing network comprising a partially decentralized blockchain framework, wherein the blockchain framework comprises a plurality of peer nodes configured with dedicated services to collectively execute a set of trust protocols to endorse disposition of a transaction in a centrally maintained master ledger; (Swarnam Par. (0041) "The endorsements are collected as transactions and packaged into the transaction blocks 156 by the orderer nodes 154. The transaction blocks 156 are distributed back to the peer nodes 126 that share the same ledger"))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in further view of Swarnam because blockchain also can be used to maintain digital assets, such as stocks, bonds, land titles, and the like. Stored transactions record the transfer of assets between users. Blockchain can store data and documents, either in full or merely a digest of the data (e.g., a cryptographic hash like SHA-256), to provide evidence of the existence of data or documents, such as contracts, patents, scientific publications, deeds, insurance policies, and the like. [Swarnam, para.0002]
Swarnam does not teach; that is configured to store data asset records of decentralized applications
However, Blankstein teaches; that is configured to store data asset records of decentralized applications; (Blankstein Par. (21) "Such a platform can be implemented, for example, for supporting decentralized applications or "DApps.""))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in further view of Blankstein because blockchain is a distributed digital ledger that allows multiple parties to engage in secure, trusted transactions with one another without an intermediary. The blockchain itself can include a chain of blocks that are linked together cryptographically, with each block in the chain storing one or more transactions and the number of blocks in the chain growing over time. [Blankstein, para.2]
Batra does not teach; providing, through each network node, service level access to one or more computing devices... via federated nodes of the blockchain framework
However, Knuhtsen teaches; providing, through each network node, service level access to one or more computing devices... via federated nodes of the blockchain framework; (Knuhtsen Par. (0040) "The federated blockchain network continues to persist as long as a user pays the usage rates to the intermediary entity providing the federated blockchain service.")) (Par. (0041) "a user device, at 271, providing selected (trusted) CSPs to provide portions of the federated blockchain network then executing and transmitting the master-slave agreement for each selected CSP to the access node."))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in further view of Knuhtsen because public blockchain networks have a decentralized architecture that allow for performing secured transactions in which any number of users can utilize. In contrast, private blockchain networks regulate access by providing permission to select users to utilize the private blockchain. [Knuhtsen, para.0002].
Batra teaches: the access connecting the one or more computing devices to the configured peer-to-peer computing network to facilitate coordinated node-based core operations and trust data asset management (Batra Par. (0022) “Another type of node is a peer node which receives client submitted transactions, commits the transactions and maintains the state and a copy of the ledger.”)) (Par. (0044) “the blocks of the transaction are delivered from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions within the block are validated to ensure endorsement policy is fulfilled… each peer node 281-283 appends the block to the channel's chain, and for each valid transaction the write sets are committed to current state database.”))
Claim 15. Batra discloses the features of claim 12. Batra further discloses, wherein the blockchain framework further comprises the master data ledger, and wherein the master ledger is further configured to store smart contracts comprising object codes, the smart contracts being executable by one or more nodes of the plurality of peer nodes; (Batra Par. (0023) "The ledger is a sequenced, tamper-resistant record of all state transitions of the blockchain.")) (Par. (0036) "chain code and/or smart contracts… are created according to the customized configuration sought by the participants and can maintain their own state, control its own assets, and receive external information. This code can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain peer nodes.")) (Par. (0021) "Transactions are operations invoked on the chaincode.")) (Par. (0036) "'peer nodes' 281-284, which participate in the blockchain transaction addition and validation process (consensus)."))
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Batra in view of Swarnam, Blankstein, and Knuhtsen, and further in view of Liao et al. (US Pat.No.10664451).
Claim 13. Batra discloses the features of claim 12. Batra discloses, wherein the computing network further comprises [a plurality of decentralized multiparty applications] that are interconnected via the plurality of peer nodes of the blockchain framework; (Batra Par. (0023) "Each peer node maintains a copy of the ledger for each channel of which they are a member.")) (Par. (0036) "This code can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain peer nodes."))
Batra does not teach; a plurality of decentralized multiparty applications
However, Liao teaches; a plurality of decentralized multiparty applications; (Liao Par. (2) "Blockchain is a distributed digital ledger that allows multiple parties to engage in secure, trusted transactions with one another without an intermediary.")) (Par. (10) "FIG. 9 provides a storage routine for storing data in a data cache that is accessible by multiple decentralized applications."))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in further view of Liao because blockchain is a distributed digital ledger that allows multiple parties to engage in secure, trusted transactions with one another without an intermediary. The blockchain itself can include a chain of blocks that are linked together cryptographically, with each block in the chain storing one or more transactions and the number of blocks in the chain growing over time. [Liao, para.2]
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Batra in view of Swarnam, Blankstein, and Knuhtsen, and further in view of Hazlewood et al. (US Pat.No.9298729)
Claim 14. Batra discloses the features of claim 12. Batra does not teach, wherein the computing network further comprises a strategic master data platform for managing master data of the master ledger;
However, Hazlewood teaches; wherein the computing network further comprises a strategic master data platform for managing master data of the master ledger; (Hazlewood Par. (4) "Master Data Management (MDM) hubs have provided two approaches for the management of master data.")) (Par. (7) "the growth and adoption of master data management techniques in support of the data governance strategies within an enterprise."))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in further view of Hazlewood because it provides a system for managing data within a plurality of data management architectures [Hazlewood, para.4]
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Batra in view of Swarnam, Blankstein, and Knuhtsen, and further in view of Sankaran et al. (US Pat.No.11468390) and Bhadmidipati.
Claim 16. Batra discloses the features of claim 12. Batra does not teach, wherein the set of trust protocols comprise decentralized algorithmic system controls and centralized authoritative governance controls;
However, Sankaran teaches; wherein the set of trust protocols comprise decentralized algorithmic system controls (Sankaran Par. (129) "Alternatively, the policy may provide for validation process decided by a decentralized cluster of untrusted nodes. In the situation where the blockchain ledger is distributed to a cluster of untrusted nodes, mining of blocks in the chain may be employed to validate the blockchain ledger.")) (Par. (130) "Blockchains may use various time-stamping schemes, such as proof-of-work, to serialize changes. Alternate consensus methods include proof-of-stake, proof-of-burn, proof-of-research may also be utilized to serialize changes."))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in further view of Sankaran because the secure, distributed and immutable nature of the blockchain allows a shipping agent involved in the shipping process to access an accurate record of the shipping information. [Sankaran, para.27]
Sankaran does not teach; and centralized authoritative governance controls.
However, Bhamidipati teaches; and centralized authoritative governance controls (Bhamidpati Par. (0159) “the validation or authorization process for blocks on the ledger is determined by a centralized control of a cluster of trusted nodes. In this case, the centralized control may be a trusted node, such as Certificate Authority 110, authorized to attest and sign the transaction blocks to validate them and validation by miners may not be needed.”))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in view of Krishnaswamy in further view of Bhamidipati because the blockchain ledger may be different from a conventional blockchain in that there is a centralized clearing house, e.g. authorized central control for validation. [Bhamidipati, para.0167]
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Batra in view of Swarnam, Blankstein, Knuhtsen, Sankaran, Bhamidpati, and further in view of Kursun et al. (US Pat.No.11176101).
Claim 17. Batra discloses the features of claim 16. Batra in view of Krishnaswamy does not teach, wherein the centralized authoritative governance controls rely on a controller to instruct lower-level nodes within the blockchain framework;
However, Kursun teaches; wherein the centralized authoritative governance controls rely on a controller to instruct lower-level nodes within the blockchain framework; (Kursun Par. (69) "the system further comprises a controller or regulator node architecture and regulatory contract process that manages not only content of the chains, but also health, privacy, security, energy efficiency, immutability and other characteristics.")) (Par. (68) "the central regulatory authority 608 may receive reports on chain health and compliance and also transmit regulation instructions back to the regulatory nodes 606 for execution of one or more control decisions or actions."))
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Batra in further view of Kursun because the regulation of block chains presents unique challenges with regards to scalability, processing speed, and data security. As a result, there exists a need for a new block chain regulatory architecture that overcomes the challenges of the conventional regulatory methods. [Kursun, para.1].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDULLAHI MOHAMED ABDULLAHI whose telephone number is (571)272-9615. The examiner can normally be reached 7:30 - 5:00.
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, Ali Shayanfar can be reached at (571) 270-1050. 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.
/ABDULLAHI MOHAMED ABDULLAHI/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights