Prosecution Insights
Last updated: October 02, 2026
Application No. 18/821,822

Systems and Methods for Scalable Management and Distribution of Digital Assets

Final Rejection §103
Filed
Aug 30, 2024
Priority
Aug 31, 2023 — provisional 63/535,846
Examiner
POUDEL, SAMIKSHYA NMN
Art Unit
2436
Tech Center
2400 — Computer Networks
Assignee
Intertrust Technologies Corporation
OA Round
2 (Final)
52%
Grant Probability
Moderate
3-4
OA Rounds
10m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 52% of resolved cases
52%
Career Allowance Rate
14 granted / 27 resolved
-6.1% vs TC avg
Strong +78% interview lift
Without
With
+77.8%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
14 currently pending
Career history
48
Total Applications
across all art units

Statute-Specific Performance

§101
16.2%
-23.8% vs TC avg
§103
56.9%
+16.9% vs TC avg
§102
12.3%
-27.7% vs TC avg
§112
13.8%
-26.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 27 resolved cases

Office Action

§103
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 Arguments In the remarks filed on 06/02/2026. The applicant amended claims 1, 2, 4, 5, 7, and 11 are amended. No claims were added. Claims 9,10, 12-14 are cancelled. With respect to claim objections: Applicants’ claim amendments and remarks filed on 06/02/2026 have been fully considered and overcame the claim objections as presented in the non-final office action filed 01/02/2026. Therefore, objections have been withdrawn. With respect to 35 U.S.C. §101 rejections: Applicants’ claim amendments and remarks filed on 06/02/2026 have been fully considered and overcame the 101 rejections as presented in the non-final office action filed 01/02/2026. Therefore, 101 rejections have been withdrawn. With respect to 35 U.S.C. §102 and 103 rejections: Applicants’ arguments filed on 06/02/2026 have been received and entered. Applicants’ arguments with respect to the newly amended independent claims, see Applicant Arguments 7-9, with respect to the rejection (s) of independent claim 1 has been fully considered. Applicant argues that Khandelwal (US 20220229883 A1) in view of Marks (US 20230037728 A1) fails to teach the amended claim limitations “a content asset, the content asset comprising a plurality of encrypted content segments wherein a first subset of the content segments are encrypted with one or more common encryption keys and a second subset of the content segments are encrypted with one or more copy encryption keys” but are moot because the claim amendments changes the scope of the claims and thus necessitates the new ground of rejections as presented below. 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. Claims 1- 8, 11, and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Khandelwal (US 20220229883 A1) in view of Marks (US 20230037728 A1) in view of Carny (US 20020150239 A1). Regarding claim 1, Khandelwal teaches a method for managing a content asset performed by a ledger service executing on a system comprising a processor and a non-transitory computer-readable storage medium storing instructions that, when executed by the processor (Khandelwal, method and system for protecting, managing and monetizing creative works using blockchain, [0007] The system 100 may be stored or implemented via a server 90 (such as a web server) that may be in communication with a file server, a database and a blockchain. The system 100 includes at least one processor for executing a program or programs that implement the functionality, [0033] a computer program product stored in a machine-readable medium, [0224]), cause the system to perform the method, the method comprising: receiving, by the ledger service, a request to generate a plurality of non-fungible tokens associated with a content asset, the request comprising one or more token minting parameters, the token minting parameters comprising an indication that N non-fungible tokens should be minted by the ledger service in response to the request (Khandelwal, The system then determines if the user has requested an NFT to be minted as a result of the validated submission (1210), [0046], If the user requests an NFT to be minted, the system passes the submission to the validated NFTs component 126 of the encapsulating trust mechanisms component 108 for minting of the validated NFT, [0047] Once a validated NFT is minted for IP owners of a creative work, one or more child NFTs can be minted. These child NFTs can be minted and used to provide rights to owners of the validated NFTs or third parties, [0157] the system then sends the package of proof, among other information to a Validated NFT smart contract component. In one embodiment, the other information that is sent to the Validated NFT Smart Contract may include at least one of: ID Number, Owners Information (Owner Address, Number of Shares), Creator Names, Creation Date, File to hash, including the original creation file and/or a zip file of the Package of Proof, and/or Payment Plan (Percentage Type and Value to Parties or Fixed Value or Free), [0181]) [Examiner interprets that system receiving a user submissions requesting of NFTs and system minting a validated NFT and one or more child NFTs based on a predetermined number of tokes or shares as limitation above]; generating, by the ledger service based on the request, a master token, the master token comprising a token identifier associated with the master token and metadata associated with the content asset (Khandelwal, a unique non-fungible token (NFT) can be minted (e.g. ERC-721) to represent the creative work. This NFT can then be stored in the blockchain and placed in a marketplace where it can be monetized, [0010] minting a validated non-fungible token (NFT), the validated NFT (i.e., a master token) including at least the creative work and the package of proof, [0016] a validated NFT may represent ownership of the underlying creative work associated with the NFT (musical works, literary works, visual works, etc.)., [0174] the system then sends the package of proof, among other information to a Validated NFT smart contract component. In one embodiment, the other information that is sent to the Validated NFT Smart Contract may include at least one of: ID Number, Owners Information (Owner Address, Number of Shares), Creator Names, Creation Date, File to hash, including the original creation file and/or a zip file of the Package of Proof, and/or Payment Plan (Percentage Type and Value to Parties or Fixed Value or Free) (i.e. token identifier + metadata associated with the asset) [0181]) [Examiner interprets that system generating unique validated NFT (i.e., master token with token ID) containing data describing creative works, creator names, date etc., (i.e., metadata) as limitation above]; recording the generated master token in a trusted ledger managed by the ledger service (Khandelwal, a unique non-fungible token (NFT) can be minted (e.g. ERC-721) to represent the creative work. This NFT can then be stored in the blockchain and placed in a marketplace where it can be monetized, [0010] each time a creative work is validated, an NFT may be minted for that creative work. This validated NFT (i.e., the generated master token) may be seen as a creator's immutable claim to the creation and registered on a blockchain, he NFT may be associated, or include, the creator's package of proof, stored on the blockchain, for example as a hash of one or more files or the like. This combination of the profile pages, packages of proof, and NFTs allows the creator to manage the creative content/work. [0047]) [Examiner interprets that system storing the validated NFT in the blockchain in a public, immutable record on a blockchain (i.e., trusted ledger) as limitation above]; generating, by the ledger service based on the request, a set of N-1 copy tokens, wherein each copy token of the set of N-1 copy tokens comprises a copy token identifier associated with the respective copy token and a reference to the master token (Khandelwal, Once a validated NFT is minted for IP owners of a creative work, one or more child NFTs can be minted. These child NFTs can be minted and used to provide rights to owners of the validated NFTs or third parties, [0157] the child NFTs are linked to the validated NFT using a dual link, where each child NFT stores the connected validated NFT contract address and NFT ID; and that corresponding Validated NFT stores the child NFT's smart contract address the NFT ID, [0166] A validated NFT can be minted for the source creative work (e.g. image or video clip) and collectible NFTs can be minted that reference the master, [0216] Through Collectible NFTs, copies of the creative work can be sold without transferring the underlying ownership in the creative work, [0183]) [Examiner interprets that system generating child NFTs that are derived from the validated NFT (i.e., master token) and child NFT storing the connected validated NFT contract address and NFT ID as limitation above]; and recording each copy token of the set of N-1 copy tokens in a trusted ledger managed by the ledger service (Khandelwal, a unique non-fungible token (NFT) can be minted (e.g. ERC-721) to represent the creative work. This NFT can then be stored in the blockchain and placed in a marketplace where it can be monetized, [0010] Once a validated NFT is minted for IP owners of a creative work, one or more child NFTs can be minted. These child NFTs can be minted and used to provide rights to owners of the validated NFTs or third parties, [0157] the child NFTs are linked to the validated NFT using a dual link, where each child NFT stores the connected validated NFT contract address and NFT ID; and that corresponding Validated NFT stores the child NFT's smart contract address the NFT ID, [0166] the system may then generate collectible NFTs based on the Validated NFT. Through Collectible NFTs, copies of the creative work can be sold without transferring the underlying ownership in the creative work, [0166]) [Minted NFTs are inherently recorded on the blockchain ledger]. Although Khandelwal discloses minting NFTs using ERC 1155 standard and explicitly teaches minting predetermined number (X) of shares for a validated NFT, [0182] it is well known in the art that ERC 1155 supports mint operations in which mint request includes parameters specifying token quantities, But Khandelwal does not explicitly teach: the content asset comprising a plurality of encrypted content segments wherein a first subset of the content segments are encrypted with one or more common encryption keys and a second subset of the content segments are encrypted with one or more copy encryption keys; Receiving a request to generate a plurality of non-fungible tokens associated with a content asset, the request comprising token minting parameters comprising an indication that N non-fungible tokens should be minted by the ledger service in response to the request; generating, by the ledger service based on the request, a set of N-1 copy tokens, wherein each copy token of the set of N-1 copy tokens However, Marks teaches: Receiving a request to generate a plurality of non-fungible tokens associated with a content asset, the request comprising token minting parameters comprising an indication that N non-fungible tokens should be minted by the ledger service in response to the request (Marks, The method may include receiving, from a verified seller with a UIAM minter account, a request to mint a Parent UIAM token and at least one Child UIAM token, [0010] seller 103 may designate how many units of the physical assets are to be sold in the batch, [0114] Child UIAM token(s) may be minted, the number of which may correspond with the number of UIAM-linked assets provided by seller 103, [0122]) [Examiner interprets that system designating how many units of non-fungible tokens and total number of child tokens corresponding to the number based on request as limitation above]; generating, by the ledger service based on the request, a set of N-1 copy tokens, wherein each copy token of the set of N-1 copy tokens (Marks, The method may include receiving, from a verified seller with a UIAM minter account, a request to mint a Parent UIAM token and at least one Child UIAM token, [0010] seller 103 may designate how many units of the physical assets are to be sold in the batch, [0114] Child UIAM token(s) may be minted, the number of which may correspond with the number of UIAM-linked assets provided by seller 103, [0122]) [Examiner interprets that system minting the number of child tokens corresponding with the number of UIAM linked assets provided as limitation above]; Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Khandelwal to include a concept of Receiving a request to generate a plurality of non-fungible tokens associated with a content asset, the request comprising token minting parameters comprising an indication that N non-fungible tokens should be minted by the ledger service in response to the request, and generating, by the ledger service based on the request, a set of N-1 copy tokens, wherein each copy token of the set of N-1 copy tokens and as taught by Marks for the purpose of receiving, from a verified seller with a UIAM minter account, a request to mint a Parent UIAM token and at least one Child UIAM token, [Marks:0010] designating how many units of the physical assets are to be sold in the batch, [Marks:0114] and minting Child UIAM token(s) the number of which may correspond with the number of UIAM-linked assets provided by seller 103, [Marks:0122]. Khandelwal and Marks do not explicitly teach: the content asset comprising a plurality of encrypted content segments wherein a first subset of the content segments are encrypted with one or more common encryption keys and a second subset of the content segments are encrypted with one or more copy encryption keys However, Carny teaches: the content asset comprising a plurality of encrypted content segments wherein a first subset of the content segments are encrypted with one or more common encryption keys and a second subset of the content segments are encrypted with one or more copy encryption keys (Carny, the content should be stored (e.g., in a proxy server, streaming server or a content distribution network) before it is distributed to the final user… If one is going to employ key management for digital rights management, then it is required to send a content P that is encrypted with one key, Ks, {E.sub.Ks(P)}, to multiple users, U.sub.l, . . . U.sub.N, such that each users will posses a special key, K.sub.1, . . . K.sub.N. Using current methods, one should either first decrypt die content using the key K.sub.S and then re-encrypt the content using one of the keys K.sub.1, . . . K.sub.N, {C.sub.i=E.sub.Ki(D.sub.Ks(P))} or else encrypt the encrypted context, E.sub.Ks(P), with the key K.sub.i and send the doubly-encrypted content, {C.sub.is=E.sub.Ki(E.sub.Ks(P))}, together with the two keys, K.sub.S and K.sub.i, to the final user, [0006] a method and system that allow personalized encryption of previously encrypted digital content, [0007] real-time personalized encryption of digital content (e.g., video, audio, e-book, executable code etc.).. the encryption method is based on first selecting, either manually or automatically, at least one salient fraction of the content, whose removal will greatly reduce the quality of the content, and then dividing each of the fractions to several segments. Each segment S.sub.j is then replicated to N copies, S.sub.j,l, . . . S.sub.j,N, and each copy is encrypted with a special key, K.sub.j,n, n=1 . . . N. Each encrypted segment and each of the corresponding keys are regarded as a logical symbol of a N-letter alphabet, [0049] each copy of the data segment is encrypted with a unique encryption key, corresponding to one of the symbols in the alphabet, [0052] The key management system 250 produces individual encryption keys for each copy of each segment. Each copy of each segment is thereafter encrypted with the corresponding key, [0053] the method additionally comprises encrypting the portion of the digital content not selected in the selection step, [0066]) [Examiner interprets that system using personalized encryption of digital content that may already be encrypted using key common to multiple distributed copies/users while selected portions of that content are divided into segments, replicated into multiple copies, and the respective copies are encrypted using individual copy specific encryption keys as limitation above]. Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Khandelwal and Marks to include a concept of the content asset comprising a plurality of encrypted content segments wherein a first subset of the content segments are encrypted with one or more common encryption keys and a second subset of the content segments are encrypted with one or more copy encryption keys and as taught by Carny for the purpose of allowing personalized encryption of previously encrypted digital content [Carny:0007]. Regarding claim 2, Khandelwal, Marks and Carny teach the method of claim 1, wherein the request to generate the plurality of non-fungible tokens is received from a token rights management service (Marks, a UIAM may provide its owner with permissioned access to proprietary digital data. UIAM-linked proprietary data may be stored in a centralized or decentralized database, Corresponding UIAM token ownership may authorize viewing and/or modification access to such proprietary data. Further, permissioned access to the UIAM-linked proprietary data may be similarly documented in and/or enabled by transactions published in a public blockchain, a private blockchain, and/or a decentralized digital ledger, [0052] UIAM Application Entity 120 may substantially comprise the back-end of UIAM system 100, [0076] UIAM Application Entity 120 may additionally comprise a plurality of functional software blocks, such as, for example, a data intake engine, an analytics engine, a token distribution block, a blockchain integration block, a financial transaction block, and/or other functional software blocks.. further comprise a private blockchain network and/or a public blockchain network, [0077]) [Examiner interprets that UIAM Application Entity 120 managing minting, controlling permissions, and enforcing rights via smart contracts as the request to generate the plurality of non-fungible tokens is received from a token rights management service]. Regarding claim 3, Khandelwal, Marks and Carny teach the method of claim 2, wherein the request to generate the plurality of non-fungible tokens is received from a blockchain connector service of the token rights management service (Marks, UIAM Application Entity 120 may additionally comprise a plurality of functional software blocks, such as, for example, a data intake engine, an analytics engine, a token distribution block, a blockchain integration block, a financial transaction block, and/or other functional software blocks.. further comprise a private blockchain network and/or a public blockchain network, [0077] certain functional software blocks of UIAM Application Entity 120 may interface with one or more third party services directly and/or over a communications network(s), via, for example, API calls, ABI calls, and/or the like to obtain data or other information; facilitate financial transactions with financial exchange entity 180; and record data in, for example, a blockchain associated with blockchain entity 160. Such data to be obtained may include, for example, ownership-related data, permission access data, financial data, proof of transactions, other data referenced herein, and/or the like, [0078]) [Examiner interprets that blockchain integration block interfacing between application logic and blockchain as blockchain connecter service]. Regarding claim 4, Khandelwal, Marks and Carny teach teaches method of claim 1, wherein the metadata comprises one or more of title information associated with the content asset, description information associated with the content asset, ownership information associated with the content asset, and an indication of a location of the content asset (Khandelwal, For validated NFTs, details are stored (e.g. as components of the NFT or externally and linked by reference data stored in the NFT) about the creative work, including supporting documents, and other details about the creative work, the creator, and the current owner(s) of the IP in the work, including information collected in validation component 102. In an embodiment, author details are stored in the NFT, a hash of the supporting documents is stored in the NFT and a reference link to externally stored documents/information is stored in the NFT, [0156] a validated NFT allows for key information to be stored within the NFT and/or hashed in the NFT record. In one embodiment, a validated NFT may represent ownership of the underlying creative work associated with the NFT (musical works, literary works, visual works, etc.), [0174] the system then sends the package of proof, among other information to a Validated NFT smart contract component. In one embodiment, the other information that is sent to the Validated NFT Smart Contract may include at least one of: ID Number, Owners Information (Owner Address, Number of Shares), Creator Names, Creation Date, File to hash, including the original creation file and/or a zip file of the Package of Proof, and/or Payment Plan (Percentage Type and Value to Parties or Fixed Value or Free) (i.e. token identifier + metadata associated with the asset) [0181]) [Examiner interprets that Validated NFTs containing ownership information, description of creative works, owner information, and link by reference data stored in NFT (i.e., location) as limitation above]. Regarding claim 5, Khandelwal, Marks and Carny teach teaches the method of claim 4, wherein the indication of the location of the content asset comprises a URL location for accessing the content asset (Khandelwal, For validated NFTs, details are stored (e.g. as components of the NFT or externally and linked by reference data stored in the NFT) about the creative work, including supporting documents, and other details about the creative work, the creator, and the current owner(s) of the IP in the work, including information collected in validation component 102. In an embodiment, author details are stored in the NFT, a hash of the supporting documents is stored in the NFT and a reference link to externally stored documents/information is stored in the NFT, [0156]) [Examiner interprets that link by reference data stored in NFT (i.e., URL location) as limitation above]. Regarding claim 6, Khandelwal, Marks and Carny teach teaches the method of claim 1, wherein the reference to the master token comprises the token identifier associated with the master token (Khandelwal, the child NFTs are linked to the validated NFT using a dual link, where each child NFT stores the connected validated NFT contract address and NFT ID; and that corresponding Validated NFT stores the child NFT's smart contract address the NFT ID. Similar to the method described above for validated NFTs, the legal rights of a child NFT can be specified in a legal contract/document, [0166]) [Examiner interprets that contact address + NFT ID as token identifier]. Regarding claim 7, Khandelwal, Marks and Carny teach the method of claim 1, wherein the master token further comprises a token serial number corresponding to an initial token serial number for the content asset (Khandelwal, a unique non-fungible token (NFT) can be minted (e.g. ERC-721) to represent the creative work. This NFT can then be stored in the blockchain and placed in a marketplace where it can be monetized, [0010] the child NFTs are linked to the validated NFT using a dual link, where each child NFT stores the connected validated NFT contract address and NFT ID; and that corresponding Validated NFT stores the child NFT's smart contract address the NFT ID, [0166] the system then sends the package of proof, among other information to a Validated NFT smart contract component. In one embodiment, the other information that is sent to the Validated NFT Smart Contract may include at least one of: ID Number, Owners Information (Owner Address, Number of Shares), Creator Names, Creation Date, File to hash, including the original creation file and/or a zip file of the Package of Proof, and/or Payment Plan (Percentage Type and Value to Parties or Fixed Value or Free), [0181]) [Examiner interprets that validated NFT i.e., the master token) containing Token ID number (i.e., initial token serial number) as limitation above]. Regarding claim 8, Khandelwal, Marks and Carny teach method of claim 7, wherein each copy token of the set of N-1 copy tokens comprises a token serial number for the respective copy token (Khandelwal, the child NFTs are linked to the validated NFT using a dual link, where each child NFT stores the connected validated NFT contract address and NFT ID; and that corresponding Validated NFT stores the child NFT's smart contract address the NFT ID, [0166] the system may then generate collectible NFTs based on the Validated NFT. Through Collectible NFTs, copies of the creative work can be sold without transferring the underlying ownership in the creative work. The owner of the validated NFT can mint new collectible NFTs, [0183]) [Examiner interprets that each child /collect NFT having its own NFT ID (i.e., token serial number for respective copy token) as limitation above]. Regarding claim 11, Khandelwal, Marks and Carny teach the method of claim 1, wherein the content asset comprises one or more of text content, audio content, and video content (Khandelwal, method for protecting, managing and/or monetizing creative works. Examples of creative works include, but are not limited to, trademarks, industrial designs, patents, music, videos, e-books, manuscripts, photographs, digital art, software code, websites, inventions, trademarks, copyrights, designs, different digital files types (mp3, mp4, epub, txt, jpeg, pdf, html) and the like, [0032]) Regarding claim 15, Khandelwal, Marks and Carny teach the method of claim 1, wherein the trusted ledger comprises cryptographically linked entries (Khandelwal, With respect to the timestamping component 104, the timestamping component 104 enables creators to post a permanent record (with a timestamp) of their creative work to the blockchain, in a short period of time, such as in minutes. The timestamping component 104 records the claim, or submission, of the creative work as a public, immutable record on a blockchain that the creator can use to prove the creative work is theirs. In one embodiment, the decentralized timestamping of intellectual property component 104 allow claims of ownership to be made quickly and inexpensively by creating, for example, a one-way hash of a submitted creative work on a blockchain (for example, a public blockchain such as Ethereum). This may be seen as a process of decentralized timestamping of intellectual property, [0035]) [Blockchain record are inherently cryptographically linked]. Regarding claim 16, Khandelwal, Marks and Carny teach the method of claim 15, wherein the trusted ledger comprises a trusted immutable distributed assertion ledger (Khandelwal, With respect to the timestamping component 104, the timestamping component 104 enables creators to post a permanent record (with a timestamp) of their creative work to the blockchain, in a short period of time, such as in minutes. The timestamping component 104 records the claim, or submission, of the creative work as a public, immutable record on a blockchain that the creator can use to prove the creative work is theirs. In one embodiment, the decentralized timestamping of intellectual property component 104 allow claims of ownership to be made quickly and inexpensively by creating, for example, a one-way hash of a submitted creative work on a blockchain (for example, a public blockchain such as Ethereum). This may be seen as a process of decentralized timestamping of intellectual property, [0035]). Regarding claim 17, Khandelwal, Marks and Carny teach the method of claim 16, wherein the trusted immutable distributed assertion ledger comprises a blockchain ledger (Khandelwal, a unique non-fungible token (NFT) can be minted (e.g. ERC-721) to represent the creative work. This NFT can then be stored in the blockchain and placed in a marketplace where it can be monetized, [0010]). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20070067244 A1: “relates to preventing piracy of digital content in a broadcast encryption system and more specifically to tracing traitors who may be colluding to redistribute such content and/or related decryption keys, and to renewably revoking compromised keys to prevent further use in gaining unauthorized access to content” THIS ACTION IS MADE FINAL. Applicants are 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 SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri. 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, SHEWAYE GELAGAY can be reached at (571)272-4219. 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. /S.N.P./Examiner, Art Unit 2436 /TRONG H NGUYEN/Primary Examiner, Art Unit 2436
Read full office action

Prosecution Timeline

Aug 30, 2024
Application Filed
Jan 02, 2026
Non-Final Rejection mailed — §103
Jun 02, 2026
Response Filed
Aug 27, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12717884
PROACTIVE BIOMETRIC SIGNATURE GENERATION
3y 9m to grant Granted Aug 25, 2026
Patent 12645787
STACK TRACE ANALYSIS MODEL
2y 11m to grant Granted Jun 02, 2026
Patent 12619726
CYBER RESILIENCE INTEGRATED SECURITY INSPECTION SYSTEM (CRISIS) AGAINST FALSE DATA INJECTION ATTACKS
4y 1m to grant Granted May 05, 2026
Patent 12591663
INFORMATION PROCESSING DEVICE, INFORMATION PROCESSING METHOD, AND INFORMATION PROCESSING COMPUTER PROGRAM PRODUCT
2y 7m to grant Granted Mar 31, 2026
Patent 12470379
LINK ENCRYPTION AND KEY DIVERSIFICATION ON A HARDWARE SECURITY MODULE
3y 0m to grant Granted Nov 11, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
52%
Grant Probability
99%
With Interview (+77.8%)
2y 11m (~10m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 27 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month