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
1. This action is responsive to: an original application filed on 30 June 2025.
2. Claims 1-20 are currently pending and rejected.
Priority
3. Priority date claimed from parent application has been noted.
Drawings
4. The drawings filed on 30 June 2025 are accepted by the examiner.
Double Patenting
5. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents /process/ file/efs/guidance /eTD-info-I.jsp.
Claims 1-20 are rejected under the grounds of non-statutory obviousness-type double patenting, as they are deemed unpatentable over claims 1-20 of US Patent application No. 18170663.
Although the conflicting claims are not identical, they are considered not patentably distinct from one another, as they convey the same inventive concept. Specifically, both sets of claims disclose a method for ACCESS LAYER SYSTEMS OF PEER DATA PROCESSING NODES PROVIDING A SECURITY FRAMEWORK AND TRUST CONTROLS USING RBAC MODEL. Furthermore, it would have been obvious to one of ordinary skill in the art, at the time of the invention’s filing, to employ this approach to prevent and protect data from unwanted user, thereby rendering the claims unpatentable.
Claim Rejections - 35 USC § 103
6. 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.
Claims 1-20 are rejected under 35 U.S.C §103 as being unpatentable over Kucherov et al. (US Publication No. 20230069247), hereinafter Kucherov and in view of Padmanabhan et al. (US Publication No. 20200374106), hereinafter Padmanabhan.
Regarding claim 1:
A blockchain computing platform, comprising: one or more virtual machines configured and deployed to execute an operating system of the blockchain computing platform across a virtual network, the virtual network including a master ledger that stores data asset records for master data received from decentralized application transactions performed by peer nodes, the decentralized application transactions including business transactions (Haque, ¶17-18), wherein Using the master ledger may allow for the network service to implement distributed ledgers for a plurality of users as part of a service, such as a content service, a premises management service, and/or the like. A plurality of master ledgers may be stored for users as part of the network service. The plurality of master ledgers may be stored in a network ledger (e.g., managed and/or stored by the network service). The network ledger may comprise data blocks for a plurality of master ledgers associated with different accounts. The data blocks associated with a specific account stored in the network ledger may be a master ledger for the specific account.
Haque does not explicitly suggest, and a plurality of interconnected data processing nodes each comprising a plurality of functional layers, wherein the plurality of functional layers comprise an identity management access layer that is configured to establish a blockchain computing function defining (a) role-based access control (RBAC) policies for access to master data management blockchain services, and (b) attribute-based access control (ABAC) time-based rules restricting access to portions of the master data; however in a same field of endeavor Padmanabhan teaches this limitation (Padmanabhan, ¶544, ¶92), wherein access control and consensus on read processed described herein. The use case enables the definition of permission rules also referred to as policies. In the context of a distributed enterprise platform, both role based and attribute based control can be implemented. Role based control defines the access rights of a user and the attribute-based control extends access rights to attributes such as properties of a resource, entities and the execution environment. The access controls can be divided into entity level and record level access in combination with blockchain. The entity level access is similar to a object or field level control that allows a set of defined users or partners to access an entity in a blockchain as well as associated fields. A record level access can be similar to sharing settings in other platforms that allow access to the record based on permission defined by the record owner.
and an availability management network layer that provides authoritative flows, facilitated via the master ledger, and algorithmic flows, facilitate by other nodes of the plurality of interconnected data processing nodes, that incorporate validation and verification for tracking and optimizing a plurality of data processes performed via the plurality of interconnected data processing nodes (Haque, ¶18, ¶30), wherein The one or more ledger nodes 102 (e.g., miners) may be configured to generate data blocks based on a ledger process (e.g., blockchain process, mining process, linking process). A data block may be added to a master ledger if the master ledger is determined to be valid. As described further herein, the one or more ledger nodes 102 may validate each data block to determine that the ledger is valid. If the data is valid, the one or more ledger nodes 102 may perform the ledger process.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of ledger distribution of Haque with the role and attribute access control disclosed in Padmanabhan to enforces the defined metadata, any transaction which fails compliance is either prohibited from being transacted onto the blockchain or if written to the blockchain, the transaction will never be accepted into a block on the main chain as the smart contract validation failure will prevent the transaction from reaching consensus for acceptance. stated by Padmanabhan at para.473.
Regarding claim 2:
wherein the blockchain computing platform is configured to aggregate virtual computing results in master data across the virtual network (Haque, ¶25).
Regarding claim 3:
wherein the portions of the master data comprise secure private data (Haque, ¶30).
Regarding claim 4:
wherein the portions of the master data comprise sensitive documents that are accepted by the blockchain computing platform and stored in blocks of the blockchain computing platform with user consent (Haque, ¶39).
Regarding claim 5:
wherein the plurality of functional layers further comprises a security framework configured to provide authentication, authorization and accounting functionalities (Haque, ¶69).
Regarding claim 6:
wherein the plurality of functional layers further comprises a security framework that controls access to processing node resources by using an active directory of user identifications and certificate authority certificates to identify and grant access to the processing node resources (Haque, ¶72).
Regarding claim 7:
wherein the virtual network is configured with business rules that overlay the virtual network and comprise policies and usage rules (Haque, ¶128).
Regarding claim 8:
wherein the plurality of functional layers further comprise an availability management network layer, an asset management service layer, and a storage management data layer (Haque, ¶85).
Regarding claim 9:
one or more virtual machines configured and deployed to execute an operating system of a blockchain computing platform across a virtual network, the virtual network including a master ledger that stores data asset records for master data received from decentralized application transactions performed by peer nodes, the decentralized application transactions including business transactions (Haque, abstract, ¶16), wherein The distributed ledger may be used for managing permissions and other settings at a premises. The distributed ledger may comprise a plurality of versions of the distributed ledger stored at different locations and/or stored by different devices. The distributed ledger may comprise a master ledger and one or more device ledgers. The master ledger may be a version of a distributed ledger stored by a network service. The one or more device ledgers may be versions of the distributed ledger that are stored by one or more premises device, such as Internet of Things (IoT) devices, security devices, automation devices, and/or the like. The master ledger may be used as a master version of the distributed ledger for adding data blocks to the distributed ledger. The master ledger may be stored in a network location external to premises at which device ledgers are located. If a data block is added to the master ledger, any corresponding device ledger may be updated by retrieving a new copy of the master ledger or by adding any additional data blocks added to the master ledger.
Haque does not explicitly suggest, and a plurality of interconnected data processing nodes each comprising a plurality of functional layers, wherein the plurality of functional layers comprise an identity management access layer that is configured to establish a blockchain computing function defining (a) role-based access control (RBAC) policies for access to master data management blockchain services, and (b) attribute-based access control (ABAC) time-based rules restricting access to portions of the master data; however in a same field of endeavor Padmanabhan teaches this limitation (Padmanabhan, ¶544, ¶92), wherein access control and consensus on read processed described herein. The use case enables the definition of permission rules also referred to as policies. In the context of a distributed enterprise platform, both role based and attribute based control can be implemented. Role based control defines the access rights of a user and the attribute based control extends access rights to attributes such as properties of a resource, entities and the execution environment. The access controls can be divided into entity level and record level access in combination with blockchain. The entity level access is similar to a object or field level control that allows a set of defined users or partners to access an entity in a blockchain as well as associated fields. A record level access can be similar to sharing settings in other platforms that allow access to the record based on permission defined by the record owner.
and an availability management network layer that provides authoritative flows, facilitated via the master ledger, and algorithmic flows, facilitate by other nodes of the plurality of interconnected data processing nodes, that incorporate validation and verification for tracking and optimizing a plurality of data processes performed via the plurality of interconnected data processing nodes (Haque, ¶18, ¶30), wherein The one or more ledger nodes 102 (e.g., miners) may be configured to generate data blocks based on a ledger process (e.g., blockchain process, mining process, linking process). A data block may be added to a master ledger if the master ledger is determined to be valid. As described further herein, the one or more ledger nodes 102 may validate each data block to determine that the ledger is valid. If the data is valid, the one or more ledger nodes 102 may perform the ledger process.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of ledger distribution of Haque with the role and attribute access control disclosed in Padmanabhan to enforces the defined metadata, any transaction which fails compliance is either prohibited from being transacted onto the blockchain or if written to the blockchain, the transaction will never be accepted into a block on the main chain as the smart contract validation failure will prevent the transaction from reaching consensus for acceptance. stated by Padmanabhan at para.473.
Regarding claim 10:
wherein the access is provided based on using enterprise message queue interfaces and based on synchronizing data stored to blocks of the blockchain computing platform (Haque, ¶22).
Regarding claim 11:
wherein processing node resources are distributed across the virtual network (Haque, ¶25).
Regarding claim 12:
Haque does not explicitly suggest, wherein the access is provided based on using open and orchestrated communications that comprise multiple levels of trust control channel messaging; however, in a same field of endeavor Padmanabhan teaches this limitation (Padmanabhan, ¶545, ¶88).
Same motivation for combining the respective features of Haque and Padmanabhan applies herein, as discussed in the rejection of claim 9.
Regarding claim 13:
Haque does not explicitly suggest, wherein the multiple levels of trust control channel messaging comprise two levels of trust control channel messaging comprising a decentralized control system and a centralized control system; however, in a same field of endeavor Padmanabhan teaches this limitation (Padmanabhan, ¶545, ¶88).
Same motivation for combining the respective features of Haque and Padmanabhan applies herein, as discussed in the rejection of claim 9.
Regarding claim 14:
wherein the decentralized control system comprises at least some of the plurality of interconnected data processing nodes and is configured to rely on distributed control incorporating lower-level components operating on local information (Haque, ¶38).
Regarding claim 15:
wherein each component of the lower-level components is provided equal responsibility for contributing to one or more system objectives in accordance with algorithmic trust controls (Haque, ¶80).
Regarding claim 16:
Haque does not explicitly suggest, wherein the algorithmic trust controls comprise consensus-based trust controls in accordance with a consensus of each component of the lower-level components; however, in a same field of endeavor Padmanabhan teaches this limitation (Padmanabhan, ¶102).
Same motivation for combining the respective features of Haque and Padmanabhan applies herein, as discussed in the rejection of claim 9.
Regarding claim 17:
Haque does not explicitly suggest, wherein the centralized control system comprises at least some of the plurality of interconnected data processing nodes and comprises a controller configured to instruct components through a hierarchy of entities however, in a same field of endeavor Padmanabhan teaches this limitation (Padmanabhan, ¶706).
Same motivation for combining the respective features of Haque and Padmanabhan applies herein, as discussed in the rejection of claim 9.
Regarding claim 18:
Haque does not explicitly suggest, wherein each of the components is instructed to further instruct a respective next lower-level node of the plurality of interconnected data processing nodes according to authoritative trust controls; however, in a same field of endeavor Padmanabhan teaches this limitation (Padmanabhan, ¶120).
Same motivation for combining the respective features of Haque and Padmanabhan applies herein, as discussed in the rejection of claim 9.
Regarding claim 19:
Haque does not explicitly suggest, wherein the controller is further configured to provide supervision for network interactions between multiple nodes of the plurality of interconnected data processing nodes, the supervision facilitating oversight of peer interactions through governance; however, in a same field of endeavor Padmanabhan teaches this limitation (Padmanabhan, ¶120, ¶138).
Same motivation for combining the respective features of Haque and Padmanabhan applies herein, as discussed in the rejection of claim 9.
Regarding claim 20:
wherein the controller is further configured to obtain approval of endorsed transactions in a master ledger configured to store data asset records of decentralized applications (Haque, ¶45-46).
Conclusion
7. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Monjour Rahim whose telephone number is (571)270-3890.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shewaye Gelagay can be reached on 571-272-4219. 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 CANANDA) or 571-272-1000.
/Monjur Rahim/
Patent Examiner
United States Patent and Trademark Office
Art Unit: 2436; Phone: 571.270.3890
E-mail: monjur.rahim@uspto.gov
Fax: 571.270.4890
Prosecution Insights