DETAILED ACTION
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 .
Status of Claims
This communication is responsive to the amendment filed om 03/06/2026.
Claims 1, 12, and 20 are independent claims.
Claims 1-25 are pending in this application.
This action has been made FINAL.
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 20-25 are rejected under 35 U.S.C. 101 because the claims do not amount to significantly more than an abstract idea.
Regarding independent claim 20, the claim recites language of:
“obtaining, by the document management system, a document access request to access a document based on an access attempt of a virtual file corresponding to the document by a document authoring application, the document access request comprising a blockchain reference obtained from the virtual file and indicative of a blockchain having stored therein the document;
searching, by the document management system, for the blockchain corresponding to the blockchain reference in a register;
identifying, by the document management system and based on the searching, the blockchain corresponding to the blockchain reference and accessing a block of the blockchain storing a latest version of the document; and
transmitting, by the document management system, a temporary file corresponding to the latest version of the document to the document authoring application.”
a/ Analysis under Step 2A, Prong I:
In fact, the particular step of “identifying, …, the blockchain corresponding to the blockchain reference”, as drafted, is a mental process that, under its broadest reasonable interpretation, covers performance of the limitation in human mind (e.g., an observation, evaluation, judgment, option, etc.) but for the recitation of generic computer’s component(s). Thus, if a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mental mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. See MPEP 2106.04(a)(2), Part III.
b/ Analysis under Step 2A, Prong II:
The remaining limitations in claim 20 do not integrate the judicial exception into a practical application. For instance, the additional element, e.g., “a document management system” is known as generic computing component/unit using for performing the computing functions of the above indicated steps of “obtaining…”, “searching…”, “identifying…. and accessing…”, and “transmitting…”. Therefore, the additional element amounts no more than mere instructions to apply the exception using the generic computing component/unit having at least a processor or a memory, see Mayo, 566 U.S. AT 84. Next, the additional limitations of “obtaining, …, a document access request…”, “searching, …, for the blockchain…”, “… accessing a block of the blockchain…”, and “transmitting a temporary file…” represent an insignificant extra solution activities because these additional steps including in the claim as the computing functions that do not integrate into a practical application because these additional steps do not specify in details of how to execute/process data for accessing a document for auditing/editing to new version purpose. See MPEP 2106.04(a)-(h).
c/ Analysis under Step 2B:
Furthermore, independent claim 20 does not include additional elements and/or limitations beyond the judicial exception that, alone or in combination, are not “well-understood, routine, conventional” (see MPEP 2106.05(d)). As discussed above with respect to integration of the abstract idea into a practical application in analysis under Step 2A (Prong Two), the additional element of using “a document management system” for performing the steps of “obtaining…”, “searching…”, “identifying the blockchain… and accessing a block of the blockchain…”, and “transmitting a temporary file…” that amounts no more than mere instructions/functions to apply the exception using the highly generic computing component (e.g. , “system” having at least a processor or a memory) and is being only used as tools that are well-understood, routine, conventional amount to no more than implementing the abstract idea with a computing system. Next, the claim recites additional steps of additional limitations of “obtaining, …, a document access request…”, “searching, …, for the blockchain…”, “… accessing a block of the blockchain…”, and “transmitting a temporary file…” represent an insignificant extra solution activity because these additional steps including in the claim as the computing functions to apply the exception using a generic computer components that are well-understood, routine, conventional activity to a skill artisan in the relevant technical field of receiving/obtaining and transmitting data over a network, e.g., using the Internet to gather data/information, see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362, and storing/retrieving information in memory, see Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
For the at least above reasons, the limitations including the amended limitations in claim 20, individually and/or in combination, do not amount to significantly more than the abstract idea.
Claims 21-25 depend on independent claim 20 and include all the limitations of claim 20; and hence, claims 21-25 recite the same as being the above abstract idea as well as under Step 2A (Prong I, Prong II), and Step 2B.
Regarding claim 21, the claim recites additional limitations of “receiving an audit request for an audit trail of the document from the document authoring application, the audit access request comprising the blockchain reference; obtaining the audit trail of the blockchain corresponding to the blockchain reference; and transmitting the audit trail to the document authoring application” which do not integrate the judicial exception into a practical application. The claim language provides further definition of the audit access request comprising the blockchain reference which does not amount to more than generally linking the use of a judicial exception to a particular technological environment or field of use. Also, the additional steps of “receiving an audit request…”, “obtaining the audit trail…”, and “transmitting the audit trail…” represent an insignificant extra solution activity because these additional steps including in the claim as the computing functions to apply the exception using a generic computer components that are well-understood, routine, conventional activity to a skill artisan in the relevant technical field of gathering and transmitting data via network, see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362. Thus, the claim does not include additional limitations/elements that are sufficient to amount to significantly more than the judicial exception because the additional elements, when considered both individually and as an ordered combination, do not amount to significantly more than the abstract idea.
Regarding claim 22, the claim recites further additional limitation of “wherein receiving the document access request from the document authoring application comprises receiving the document access request from a software add-in of the document authoring application configured to interface the document authoring application with the document management system; and wherein receiving the audit request comprises receiving the audit request from the software add-in of the document authoring application” which do not integrate the judicial exception into a practical application. The additional steps do not amount to more than generally linking the use of a judicial exception to a particular technological environment or field of use. The additional element of “the document management system” and “the software add-in” are generic computing components and are being only used as computing tools. Also, the additional steps of “…receiving the document access request…”, “…configured to interface the document authoring application…”, and “…receiving the audit request…” represent an insignificant extra solution activity because these additional steps including in the claim as the computing functions to apply the exception using a generic computer components that are well-understood, routine, conventional activity to a skill artisan in the relevant technical field of gathering data via network, see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362, and presenting data vis graphical user interface, see OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93. Thus, the claim does not include additional limitation/element that is sufficient to amount to significantly more than the judicial exception because the additional limitations/elements, when consider both individually and as an ordered combination, do not amount to significantly more than the abstract idea.
Regarding claim 23, the claim recites further additional limitation of “receiving a document save request from the document authoring application, the document save request comprises the blockchain reference and a current version of the document; identifying the blockchain corresponding to the blockchain reference of the document save request; and storing the current version of the document as a new block of the blockchain.” in which the step of “identifying the blockchain…”, as drafted, is a mental process as performing in the mind that falls within the “Mental Processes” grouping of abstract idea (see MPEP 2106.04 (a)(2), part III). Plus, the additional element of “receiving aa document save request…” having the blockchain reference and a current version of the document does not integrate the judicial exception into a practical application. For instance, the additional step of “receiving…” and “storing the current version of the document…” represent insignificant extra solution activities because these additional steps including in the claim as the computing functions that do not amount to significantly more than mere instructions to apply the exception using a generic computer components that are well-understood, routine, conventional activity to a skill artisan in the relevant technical field of gathering data via network, see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362, and storing and retrieving information in memory, see Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
Thus, the claim does not include additional limitation/element that is sufficient to amount to significantly more than the judicial exception because the additional limitations/elements, when consider both individually and as an ordered combination, do not amount to significantly more than the abstract idea.
Regarding claim 24, the claim recites further additional limitation of “…generating an encrypted version of the current version of the document based on encrypting the current version of the document with a symmetric encryption key; generating an encrypted version of symmetric key based on encrypting the symmetric encryption key with a public key of a user that created the current version of the document; and storing in the new block the encrypted version of the current version of the document and the encrypted version of symmetric key” in which the additional steps of “generating an encrypted version of the current version…”, “generating an encrypted version of symmetric key…” and “…that created the current version…”, “encrypting the current version…” and “encrypting the symmetric encryption key…” do not amount to more than generally linking the use of a judicial exception to a particular technological environment or field of use, and a symmetric encryption key with a public key is being only used as a tool. Also, the steps of “storing in the new block the encrypted version…” does not integrate the judicial exception into a practical application. For instance, the additional step of “storing…” represents insignificant extra solution activities because this additional step including in the claim as the computing functions that do not amount to significantly more than mere instructions to apply the exception using a generic computer components that are well-understood, routine, conventional activity to a skill artisan in the relevant technical field of storing and retrieving information in memory, see Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
Thus, the claim does not include additional limitation/element that is sufficient to amount to significantly more than the judicial exception because the additional limitations/elements, when considered both individually and as an ordered combination, do not amount to significantly more than the abstract idea.
Regarding claim 25, the claim recites further additional limitation of “…obtaining a private key of a user that created the latest version of the document based on a user identifier stored in the block; decrypting an encrypted symmetric encryption key stored in the block with the private key to obtain a symmetric encryption key; and decrypting an encrypted version of the document stored in the block with the symmetric encryption key to obtain the latest version of the document” which do not integrate the judicial exception into a practical application. The additional steps of “decrypting an encrypted symmetric encryption key s…; and decrypting an encrypted version...” do not amount to more than generally linking the use of a judicial exception to a particular technological environment or field of use, and a symmetric encryption key with a public key is being only used as a tool. Also, the step of “obtaining a private key…” does not integrate the judicial exception into a practical application. For instance, the additional step of “obtaining…” represents insignificant extra solution activities because this additional step including in the claim as the computing functions that do not amount to significantly more than mere instructions to apply the exception using a generic computer components that are well-understood, routine, conventional activity to a skill artisan in the relevant technical field of gathering data via network, see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362. Thus, the claim does not include additional limitation/element that is sufficient to amount to significantly more than the judicial exception because the additional limitations, when consider both individually and as an ordered combination, do not amount to significantly more than the abstract idea.
For at least above reasons, claims 20-25 are not drawn to eligible subject matter as they are directed to an abstract idea without significant more.
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, 5, and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Candelario et al., US Pub. No. 2021/0026980 A1 (hereinafter as “Candelario”), in view of Habouzit et al., US Pub. No. 2015/0347440 A1 (hereinafter as “Habouzit”).
Regarding independent claim 1, Candelario teaches a method for accessing a document by a document authoring application (Abstract: “A method for preparing a credential package includes providing access to a credential record of a plurality of credential records stored in a database system…”; and par. [0039]), the method comprising:
obtaining, by the document authoring application, a blockchain reference from a virtual file of a computing device (in comparing to the Applicant’s Fig. 4, Abstract: crendential documents in the credential system having virtual machine(s), see par. [0019] of Candelario wherein the metadata field; and Fig. 3 and par. [0037] discloses transaction which is interpreted as the virtual file, and in pars. [0043-45] via ledger/blockchain, [0046-48] via virtual machines, database instance in virtual machine interpreted as virtual file, blockchain data=reference; and par. [0093] discloses each node of the plurality of nodes implements a consensus algorithm and includes a file system to store the documents. For example, the consensus algorithm and the file system are implemented in a virtual machine at the node. In another example, the consensus algorithm and the file system are implemented in separate virtual machines at the node. In an additional example, each node includes a block logger to log events, which teaches the virtual document/file, and consensus algorithm as blockchain reference), the virtual file corresponding to a document stored in a blockchain by a document management system remote from the computing device (Fig. 3 via network 316, and par. [0033]; and in pars. [0019] and [0020] “each document is to be securely stored within the distributed ledger network.”), the blockchain reference indicative of the blockchain having stored therein the document (par. [0019] of Candelario discloses metadata=reference, the distribute ledger system=blockchain);
transmitting, by the document authoring application, a document access request to the document management system (par. [0020] “each document is to be securely stored within the distributed ledger network. Documents can be broken down into chunks, encrypted, and distributed throughout the network. When requested, the documents can be reassembled from the chunks, decrypted, and passed back to the requester”), the document access request comprising the blockchain reference (see pars. [0054 and 58] and [0060]).
Candelario teaches “a temporary file” when the node receives the file (see par. [0057]). However, Candelario does not explicitly teach the limitations: “receiving, by the document authoring application, a temporary file corresponding to a latest version of the document from the document management system; and outputting, by the document authoring application, at least in part contents of the document from the temporary file.”
In the same field of endeavor (i.e., data processing), Mullins teaches:
receiving, by the document authoring application, a temporary file corresponding to a latest version of the document from the document management system (par. [0030] discloses “the application” (further in par. [0034] e.g., “one or more applications” that can be interfaced to application programming interface (API) via communications interface as interpreted the document authoring application), and “the temporary file”, and par. [0032] “In operation 130, the saved temporary file is renamed over the existing document. In effect, the edited version of the existing document, which was saved in the temporary file in operation 120, replaces the existing document. During the rename process, the temporary file inherits the filename of the existing document. However, the temporary file will keep its own POSIX file identifier. The POSIX identifier associated with the existing document filename will not be associated with the edited version of the existing document.” The edited version of the existing document, which was saved in the temporary file in operation 120 is taught the temporary file associating/corresponding to the edited=latest version of the document, in comparing to Applicant’s Fig. 4, elements 514 and 516; and further in par. [0040]); and
outputting, by the document authoring application, at least in part contents of the document from the temporary file (par. [0028] “In operation 110, a temporary file can be generated having the contents of the existing document. The temporary file typically has either a different filename, or is in a different directory, than the existing document. The temporary file and the existing document have different POSIX file identifiers”; par. [0052] “The application 205 can call appropriate file system 215 operations to generate the temporary file and to populate the temporary file with the contents of the existing document.”; and pars. [0139] and [0140] teaches the technical algorithm of the document identifier existed in the temporary file as part content of the document being display/output as retrieving through the interface).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Habouzit would have provided Candelario with the above indicated limitations for allowing a skill artisan in motivation as modifies to perform the temporary file corresponding/associating the edited version document having the document identifier and metadata causing output as part content of the document efficiently tracking document by the management system (Habouzit: Abstract, pars. [0032, 40]).
Regarding claim 5, Candelario and Habouzit, in combination, teach:
wherein the temporary file further comprises the blockchain reference (Candelario: see par. [0057] e.g., “a temporary file”; and Habouzit: par. [0040] e.g., “metadata about the tracked document including, but not limited to, an inode identifier of the document, an inode identifier of a parent of the document, the filename of the document before the safe save of a temporary file over the document, the owner of the file, optionally including an access control list or other permission information, a date/time stamp of the creation of the tombstone, and a persistent document identifier (DOCID) such, as a universally unique identifier (UUID) for the document”. The document identifier, metadata, an inode identifier in the content of temporary file are interpreted as the reference),
the method further comprising: transmitting, by the document authoring application, a document save request to the document management system (Candelario: par. [0015] “a credentialing system provides an interface into a credential record that references documents stored in conjunction with a distributed ledger system. The distributed ledger contains a record of transactions within the credentialing system.”; pars. [0047] and [0050] e.g., “upload the file”), the document save request comprises the blockchain reference of the temporary file and a current version of the document (Candelario: par. [0043] e.g., “This is where all transactions are logged to create a ledger. A blockchain data structure can be used to store the transaction”; and par. [0044] Filesystem storage for documents.”; and Habouzit: see pars. [0032 and 70]).
Regarding claim 11, Habouzit teaches: wherein the document authoring application is running on at least one server remote from the computing device (see Fig. 2, Abstract, and pars. [0046 and 0117])
Claims 2-4 are rejected under 35 U.S.C. 103 as being unpatentable over Candelario and Habouzit, and further in view of Saurabh et al., US Pub. No. 20220114150 (hereinafter as “Saurabh”).
Regarding claim 2, the claim is rejected by the same reasons set forth above to claim 1. Candelario and Habouzit do not explicitly teach the limitations recite in the claim.
In the same field of endeavor (i.e., blockchain processing), Saurabh teaches:
transmitting, by the document authoring application, an audit request for an audit trail of the document to the document management system, the audit request comprises the blockchain reference (par. [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129, peer nodes 104-110 may generate an event to signify the completion of the update transaction and transmit the event to the application 124 or API 122 that generated the initial transaction request.”, wherein the chaincode (i.e., hash code/keys/identifier(s), digital assets) is interpreted as the reference, see further in pars. [0079] “digital assets as blocks written to the audit trail 129, group the storage transactions into blocks, and build a hash chain over the blocks.”, and [0086]);
receiving, by the document authoring application, the audit trail from the document management system (par. [0019] “query the ledger(s) containing the audit trail…”; pars. [0098] and [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129… In some embodiments, upon a validated update of the ledger comprising the audit trail 129…”); and
outputting, by the document authoring application, at least in part the audit trail (par. [0019] “The one or more digital assets that may comprise the audit trail can be forwarded from respective monitoring servers, logging servers and/or output from migration tools toward nodes of a blockchain network being utilized by a blockchain platform using an application programming interface (API) functionality to execute application code to implement one or more blockchain transactions. Administrators and/or auditors responsible for tracking the progress of the tasks can access and audit the blocks of the audit trail via the blockchain platform, query the ledger(s) containing the audit trail…”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Saurabh would have provided Candelario and Habouzit with the above indicated limitation for performing of audit trail for the file/document storing the blockchain more efficient security (Saurabh: Abstract, and pars. [0018-19]).
Regarding claim 3, Habouzit and Saurabh, in combination, teach: wherein the document authoring application (Habouzit: Abstract, e.g., “Applications can opt in to document tracking”) comprises:
a software add-in for obtaining the blockchain reference (Habouzit: Abstract, e.g., “Applications can opt in” teaches a software add-in; and Saurabh: fig. 2A, elements 120, and 124; par. [0019] and [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129, peer nodes 104-110 may generate an event to signify the completion of the update transaction and transmit the event to the application 124 or API 122 that generated the initial transaction request.”),
transmitting the document access request (Saurabh: fig. 2A, elements 120, and 124; par. [0019] and [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction)”);
receiving the temporary file (Habouzit: pars. [0028, 32] discloses the “temporary file”),
transmitting the audit request (Saurabh: par. [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129, peer nodes 104-110 may generate an event to signify the completion of the update transaction and transmit the event to the application 124 or API 122 that generated the initial transaction request.”, wherein the chaincode (i.e., hash code/keys/identifier(s), digital assets) is interpreted as the reference, see further in pars. [0079] “digital assets as blocks written to the audit trail 129, group the storage transactions into blocks, and build a hash chain over the blocks.”, and [0086]),
receiving the audit trail (Saurabh: par. [0019] “query the ledger(s) containing the audit trail…”; pars. [0098] and [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129…”), and
outputting the audit trail (Saurabh: par. [0019] “The one or more digital assets that may comprise the audit trail can be forwarded from respective monitoring servers, logging servers and/or output from migration tools toward nodes of a blockchain network being utilized by a blockchain platform using an application programming interface (API) functionality to execute application code to implement one or more blockchain transactions. Administrators and/or auditors responsible for tracking the progress of the tasks can access and audit the blocks of the audit trail via the blockchain platform…”).
Regarding claim 4, Candelario, Habouzit and Saurabh teach:
wherein the temporary file further comprises the blockchain reference (Candelario: see par. [0057] e.g., “a temporary file”; and Habouzit: par. [0040] e.g., “metadata about the tracked document including, but not limited to, an inode identifier of the document, an inode identifier of a parent of the document, the filename of the document before the safe save of a temporary file over the document, the owner of the file, optionally including an access control list or other permission information, a date/time stamp of the creation of the tombstone, and a persistent document identifier (DOCID) such, as a universally unique identifier (UUID) for the document”. The document identifier, metadata, an inode identifier in the content of temporary file are interpreted as the reference); and
wherein the audit request comprises the blockchain reference of the temporary file (Saurabh: par. [0019] “query the ledger(s) containing the audit trail…”; par. [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129…”, and par. [0073] discloses the chaincode and digital assets embedded the blockchain reference).
Claims 6, and 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over Candelario, and Habouzit, and further in view of Patel et al., US Pub. No. 2020/0159891 A1 (hereinafter as “Patel”).
Regarding claim 6, the claim is rejected by the same reasons set forth above to claim 1. Furthermore, Candelario and Habouzit teach: “wherein the document authoring application is running on the computing device” (Habouzit: see Fig. 2, elements 205s Application(s) is/are running on the computing device that teach as the document authoring application). In addition, Candelario’s par. [0044] further discloses virtual file system e.g., “Filesystem storage for documents. The filesystem storage can be located on either virtual machine, however locating it on the Swirlds virtual machine takes network performance out of the equation and makes configuring the virtual servers easier”.
However, Candelario and Habouzit do not explicitly teach: “providing, by the computing device, a virtual file system comprising the virtual file, the virtual file system corresponding to documents stored in blockchains by the document management system and authorized to be accessed by the computing device.”
In the same field of endeavor (i.e., data processing), Patel teaches:
providing, by the computing device, a virtual file system comprising the virtual file (Patel: Fig. 1 element 116, “Blockchain Protocol Layer (Virtual Execution Environment), and par. [0052] a virtual machine having a temporary data structure is interpreted as virtual file system, par. [0172] “a Virtual Machine (VM) image”=virtual file), the virtual file system corresponding to documents stored in blockchains by the document management system and authorized to be accessed by the computing device (Patel: fig. 1 and 17 as explained above for authoring the file/documents).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of Patel with the above indicated limitation with the teachings of Candelario and Habouzit. The motivation would be allowed for a skill artisan to using the virtual file in the virtual file system corresponding to documents stored in blockchain being authorized for accessing in secure.
Regarding claim 8, Candelario and Patel, in combination, teach: wherein obtaining the blockchain reference comprises retrieving the blockchain reference from the virtual file in response to a user request via the virtual file system to open the document corresponding to the virtual file (Candelario: see again in par. [0044]; and Patel: pars. [0050] “… retrieve any of the data or information described herein.”; and [0052] smart contract is also interpreted as virtual file having code (e.g., hash code/keys/reference), par. [0053] “…receives a hash and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor. If the hashes of the hash identifier and the hash created from the stored identifier template data match, then the chaincode sends an authorization key to the requested service...”, wherein the authorization key is interpreted as the reference to the user request service, and [0102] “The digital content may include one or more media files and associated information. The media files may contain images, video, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspects of the blockchain serve as a safeguard to protect the integrity, validity, and authenticity of the digital content,…”, and [0172] temporary data structure having virtual file (e.g., VM image), and [0061] “retrieve the user’s enrollment and transaction certificates from the certificate authority…”).
Regarding claim 9, the claim is rejected by the same reasons set forth above to claim 1. Furthermore, Patel teaches: wherein obtaining the blockchain reference comprises retrieving the blockchain reference from the virtual file in response to a user request via the document authoring application to open the document corresponding to the virtual file (Patel: pars. [0052] smart contract is also interpreted as virtual file having code (e.g., hash code/keys/reference), par. [0053] “…receives a hash and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor. If the hashes of the hash identifier and the hash created from the stored identifier template data match, then the chaincode sends an authorization key to the requested service. The chaincode may write to the blockchain data associated with the cryptographic details.”, wherein the authorization key is interpreted as the reference to the user request service, and par. [0172] temporary data structure having virtual file (e.g., VM image), and [0061] “retrieve the user’s enrollment and transaction certificates from the certificate authority…”, see further in figs. 3, 16-17).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of Patel with the above indicated limitation with the teachings of Candelario and Habouzit. The motivation would be allowed for a skill artisan to perform the accessing and retrieving the blockchain reference from the virtual file in the virtual file system in response to the user request to open the document.
Regarding claim 10, the claim is rejected by the same reasons set forth above to claim 1. Furthermore, Patel teaches: wherein the document has multiple versions and each version of the document is stored by a separate block of the blockchain (see Figs. 9B and 12, wherein each block of the blockchain contain unique version, see par. [0098] “An entry block is then formed to include first tracking value and to include or reference the video file, at 1173. The entry block may be a genesis block including or referencing the original video file or may be a new appended block in the blockchain including or referencing data and/or changes performed relative to the original video file. In this latter case, the blockchain may, for example, reference n−1 versions of the original video file (e.g., which may be the original video file itself or a processed version of that file)…”, and par. [0101] as well disclose the multiple versions of the video file=document, see [0102] “The digital content may include one or more media files and associated information. The media files may contain images, video, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspects of the blockchain serve as a safeguard to protect the integrity, validity, and authenticity of the digital content,…”).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of Patel with the above indicated limitation with the teachings of Candelario and Habouzit. The motivation would be allowed for a skill artisan to facilitate the multiple versions and each version of the document that is stored by a separate block of the blockchain for archiving purpose.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Candelario, Habouzit, and Patel, and further in view of Greenblatt et al., US Patent No. 11,295,029 B1 (hereinafter as “Greenblatt”).
Regarding claim 7, the claim is rejected by the same reasons set forth above to claim 1 and 6. However, Candelario, Habouzit, and Patel do not explicitly teach a feature of “a shell extension.”
In the same field of endeavor, Greenblatt teaches:
wherein a shell extension and/or a background service runs on the computing device (Greenblatt: see col. 8, line 36, e.g., “a shell type running the process…”; Patel: pars. [0039] and [0047] e.g., blockchain base or platform services (e.g., cryptographic trust services, etc.), which is interpreted as the background service) and
wherein the shell extension and/or the background service provide the virtual file system (Greenblatt: see col. 8, line 36 “a shell type running the process”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Greenblatt would have provided Candelario, Habouzit and Patel with a shell extension for allowing a skill artisan in motivation as modifies to the document processing more efficient.
Claims 12, 17, 19-20, and 23-25 are rejected under 35 U.S.C. 103 as being unpatentable over Greenblatt et al., US Patent No. 11,295,029 B1 (hereinafter as “Greenblatt”) and further in view of Patel et al., US Pub. No. 2020/0159891 A1 (hereinafter as “Patel”).
Regarding independent claim 12, Greenblatt teaches a method for accessing document by a computing device (see Fig. 1), the method comprising:
providing, by the computing device, virtual file system comprising one or more virtual files (Fig. 1, elements 102 – client side and 110 – File system may be Virtual File System (VFS), and see col. 8, lines 1-7, e.g., ‘virtual file system” having the virtual file(s); and col. 9, lines 45-56: wherein the image file(s) is interpreted as the virtual file), each one of the one or more virtual files corresponding to a respective document stored in a blockchain by a document management system (Fig. 1 at element 140 as document management system remote from the computing device at element 102; and col. 9, lines 45-56: wherein the image file(s) is interpreted as the virtual file; and col. 12, lines 23-37: wherein the electronic file(s) is a document; and col. 19, lines 59-61 and lines 64-67 via “block chaining” is interpreted as blockchain);
receiving, by the computing device, user input to open a document corresponding to a selected virtual file of the one or more virtual files, the selected virtual file comprises a blockchain reference indicative of the blockchain having stored therein the document (Fig. 1, Fig. 2, element 204; col. 7, lines 59-67, e.g., “metadata” interpreted as the blockchain reference (Fig. 1 at element 140 and col. 14, line 20, e.g., “Blockchain”)).
causing a document authoring application to transmit a document access request for the document corresponding to the selected virtual file to the document management system, the document access request comprising the blockchain reference (again in col. 1, lines 62-63: “sending the message from the computer system to a server”; Fig. 1, element 140 is shown the server having files having metadata/key as reference stored in blocks that equate blockchain; Fig. 2, elements 204 and 206 shown as the transmitting the file=document open=access request; and col. 10, lines 55-56 that the access request may include a decryption key=reference; see further in col. 12, lines 12-22 disclose the request includes reference(s) of blocked file(s), and col. 18, lines 65-67 and col. 19, lines 1-12 disclose request may include information, e.g., the file information and classifier information as interpreted as the blockchain/file reference).
Greenblatt does not explicitly teach the limitations: “receiving, by the computing device, contents of the document corresponding to the selected virtual file; and outputting, by the computing device, at least in part the contents of the document.”
In the same field of endeavor (i.e., data processing), Patel teaches:
receiving, by the computing device, contents of the document corresponding to the selected virtual file (e.g., digital contents of the video, see pars. [0002-3]; par. [0098] discloses the video file as interpreted as the virtual file); and
outputting, by the computing device, at least in part the contents of the document (Fig. 15 as shown the output at least in part content of the document, and pars. [0054] and [0172] teaches the output of smart contract and hash codes are interpreted as outputting at least in part contents).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Patel would have provided Greenblatt with the above indicated limitations for performing output at least in part contents of the document from the temporary data structure/ledger(s) (Patel: fig. 15, pars. [0052, 54, and 117-118]).
Regarding claim 17, Patel teaches:
receiving user input to save a current version of the document (par. [0003] “ an interface, a storage area, and a processor that is configured to perform one or more of an interface to receive and store a video file, a storage area to store a blockchain that references the video file, the blockchain which includes a plurality of cryptographically linked blocks in an ordered sequence, each of the plurality of blocks which includes a header, a version of the video file with metadata, and a tracking value, the version of the video file in each of the plurality of blocks which corresponds to an original version of the video file or a processed version of the video file, …”); and
causing the document authoring application to transmit a document save request to the document management system (again par. [0003] “receive and store a video file”), the document save request comprises the blockchain reference and the current version of the document (pars. [0033] “…store a blockchain that references the video file, the blockchain which includes a plurality of cryptographically linked blocks in an ordered sequence, each of the plurality of blocks which includes a header, a version of the video file with metadata, and a tracking value, the version of the video file in each of the plurality of blocks which corresponds to an original version of the video file or a processed version of the video file, and a processor to append each of the plurality of blocks, except an entry block, to a previous block of the plurality of blocks with no change to the previous block to form the blockchain”, and pars. [0047-48] via “receive and store” algorithm, and pars. [0117] wherein the “version number” is indicated the current/lastest version, and [0118]).
Regarding claim 19, Patel teaches: wherein the document has multiple versions and each version of the document is stored by a separate block of the blockchain (see Figs. 9B and 12; and par. [0098] “An entry block is then formed to include first tracking value and to include or reference the video file, at 1173. The entry block may be a genesis block including or referencing the original video file or may be a new appended block in the blockchain including or referencing data and/or changes performed relative to the original video file. In this latter case, the blockchain may, for example, reference n−1 versions of the original video file (e.g., which may be the original video file itself or a processed version of that file)…”, and par. [0101] as well disclose the multiple versions of the video file=document).
Regarding independent claim 20, Greenblatt teaches a method for accessing a document by a document management system, the method comprising:
obtaining, by the document management system, a document access request to access a document based on an access attempt of a virtual file corresponding to the document by a document authoring application (Fig. 1, and Fig. 2, element 204; and col. 3, lines 8-10 e.g., “the file access request includes an open request, a read request, a write request, or a permission change request”; col. 9, lines 45-56: wherein the image file(s) is interpreted as the virtual file; and col. 12, lines 23-37: wherein the electronic file(s) is a document).
Greenblatt does not explicitly teach the limitations: “searching, by the document management system, for the blockchain corresponding to the blockchain reference in a register; identifying, by the document management system, the blockchain corresponding to the blockchain reference and accessing a block of the blockchain storing a latest version of the document; and transmitting, by the document management system, a temporary file corresponding to the latest version of the document to the document authoring application.”
In the same field of endeavor (i.e., data processing), Patel teaches:
searching, by the document management system, for the blockchain corresponding to the blockchain reference in a register (pars. [0050] “register” and [0093] “generate, manage, and track a blockchain of digital content for purposes of establishing an immutable chain-of-custody for the content 1100…”; and par. [0133] “by querying the blockchain for the transaction history of the tracking values across the blocks….”).
identifying, by the document management system, the blockchain corresponding to the blockchain reference (Figs. 3 and 12, element 1200, e.g., blockchain having blocks (fig. 13 described each of blocks in identified blockchain); and par. [0103] “The blockchain… each block of the blockchain may store a hash value of reference information (e.g., header, tracking value, etc.) along the associated digital content.”), and accessing a block of the blockchain storing a latest version of the document (Fig. 9B, wherein each data block of the blockchain storing “version” of file”, pars. [0098] and [0117] wherein the “n−1 versions” and “version number” inherit the new/latest version as known by a skill artisan, and [0118]; and par. [0102] “ The media files may contain images, video, graphics, animations, web pages, documents, or other forms of digital content.”); and
transmitting, by the document management system, a temporary file corresponding to the latest version of the document to the document authoring application (see par. [0098] “…. the blockchain may, for example, reference n−1 versions of the original video file (e.g., which may be the original video file itself or a processed version of that file)…”, wherein the “n-1 versions” include latest version, and par. [0101] as well disclose the multiple versions of the video file=document; and par. [0052] teaches the “temporary” data structure is interpreted as the temporary file, and par. [0153] “…store records, including a copy of a shared ledger for the blockchain and the blockchain itself. In one embodiment, the participants may have local or temporary ledgers, which may store processing changes of the video file before it is endorsed and approved through consensus. Once there is endorsement and consensus, the blockchain may be appended with a new block to reflect the processing change and the shared ledger may be updated accordingly for storage on all participant computers in the network.”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Patel would have provided Greenblatt with the above indicated limitations for performing output at least in part contents of the document from the temporary data structure/ledger(s) (Patel: fig. 15, pars. [0052, 54, and 117-118]).
Regarding claim 23, Greenblatt and Patel, in combination, teach:
receiving a document save request from the document authoring application (Greenblatt: Fig. 2, element 204; and col. 3, lines 8-10 e.g., “the file access request includes an open request, a read request, a write request, or a permission change request”; and Patel: see par. [0003] “ an interface, a storage area, and a processor that is configured to perform one or more of an interface to receive and store a video file, a storage area to store a blockchain that references the video file, the blockchain which includes a plurality of cryptographically linked blocks in an ordered sequence, each of the plurality of blocks which includes a header, a version of the video file with metadata, and a tracking value, the version of the video file in each of the plurality of blocks which corresponds to an original version of the video file or a processed version of the video file, and a processor to append each of the plurality of blocks), the document save request comprises the blockchain reference and a current version of the document (Patel: pars. [0033] “…store a blockchain that references the video file, the blockchain which includes a plurality of cryptographically linked blocks in an ordered sequence, each of the plurality of blocks which includes a header, a version of the video file with metadata, and a tracking value, the version of the video file in each of the plurality of blocks which corresponds to an original version of the video file or a processed version of the video file, and a processor to append each of the plurality of blocks, except an entry block, to a previous block of the plurality of blocks with no change to the previous block to form the blockchain”, and pars. [0047-48] via “receive and store” algorithm, and pars. [0117] wherein the “version number” is indicated the current/lastest version, and [0118]);
identifying the blockchain corresponding to the blockchain reference of the document save request (Patel: par. [0003] “one or more of an interface to receive and store a video file, a storage area to store a blockchain that references the video file, the blockchain which includes a plurality of cryptographically linked blocks in an ordered sequence, each of the plurality of blocks which includes a header, a version of the video file with metadata, and a tracking value, the version of the video file in each of the plurality of blocks which corresponds to an original version of the video file or a processed version of the video file,…”); and
storing the current version of the document as a new block of the blockchain (Patel: Fig. 9A illustrated an embodiment of a process to add a new block to a distributed ledger of a blockchain; and par. [0098] “a new appended block in the blockchain including or referencing data and/or changes performed relative to the original video file. In this latter case, the blockchain may, for example, reference n−1 versions of the original video file (e.g., which may be the original video file itself or a processed version of that file)”).
Regarding claim 24, Patel teaches wherein storing the current version comprises:
generating an encrypted version of the current version of the document based on encrypting the current version of the document with a symmetric encryption key (pars. [0098] “reference n−1 versions of the original video file (e.g., which may be the original video file itself or a processed version of that file).“), and [0054] “…a set of key/value versions that were read in the chaincode (read set), and the set of keys/values that were written in chaincode (write set)” and par. [0134] “a symmetric encryption is used”);
generating an encrypted version of symmetric key based on encrypting the symmetric encryption key with a public key of a user that created the current version of the document (par. [0079] “a public key and certificate, a signature of the client, identities of endorsers, endorser signatures, a proposal hash, chaincode events, response status, namespace, a read set (list of key and version read by the transaction, etc.), a write set (list of key and value, etc.), a start key, an end key, a list of keys, a Merkel tree query summary, and the like.”; and par. [0134] “public keys…”); and
storing in the new block the encrypted version of the current version of the document and the encrypted version of symmetric key (pars. [0098 and 134] as explained above to storing versions and symmetric encryption key).
Regarding claim 25, Patel teaches wherein accessing the block of the blockchain storing the latest version of the document comprises:
obtaining a private key of a user that created the latest version of the document based on a user identifier stored in the block (pars [0134], e.g., “private keys, public keys,…” and [0173] “a public key – private key pair”);
decrypting an encrypted symmetric encryption key stored in the block with the private key to obtain a symmetric encryption key (par. [0133] “decrypting the tracking value of the block that is most currently included (e.g., the last (N.sup.th) block), and then continuing to decrypt the tracking value of the other blocks until the genesis block is reached and the original video file is recovered. The decryption may involve decrypting the headers and video files and associated metadata at each block, as well.”, and pars [0134], e.g., “private keys, public keys,…” and [0173] “a public key – private key pair”, and [0173] “The encrypted file f(file) may be decrypted 210”); and
decrypting an encrypted version of the document stored in the block with the symmetric encryption key to obtain the latest version of the document (par. [0133] “decrypting the tracking value of the block that is most currently included (e.g., the last (N.sup.th) block), and then continuing to decrypt the tracking value of the other blocks until the genesis block is reached and the original video file is recovered. The decryption may involve decrypting the headers and video files and associated metadata at each block, as well.”, and pars. [0098 and 134] as explained above to storing versions and symmetric encryption key, and [0173], e.g., “The encrypted file f(file) may be decrypted 2100…”).
Claims 13-16, 18, and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Greenblatt and Patel, and further in view of Saurabh et al., US Pub. No. 20220114150 (hereinafter as “Saurabh”).
Regarding claim 13, the claim is rejected by the same reasons set forth above to claim 1. Greenblatt and Patel do not explicitly teach the limitations recite in the claim.
In the same field of endeavor (i.e., blockchain processing), Saurabh teaches:
receiving user input for an audit trail of the document (par. [0019] “query the ledger(s) containing the audit trail…” interpreted user input=query for the audit trail; par. [0098] “The chaincode receives a hash 605 and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor. If the hashes of the hash identifier and the hash created from the stored identifier template data match, then the chaincode sends an authorization key to the requested service. The chaincode may write to the blockchain data associated with the cryptographic details (e.g., thus confirming a transfer of the digital asset such as a log, record, alert or event to the audit trail 129; or identifying a discrepancy with a perspective transfer of a digital asset, etc.)…”, and [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129…”);
causing the document authoring application to transmit an audit request for the document to the document management system, the audit request comprises the blockchain reference (par. [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129, peer nodes 104-110 may generate an event to signify the completion of the update transaction and transmit the event to the application 124 or API 122 that generated the initial transaction request.”, wherein the chaincode (i.e., hash code/keys/identifier(s), digital assets) is interpreted as the reference, see further in pars. [0079] “digital assets as blocks written to the audit trail 129, group the storage transactions into blocks, and build a hash chain over the blocks.”, and [0086]);
receiving, by the computing device, contents of the audit trail of the document (par. [0098] “The chaincode receives a hash 605 and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor. If the hashes of the hash identifier and the hash created from the stored identifier template data match, then the chaincode sends an authorization key to the requested service. The chaincode may write to the blockchain data associated with the cryptographic details (e.g., thus confirming a transfer of the digital asset such as a log, record, alert or event to the audit trail 129; or identifying a discrepancy with a perspective transfer of a digital asset, etc.)…”, and [0112] “…The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129…”;
outputting, by the computing device, at least in part the contents of the audit trail (par. [0019] “The one or more digital assets that may comprise the audit trail can be forwarded from respective monitoring servers, logging servers and/or output from migration tools toward nodes of a blockchain network being utilized by a blockchain platform using an application programming interface (API) functionality to execute application code to implement one or more blockchain transactions. Administrators and/or auditors responsible for tracking the progress of the tasks can access and audit the blocks of the audit trail via the blockchain platform, query the ledger(s) containing the audit trail…”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the instant application to combine the teachings of the cited references because the teachings of Saurabh would have provided Greenblatt and Patel with the above indicated limitation for performing of audit trail for the file/document storing the blockchain more efficient security (Saurabh: Abstract, and pars. [0018-19]).
Regarding claim 14, Greenblatt, Patel and Saurabh, in combination, teach:
wherein the document authoring application is running on the computing device (Greenblatt: see in Fig. 1; and Patel: see Fig. 1, elements 120 and 124 are interpreted as the document authoring application which is running on the computing device, see fig. 10); and
wherein causing the document authoring application to transmit the document access request comprises transmitting, by the document authoring application, the document access request to the document management system (Greenblatt: Fig. 1, Fig. 2; and col. 1, lines 62-63: “sending the message from the computer system to a server”; and Patel: fig. 14 and fig. 17, wherein the “Application” is interpreted as the document authoring application; and par. [0053] “the chaincode receives a hash and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor. If the hashes of the hash identifier and the hash created from the stored identifier template data match, then the chaincode sends an authorization key to the requested service. The chaincode may write to the blockchain data associated with the cryptographic details.”, and par. [0055] as well for transmitting request algorithm); and
wherein causing the document authoring application to transmit the audit request comprises transmitting, by the document authoring application, the audit request to the document management system (Saurabh: see fig. 2A; and par. [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129, peer nodes 104-110 may generate an event to signify the completion of the update transaction and transmit the event to the application 124 or API 122 that generated the initial transaction request.”, wherein the chaincode (i.e., hash code/keys/identifier(s), digital assets) is interpreted as the reference, see further in pars. [0079] “digital assets as blocks written to the audit trail 129, group the storage transactions into blocks, and build a hash chain over the blocks.”, and [0086]).
Regarding claim 15, Patel and Saurabh teach:
wherein receiving the contents of the document comprises receiving, by the document authoring application, a temporary file comprising the blockchain reference and the contents of the document corresponding to the selected virtual file (Patel: par. [0052] discloses the “temporary data” and “smart contract” of the blockchain include as the blockchain reference, and par. [0153] “…store records, including a copy of a shared ledger for the blockchain and the blockchain itself… local or temporary ledgers, which may store processing changes of the video file before it is endorsed and approved through consensus. Once there is endorsement and consensus, the blockchain may be appended with a new block to reflect the processing change and the shared ledger may be updated accordingly for storage …”, wherein the video file includes the content of document/file);
wherein the audit request comprises the blockchain reference of the temporary file (Saurabh: par. [0019] “…the audit trail can be forwarded from respective monitoring servers, logging servers and/or output from migration tools toward nodes of a blockchain network being utilized by a blockchain platform using an application programming interface (API) functionality to execute application code to implement one or more blockchain transactions… responsible for tracking the progress of the tasks can access and audit the blocks of the audit trail via the blockchain platform, query the ledger(s) containing the audit trail, …” wherein the query=request; par. [0097] “The code may be used to create a temporary data structure in a virtual machine or other computing platform. Data written to the blockchain can be public and/or can be encrypted and maintained as private. The temporary data that is used/generated by the smart contract is held in memory by the supplied execution environment, then deleted once the data needed for the blockchain is identified” wherein the smart contract code used to create temporary data structure is interpreted as the reference of the temporary file); and
wherein receiving the contents of the audit trail comprises receiving, by the document authoring application, the audit trail (Saurabh: par. [0019] “query the ledger(s) containing the audit trail…”; par. [0098] “The chaincode receives a hash 605 and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor. If the hashes of the hash identifier and the hash created from the stored identifier template data match, then the chaincode sends an authorization key to the requested service. The chaincode may write to the blockchain data associated with the cryptographic details (e.g., thus confirming a transfer of the digital asset such as a log, record, alert or event to the audit trail 129; or identifying a discrepancy with a perspective transfer of a digital asset, etc.)…”, and [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129…”).
Regarding claim 16, Patel and Saurabh teach: wherein the document authoring application (Patel: fig. 1, elements 124 and 120, fig. 17 via Application(s) for authoring user/member requests, and par. [0046] “The blockchain configuration may include one or more applications 124 linked to application programming interfaces (APIs) 122 to access and execute stored program/application code 120 (e.g., chaincode, smart contracts, etc.) which can be created according to a customized configuration sought by participants and can maintain their own state, control their own assets, and receive external information. This can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain nodes 104-110.”) comprises
a software add-in for transmitting the document access request (Patel: fig. 14 and fig. 17, wherein the “Application” is interpreted as the document authoring application; and par. [0053] “the chaincode receives a hash and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor. If the hashes of the hash identifier and the hash created from the stored identifier template data match, then the chaincode sends an authorization key to the requested service. The chaincode may write to the blockchain data associated with the cryptographic details.”, and par. [0055] as well for transmitting request algorithm),
receiving the temporary file (Patel: pars. [0003] discloses “a version of the video file” is interpreted as the latest version corresponding to “an original version of the video file”, and [0004]; par. [0052] wherein the “temporary” data structure is interpreted as the temporary file, and par. [0153] “…store records, including a copy of a shared ledger for the blockchain and the blockchain itself. In one embodiment, the participants may have local or temporary ledgers, which may store processing changes of the video file before it is endorsed and approved through consensus. Once there is endorsement and consensus, the blockchain may be appended with a new block to reflect the processing change and the shared ledger may be updated accordingly for storage on all participant computers in the network.”; and pars. [0117] wherein the “version number” is indicated the new/latest version, and [0118]),
transmitting the audit request (Saurabh: par. [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129, peer nodes 104-110 may generate an event to signify the completion of the update transaction and transmit the event to the application 124 or API 122 that generated the initial transaction request.”, wherein the chaincode (i.e., hash code/keys/identifier(s), digital assets) is interpreted as the reference, see further in pars. [0079] “digital assets as blocks written to the audit trail 129, group the storage transactions into blocks, and build a hash chain over the blocks.”, and [0086]),
receiving the audit trail (Saurabh: par. [0019] “query the ledger(s) containing the audit trail…”; par. [0098] “The chaincode receives a hash 605 and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor. If the hashes of the hash identifier and the hash created from the stored identifier template data match, then the chaincode sends an authorization key to the requested service. The chaincode may write to the blockchain data associated with the cryptographic details (e.g., thus confirming a transfer of the digital asset such as a log, record, alert or event to the audit trail 129; or identifying a discrepancy with a perspective transfer of a digital asset, etc.)…”, and [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129…”), and
outputting the audit trail (Saurabh: par. [0019] “The one or more digital assets that may comprise the audit trail can be forwarded from respective monitoring servers, logging servers and/or output from migration tools toward nodes of a blockchain network being utilized by a blockchain platform using an application programming interface (API) functionality to execute application code to implement one or more blockchain transactions. Administrators and/or auditors responsible for tracking the progress of the tasks can access and audit the blocks of the audit trail via the blockchain platform…”).
Regarding claim 18, Patel and Saurabh teach: wherein the document authoring application is running on at least one server remote from the computing device (Patel: see Abstract, e.g., “one or more of authorizing a blockchain for a video file…”; and fig. 1, element 120, 122-124 are authoring application is running on at least server remote from the peers computing device(s); and fig. 3 and fig. 15) and accessible by the computing device via a web browser running on the computing device (Saurabh: pars. [0054] e.g., “The applications are accessible from various client devices through a thin client interface such as a web browser…”, and [0063] “cloud computing environment 300 includes one or more cloud computing nodes 310 with which customers can access using client devices operated or configured by cloud consumers. Nodes 310 of the cloud computing environment 300, such as one or more host systems or edge devices may communicate with one another and may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This may allow the cloud computing environment 300 to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on the client devices 318a-318n connecting or communicating with the nodes 310 of the cloud network 250. It is understood that the types of client devices 318a-318n connected to the cloud computing environment 300 are intended to be illustrative only and that computing nodes 310 of the cloud computing environment 300 can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser)”).
Regarding claim 21, Patel and Saurabh teach:
receiving an audit request for an audit trail of the document from the document authoring application, the audit access request comprising the blockchain reference (Patel: fig. 1, element 120 – Application code is authoring application; Saurabh: fig. 2A, element 120; and par. [0019] “query the ledger(s) containing the audit trail…”; par. [0098] “The chaincode receives a hash 605 and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor. If the hashes of the hash identifier and the hash created from the stored identifier template data match, then the chaincode sends an authorization key to the requested service. The chaincode may write to the blockchain data associated with the cryptographic details (e.g., thus confirming a transfer of the digital asset such as a log, record, alert or event to the audit trail 129; or identifying a discrepancy with a perspective transfer of a digital asset, etc.)…”, and [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129…”);
obtaining the audit trail of the blockchain corresponding to the blockchain reference (Saurabh: fig. 5A, elements 102, 120 and 529; and par. [0099] wherein the chaincode and signature are interpreted as the blockchain reference); and
transmitting the audit trail to the document authoring application (Saurabh: par. [0101] “…verify (a) that the transaction proposal 59 to add the digital asset to the block comprising the audit trail 129 …”, fig. 5A elements 102, 120, and 529).
Regarding claim 22, Patel and Saurabh teach:
wherein receiving the document access request from the document authoring application comprises receiving the document access request from a software add-in of the document authoring application configured to interface the document authoring application with the document management system (Patel: par. [0046] “The blockchain configuration may include one or more applications 124 linked to application programming interfaces (APIs) 122 to access and execute stored program/application code 120 (e.g., chaincode, smart contracts, etc.) which can be created according to a customized configuration sought by participants and can maintain their own state, control their own assets, and receive external information. This can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain nodes 104-110.” Wherein the own application/software is interpreted as the software add-in for obtaining/receiving the blockchain reference, see fig. 1, elements 124,120, fig. 17; and Saurabh: fig. 2A, elements 120, and 124; par. [0019] and [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129, peer nodes 104-110 may generate an event to signify the completion of the update transaction and transmit the event to the application 124 or API 122 that generated the initial transaction request.”); and
wherein receiving the audit request comprises receiving the audit request from the software add-in of the document authoring application (Patel: par. [0046] “The blockchain configuration may include one or more applications 124 linked to application programming interfaces (APIs) 122 to access and execute stored program/application code 120 (e.g., chaincode, smart contracts, etc.) which can be created according to a customized configuration sought by participants and can maintain their own state, control their own assets, and receive external information. This can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain nodes 104-110.” wherein the own application/software is interpreted as the software add-in for obtaining/receiving the blockchain reference, see fig. 1, elements 124,120, fig. 17; and Saurabh: fig. 2A, elements 120, and 122 - API; par. [0019] and [0112] “…receiving the original update request which invoked the chaincode to update the ledger comprising the audit trail 129. The peer nodes 104-110 may validate the blocks received from the ordering node and if the update request is considered valid, each peer node receiving a block from the ordering node may update their copy of the ledger of the audit trail 129 maintained by each peer node 104-110 (if a consensus was reached by the peer nodes 104-110 to perform the update transaction). In some embodiments, upon a validated update of the ledger comprising the audit trail 129, peer nodes 104-110 may generate an event to signify the completion of the update transaction and transmit the event to the application 124 or API 122 that generated the initial transaction request.”).
Response to Arguments
Referring to claim rejection under 35 USC §101 as being abstract idea to claim 20-25, Applicant’s arguments (see Remarks, pages 8-10) have been fully considered, but are not persuasive.
Regarding independent claim 20, Applicant argued that “Applicant does not concede that the step of “identifying […] the blockchain corresponding to the blockchain reference” is performable by the human mind (Remarks, page 9, at second paragraph).
Examiner is not persuaded. According MPEP §2106.04(a)(2) (part III – Mental Processes”) under analysis of Step 2A (Prong I), the limitation/step of “identifying, …, the blockchain corresponding to the blockchain reference”, as drafted, is a mental process, which is performed in human mind (e.g., observations, evaluations, judgments, and/or opinions), or by a human using a pen and paper, but for the recitation of generic computer component(s), see CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). In claim 20, the generic computer component(s) is the “document management system” which is performed “the searching” for “the blockchain corresponding to the blockchain reference in a register” for coming up the step of “identifying […] the blockchain…”.
Also, claim 20 does not recite additional elements/limitations that integrate the judicial exception into a practical application. Examiner respectfully submits that the addition element of “the document management system” is known as generic computing component(s) (see Applicant’s Drawings at Figure 11) using for performing the computing functionality as known in the technical field in use as tool(s) component (see Mayo, 566 U.S. AT 84). Also, the additional steps of “obtaining,…, a document access request…”, “searching,…, for the blockchain…”, and “transmitting…” represent insignificant extra solution activities because these additional limitations/steps do not specify “how” to perform/process data (see Applicant’s Drawings at Figure 7A-7B for the purpose of specifying in details of accessing, auditing, updating document in the blockchain infrastructure architecture). Seemly reciting the common additional limitations/steps including the amended limitations/steps does not impose any meaningful limits on practicing the abstract idea (see MPEP §2106.04(a)-(h)).
Finally, claim 20 does not recite any additional element(s)/limitation(s) beyond the judicial exception that, alone or in combination, were not “well-understood, routine, conventional” (see MPEP §2106.05(d)). The addition element of “the document management system” is known a highly computing component(s), and the additional steps of “obtaining,…, a document access request…”, “searching,…, for the blockchain…”, and “transmitting…” representing insignificant extra solution activities that as known by a skill artisan in the relevant technical field of receiving/obtaining and transmitting data over a network, e.g., using the Internet to gather data/information, see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362, and storing/retrieving information/data in memory, see Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015)
For at least above reasons, the rejections are maintained.
Referring claim rejections under 35 USC §103, Applicant’s arguments (see Remarks, pages 10-13) to claim 1 (similar to respective claims 12 and 20) and claim 12 (see Remarks, pages 13-15) have been fully considered but are not persuasive.
A/ Regarding independent claim 1, Applicant argued that Candelario does not disclose a “virtual file” on the client device from which a document authoring application obtains a “blockchain reference” (see Remarks, page 11, 3rd paragraph)
Examiner is not persuaded. Candelario teaches the “receiving credential document information associated with the credential document” (Abstract), and the credential document having document information sending from credentialing system node (par. [0019]: “A document can be a file and a set of metadata fields associated with that file. Each type of credential document can have different required metadata fields”). The number of nodes should include the credentialing system node, which comprised of: One Swirlds node or virtual machine and the filesystem storage can be located on either virtual machine […] (par. [0040], and par. [0046]: “Each node can consist of two virtual machines: The Hashgraph node itself and the database instance. A single database user is created for the Hashgraph node's use. The database access credentials are unique for each node, such that node A's Hashgraph machine can only access node A's database instance.”). Technically, the credential document and/or hashgraph and database instance in the virtual machine(s) should embed the virtual document/file. Candelario further discloses in pars. [0047] “the blockchain data”, and [0093] (emphasis added): “In another example of the fifth aspect and the above examples, each node of the plurality of nodes implements a consensus algorithm and includes a file system to store the documents. For example, the consensus algorithm and the file system are implemented in a virtual machine at the node... In an additional example, each node includes a block logger to log events. In a further example, each node includes an encryption system to encrypt documents” that teaches the virtual file, respectively, and the “consensus algorithm” embedded the reference of blockchain, e.g., Proof of Work (PoW): Used by Bitcoin, PoW requires miners to solve complex mathematical puzzles to validate transactions and add new blocks. It is highly secure but energy-intensive; Proof of Stake (PoS): Validators are chosen based on the amount of cryptocurrency they stake. It is more energy-efficient than PoW but can lead to centralization if wealthier participants dominate; Delegated Proof of Stake (DPoS): Token holders vote for delegates who validate transactions. It offers faster transaction processing but may risk centralization if a few delegates gain excessive power; Practical Byzantine Fault Tolerance (PBFT): Nodes exchange messages to agree on the system's state, requiring a supermajority to finalize decisions. It is efficient but less scalable for large networks; Proof of Authority (PoA): A small group of trusted validators is pre-selected to validate transactions. It is efficient but sacrifices decentralization; Proof of Space and Time (PoST): allocated storage space and waited a specific time. It is energy-efficient but requires significant storage resources (see definition in the link https://www.bing.com/search?q=blockchain+consensus+algorithms&FORM=QSRE1).
Since the claim does not require any particular “virtual file” and “blockchain reference”, hence, the credential documents, database instance(s), a block logger associated with consensus algorithm having protocols in the “virtual machine” (in comparing to Applicant’s Drawings at Figures 2A-2B, 3 (element 202 and 230), and Figure 8A at element 802), should be matched as broadest reasonable interpretation. See MPEP §2111 – Claim Interpretation.
B/ Regarding independent claim 12, Applicant argued that Greenblatt does not disclose a client OS-level virtual file system whose virtual files correspond to documents stored in a blockchain by a remote document management system, nor that a selected virtual file comprises a blockchain reference indicative of such a blockchain” (see Remarks, page 14).
Examiner is not persuaded. Greenblatt teaches, discloses, or expressly suggests the file system 110 may a virtual file system (VFS), which can comprise the virtual files at the client system 102 (see Fig. 1, element 110; and col. 8, lines 1-7) (in comparing to Applicant’s Drawings at Figures 2A-2B, 3 (element 202 and 230), and Figure 8A at element 802). Greenblatt further teaches “the block chaining (CBC) associated with symmetric file keys (Fig. 1, elements 140, in particular at elements 120-144; and col. 19, lines 59-67 to col. 20, lines 1-3: wherein the “hash-based symmetric key”/keys is/are inherited to blockchain reference). Since the claim does not require any particular “blockchain reference”; hence, the hash-based symmetric key(s) in the block chaining of Greenblatt should be matched as broadest reasonable interpretation (see MPEP §2111 – Claim Interpretation). As result, Greenblatt teaches the association/correspondence between the virtual file in the virtual system at the system 102 and the encrypted files/documents in the remote system 140 via cloud network 130 (Greenblatt: Fig. 1).
Also, examiner respectfully submits that Patel, in the same field of endeavor (i.e., data processing), teaches, discloses, or expressly suggests the limitations “receiving, by the computing device, contents of the document corresponding to the selected virtual file” (Fig. 15 as shown the output at least in part content of the document, which corresponds to the virtual file, see further details in pars. [0002-3]: digital contents of the video, and [0098] discloses the video file as interpreted as the virtual file), and “outputting, by the computing device, at least in part the contents of the document” (Fig. 15 as shown the output at least in part content of the document, and pars. [0054] and [0172] teaches the output of smart contract and hash codes are interpreted as outputting at least in part contents).
For at least above reasons, the rejections are maintained.
Any other claims argued merely because of dependency on the previouslyargued claims 1 and 12 in the arguments presented to the examiner filed on 03/06/2026 are moot in view of the examiner's interpretation of the claims and art and are still considered rejected based on their respective rejections from at least a prior Office action (part(s) of recited above details).
The Examiner respectfully reminds Applicant of the broadest reasonable interpretation standard (see MPEP §2111 – Claim Interpretation, e.g., "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).
Prior Arts
The prior art made of record on form PTO-892 and not relied upon is considered pertinent to applicant's disclosure. Applicant is required under 37 C.F.R. § 1.111(c) to consider these references fully when responding to this action.
It is noted that any citation to specific, pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. See In re Heck, 699 F.2d 1331, 1332-33, 216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275,277 (CCPA 1968)); Merck & Co. v. Biocraft Laboratories, 874 F.2d 804, 10 USPQ2d 1843 (Fed. Cir.), cert. denied, 493 U.S. 975 (1989).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jessica N. Le whose telephone number is (571)270-1009. The examiner can normally be reached M-F 9:30 am - 5:30 pm (EST).
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, SHERIEF BADAWI can be reached on (571) 272-9782. 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.
/Jessica N Le/Examiner, Art Unit 2169
/SHERIEF BADAWI/Supervisory Patent Examiner, Art Unit 2169
Prosecution Insights