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
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114.
Response to Amendment
The Request for continued Examination, filed on 05/01/2026, has been entered and acknowledged by the Examiner. In the Amendment, applicant amended claims 1 and 8.
As to Arguments and Remarks filed in the Amendment, please see Examiner’s responses shown after Rejections - 35 U.S.C § 103
Please note claims 1-14 are pending.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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-14 are rejected under 35 U.S.C. 103 as being unpatentable over Dintchev et al. (US Patent 11,550,931 hereinafter Dintchev), in view of Spina et al. (US PGPUB 2018/0262589, hereinafter Spina).
Examiner Note: For better understanding, below is explanation at least one way from many ways of how examiner interprets:
I: CRUD stands for Create, Read, Update, and Delete. It represents the four functions used to manage and manipulate data in computer programming and databases.
(1) Create: Make new data. Example: Signing up for a new account or adding an item to a shopping cart.
(2) Read: View or look up existing data. Example: Checking profile page or searching for a product.
(3) Update: Change or edit current data. Example: Changing password or updating shipping address.
(4) Delete: Remove data. Example: Deleting a user profile or clearing an item from a list.
CRUD Connects to Technology: (1) Databases: In standard SQL databases, these actions match commands like INSERT, SELECT, UPDATE, and DELETE.
(2) Web APIs: Web services often use REST standards where actions map to methods like POST, GET, PUT, and DELETE.
II: Data Envelope: A "data envelope" most commonly refers to Data Envelopment Analysis (DEA), a math and business tool used to measure how well different groups use their resources.
It can also mean a digital envelope in security or a standard JSON wrapper in web APIs.
Data Envelopment Analysis (DEA): (1) A linear programming method to check the relative efficiency of peer units (like stores, schools, or hospitals).
(2) It compares multiple inputs (like staff and money) against multiple outputs (like sales or patients helped).
(3) The "Envelope": It builds an "efficient frontier" line that wraps around the best-performing data points, creating an envelope boundary to show which units waste resources.
Digital Envelope (Cybersecurity): (1) A secure data transmission method. (2) It uses fast symmetric encryption to lock the actual message, and public-key cryptography to lock the key itself.
API Data Envelope (Web Development): (1) A standard JSON response format.
(2) It places the main payload inside a predictable top-level container or key (such as a "data" field) alongside metadata or status codes.
As per as claim 1, Dintchev discloses:
(Currently Amended) A data management method, comprising:
performing a create/read/update/delete (“CRUD”) function on data that is transiently stored in a database so as to be accessible by a computer, wherein the CRUD function is performed in accordance with a received data envelope and with respect to a database (Dintchev, e.g., [col. 10, lines 17-25], “…metadata or envelope data collectively pertaining to the uploaded owner files 115. The information provided in the metadata or envelope data may include descriptive name(s) and/or details of the collection of uploaded owner files 115. For example, if the uploaded owner files 115 are related to a fire and associated insurance claim, the metadata or envelope data may include a description such as “Documents and photographs pertaining to fire damage, December 2018”.”, i.e., ‘data envelope’)…”); and
storing, on a block of the blockchain, a hash value of the data on which the CRUD function is performed, wherein the hash value indicates a location of the data in a permanent storage distinct from the database, and wherein the block includes an indication of the CRUD function performed in accordance with the received data envelope (Dintchev, e.g., [col. 10, lines 12-34], “…when the notarized hash 140, in base-64 format, is successfully recorded to the blockchain 145, the capsule file generation process 100 of some embodiments retrieves the storage location 150 of the stored transaction (or recorded block) with the recorded base-64 formatted notarized hash 140. In some embodiments, the blockchain 145 presents the storage location 150 to the central notary system by the blockchain 145 as a reference storage location that includes referencing information applicable to the particular blockchain implementation utilized by the capsule file generation system 110. Specifically, when a private Ethereum blockchain implementation is utilized, as abstracted with Microsoft Azure Blockchain Workbench, the referenced storage location includes the workbench Contract ID, the Contract Action ID, and the Ethereum Transaction Address. However, when the public Ethereum Blockchain (Mainnet) is utilized, the referenced storage location includes the Smart Contract Address, the Block ID containing the transaction created, and the Transaction Hash identifier of the transaction created for the storage. On the other hand, when the Bitcoin public Blockchain is utilized, the referenced storage location includes the transaction ID of the successful transaction”, i.e., ‘wherein the hash value indicates a location of the data in a permanent storage distinct from the database” and further see [col. 18, lines 10-67], [col. 20, lines 1-31], “… read the record of the notarized hash from the blockchain storage location identified by the capsule file…”) ).
To make records clearer regarding to the features of “data that is transiently stored in a database”, (although as stated above, Dintchev functional disclose the features of data that is transient stored in a database (Dintchev, e.g., [col. 10, lines 17-25]).
However, Spina, in an analogous art, discloses “data that is transiently stored in a database” (Spina, e.g., [abstract], [0090], [0106], “… store production data in a persistent datastore and to store status data in a transient datastore…” and [0106], “…production data is stored to a volume oriented datastore (e.g., persistent datastore 216A) and block 908 illustrates that status data is stored in a transient data oriented datastore (e.g., transient datastore 216B).”. Thus, it would have been obvious to one of ordinary skill in the art BEFORE the effective filling date of the claimed invention to combine the teaching of Spina and Dintchev to perform various functionality including verifying a client (e.g., client 136a-b) using a datastore storing data for various authorization schemes (Spina, e.g., [0064-0067]).
As per as claim 2, the combination of Spina and Dintchev disclose:
The data management method of claim 1, wherein the CRUD function is a create function, and the block is an initial block on the datachain (Dintchev, e.g., [col. 15-16, lines 40-14], “…select a newly created capsule file to share with other users immediately after creation of the new capsule file…”).
As per as claim 3, the combination of Spina and Dintchev disclose:
The data management method of claim 1, wherein the CRUD function is an update function, and the block is an additional block on the datachain (Dintchev, e.g., [col. Col. 16, lines 15-27], “…record is overwritten with a new updated record the includes the current specified access rights in connection with the particular capsule file”).
As per as claim 4, the combination of Spina and Dintchev disclose:
The data management method of claim 1, wherein the CRUD function is a delete function, and the block is an additional block on the data chain and includes a delete indicator (Dintchev, e.g., [col. Col. 16, lines 15-27], “…record is overwritten with a new updated record the includes the current specified access rights in connection with the particular capsule file”).
As per as claim 5, the combination of Spina and Dintchev disclose:
The data management method of claim 1, wherein the CRUD function is a read function, and the data is read from at least one of: the database and the permanent storage (Dintchev, e.g., [col. 17-col. 18, lines 41-9], “…The capsule file verification process 500 reads the central access control database 175 to review the access rights granted by the capsule owner to the capsule file …”).
As per as claim 6, the combination of Spina and Dintchev disclose:
The data management method of claim 1, further comprising: creating the database from the blockchain and the permanent storage (Dintchev, e.g., [col. 15, lines 44-50], “… created capsule files, but may select a newly created capsule file to share with other users immediately after creation of the new capsule file …” and [col. 16, lines 40-67], “…user 505 may be the capsule owner (that is, the original owner user) for whom the capsule file 510 was created, such as by the capsule file generation process…”).
As per as claims 7 and 14, the combination of Singh and Mueller disclose:
The data management method of claim 1, further comprising: encrypting the data stored in the permanent storage, wherein the hash value is of the encrypted data (Dintchev, e.g., [col. 5, lines 15-18], [col. 1,lines 14-45], [col. 11, lines 30-67] and [col. 18-19, lines 21-44], “…record of the notarized hash from the blockchain storage location identified by the capsule file…when the files in the capsule file 510 were encrypted with AES 256 bit in Cipher Block Chaining, with a sixteen byte Initialization Vector (IV) stored as prepended to the encrypted file bytes in the capsule file 510, the central notary system …”).
Claims 8-14 are essentially the same as claims 1-7 except that they set forth the claimed invention as a system rather a method, respectively and correspondingly, therefore is rejected under the same reasons set forth in rejections of claims 1-7.
Response to Arguments
The Examiner respectfully reminds applicant of the broadest reasonable interpretation standard (See MPEP 2111), "During examination, the claims must be interpreted as broadly as their terms reasonably allow." In re American Academy of Science Tech Center, 367 F.3d 1359, 1369, 70 USPQ2d 1827, 1834 (Fed. Cir. 2004) (The USPTO uses a different standard for construing claims than that used by district courts; during examination the USPTO must give claims their broadest reasonable interpretation.) In Phillips v. AWH Corp., 415 F.3d 1303, 75 USPQ2d 1321 (Fed. Cir. 2005), the court further elaborated on the “broadest reasonable interpretation" standard and recognized that “The Patent and Trademark Office (“PTO") determines the scope of claims in patent applications not solely on the basis of the claim language, but upon giving claims their broadest reasonable construction." Thus, when interpreting claims, the courts have held that Examiners should (1) interpret claim terms as broadly as their terms reasonably allows and (2) interpret claim phrases as broadly as their construction reasonably allows.
Applicant’s arguments filed 05/01/2026 with respect to claims 1-14 have been considered but are moot in view of the new ground(s) of rejection necessitated by applicant's amendment to the claims. Applicant's newly amended features are taught implicitly, expressly, or impliedly by the prior art of record (See the new ground(s) of rejection set forth herein above).
The Examiner respectfully submits that, with respect to the totally newly amended subject matter, the Examiner respectfully cited proper paragraphs from cited reference to reject the claim in responsive to the newly amended, please refer to the corresponding section of the office action.
Additional Art Considered
The prior art made of record and not relied upon is considered pertinent to the Applicants’ disclosure.
The following patents and papers are cited to further show the state of the art at the time of Applicants’ invention with respect to performing a CRUD (create, read, update and delete) function on data in accordance with a received data envelope and with respect to a database, and storing a hash value on a block of a blockchain which using a cryptographic blockchain replicating create-read-update-delete (CRUD) functionality in an enterprise IT environment.
a. Johnson Wong (US PGPUB 2019/0108139, hereafter Wong); “Client Side Persistent Caching Framework” discloses “ create, read, update or delete operation is performed on the content stored in the volatile memory system to generate modified content in the volatile memory system, a second request to synchronize content is received from the volatile memory system to the persistent memory system, and, in response to the second request, the modified content is retrieved from the volatile memory system and the modified content is stored in the persistent memory system”.
Wong also teaches data stored in the local Persistent Store. Instead, the Transient Store is used to capture data to be operated upon [0026-0027].
Wong further teaches determined to persist the data of the Transient Store (e.g., at a point of minimal activity on the main thread) [0028].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. See form 892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TUAN A PHAM whose telephone number is (571)270-3173. The examiner can normally be reached M-F 7:45 AM - 6:30 PM.
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, Tony Mahmoudi can be reached on 571-272-4078. 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.
/TUAN A PHAM/Primary Examiner, Art Unit 2163
Prosecution Insights