Office Action Predictor
Application No. 18/198,278

TRUSTED DATA MANAGEMENT SYSTEMS AND METHODS

Final Rejection §103
Filed
May 16, 2023
Examiner
LANIER, BENJAMIN E
Art Unit
2437
Tech Center
2400 — Computer Networks
Assignee
Intertrust Technologies Corporation
OA Round
6 (Final)
69%
Grant Probability
Favorable
7-8
OA Rounds
3y 6m
To Grant
48%
With Interview

Examiner Intelligence

69%
Career Allow Rate
628 granted / 909 resolved
Without
With
+-21.5%
Interview Lift
avg trend
3y 6m
Avg Prosecution
36 pending
945
Total Applications
career history

Statute-Specific Performance

§101
7.4%
-32.6% vs TC avg
§103
48.1%
+8.1% vs TC avg
§102
17.7%
-22.3% vs TC avg
§112
17.1%
-22.9% vs TC avg
Black line = Tech Center average estimate • Based on career data

Office Action

§103
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 . Response to Amendment Applicant’s amendment filed 22 September 2025 amends claim 1 and adds claim 19. Applicant’s amendment has been fully considered and entered. Response to Arguments Applicant argues on page 8 of the response, “Specifically, the references do not disclose or suggest ‘first fact information’ that includes both a hash of a ‘first data set’ and a hash of an earlier version of the ‘first data set’ – that is, the claimed ‘second data set.’” In response, the claimed “subsequent version of the second data set” is defined by the claims as having been generated by “transforming at least a portion of the second data set”. The combination of Aleksander and Sauerwein Jr teach this limitation because Aleksander discloses a digital file (Page 10, lines 23-26: digital file reads on the claimed first data set) and data associated with the file such as origin of the file (Page 10, line 31- Page 11, line 6: data associated with the file reads on the claimed second data set). Aleksander does not disclose that the digital file is generated using the data associated with the file such as the origin of the file. Sauerwein Jr discloses that file metadata, which includes GPS coordinates and timestamps, is utilized to create tags ([0029]: tag creation from metadata reads on the claims transforming at least a portion of the second data set) such that the tags are inserted into the files ([0012]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the digital files of Aleksander to have included the tag data associated with the file as metadata in order to facilitate file search, retrieval, and processing as suggested by Sauerwein Jr ([0001]). Therefore, Aleksander, as modified by Sauerwein Jr, discloses digital files generated to include the tag data associated with the file as metadata. This disclosure reads on the claimed first data set being a subsequent version of the second data set since the claims specify that the first data set is generated by “transforming at least a portion of the second data set”. As it pertains to the first and second hashes, Aleksander discloses that a verification procedure is performed to determine if the digital file is registered to a blockchain by obtaining the data to be verified and hashing the obtained data (Page 19, lines 7-12, 27-29). Aleksander does not disclose that the individual data sets of the digital file are hashed separately. Aciicmez discloses generating independent hash values for each distinct portion of data ([0018]), which meets the limitation of a first hash, the first hash being generated based on the first data set, and a second hash, the second hash being generated based on a second data set. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the individual data sets of the digital files in Aleksander to have been hashed separately in order to reduce the time required to calculate the hash values for the entire digital file as suggested by Aciicmez ([0018]). Applicant argues on page 8 of the response, “Indeed, the ‘GPS coordinates’ and ‘timestamp’ of Sauerwein merely provide location and time information associated with a record, which is different than a hash of an earlier version of a dataset (i.e., the ‘second data set’) used to derive another dataset (i.e., the ‘first data set’) associated with the record.” In response, Applicant has not fully considered the proposed modification of Aleksander as presented in the Non-Final dated 22 May 2025 (“Non-Final”). As detailed above, Aleksander discloses a digital file (Page 10, lines 23-26) and data associated with the file such as origin of the file (Page 10, line 31- Page 11, line 6). Aleksander does not disclose that the digital file is generated using the data associated with the file such as the origin of the file. Sauerwein Jr discloses that file metadata, which includes GPS coordinates and timestamps, is utilized to create tags ([0029]) such that the tags are inserted into the files ([0012]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the digital files of Aleksander to have included the tag data associated with the file as metadata in order to facilitate file search, retrieval, and processing as suggested by Sauerwein Jr ([0001]). Aleksander discloses that a verification procedure is performed to determine if the digital file is registered to a blockchain by obtaining the data to be verified and hashing the obtained data (Page 19, lines 7-12, 27-29). Aleksander does not disclose that the individual data sets of the digital file are hashed separately. Aciicmez discloses generating independent hash values for each distinct portion of data ([0018]), which meets the limitation of a first hash, the first hash being generated based on the first data set, and a second hash, the second hash being generated based on a second data set. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the individual data sets of the digital files in Aleksander to have been hashed separately in order to reduce the time required to calculate the hash values for the entire digital file as suggested by Aciicmez ([0018]). Applicant argues on pages 8-9 of the response, “Aciicmez is similarly deficient. While the reference in paragraph [0017] details use of ‘multiple one-way mapping values’ that can be ‘determined respectively for multiple portions of…data and effectively used to verify the integrity of the data,’ these multiple ‘one-way mapping values’ are associated with different portions of the same data set.” In response, Applicant has failed to fully appreciate the proposed modification of Aleksander as presented in the Non-Final with respect to the Aciicmez disclosure. Specifically, Aleksander discloses that a verification procedure is performed to determine if the digital file is registered to a blockchain by obtaining the data to be verified and hashing the obtained data (Page 19, lines 7-12, 27-29). Aleksander does not disclose that the individual data sets of the digital file are hashed separately. Aciicmez discloses generating independent hash values for each distinct portion of data ([0018]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the individual data sets of the digital files in Aleksander to have been hashed separately in order to reduce the time required to calculate the hash values for the entire digital file as suggested by Aciicmez ([0018]). Therefore, as modified in the manner described above, Aleksander discloses that a verification procedure is performed to determine if the digital file is registered to a blockchain by obtaining the data to be verified and hashing each individual data set of the obtained data (Aleksander: Page 19, lines 7-12, 27-29 & Aciicmez: [0018]). Hashing each individual data set of Aleksander would include the hashing the first set of data and hashing the second set of data. 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 (i.e., changing from AIA to pre-AIA ) 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. The factual inquiries 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 1-7, 9-11, 14-16, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Aleksander, WO 2019/233646, in view of Sauerwein Jr, U.S. Publication No. 2009/0161994, and further in view of Aciicmez, U.S. Publication No. 2010/0106976. Referring to claim 1, Aleksander discloses a blockchain file registration wherein a blockchain system registers on a blockchain (Page 13, lines 1-5 & Page 12, lines 11-13, 19-23: file registered as transaction data where the transaction data is created a third data set; Page 11, lines 7-10 & Figure 1: third data set includes the file and the data associated with the file) a digital file (Page 10, lines 23-26: digital file reads on the claimed first data set), along with data associated with the file (Page 10, line 31 – Page 11, line 6: data associated with the file reads on the claimed second data set). A verification procedure is performed to determine if the digital file is registered to a blockchain by obtaining the data to be verified and hashing the obtained data (Page 19, lines 7-12, 27-29: hash reads on the claimed first fact information; data to be verified includes the transaction data registered, which includes the digital file and the associated data. Therefore hashing all the data would include hashing the digital file and the associated data), which meets the limitation of accessing a first data set and first fact information associated with the first data set, the first fact information comprising a [first] hash, the [first] hash being generated based on the first data set, and a [second] hash, the [second] hash being generated based on the second data set. The generated hash is utilized to search the database utilizing a query to see if the hash is contained within the blockchain (Page 19, line 30 – Page 20, line 9: blockchain reads on the claimed trusted assertion ledger; blockchain system reads on the claimed trusted assertion service; blockchain block corresponding to the hash reads on the claimed first assertion), which meets the limitation of generating a first query, the first query comprising the first fact information, transmitting the first query to a trusted assertion service to determine whether a trusted assertion ledger managed by the trusted assertion service comprises a first assertion comprising the first fact information. If the search results in the hash being found in the blockchain, the stored data associated with the hash is sent to the user terminal and a positive message is returned to the user (Page 20, lines 5-12 & Page 21, lines 7-11), which meets the limitation of receiving a first response from the trusted assertion service indicating that the trusted assertion ledger comprises the first assertion. Upon receipt of a positive message, the user can choose to proceed with verification of ownership of the data (Page 20, lines 10-12: verifying ownership reads on the claimed determining a provenance), which meets the limitation of determining a provenance of the first data set associating the first data set with the second data set based, at least in part, on the first response indicating that the trusted assertion ledger comprises the first assertion. Aleksander discloses a digital file (Page 10, lines 23-26: digital file reads on the claimed first data set) and data associated with the file such as origin of the file (Page 10, line 31- Page 11, line 6: data associated with the file reads on the claimed second data set). Aleksander does not disclose that the digital file is generated using the data associated with the file such as the origin of the file. Sauerwein Jr discloses that file metadata, which includes GPS coordinates and timestamps, is utilized to create tags ([0029]: tag creation from metadata reads on the claims transforming at least a portion of the second data set) such that the tags are inserted into the files ([0012]), which meets the limitation of the first data set being a subsequent version of the second data set generated by transforming at least a portion of the second data set. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the digital files of Aleksander to have included the data associated with the file as metadata in order to facilitate file search, retrieval, and processing as suggested by Sauerwein Jr ([0001]). Aleksander discloses that a verification procedure is performed to determine if the digital file is registered to a blockchain by obtaining the data to be verified and hashing the obtained data (Page 19, lines 7-12, 27-29). Aleksander does not disclose that the individual data sets of the digital file are hashed separately. Aciicmez discloses generating independent hash values for each distinct portion of data ([0018]), which meets the limitation of a first hash, the first hash being generated based on the first data set, and a second hash, the second hash being generated based on a second data set. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the individual data sets of the digital files in Aleksander to have been hashed separately in order to reduce the time required to calculate the hash values for the entire digital file as suggested by Aciicmez ([0018]). Referring to claim 2, Aleksander discloses that if the search results in the hash being found in the blockchain, the stored data associated with the hash is sent to the user terminal (Page 20, lines 5-12), which meets the limitation of wherein the method further comprises receiving the first data set. Aleksander discloses that the if the hash is found to be present in the blockchain block specified by the system, the user can choose to check the integrity of the data (Page 20, lines 5-9). Aleksander discloses that the hash of the transaction data to be retrieved from a database connected to the blockchain database (Page 14, line 19 – Page 15, line 6: hash of transaction data stored in database and information retrievable from the database; combined database system reads on the claimed data management service), which meets the limitation of receiving the first fact information associated with the first data set from a data management service. Referring to claims 3, 4, Aleksander discloses that a verification procedure is performed to determine if the digital file is registered to a blockchain by obtaining the data to be verified and hashing the obtained data (Page 19, lines 7-12, 27-29: hash reads on the claimed first fact information; Examiner notes that the claimed identification information is never functionally utilized in the claims and would therefore be considered non-functional descriptive material that does not receive patentable weight. See MPEP 2111.04-2111.05), which meets the limitation of wherein the first fact information further comprises identification information associated with a data processing program used to generate the first data set using the second data set, wherein the identification information associated with the data processing program comprises an identifier of a data processing service that generated the first data set using the data processing program. Referring to claim 5, Aleksander discloses that if the search results in the hash being found in the blockchain, the stored data associated with the hash is sent to the user terminal where the stored data includes a digital signature (Page 20, lines 5-12 & Page 21, lines 7-11) that was calculated using a user private key (Page 17, lines 20-27: private key reads on the claimed first cryptographic key; user private key can be said to be associated with the user’s terminal; user’s terminal reads on the claimed data processing service), which meets the limitation of wherein the first assertion further comprises a digital signature generated using a first cryptographic key, the first cryptographic key being securely associated with the data processing service. Referring to claim 6, Aleksander discloses that if the search results in the hash being found in the blockchain, the stored data associated with the hash is sent to the user terminal where the stored data includes a digital signature (Page 20, lines 5-12 & Page 21, lines 7-11) that was calculated using a user private key (Page 17, lines 20-27: private key reads on the claimed second cryptographic key; user private key can be said to be associated with the user’s terminal; Page 16, lines 28-29 suggests that functionality can be performed using a program and this program would read on the claimed data processing program), which meets the limitation of wherein the first assertion further comprises a digital signature generated using a first cryptographic key, the first cryptographic key being securely associated with the data processing service. Referring to claim 7, Aleksander discloses that a verification procedure is performed to determine if the digital file is registered to a blockchain by obtaining the data to be verified and hashing the obtained data (Page 19, lines 7-12, 27-29) wherein the hashed data can include any digital good (Page 13, lines 10-13: Examiner notes that the claimed data processing program is never functionally utilized in the claims and would therefore be considered non-functional descriptive material that does not receive patentable weight. See MPEP 2111.04-2111.05), which meets the limitation of wherein the first fact information further comprises a [third] hash, the [third] hash being generated based on the data processing program. Aleksander does not disclose that the individual data sets of the digital file are hashed separately. Aciicmez discloses generating independent hash values for each distinct portion of data ([0018]), which meets the limitation of a third hash, the third hash being generated based on the data processing program. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the individual data sets of the digital files in Aleksander to have been hashed separately in order to reduce the time required to calculate the hash values for the entire digital file as suggested by Aciicmez ([0018]). Referring to claim 9, Aleksander discloses that a verification procedure is performed to determine if the digital file is registered to a blockchain by obtaining the data to be verified and hashing the obtained data (Page 19, lines 7-12, 27-29: hash reads on the claimed first fact information; Examiner notes that the claimed configuration information is never functionally utilized in the claims and would therefore be considered non-functional descriptive material that does not receive patentable weight. See MPEP 2111.04-2111.05), which meets the limitation of wherein the first fact information further comprises configuration information associated with the generation of the first data set by the data processing program. Referring to claim 10, Aleksander discloses that transaction is registered by placing the transaction information in a block of the blockchain (Page 13, lines 1-5: placing the transaction in the blockchain reads on the claimed securely storing by the data management service) wherein the transaction includes the hash (Col. 18, lines 11-13: hash reads on the claimed first fact information), and is created from third data set (Page 12, lines 11-13, 19-23) and the third data is set is created by merging the data file with the second data set into a data structure (Page 11, lines 7-10 & Figure 1), which meets the limitation of wherein the first fact information is securely stored with the second data set by the data management service. Referring to claim 11, Aleksander discloses that the hash of the transaction data can be retrieved separately from the data in the blockchain (Page 14, line 19 – Page 15, line 6), which meets the limitation of wherein accessing the first data set and the first fact information comprises receiving the first fact information separately from the first data set. Referring to claim 14, Aleksander discloses that a verification procedure is performed to determine if the digital file is registered to a blockchain by obtaining the data to be verified and hashing the obtained data (Page 19, lines 7-12, 27-29: hash reads on the claimed hash of the second data set; data to be verified includes the transaction data registered, which includes the digital file and the associated data. Therefore hashing all the data would include hashing the associated data). The generated hash is utilized to search the database utilizing a query to see if the hash is contained within the blockchain (Page 19, line 30 – Page 20, line 9: verification procedure could be performed any number of times. Therefore the concept of “second” query/assertion versus “first” query/assertion is met), which meets the limitation of generating a second query, the second query comprises the [second] hash generated based on the second data set, and transmitting the second query to the trusted assertion service to determine whether the trusted assertion ledger managed by the trusted assertion comprises a second assertion comprising the [second] hash of the second data set. Aleksander does not disclose that the individual data sets of the digital file are hashed separately. Aciicmez discloses generating independent hash values for each distinct portion of data ([0018]), which meets the limitation of the second hash, the second hash being generated based on a second data set. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the individual data sets of the digital files in Aleksander to have been hashed separately in order to reduce the time required to calculate the hash values for the entire digital file as suggested by Aciicmez ([0018]). Referring to claim 15, Aleksander discloses that if the search results in the hash being found in the blockchain, the stored data associated with the hash is sent to the user terminal and a positive message is returned to the user (Page 20, lines 5-12 & Page 21, lines 7-11), which meets the limitation of receiving a second response from the trusted assertion service indicating that the trusted assertion ledger comprises the second assertion. Upon receipt of a positive message, the user can choose to proceed with verification of ownership of the data (Page 20, lines 10-12: verifying ownership reads on the claimed determining a provenance; Examiner notes that the claims do not define the claimed “association” between the first data set and the third data set. Therefore, any association between the data reads on the claimed association. For instance, the third data set of Aleksander that includes the file and the data associated with the file (See page 10, line 23 – page 11, line 6) can read on the claimed third data set), which meets the limitation of determining that the provenance of the first data set associating the first data set with a third data set based, at least in part, on the second response indicating that the trusted assertion ledger comprises the second assertion. Referring to claim 16, Aleksander discloses that the generated hash is utilized to search the database utilizing a query to see if the hash is contained within the blockchain (Page 19, line 30 – Page 20, line 9), which meets the limitation of wherein the trusted assertion ledger comprises a blockchain ledger. Referring to claim 18, Aleksander discloses that if the search results in the hash being found in the blockchain, the stored data associated with the hash is sent to the user terminal and a positive message is returned to the user (Page 20, lines 5-12 & Page 21, lines 7-11: data associated with the hash would include the data associated with the file (See page 10, line 23 – page 11, line 6); data associated with the file reads on the claimed metadata), which meets the limitation of wherein the first response comprises metadata information associated with the first data set. Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Aleksander, WO 2019/233646, in view of Sauerwein Jr, U.S. Publication No. 2009/0161994, in view of Aciicmez, U.S. Publication No. 2010/0106976, and further in view of Jiang, U.S. Publication No. 2020/0193430. Referring to claim 8, Aleksander does not disclose that the blockchain query includes a timestamp. Jiang discloses a blockchain query that includes a timestamp ([0052]), which meets the limitation of the binding comprising a timestamp. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed information for the blockchain query of Aleksander to have additionally included timestamp information in order to provide more specific information regarding the generation of the data on the blockchain as specified by Jiang ([0038]-[0039]). Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Aleksander, WO 2019/233646, in view of Sauerwein Jr, U.S. Publication No. 2009/0161994, in view of Aciicmez, U.S. Publication No. 2010/0106976, and further in view of Liu, WO 2018/032890. Referring to claim 12, Aleksander discloses that a verification procedure is performed to determine if the digital file is registered to a blockchain by obtaining the data to be verified from an upload procedure and hashing the obtained data (Page 19, lines 7-12, 27-29), which meets the limitation of wherein accessing the first data set and first fact information comprises issuing a data [request] to a data management service for the first data set, and in response to the data request, receiving the first data set and the first fact information associated with the first data set from the data management service. Aleksander does not disclose that the upload procedure includes a request. Liu discloses a content upload procedure that utilizes an upload request (Page 24, third paragraph), which meets the limitation of issuing a data request to a data management service for the first data set. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the upload procedure of Aleksander to have utilized an upload request in order to ensure that the upload procedure can be processed as suggested by Liu (Page 24, third paragraph). Referring to claim 13, Aleksander discloses that a verification procedure is performed to determine if the digital file is registered to a blockchain by obtaining the data to be verified from an upload procedure and hashing the obtained data (Page 19, lines 7-12, 27-29), which meets the limitation of wherein accessing the first data set comprises accessing the first data set from [a data marketplace interface exposed by a data management service]. Aleksander does not disclose that the upload procedure includes a marketplace interface. Liu discloses a content upload procedure that utilizes an upload request (Page 24, third paragraph: upload request can be considered a marketplace interface as claimed), which meets the limitation of wherein accessing the first data set comprises accessing the first data set from a data marketplace interface exposed by a data management service. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the upload procedure of Aleksander to have utilized an upload request in order to ensure that the upload procedure can be processed as suggested by Liu (Page 24, third paragraph). Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Aleksander, WO 2019/233646, in view of Sauerwein Jr, U.S. Publication No. 2009/0161994, in view of Aciicmez, U.S. Publication No. 2010/0106976, and further in view of Penugonda, U.S. Publication No. 2020/0226233. Referring to claim 17, Aleksander discloses that if the search results in the hash being found in the blockchain, the stored data associated with the hash is sent to the user terminal and a positive message is returned to the user (Page 20, lines 5-12 & Page 21, lines 7-11). Aleksander does not disclose that the third data set includes a timestamp. Penugonda discloses a ledger-based content system that utilizes content information that includes content origin information and timestamps ([0025]: Examiner notes that the stored data associated with the hash in Aleksander includes the third data set (See page 10, line 23 – page 11, line 6)), which meets the limitation of wherein the first response comprises an indication of timestamp information associated with the first assertion. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed information for the third data set of Aleksander to have additionally included timestamp information in order to provide an indication of when the digital file was generated as suggested by Penugonda ([0025]). Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Aleksander, WO 2019/233646, in view of Sauerwein Jr, U.S. Publication No. 2009/0161994, in view of Aciicmez, U.S. Publication No. 2010/0106976, and further in view of Schepis, U.S. Patent No. 9,268,964. Referring to claim 19, Aleksander discloses a blockchain file registration wherein a blockchain system registers on a blockchain (Page 13, lines 1-5 & Page 12, lines 11-13, 19-23 & Page 11, lines 7-10 & Figure 1) a digital file (Page 10, lines 23-26: digital file reads on the claimed first data set), along with data associated with the file (Page 10, line 31 – Page 11, line 6: data associated with the file reads on the claimed second data set), which meets the limitation of wherein the first data set comprises a first content file and the second data set comprises a second content [file]. Aleksander does not disclose that the data associated with the file is formatted as a file. Schepis discloses metadata structured in a file format (Col. 1, lines 51-52 & Col. 5, lines 43-49), which meets the limitation of the second data set comprises a second content file. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the data associated with the files in Aleksander to have been formatted as a file in order to provide the ability to search and organize the file data using specific types of devices as suggested by Schepis (Col. 1, lines 12-33). Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 BENJAMIN E LANIER whose telephone number is (571)272-3805. The examiner can normally be reached M-Th: 6:20-4:50. 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, Alexander Lagor can be reached at 5712705143. 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. /BENJAMIN E LANIER/ Primary Examiner, Art Unit 2437
Read full office action

Prosecution Timeline

May 16, 2023
Application Filed
Feb 15, 2024
Non-Final Rejection — §103
May 22, 2024
Response Filed
Jun 07, 2024
Final Rejection — §103
Oct 14, 2024
Request for Continued Examination
Oct 17, 2024
Response after Non-Final Action
Oct 22, 2024
Non-Final Rejection — §103
Jan 27, 2025
Response Filed
Feb 03, 2025
Final Rejection — §103
May 06, 2025
Request for Continued Examination
May 13, 2025
Response after Non-Final Action
May 19, 2025
Non-Final Rejection — §103
Aug 15, 2025
Interview Requested
Aug 28, 2025
Applicant Interview (Telephonic)
Aug 28, 2025
Examiner Interview Summary
Sep 22, 2025
Response Filed
Sep 29, 2025
Final Rejection — §103
Apr 03, 2026
Response after Non-Final Action

Precedent Cases

Applications granted by this same examiner with similar technology. Study what changed to get past this examiner.

Patent 12598079
DIGITAL SIGNATURES WITH KEY-DERIVATION
2y 5m to grant Granted Apr 07, 2026
Patent 12587541
SECURE CONNECTION BROKER FOR SWARM COMMUNICATIONS
2y 5m to grant Granted Mar 24, 2026
Patent 12566846
TURING MACHINE AGENT FOR BEHAVIORAL THREAT DETECTION
2y 5m to grant Granted Mar 03, 2026
Patent 12566884
MULTIMODAL FINGERPRINTING OF DIGITAL ASSETS
2y 5m to grant Granted Mar 03, 2026
Patent 12556414
SYSTEMS AND METHODS FOR AUTHENTICATION USING RELATIVISTIC ZERO KNOWLEDGE PROOFS
2y 5m to grant Granted Feb 17, 2026

AI Strategy Recommendation

Click below to generate an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

7-8
Expected OA Rounds
69%
Grant Probability
48%
With Interview (-21.5%)
3y 6m
Median Time to Grant
High
PTA Risk
Based on 909 resolved cases by this examiner