DETAILED ACTION
-Claims 1-8 were elected and are presented for examination.
-Claims 9-20 are withdrawn.
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 .
Election/Restriction
Applicant’s election without traverse of Group I in the reply filed on 7/20/2026 is acknowledged.
Drawings
Figures 8, 9, 10 filed on 10/23/24 are objected to because they include portions that are illegible and blurry.
The drawing labeled as Figure 10 filed on 11/13/2024 does not correspond to Figure 10 of the originally filed drawings, instead it appears to correspond to Figure 9.
Double Patenting
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 conflicting claims 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); 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 nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) 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 www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-8 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No.12373606. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the issued patent anticipate the claims of the instant application.
Claims 1-8 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of copending Application No. 19/254782. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the copending application anticipate the claims of the instant application.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1-8 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of copending Application No. 18/923952. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the copending application in view of Padmanabhan US Pub.No.2021/0226774 render obvious the claims of the instant application. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the copending application with Padmanbhan because it provides the benefit of improving upon, modifying, and expanding upon blockchain and related distributed ledger technologies by providing means for implementing user access controls in a metadata driven blockchain operating via Distributed Ledger Technology (DLT) using granular access objects and ALFA/XACML visibility rules in conjunction with a cloud based computing environment [Padmanabhan, 0012].
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1-8 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-10 of copending Application No. 18/924019. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the copending application in view of Padmanabhan US Pub.No.2021/0226774 render obvious the claims of the instant application. The same motivation to modify with Padmanabhan, as above, applies.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1-8 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of copending Application No. 18/170613. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the copending application in view of Padmanabhan US Pub.No.2021/0226774 render obvious the claims of the instant application. The same motivation to modify with Padmanabhan, as above, applies.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1-8 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-22 of copending Application No. 18/170645. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the copending application in view of Padmanabhan US Pub.No.2021/0226774 render obvious the claims of the instant application. The same motivation to modify with Padmanabhan, as above, applies.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
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-8 are rejected under 35 USC § 101 because they are directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claimed blockchain computing platform is directed to software per-se.
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.
Claims 1-8 are rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan (US Pub.No.2021/0226774), hereinafter Padmana.
Re Claim 1. Padmana discloses a node-based core operations and trust data asset management blockchain computing platform (i.e. means for operating a blockchain interface to a blockchain on behalf of a plurality of tenants of the host organization) [Padmana, para.0064], the computing platform comprising: one or more virtual machines configured and deployed to execute an operating system of the blockchain computing platform across an enterprise virtual network (i.e. Host organization users may interact with such accessible cloud platforms 177 to create and record data, and where appropriate, data and events may be pushed back into the blockchain 186 through configured virtual objects 197 which communicate with the REST API to write information into the blockchain or to reference information in the blockchain or to update state information for managed events within the blockchain) [Padmana, para.0204]; a plurality of interconnected data processing nodes each comprising a plurality of functional layers, wherein the plurality of functional layers comprises an identity management access layer that is configured to establish a blockchain computing function (i.e. Data is stored in an encrypted format where the encryption key is distributed as a shared secret with other nodes in the blockchain platform. The nodes 133 of the network perform a consensus on read operation when a request to access the data is made. The consensus on read process examines the credentials or any configured criteria that is determined to be required, which is provided in the access request. Each node that approves of the read access responds with its portion of the shared secret that enables the requesting node to generate the key from the shared secrets to decrypt the data on the blockchain and access the data……………permissioned (e.g., private) blockchains use an access control layer to govern who has access to the network. The embodiments further provide access controls for entities within or external to a private or public blockchain. In contrast to public blockchain networks, validators on private blockchain networks are vetted, for example, by the network owner, or one or more members of a consortium. They rely on known nodes to validate transactions) [Padmana, para.0087, 0102] comprising: defining (a) role-based access control (RBAC) policies for access to node-based core operations and trust data asset management blockchain services (i.e. Any relevant factors may be used in determining which nodes participate in the consensus protocol, including, for example, the selected consensus protocol itself, a particular node's computing resources, the stake a particular node has in the consortium or the selected consensus protocol, relevant (domain) knowledge a particular node has, whether that knowledge is inside (on-chain) or outside (off-chain) with regard to the blockchain or consortium, a particular node's previous or historical performance, whether in terms of speed or accuracy, or lack thereof, in participating in the selected consensus protocol) [Padmana, para.0244], (i.e. the smart contract will retrieve the metadata from the access control objects to infer the rules and based on the known user which is determined from the originator of the access request (e.g., what user is requesting access), the smart contract will then enforce the rules for the referenced entity objects as they apply specifically to that particular user,) [Padmana, para.0687, see also para.0700-0701] and (b) attribute-based access control (ABAC) time-based rules restricting access to portions of master data and reference data for trust data assets (i.e. For example, the doctor seeking to access a patient's medical information from a clinical trial may resolve to a permitted transaction or a prohibited transaction based on whether or not the clinical trial completed within the last 3 months or more than the last 3 months, which simply cannot be known until the time that the transaction is received at the blockchain………….Any number of permissible rules may be defined by the XACML link or reference, such as employees may access records during business hours) [Padmana, para.0696-0698], (i.e. the shared ledger implements a Distributed Ledger Technology (DLT) data store internal to the host organization; in which a copy of the data stored by the network org is accessible from each of the plurality of shared ledger nodes distributed across a plurality of geographically dispersed data centers of the host organization; and in which the DLT data store immutably stores all data within assets added to the DLT data store) [Padmana, para.0158]; and maintaining a security framework that controls access to processing node resources and trust data asset results available across the enterprise virtual network (i.e. Because the access control objects are stored utilizing the metadata platform a single agnostic smart contract may be utilized for different customer organizations as the smart contract only needs to know to go and retrieve the access control objects upon receipt of a blockchain transaction requesting access to any blockchain entity object. In such a way, all access control permissions may be resolved dynamically at runtime………………………….an entirely generic smart contract may be utilized for any company or organization, so long as such organizations utilize the metadata platform for configuring their access control objects to define such rules and permissions on the blockchain) [Padmana, para.0678, 0687].
Padmana does not explicitly teach all the above in one embodiment, however it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the different embodiments because it is suggested by Padmana: it is to be understood that the claimed embodiments are not limited to the explicitly enumerated embodiments disclosed. To the contrary, the disclosure is intended to cover various modifications and similar arrangements as are apparent to those skilled in the art [Padmana, para.0903].
This motivation is also applicable to the dependent claims.
Re Claim 2. Padmana discloses the blockchain computing platform of claim 1, Padmana further discloses: wherein the blockchain computing platform is configured to aggregate virtual computing results in master data across the virtual network (i.e. Further depicted here, is the materialized view 920 which permits a host organization user 925 to interact with the data transacted onto the blockchain via the metadata compliant transaction 915 from the accessible cloud platforms 177 available via the host organization 110. In computing, a materialized view 920 is a database object that contains the results of a query. For example, the materialized view 920 may be a local copy of data located remotely, or may be a subset of the rows and/or columns of a table or join result, or may be a summary using an aggregate function………………….In any database management system following the relational model, a view is a virtual table representing the result of a database query. Whenever a query or an update addresses an ordinary view's virtual table, the DBMS converts these into queries or updates against the underlying base tables……………. the authoritative copy of the data is hosted external to the host organization on the accessible blockchain(s) 999 and is not stored by any table within the database systems 130 of the host organization. The materialized view discussed above is an optional feature, but even when used, the information within the materialized view is not the authoritative copy. Any transactions making modifications to the data associated with the application, must not only comply with the defined metadata, but must also be updated at the blockchain) [Padmana, para.0536-0539, 0572].
Re Claim 3. Padmana discloses the blockchain computing platform of claim 1, Padmana further discloses: wherein the portions of the master data comprise secure private data (i.e. When the data is first stored in the blockchain that is to have restricted access for reads, the transaction is received by the blockchain service interface 190 (Block 1010). The blockchain consensus manager 191 determines whether the transaction is to be confirmed to the blockchain according to the consensus protocol of the blockchain network (block 1011). Where the transaction is to be committed, the blockchain consensus manager 191 generates a key to encrypt the data to be stored) [Padmana, para.0578].
Re Claim 4. Padmana discloses the blockchain computing platform of claim 1, Padmana further discloses: 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 (i.e. there is the problem of personally identifiable information in which some data written to the blockchain may store some personally identifiable information and may be shared among different institutions and organizations. Hence, there is the need to control the accesses to such data resources by third-entities, ……….For example, consider a medical patient having undergone a clinical trial and provides consent for certain doctors to see the information. Such a user may define that the doctors have consent to view the information for no more than 3 months from the conclusion of the clinical trial) [Padmana, para.0651, 0691].
Re Claim 5. Padmana discloses the blockchain computing platform of claim 1, Padmana further discloses: wherein the security framework is configured to provide authentication, authorization and accounting functionalities (i.e. The permissions manager 181 or related component may authenticate the request to verify that sufficient credentials have been presented to ensure that the requestor is authorized to initiate a process…………….because the shared ledger provides all the information in a cryptographic manner, a type of an audit trail or fully transparent audit log is created, permitting the founder org and possibly the partner orgs to see who changed what data and when, thus allowing a full traceback as to the who, what, where, when, and why changes to the data records were made, as may be required by law, accounting principles, or contractual obligations) [Padmana, para.0599, 0181, also 0226-0229].
Re Claim 6. Padmana discloses the blockchain computing platform of claim 1, Padmana further discloses: wherein the security framework controls access to the 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 (i.e. In further embodiments, a permissions manager 181 operates to enforce access controls and privileges as defined in metadata for data stored in the blockchain. The permissions manager 181 can enforce restrictions on accessing records, objects, fields, or similar levels of granularity on access control including read and write access controls. The permissions manager 181 enforces management of the blockchain data based on metadata defining access privileges. The access privileges utilize a unique user identifier (UUID) or similar entity identifier. The metadata can define a list of entities with permission to read or write data in the blockchain………………………………the permissions manager 181 receives a request from an entity to write specified data associated with a UUID and access control privileges (Block 1226). The permissions manager 181 or related component may authenticate the request to verify that sufficient credentials have been presented to ensure that the requestor is authorized to initiate a write process to change the identified data (Block 1227). For example, a requestor may present a security token, password, encryption key and/or similar credentials to verify authorization. If authenticated, then the request is processed to determine or to identify either a smart contract tied to the UUID or to identify or determine an identifier for the data to written to the blockchain) [Padmana, para.0088-0089, 0623].
Re Claim 7. Padmana discloses the blockchain computing platform of claim 1, Padmana further discloses: wherein the virtual network is configured with business rules that overlay the virtual network and comprise policies and usage rules (i.e. The blockchain protocol certification 166 defines the required size and/or data structure of the block payload 169 as well as certifying compliance with a particular blockchain protocol implementation, and thus, certifies the blockchain protocol block subscribes to, implements, and honors the particular requirements and configuration options for the indicated blockchain protocol. The blockchain protocol certification 166 may also indicate a version of a given blockchain protocol and the blockchain protocol may permit limited backward and forward compatibility for blocks before nodes will begin to reject new blockchain protocol blocks for non-compliance……………..the blockchain metadata definition manager 196 executes smart contract validation 563, and if the data to be written to the blockchain is not compliant with the requirements set forth by the executed smart contract, then the transaction is rejected 565, for instance, sending the transaction back to a query interface to inform the originator of the transaction. Otherwise, assuming the transaction is compliant pursuant to smart contract execution, then the transaction is validated 564 and written to the blockchain) [Padmana, para.0112, 0352].
Re Claim 8. Padmana discloses the blockchain computing platform of claim 1, Padmana further discloses: wherein the plurality of functional layers further comprises an availability management network layer, an asset management service layer, and a storage management data layer (i.e. here is further depicted a metadata layer 156 having knowledge of all presently defined metadata definitions created and pushed to the accessible blockchains, followed by a network organization 157 layer or a shared ledger, which serves as an interface to the variously accessible blockchains. The state ledger 147 maintains the status of the accessible blockchains and any connection or non-connection states while the history 148 block maintains a transaction history and logging for the platform. The integration platform layer 146 provides an interface to other components within the host organization 110 to interface with the components of the blockchain metadata definition manager 196 while the access control layer 151 is described in greater detail below, but provides certain access rights and restrictions for private and permissioned blockchains………………the blockchain metadata definition manager 196 writes data or metadata onto a blockchain by transacting an asset to the blockchain or adding an asset to the blockchain via a new transaction with the blockchain. According to a particular embodiment, the transaction has a specific transaction type, for instance, defined as a blockchain storage transaction type, which triggers execution of a smart contract to perform validation of the transaction and specifically to perform validation of the data or metadata within the asset being added to or transacted onto the blockchain ………………… a Distributed Ledger Technology (DLT) data store internal to the host organization; in which a copy of the data stored by the network org is accessible from each of the plurality of shared ledger nodes distributed across a plurality of geographically dispersed data centers of the host organization; and in which the DLT data store immutably stores all data within assets added to the DLT data store) [Padmana, para.0120, 0273, 0158].
Prior art made of record however not relied upon includes:
Frederick et al (US Pub.No.2019/0166133) describes a system that receives information from one of the set of computing platforms when the set of connections is established, verifies authenticity of an aspect of the information, generates a new-block of a block-chain associated with a user by cryptographically encrypting the information, adds the new-block to the block-chain, stores the block-chain with the new-block in the memory, generates a command to execute an action associated with the new-block and transmits the command to the computing platform through the communication interface after verifying of the authenticity [Abstract].
Garg et al (US Pub.No.2021/0342291) describes an example operation includes one or more of identifying, by an archiving server node, a unique archival policy for each of a plurality of blockchain nodes, executing, by the archiving server node, a consensus mechanism to determine at least one block from a plurality of blocks of the plurality of the blockchain nodes to be archived, and running the unique archival policy to archive the at least one block from the plurality of the blocks [Abstract].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NOURA ZOUBAIR whose telephone number is (571)270-7285. The examiner can normally be reached Monday - Friday.
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.
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights