DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on October 31, 2025 has been entered.
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 .
Acknowledgements
This Office Action is in response to Applicant’s claims and remarks filed on October 31, 2025.
Claims 1-11 are currently pending and have been examined.
Claim Objections
Claims 1 and 5 are objected to because of the following informalities:
Claims 1 and 5 each recite “a first decryption key that is able to decrypt information encrypted with the first encryption key” which appears to be a typographical error of “a first decryption key that is able to decrypt the information encrypted with the first encryption key.”
Appropriate correction is required.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-11 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
In particular, Claim 1 recites
adding, to a blockchain, a first block that includes:
a first version of user profile information, of a particular user, that is encrypted using a first encryption key, and
a first transaction ID that identifies a transaction entry corresponding to the first version of the user profile information;
applying embedded preference data included in the first version of the user profile information to identify, for each of a plurality of entity computing devices that are to use the user profile information, a subset of fields of the user profile information designated for propagation to that entity computing device;
communicating, to a plurality of entity computing devices:
the first transaction ID, and
a first decryption key that is able to decrypt information encrypted with the first encryption key; and
the subset of fields of the user profile information designated for that entity computing device;
updating the user profile information by adding, to the blockchain, a second block that refers to the first transaction ID and includes a second version of the profile information encrypted using the first encryption key.
However, the specification does not describe an embodiment where: (1) applying preference data in the profile information to identify fields designated for entity computing device(s), (2) communicating a decryption key corresponding to the encryption key that encrypted the user profile information to a plurality of entity computing devices, and (3) communicating the subset of fields of the user profile information designated for that specific entity computing device of the plurality of entity computing device, all coexist. Although the specification describes embodiments where the profile information is encrypted and transmitted in encrypted form to the entity computing devices (“Once a transaction entry is written to a blockchain with encrypted payload data, the transaction ID of the transaction entry and decryption key (in the case of asymmetric encryption) can be communicated to one or more entities that desire to use user profile information included in the encrypted payload data. For example, user computing device 114 may transmit a transaction ID and decryption key to entity computing device 118. Once received by entity computing device 118, the transaction entry corresponding to the transaction ID can be accessed and the encrypted payload data can be decrypted using the decryption key. User profile information that is included as part of the payload data can then be utilized by the receiving entity.” [0035], and “when entity computing device 118 decrypts the encrypted payload data, entity computing device 118 may identify that an entity account ID associated with entity computing device 118 is included in the whitelist or blacklist. In this scenario, entity computing device 118 may include programmatic instructions that cause the entity computing device 118 to take an action in response such an identification. For example, in response to identifying that a blacklist includes an entity account ID associated with entity computing device 118, entity computing device 118 restricts all further actions taken by entity computing device 118 with respect to the transaction entry” [0048]), these embodiments do not disclose processing embedded preference data first (i.e.: “applying embedded preference data…to identify…”) and also sending (i.e.: “communicating, to a plurality of entity computing devices…”) the subset of fields designated for that entity computing device (it is additionally noted that a person having ordinary skill in the art would understand that this would defeat the purpose for it to be encrypted in the first place). Conversely, the specification at [0065] and [0067] describes an embodiment where the blockchain gateway decrypts the profile information to identify the fields that are not restricted for a particular requesting entity and subsequently transmit those unencrypted fields to the corresponding entities.
Therefore, there is insufficient support in the original disclosure for “applying embedded preference data included in the first version of the user profile information to identify, for each of a plurality of entity computing devices that are to use the user profile information, a subset of fields of the user profile information designated for propagation to that entity computing device;” and “communicating, to a plurality of entity computing devices:” “a first decryption key that is able to decrypt information encrypted with the first encryption key; and the subset of fields of the user profile information designated for that entity computing device.”
Claims 2-4 which depend on Claim 1 include all of the limitations of Claim 1; therefore, they are rejected for the same reasons given above for Claim 1.
Claim 5 is similar in this respect to Claim 1; therefore, it is rejected for the same reasons given above for Claim 1.
Claims 6-11 which depend on Claim 5 include all of the limitations of Claim 5; therefore, they are rejected for the same reasons given above for Claim 5.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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-9 are rejected under 35 U.S.C. 103 as being unpatentable over Gonzales, Jr. (US 2019/0205563 A1)(“Gonzales”) in view of Dillenberger (US 2017/0177898 A1)(“Dillenberger”).
As to Claims 1 and 5, Gonzales discloses a method (“method,” [0043])/one or more non-transitory computer-readable media (“computer readable medium,” [0043]) storing instructions (“programed with instructions…” [0107]) which, when executed by one or more processors (processor 902), cause (“execute computer executable instructions of one or more application programs, and communicate with other components of the computing device architecture 900 in order to perform various functionality described herein” [0136]):
adding, to a blockchain, a first block (“Owner device 110 initiates personal information data blockchain 140 by creating genesis block 142A”, [0054]) that includes:
a first version (“Version index: 0.1”, see Fig.2A) of user profile information of a particular user, (“Genesis block 142A can include the personal information data belonging to a user of owner device 100.” [0054]) that is encrypted (“The personal information can be encrypted by the user to prevent unauthorized access to the user's information,” [0039]) using a first encryption key (“see Message Authentication Code” in Block 210A, Fig.A; “Each block may include a pointer to the other block, and a hash (or Message Authentication Code function) of the other block.” [0059], note: MACs must use encryption keys), and
a first transaction ID (“Version: 2016-01 .15_ 1535hr”, see Block 210A, Fig.2A) that identifies a transaction entry corresponding to the first version of the user profile information (“Version: 2016-01 .15_ 1535hr” is in the Genesis Block 210A that also includes “Version index: 0.1,” see Block 210A, Fig.2A), and
applying embedded preference data (“The permissions identify the parts of the personal information data that the platform has authorization to access.” [0068], wherein the permissions are the preference data) included in the first version of the user profile information (“Note that the personal information data and the authorized access data can, in some examples, be combined in the same blockchain data blocks” [0063]) to identify, for each of a plurality of entity computing devices that are to use the user profile information (“The permissions identify the parts of the personal information data that the platform has authorization to access.” [0068]), a subset of fields of the user profile information designated for propagation to that entity computing device (“The user can define an authorized access list defining access to the personal information data blockchain. In some examples, the user generates a data block in an authorized access data blockchain for storing the authorized access data that includes an identifier for one or more platforms that have authorized access. The authorized access data can include permissions that determine which select portions of the personal information that each platform can access.” [0040], “The permissions identify the parts of the personal information data that the platform has authorization to access. In this example, the list of authorized access platforms and permissions identified in genesis block 292A is: (platform1, permissions1); (platfom2, permissions2); and (platform3, permissions3).” [0068], “The ACCESS script performs filtering the personal information data based on the permissions2, which determine which parts of the personal information data to release to platform2. In this example, the permissions2 indicate that platform2 is only authorized to access data1, data3A (the value of data3 as modified to data3A in block 342C), data5 and data6. Because platform2 is found in the authorized access data, the ACCESS script, at 308, releases only the personal information data in the personal information data blockchain, as it exists at that point, that platform2 is authorized to access to client/server 1208, which includes personal information data1, data3A, data5 and data6.” [0072], “The personal information data is filtered using the permissions to include only the authorized data authDATA for the platform. The authorized data is then returned to the platform.’ [0075], [0079]);
communicating, to a plurality of entity computing devices (“when a change data block 142 is created for a personal information data blockchain 140 transaction or an access data block 152 is created for an authorized access data blockchain 150 transaction, the transaction is broadcast, at 472, to the cluster of untrusted nodes…a winning node broadcasts the validation solution for the transaction block and adds the transaction block to its copy of the personal information data or authorized access data blockchain ledger. At 478, in response to the winning node’s broadcast, the other nodes add the transaction block to their copies of the personal information” [0082]):
the subset of fields of the user profile information designated for that entity computing device (“The ACCESS script performs filtering the personal information data based on the permissions2, which determine which parts of the personal information data to release to platform2. In this example, the permissions2 indicate that platform2 is only authorized to access data1, data3A (the value of data3 as modified to data3A in block 342C), data5 and data6. Because platform2 is found in the authorized access data, the ACCESS script, at 308, releases only the personal information data in the personal information data blockchain, as it exists at that point, that platform2 is authorized to access to client/server 1208, which includes personal information data1, data3A, data5 and data6.” [0072]);
updating the user profile information by adding, to the blockchain, a second block (“To add or modify personal information data, the user generates another data block in the personal information data blockchain that includes the added or modified personal information data.” [0039]) that refers to the first transaction ID (“Each block may include a pointer to the other block, and a hash (or Message Authentication Code function) of the other block.” [0059], see Fig.2A) and includes a second version (“Version index: 0.2” Fig.2A) of the profile information (Fig.2A and [0039]).
Gonzales does not directly disclose
the communicating, to a plurality of entity computing devices, including the first transaction ID and a first decryption key that is able to decrypt information encrypted with the first encryption key;
the second version of the profile information encrypted using the first encryption key.
Dillenberger teaches
communicating, a first transaction ID (“Transaction ID 1”, see 218, in Fig.2) and a first decryption key that is able to decrypt information encrypted with a first encryption key (“encrypts transactions before they are added to blockchains, while also allowing the encrypted contents to be added to the blockchain. Holders of the security keys for the encrypted transactions can then share the keys with other entities.” [0017], “receiving a request with a transaction identifier and a decryption key from another user system to access the additional data;” Claim 9); and
second information (“Block 2,” see Fig.2) encrypted using the first encryption key (“A common encryption key may be used for each the additional data in each block 252, 292” [0035]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Gonzales by the features of Dillenberger, and in particular, to include in the communicating, to a plurality of entity computing devices step of Gonzales, the first transaction ID and a first decryption key that is able to decrypt information encrypted with the first encryption key, as taught by Dillenberger, and to encrypt the second version of the profile information of Gonzales, with the first encryption key, as taught by Dillenberger.
A person having ordinary skill in the art would have been motivated to combine these features because it would aid in retrieving the personal information data by “tracing the change data blocks back to the genesis data block” (Gonzales, [0063]) and it would “provide[s] blockchain security and ledger services that allow participants to encrypt different types of records, with different keys that still allow blockchain hashing and verification but does not allow public participants to view the data without the key” (Dillenberger, [0019]).
As to Claim 2 and 6, the Gonzales/Dillenberger combination discloses as discussed above.
Gonzales further discloses:
updating the user profile information by adding, to the blockchain, a third block (“To add or modify personal information data, the user generates another data block in the personal information data blockchain that includes the added or modified personal information data.” [0039], see Block 210C in Fig.2A) that refers to the first transaction ID (Block 210C refers to the previous version in Block 210B which refers to the “Previous version: 2016-01.15_1535hr” see Fig.2A) and includes a third version (“Version index: 0.3” Fig.2A) of the profile information (Fig.2A and [0039]).
Gonzales does not directly disclose
third version of the profile information encrypted using a second encryption key that is different from the first encryption key;
communicating, to a subset of the plurality of entity computing devices, a second decryption key that is able to decrypt information encrypted with the second encryption key;
wherein at least one of the plurality of entity computing devices is not included in the subset.
Dillenberger teaches
third block information (“Block n,” [0034] implies any number of blocks) encrypted using a second encryption key that is different from the first encryption key (“allow participants to encrypt different types of records, with different keys” [0019]; as such the first two blocks may be encrypted with the same key while a third block may be encrypted with another key);
communicating, to a subset of the plurality of entity computing devices, a second decryption key that is able to decrypt information encrypted with the second encryption key (“The owner(s) of the transaction(s) can send the keys for a subset of the owner(s)' transactions to only the participants they wish to view/modify/add to their virtual private ledger.” [0019]);
wherein at least one of the plurality of entity computing devices is not included in the subset (“The computing node is one of multiple computing nodes in a system using a blockchain protocol to share a transaction database.” [0037], “The owner(s) of the transaction(s) can send the keys for a subset of the owner(s)' transactions to only the participants they wish to view/modify/add to their virtual private ledger.” [0019]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Gonzales in the Gonzales/Dillenberger combination by the features of Dillenberger and in particular to encrypt the third version of the profile information of Gonzales, with the second encryption key, as taught by Dillenberger, and to include in Gonzales, the features of: communicating, to a subset of the plurality of entity computing devices, a second decryption key that is able to decrypt information encrypted with the second encryption key, and wherein at least one of the plurality of entity computing devices is not included in the subset, as taught by Dillenberger.
A person having ordinary skill in the art would have been motivated to combine these features because it would “provide[s] blockchain security and ledger services that allow participants to encrypt different types of records, with different keys that still allow blockchain hashing and verification but does not allow public participants to view the data without the key” (Dillenberger, [0019]).
As to Claims 3 and 7, the Gonzales/Dillenberger combination discloses as discussed above. Gonzales further discloses: wherein the first block includes a whitelist (“AUTHORIZED ACCESS.list {platform1, platform2, platform3}” see Fig.2B) that specifies one or more entity account IDs that are permitted to access the first version of user profile information (“The user can define an authorized access list defining access to the personal information data blockchain. In some examples, the user generates a data block in an authorized access data blockchain for storing the authorized access data that includes an identifier for one or more platforms that have authorized access. The authorized access data can include permissions that determine which select portions of the personal information that each platform can access.” [0040]).
As to Claims 4 and 8, the Gonzales/Dillenberger combination discloses as discussed above. Gonzales further discloses: wherein the first block includes one or more preferences that specify restrictions regarding one or more fields of the first version of user profile information (“The user can define an authorized access list defining access to the personal information data blockchain. In some examples, the user generates a data block in an authorized access data blockchain for storing the authorized access data that includes an identifier for one or more platforms that have authorized access. The authorized access data can include permissions that determine which select portions of the personal information that each platform can access.” [0040], “The permissions identify the parts of the personal information data that the platform has authorization to access.” [0068], “The personal information data is filtered using the permissions to include only the authorized data authDATA for the platform. The authorized data is then returned to the platform.’ [0075]).
As to Claim 9, the Gonzales/Dillenberger combination discloses as discussed above. Gonzales further discloses
receiving, via a user interface (API 510), input comprising the first version of the user profile information (“Application Program Interface (API) 510 provides an interface to the blockchain platform 520 that supports the personal information data blockchain. The blockchain platform 520 supports smart contract 522, which includes scripts 524 with code that, when executed by the blockchain platform 520, performs operations…” [0086], “The STORE.PERSONAL.INFO script 524B provides the capability for an owner of personal information to add or modify personal information data maintained on the personal information data blockchain” [0087], “Owner device 110 initiates personal information data blockchain 140 by creating genesis block 142A” [0054]); and
formatting the input into the first transaction entry (“A user generates a data block in a personal information data blockchain for storing their personal information.” [0039], “FIG. 2A show personal information data being added or modified and the changes are secured with a new change data block on the blockchain. In this example, owner device 110 of FIG. 1 identifies three items of personal data, e.g. datal, data2 and data3 when it creates genesis data block 210A. The owner device 110 signs the genesis data block 210Aand the blockchain system within which blockchain 200 is created verifies the genesis data block based on a proof function.’ [0061]).
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Gonzales in view of Dillenberger, and further in view of Yeung et al. (US 2021/0182832 A1)(“Yeung”).
As to Claim 10, the Gonzales/Dillenberger combination discloses as discussed above.
Gonzales does not directly disclose but Yeung teaches wherein the first block comprises a sender field (see “Owner 230A” in Fig.2) that identifies an address of a sender account associated with the first transaction entry (“Owner 230 may be identified, for example, from…an email address…,” [0061]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Gonzales in the Gonzales/Dillenberger combination by the features of Yeung, and in particular, to include in the first block of Gonzales, the sender field, as taught by Yeung. A person having ordinary skill in the art would have been motivated to combine these features because it would “ensure that the participants in a transaction are entitled to perform the transaction” (Yeung, [0002]).
As to Claim 11, the Gonzales/Dillenberger/Yeung combination discloses as discussed above.
Gonzales does not directly disclose but Yeung teaches determining, by another particular entity computing device of the plurality of entity computing devices, that the second version of the user profile information is the updated version of the user profile information based at least in part on the new transaction entry identifying the address of the sender account associated with the first transaction entry (“To determine whether the transferring party identified in the request is the current owner of the physical object 120, ownership transfer request processor 132 can identify a node in the distributed ledger representing the latest update to ownership records for the physical object. In some embodiments, ownership transfer request processor 132 can identify the node representing the latest update to the ownership records for the physical object by identifying an origin node in the distributed ledger representing the creation of the physical object and its associated ownership records.” [0037]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Gonzales in the Gonzales/Dillenberger/Yeung combination by the features of Yeung and in particular to include in Gonzales in the Gonzales/Dillenberger/Yeung combination, the feature of determining, by another particular entity computing device of the plurality of entity computing devices, that the second version of the user profile information is the updated version of the user profile information based at least in part on the new transaction entry identifying the address of the sender account associated with the first transaction entry taught, as by Yeung.
A person having ordinary skill in the art would have been motivated to combine these features because it would “ensure that the participants in a transaction are entitled to perform the transaction” (Yeung, [0002]).
Response to Arguments
The arguments filed on October 31, 2025 have been fully considered and addressed below.
On page 8 Applicant argues that “Gonzales…does not embed field-level restrictions inside the encrypted payload itself. Gonzales’s permission record exists external to the user data and operates at a coarse granularity. Gonzales does not teach or suggest embedded preference data that is interpreted to identify, for each recipient entity, which fields of a profile to propagate.” The Examiner respectfully disagrees. Gonzales discloses applying embedded preference data (“The permissions identify the parts of the personal information data that the platform has authorization to access.” [0068], wherein the permissions are the preference data) included in the first version of the user profile information (“Note that the personal information data and the authorized access data can, in some examples, be combined in the same blockchain data blocks” [0063]) to identify, for each of a plurality of entity computing devices that are to use the user profile information (“The permissions identify the parts of the personal information data that the platform has authorization to access.” [0068]), a subset of fields of the user profile information designated for propagation to that entity computing device (“The user can define an authorized access list defining access to the personal information data blockchain. In some examples, the user generates a data block in an authorized access data blockchain for storing the authorized access data that includes an identifier for one or more platforms that have authorized access. The authorized access data can include permissions that determine which select portions of the personal information that each platform can access.” [0040], “The permissions identify the parts of the personal information data that the platform has authorization to access. In this example, the list of authorized access platforms and permissions identified in genesis block 292A is: (platform1, permissions1); (platfom2, permissions2); and (platform3, permissions3).” [0068], “The ACCESS script performs filtering the personal information data based on the permissions2, which determine which parts of the personal information data to release to platform2. In this example, the permissions2 indicate that platform2 is only authorized to access data1, data3A (the value of data3 as modified to data3A in block 342C), data5 and data6. Because platform2 is found in the authorized access data, the ACCESS script, at 308, releases only the personal information data in the personal information data blockchain, as it exists at that point, that platform2 is authorized to access to client/server 1208, which includes personal information data1, data3A, data5 and data6.” [0072], “The personal information data is filtered using the permissions to include only the authorized data authDATA for the platform. The authorized data is then returned to the platform.’ [0075], [0079]).
On pages 8-9 Applicant argues that neither Dillenberger nor Hyun teach what Applicant argues is not taught by Gonzales in the previous argument. However, the Examiner finds that Gonzales discloses those features (as discussed above). Therefore, this argument against Dillenberger and Hyun is moot.
On page 9, Applicant argues that none of the previously argued references disclose “how much of the data should be disclosed after decryption.” However, the claims do not require knowing or determining “how much of the data should be disclosed after decryption.”
On page 9, Applicant argues that “[a] person of ordinary skill in the art would view these systems as solving distinct problems-- consent management, encryption security, and identity verification-- without any suggestion that combining them would yield the claimed embedded preference enforcement at the field level.” The Examiner respectfully disagrees. The argued references are in the same field of endeavor of storing and accessing personal data on a blockchain. Furthermore, as discussed above, Gonzales discloses the embedded preference data feature.
On page 9, Applicant argues that “Gonzales already defines access permissions at the dataset level, and its design provides no need for embedded field-level preferences.” The Examiner respectfully disagrees with the suggestion that Gonzales does not teach the “applying embedded preference data…” limitation as already discussed above. Applicant further argues that “[i]ntegrating Dillenberger’s encryption would eliminate Gonzales’s visibility into field-level content and would not produce a system capable of applying preferences embedded inside an encrypted payload. The two systems would function inconsistently if combined. Hyun’s identity verification mechanism would not remedy this inconsistency because it provides no disclosure related to preference data or propagation of specific fields. The combination therefore lacks both a motivation to combine and a reasonable expectation of success.” The Examiner respectfully disagrees for the same reasons given in the motivations to combine in the respective rejections. As noted therein, “[a] person having ordinary skill in the art would have been motivated to combine these features [of Gonzales and Dillenberger] because it would aid in retrieving the personal information data by “tracing the change data blocks back to the genesis data block” (Gonzales, [0063]) and it would “provide[s] blockchain security and ledger services that allow participants to encrypt different types of records, with different keys that still allow blockchain hashing and verification but does not allow public participants to view the data without the key” (Dillenberger, [0019]).”
On pages 9-10, Applicant argues that “[e]ven if a person of ordinary skill were to combine Gonzales, Dillenberger, and Hyun, the resulting system would still provide access to complete decrypted datasets without distinguishing individual fields.” The Examiner respectfully disagrees because Gonzales discloses the feature of “applying embedded preference data…a subset of fields…for propagation to that entity computing device” (as discussed above). Applicant further argues “[n]one of the references describes or suggests any mechanism for a gateway or other intermediary to parse a decrypted payload, identify preference metadata, and selectively transmit allowed fields. Implementing this would require substantial modification of the data structures and logic of the cited systems, which would go beyond routine optimization.” The Examiner respectfully disagrees because Gonzales discloses the feature of “applying embedded preference data…a subset of fields…for propagation to that entity computing device” (as discussed above).
On page 10, Applicant argues “…Dillenberger expressly teaches encrypting entire payloads such that no intermediary can inspect or manipulate their contents. Modifying its approach to allow a gateway to read internal preference data and selectively propagate individual fields would defeat its stated design goal of full-payload confidentiality. The art therefore teaches away from the claimed invention.” The Examiner finds the argument unpersuasive. First, as discussed in the combination asserted in the rejections, the features of Dillenberger of communicating, a first transaction ID (“Transaction ID 1”, see 218, in Fig.2) and a first decryption key that is able to decrypt information encrypted with the first encryption key (“encrypts transactions before they are added to blockchains, while also allowing the encrypted contents to be added to the blockchain. Holders of the security keys for the encrypted transactions can then share the keys with other entities.” [0017], “receiving a request with a transaction identifier and a decryption key from another user system to access the additional data;” Claim 9); and second block information (“Block 2,” see Fig.2) encrypted using the first encryption key (“A common encryption key may be used for each the additional data in each block 252, 292” [0035]) are included in Gonzales. Therefore, even if Dillenberger only disclosed encrypting full payloads, the combination outlined in the rejection would still be proper. However, Dillenberger teaches encrypting partial payloads of “additional data” (see “In another example, a unique key is required for a unique lock 254, 258, 262, 274, 278, 282 used for each portion of additional data 256, 260, 264, 276, 280, 284” in [0036]). As such, the argument is not persuasive.
On page 10, Applicant argues that “[t]he claimed invention also achieves a distinct technical effect: secure propagation of user profile updates with granular privacy enforcement at the field level. Each entity receives only those fields permitted by embedded preferences, while restricted fields remain withheld. None of the cited references, either alone or in combination, recognizes or enables this functionality.” The Examiner respectfully disagrees because Gonzales discloses the feature of “applying embedded preference data…a subset of fields…for propagation to that entity computing device” (as discussed above). Therefore, the argument is found unpersuasive.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MONICA A MANDEL whose telephone number is (571)270-7046. The examiner can normally be reached Monday and Thursday 10:00 AM-6:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ilana Spar can be reached at (571) 270-7537. 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.
/M.A.M/Examiner, Art Unit 3622
/ILANA L SPAR/Supervisory Patent Examiner, Art Unit 3622