DETAILED ACTION
This is an office action on the merits in response to the communication filed on 9/22/2025.
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 .
Claims’ Status
Claims 1-18 are cancelled. Claims 19, 25, and 31 are amended. Claims 19-36 are pending and are considered in this office action.
Priority
CONTINUATION
This application is a continuation application of U.S. application no. 15/857093 filed on December 28, 2017, now U.S. Patent US11631077 (“Parent Application”). See MPEP §201.07. In accordance with MPEP §609.02 A. 2 and MPEP §2001.06(b) (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also in accordance with MPEP §2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicants desire the information to be printed on a patent issuing from this application. See MPEP §609.02 A. 2. Finally, Applicants are reminded that the prosecution history of the Parent Application is relevant in this application. See e.g., Microsoft Corp. v. Multi-Tech Sys., Inc., 357 F.3d 1340, 1350, 69 USPQ2d 1815, 1823 (Fed. Cir. 2004) (holding that statements made in prosecution of one patent are relevant to the scope of all sibling patents).
Response to Arguments/Comments
103 Rejection
Applicant's arguments have been fully considered but they are not persuasive. In response to applicant's argument that the examiner has combined an excessive number of references, reliance on a large number of references in a rejection does not, without more, weigh against the obviousness of the claimed invention. See In re Gorman, 933 F.2d 982, 18 USPQ2d 1885 (Fed. Cir. 1991).
Furthermore, in response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the cited references are in the similar field of arts, which is data management on a blockchain, therefore there is motivation to combine these references.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 19, 20, 22, 25, 26, 28, 31, 32 and 34 are rejected under 35 U.S.C 103 as being obvious over Zinder et al. (US20170005804A1) in view of Hopkins et al. (US10521780B1) in view of Hankins et al. (US20150242643A1) in view of Tong (US20190280855A1), and further in view of Kirigin et al. (US20140067929A1).
With respect to claim 19, 25, and 31
Zinder teaches the limitations of:
a communication interface; a processor; and a memory having a blockchain application stored thereon, wherein the blockchain application, when executed by the processor, causes the processor to (fig.8 & [0146]):
receive, via a blockchain dashboard, a request from a first user to access the blockchain ([0008], A transceiver is configured to receive electronic data messages (including a first electronic data message) that includes a digital resource issuance request that is a request to issue a new amount of the resource. When a new request is received, the computer system is programmed to generate a blockchain transaction from a blockchain resource identifier (e.g., a blockchain address) to at least one participant identifier (e.g., another blockchain address). The generated transaction also includes a quantity value for this new resource that is to be issued or transferred.);
wherein the block comprises a transaction address and a transaction ID that identify a location of the data file within the blockchain ( [0057], An asset or resource record may include the participant identifier (e.g., for a corresponding company) that the asset is associated with, a unique identifier that is used to uniquely identify the asset on the blockchain (e.g., which may be, for example, a 160 bit hash value of a public key associated with the asset)….; see also [0058], Ledger storage 606, in conjunction with blockchain services 616, interfaces with the blockchain 618 to store records of validated (or to-be-validated) blockchain transactions. A record in ledger storage 606 may include source and destination identifiers that are mapped back to respective participants (e.g., stored in participant storage 602), a blockchain transaction ID, the unique identifier for the asset, an asset transaction quantity, a transaction date (e.g., when the transaction was submitted to the blockchain), a validation date (e.g., when this transaction was ultimately validated by the blockchain), a price per share, and/or a price of the asset transaction, etc.);
automatically update, through an application programming interface, a legacy system by appending the transaction address and the transaction ID to a legacy database within the legacy system (fig.1 & [0088], digital asset repository computer system 600 monitors, via the processor 608 and blockchain services 616, the blockchain 618 to determine when the submitted transaction has been validated by the blockchain. Responsive to determining the submitted transaction has been validated, ledger storage 606 (legacy system) is updated to reflect that the transaction stored in S20 has been validated by the blockchain. The digital asset repository computer system 600 may determine that a transaction has been validated by reviewing validated blocks of the blockchain 618 as they are published; [0058], A record in ledger storage 606 may include source and destination identifiers that are mapped back to respective participants (e.g., stored in participant storage 602), a blockchain transaction ID, the unique identifier for the asset, an asset transaction quantity, a transaction date (e.g., when the transaction was submitted to the blockchain), a validation date (e.g., when this transaction was ultimately validated by the blockchain), a price per share, and/or a price of the asset transaction, etc.), wherein the application programming interface enables two-way communication between the legacy system and the blockchain through the first decentralized application ([0093-0101] explain how steps S40, S42 & S46 of fig. 3A enable two-way communication between the Blockchain and the digital asset repository computer system; see also Fig. 7F which further demonstrates a web page that enables a user to begin the transfer of an asset.);
Zinder does not explicitly disclose, but Hopkins teaches:
receive authentication credentials from a first user (col.4 ln66-ln67, Parties to a contract may
-exchange keys or other credentials to enable access to each other's blockchains, see also col. 13 ln 63- col. 14 ln20);
determine, based on validating the authentication credentials of the first user, that the first user is authorized to access a first decentralized application (col.5 ln1-ln5, For example, a seller may be (e.g., via a cryptographic key) given access to a blockchain that includes buyer information such as loan information, insurance verification, driver's license, passport, social security number (SSN), or other identification verification, driving record, and so forth., see also col. 13 ln 63- col. 14 ln20);
detect, via a consensus algorithm, that the data file is valid (col.2 ln39-ln43, Implementations also take advantage of the consensus-reaching features of blockchain(s) to ensure that the sales transaction data or other data recorded in blockchain(s) is complete, accurate, and up-to-date; see also col.2 ln44-ln46 , An advantage of using blockchain(s) to store transaction data is the decentralized aspect of the consensus network for the blockchain(s); see also col.11 ln62-ln66 Because all users (e.g., financial institutions) need to know all previous transactions (e.g., deposits, withdrawals, etc.) to validate a requested transaction, all users must agree on which transactions have actually occurred, and in which order.);
provide, using a blockchain pier associated with the first user, selective access to the data file to the first user (col.6 ln29-ln39, Where applicable, a blockchain's multi-signature feature can be implemented to validate multiple party authorizations. Other individuals such as a lien-holder may also have access to keys that enable access to the vehicle. In some examples, a lien-holder may be able to disable access to the vehicle by other users, e.g., if loan payments are missed. The access control mechanism may also enable other features, such as disabling a vehicle if maintenance checks are overdue, blocking particular users (e.g., teen drivers) from using a vehicle during inclement weather, and so forth., see also col. 4 ln 66-col. 5 ln22);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Zinder with the teaching of Hopkins as they relate to data management on a blockchain. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the system of resource tracking in Zinder to include the method of using the first user credentials as taught by Hopkins for the predicated result of an improved system of a more user-friendly blockchain system.
Zinder in view of Hopkins do not explicitly disclose, but Hankins teaches:
detect one or more action items associated with the first user, wherein at least one action item comprises a request for a data file from the first user ([0157], As indicated above, a user may request an item, e.g., using the main screen of FIG. 11 or FIG. 13. In this regard, FIG. 28 is an example screen that may be used to send a file request in accordance with an example embodiment.)
based on detecting the one or more action items associated with the first user, transmit a notification to the first user, wherein the notification comprises a link that opens a window on the first user device, wherein the window is configured to allow the first user to upload the data file to the
(see fig.30, claim 14 and 15; see also [0016], Transfers of computer-storable assets to and/or from users associated with the respective top-level accounts through downloads and/or uploads of such assets are facilitated through respective dedicated portals and using respective allocated portions of the non-transitory data store,);
Examiner’s Note (Intended Use): The portion of the limitation which recites “…..is associated with a first transaction”, is merely a recited intended use of the data file. This portion is given little to no patentable weight because the limitation, or portion thereof, does not claim the function(s) as being positively recited actions or functions, and/or it does not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being “for…. [performing a specific functionality]”, etc. does not mean that the functions are required to be performed, or are actually performed.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Zinder/Hopkins with the teaching of Hankins as they relate to data management using decentralized database. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combined systems of Zinder/Hopkins, for example resource tracking in Zinder, to include the method of generating a link to allow the first user to upload a data file to a data store as taught by Hankins for the predicated result of an improved system of a more user-friendly blockchain system.
Zinder in view of Hopkins in view of Hankins do not explicitly disclose, but Tong teaches:
encrypt the data file using a cryptographic public key associated with the first user; append the data file to a block in the blockchain ([0044], The storage device can first generate initial data that corresponds to the identifier based on the identifier; update the initial data based on the data to be stored to updated data; generate the key pair that corresponds to the identifier, and encrypt the updated data as an encrypted data packet that corresponds to the identifier by using a public key in the key pair; generate the blockchain that corresponds to the identifier, and store the encrypted data packet in the blockchain; and store, in the blockchain network storage node, the blockchain that stores the updated encrypted data packet;),
based on updating the legacy system, automatically display the data file associated with the transaction address and the transaction ID by retrieving the data file from the blockchain using the transaction address and the transaction ID, wherein displaying the data file further comprises decrypting the data file using a cryptographic private key associated with the first user ([0070], decrypt the encrypted data packet based on the private key after retrieving the encrypted data packet that corresponds to the identifier, to obtain all data that corresponds to the identifier, and finally query all the data based on the data query instruction; [0060], In this implementation of the present application, an end-user device can determine a data query instruction, and proceed with a subsequent data query process. The end-user device can be a mobile phone, a tablet computer, a personal computer, a server, etc.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Zinder/Hopkins/Hankins with the teaching of Tong as they relate to data management using decentralized database. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combined systems of Zinder/Hopkins/Hankins, for example resource tracking in Zinder, to include the method of encrypting the data file and appending the data file to a block in the blockchain the first user credentials as taught by Hopkins for the predicated result of an improved system of a more user-friendly blockchain system.
Zinder in view of Hopkins in view of Hankins in view of Tong do not explicitly disclose, but Kirigin teaches:
detect that a second user has uploaded a second data file to the ([0048-0049], FIG. 4 depicts a method for allowing a content sharer to add files into a particular link sharer's content management account, which may contain, for example, various digital files and folders. The system may do this by generating a link that the content sharer uses to upload content directly into the link sharer's content management account. In various embodiments, the link facilitates the addition of files into a particular folder (or other upload location) specified by the link-sharer. In various embodiments, this may facilitate the consolidation of files from several different users into a single location…. Beginning at step 100, the file storage server system 20 (FIG. 1) receives a request, from a link sharer, to generate a link to a file set. Next, in step 102, the file storage server system generates a link in response to the request. The link is configured to cause the file storage server system to allow the link recipient to upload files to a location designated by the link (e.g., to a specified folder within the link sharer's account);
determine that the second data file requires an approval of the second data file from the first user ([0071], Various embodiments are described above as being adapted to: (1) automatically upload files to a designated location (e.g., any particular folder within the link sharer's account) if certain criteria are met; and (2) if the criteria are not met, to require manual approval of the files before they are uploaded to the designated location);
based on detecting the second data file, transmit, by executing(see claim 1, after the link recipient receives the file sharing link, receiving, by the content management system, an indication that the file sharing link has been activated by the link recipient; at least partially in response to receiving the indication that the file sharing link has been activated by the link recipient, facilitating, by the content management system, a display of a representation of the file set along with an interactive graphical element that may be activated to allow the link recipient to upload at least one file to the file set, wherein prior to uploading, the at least one file is absent from the file set;
receiving, by the content management system, an indication that the interactive graphical element has been activated by the link recipient; and at least partially in response to receiving the indication that the interactive graphical element has been activated, facilitating, by the content management system, uploading the at least one file to the file set.), wherein the second window is configured to allow the first user to submit an approval of the second data file ([0052], If the permission criteria are met, at step 116, the file storage server system automatically saves the link recipient's files to the linked file set. Otherwise, in step 114, the link recipient's uploaded files are stored in an upload location until the link sharer manually accepts each uploaded file (which the system may facilitate by displaying an appropriate message to the link sharer indicating that the files are awaiting approval). In step 118, if the link sharer accepts an uploaded file, the uploaded file is added, at step 120, to a location specified by the link such as the linked file set, another folder, or any other location that the link sharer designates.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Zinder/Hopkins/Hankins/Tong with the teaching of Kirigin as they relate to data management system. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combined systems of Zinder/Hopkins/Hankins/Tong, for example resource tracking in Zinder, to include the method of using a second user for uploading a second data file as taught by Kirigin for the predicated result of an improved system of a more user-friendly blockchain system.
With respect to claim 20, 26, and 32
The combination of Hopkins/Hankins/Tong/Kirigin teaches the limitations of claim 19, 25, and 31 respectively. Hopkins further teaches: wherein the blockchain application further causes the processor to:
detect a status of the first user; in response to detecting the status of the first user, determine that the first user is authorized to access a first set of decentralized applications (see col.4 ln66-col.5 ln12, Parties to a contract may exchange keys or other credentials to enable access to each other's blockchains. For example, a seller may be (e.g., via a cryptographic key) given access to a blockchain that includes buyer information such as loan information, insurance verification, driver's license, passport, social security number (SSN), or other identification verification, driving record, and so forth. The buyer's blockchain may also include data indicating that the driver's license, passport, or other credential of the buyer has been validated by a trusted authority, such as a government agency. A buyer may be given access to a blockchain that includes seller information such as reputation data (e.g., customer reviews), business history (e.g., how long the seller has been in business), and so forth.); and
display the first set of decentralized applications on a graphical interface (see col.8 ln7 – ln36, The buyer application 106 and the seller application 108 may each include a UI, and may be useable by a buyer and seller respectively to view information and perform actions associated with a transaction. The buyer application 106 and the seller application 108 may include any type of application, including but not limited to a mobile app, a web app, a native application, and so forth. In some examples, one or both of the buyer application 106 or the seller application 108 may include an artificial intelligence (AI) interface that automates at least a portion of the transaction processing.)
With respect to claim 22
The combination of Hopkins/Hankins/Tong/Kirigin teaches the limitations of claim 19. Hopkins further teaches: wherein the blockchain application further causes the processor to :receive authentication credentials from the second user, wherein the authentication credentials comprises a cryptographic key; determine, based on validating the authentication credentials of the second user, that the second user is authorized to access the set of encrypted data records; and decrypt the set of encrypted data records using the cryptographic key (col.15 ln44-ln60, The buyer application 106 may access (602) buyer information, such as loan information or other funding source information, stored on the blockchain(s) 122. Based on the accessed buyer information, the buyer application 106 may generate and provide (604) a token to enable access to the buyer information on the blockchain(s) 122. The token may be communicated to the seller application 108. In some examples, the token may be encoded in a scannable barcode such as a one-dimensional UPC or multi-dimensional QR code. The barcode may be presented in a UI of the buyer application 106, and the seller may use a camera or other optical data input device on the seller computing device(s) 104 to scan (e.g., capture an image of) the barcode. The seller application 108 may decode the scanned image of the barcode to extract the encoded token. In some examples, the token may be a cryptographic key (e.g., private key) that is communicated to the seller application 108.)
With respect to claim 28 and 34
The combination of Hopkins/Hankins/Tong/Kirigin teaches the limitations of claim 25 and 31 respectively. Hopkins further teaches: an executable portion for receiving, from the second user, a request to view a set of encrypted data records on the blockchain (col.15 ln61-ln63, The seller application 108 may use (606) the token to access the blockchain(s) 122 and verify the buyer information on the blockchain(s) 122.); an executable portion for receiving authentication credentials from the second user, wherein the authentication credentials comprises a cryptographic key; an executable portion for determining, based on validating the authentication credentials of the second user, that the second user is authorized to access the set of encrypted data records; and an executable portion for decrypting the set of encrypted data records using the cryptographic key (col.15 ln44-ln60, The buyer application 106 may access (602) buyer information, such as loan information or other funding source information, stored on the blockchain(s) 122. Based on the accessed buyer information, the buyer application 106 may generate and provide (604) a token to enable access to the buyer information on the blockchain(s) 122. The token may be communicated to the seller application 108. In some examples, the token may be encoded in a scannable barcode such as a one-dimensional UPC or multi-dimensional QR code. The barcode may be presented in a UI of the buyer application 106, and the seller may use a camera or other optical data input device on the seller computing device(s) 104 to scan (e.g., capture an image of) the barcode. The seller application 108 may decode the scanned image of the barcode to extract the encoded token. In some examples, the token may be a cryptographic key (e.g., private key) that is communicated to the seller application 108.)
Claims 21, 23, 27, 29, 33, and 35 are rejected under 35 U.S.C 103 as being obvious over Zinder et al. (US20170005804A1) in view of Hopkins et al. (US10521780B1) in view of Hankins et al. (US20150242643A1) in view of Tong (US20190280855A1) in view of Kirigin et al. (US20140067929A1), and further in view of Shah (US20190341134A1).
With respect to claim 21, 27, and 33
The combination of Hopkins/Hankins/Tong/Kirigin teaches the limitations of claim 19, 25, and 31 respectively. The combination does not explicitly disclose, but Shah teaches: wherein the blockchain application further causes the processor to: detect a status of a third user; in response to detecting the status of the third user, determine that the third user is restricted from accessing the first decentralized application; and display a second set of decentralized applications on a graphical interface, wherein the second set of decentralized applications excludes the first decentralized application ([0049], The multi-faceted social health care component 104 may communicate with the SHRDB 106 to provide information related to the entities 102. The interface 200 provides display of different modules 202-220 to different entities 102, such that a social cloud among the different entities 102 may be formed to actively interact with each other via the multi-faceted social health care component 104. Restricted access and display of these modules 202-220 may be provided to the entities 102 based on their specific roles and policies implemented by the SHRDB 106 for respective entities 102.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Zinder/Hopkins/Hankins/Tong/ Kirigin with the teaching of Shah as they relate to data management system. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combined systems of Zinder/Hopkins/Hankins/Tong/ Kirigin, for example resource tracking in Zinder, to include the method of preventing restricted users from accessing a first set of decentralized applicationas taught by Shah for the predicated result of an improved system of a more user-friendly blockchain system.
With respect to claim 23, 29, and 35
The combination of Hopkins/Hankins/Tong/Kirigin teaches the limitations of claim 19, 25, and 31 respectively. The combination does not explicitly disclose, but Shah teaches: wherein the blockchain application further causes the processor to: detect that a status of the first transaction has been changed; and display, via a graphical interface, a second notification to the first user ([0052], With the use of a module 214, the multi-faceted social health care component 104 may keep a track of therapies and medical prescription of different patients and constantly display the tracked information to the doctors, clinicians or other entities via module 214. The multi-faceted social health care component 104 may allow the entities 102 to generate reports of the electronic health information or any other information via module 216. Module 216 may also display alerts defined from the electronic health information of the entities 102.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Zinder/Hopkins/Hankins/Tong/ Kirigin with the teaching of Shah as they relate to data management system. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combined systems of Zinder/Hopkins/Hankins/Tong/ Kirigin, for example resource tracking in Zinder, to include the method of detecting the transaction has been changed as taught by Shah for the predicated result of an improved system of a more user-friendly blockchain system.
Claims 24, 30, and 36 are rejected under 35 U.S.C 103 as being obvious over Zinder et al. (US20170005804A1) in view of Hopkins et al. (US10521780B1) in view of Hankins et al. (US20150242643A1) in view of Tong (US20190280855A1) in view of Kirigin et al. (US20140067929A1), and further in view of NAGLA et al. (US20180075527A1).
With respect to claim 24, 30, and 36
The combination of Hopkins/Hankins/Tong/Kirigin teaches the limitations of claim 19, 25, and 31 respectively. The combination does not explicitly disclose, but NAGLA teaches: wherein the blockchain application, when executed by the processor, further causes the processor to: detect, through a smart contract, that the data file has been appended to the blockchain ([0136], If the lender lends money to the borrower then the transaction may be updated by the lender as a new block for the credit record to reflect the new credit data. A block of the credit record may include a smart contract for the transaction with certain conditions that can be evaluated by scoring processor 306 when generating a credit score, for example.); based on detecting that the data file has been appended to the blockchain, transmit a second push notification to the second user using the smart contract, wherein the second push notification comprises a second link that opens a second window on the second user device, wherein the second window is configured to allow the second user to submit an approval of the data file from the second user ([0137], Information in the blockchain for the credit record may need to be updated, such as for example due to errors entering credit information, or conflicts in information between authorized parties. In some embodiments, the platform provides a correction or dispute resolution mechanism for correcting information in the blockchain for the credit record. If an authorized entity 102, 104, 106, 108, 110, and 112 or individual wishes to correct information in a block that the authorized entity 102, 104, 106, 108, 110, and 112 or other party created, it may create a modification block, which references the prior block and indicates what data should be updated and how; see a;sp [0138], When retrieving the credit record by way of the interface application 306, the correction may show up in the form of an indicator showing that a particular piece of information was updated. The update history of that information can then be viewed, if it is not shown already in the initial view. In the case of a conflict between information (e.g. lender and borrower both updating information about the same transaction but the information does not match), notifications may be sent to both parties. The notifications can highlight discrepancies, and request that authorized entities 102, 104, 106, 108, 110, and 112 agree on a correction or other resolution to the conflicting information. The interface application 306 may automatically generate forms to provide information to the authorized entities 102, 104, 106, 108, 110, and 112 and receive information from the authorized entities 102, 104, 106, 108, 110, and 112. Once the conflict is resolved, a new block may be written to the blockchain for the credit record with information for the resolution.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Zinder/Hopkins/Hankins/Tong/ Kirigin with the teaching of Shah as they relate to data management system. One of ordinary skill in the art before effective filing date of the claimed invention was made would have recognized the combined systems of Zinder/Hopkins/Hankins/Tong/ Kirigin, for example resource tracking in Zinder, to include the method of allowing other entity, such as a second user, to approve/examine the data file as taught by NAGLA for the predicated result of an improved system of a more user-friendly blockchain system.
Zinder further teaches: receive, from the second user through the second link, an electronic signature associated with the data file ([0118], An electronic document may have a required number of signatures or signature blocks that must be fulfilled for the document to be considered executed. In the example shown in FIG. 5, electronic contract 1002 requires 4 different signatures. As shown in FIG. 5, computers associated with entities 1, 2, 3, and 4 communicate (e.g., via electronic data messages) with centralized computer system 1000 to provide electronic signatures that are applied to electronic contract 1002. In certain example embodiments, the signatures may be a true electronic signature (e.g., which can be thought of as a contract where an individual agrees their signature is represented by clicking a button, or the like, via a computer);
……electronically signing the data file ([0118], An electronic document may have a required number of signatures or signature blocks that must be fulfilled for the document to be considered executed. In the example shown in FIG. 5, electronic contract 1002 requires 4 different signatures. As shown in FIG. 5, computers associated with entities 1, 2, 3, and 4 communicate (e.g., via electronic data messages) with centralized computer system 1000 to provide electronic signatures that are applied to electronic contract 1002. In certain example embodiments, the signatures may be a true electronic signature (e.g., which can be thought of as a contract where an individual agrees their signature is represented by clicking a button, or the like, via a computer);
append a record of the electronic signature to the blockchain ([0127], The permanent record is stored as a transaction on the blockchain. The blockchain transaction that is created may include the following information regarding the transaction between the issuer and investor entities: 1) The legal names and address of the issuer and investor (and perhaps any other person who signed the electronic document, 2) the number of shares associated with the transaction, 3) the price of each share (or the total price of the transaction), 4) the class of shares that were issued or transferred, 5) the date of the execution (e.g., when the electronic document was executed), 6) the 144 date for the transaction, 7) hashed values of all of the documents associated with this transaction (e.g., there could be more than one document that is signed per issuance, 8) data or hashes for every signature that was executed (e.g. the contract name, the signer, timestamp, and additional metadata associated with the electronic signature),…..)
Hopkins further teaches:
provide, using a blockchain pier associated with the second user, selective access to the data file to the second user (col.6 ln29-ln39, Where applicable, a blockchain's multi-signature feature can be implemented to validate multiple party authorizations. Other individuals such as a lien-holder may also have access to keys that enable access to the vehicle. In some examples, a lien-holder may be able to disable access to the vehicle by other users, e.g., if loan payments are missed. The access control mechanism may also enable other features, such as disabling a vehicle if maintenance checks are overdue, blocking particular users (e.g., teen drivers) from using a vehicle during inclement weather, and so forth., see also col. 4 ln 66-col. 5 ln22).
Conclusion
THIS ACTION IS MADE Non-FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YIN Y CHOI whose telephone number is (571)272-1094 or yin.choi@uspto.gov. The examiner can normally be reached on M-F 7:30 - 5:30pm 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, Neha Patel can be reached on 571-270-1492. 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.
/YIN Y CHOI/Examiner, Art Unit 3699 10/31/2025