Prosecution Insights
Last updated: April 19, 2026
Application No. 17/894,779

SYSTEM AND METHOD FOR PARTITIONING DIGITAL RESOURCES USING A NETWORKED RESOURCE PLATFORM

Non-Final OA §103
Filed
Aug 24, 2022
Examiner
XIAO, ZESHENG
Art Unit
3698
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
BANK OF AMERICA CORPORATION
OA Round
3 (Non-Final)
42%
Grant Probability
Moderate
3-4
OA Rounds
4y 1m
To Grant
75%
With Interview

Examiner Intelligence

Grants 42% of resolved cases
42%
Career Allow Rate
48 granted / 113 resolved
-9.5% vs TC avg
Strong +33% interview lift
Without
With
+32.9%
Interview Lift
resolved cases with interview
Typical timeline
4y 1m
Avg Prosecution
26 currently pending
Career history
139
Total Applications
across all art units

Statute-Specific Performance

§101
23.7%
-16.3% vs TC avg
§103
47.0%
+7.0% vs TC avg
§102
4.5%
-35.5% vs TC avg
§112
17.5%
-22.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 113 resolved cases

Office Action

§103
DETAILED ACTION This is office action on the merits in response to the application filed on 12/18/2025. Claims 1-22 have been filed by the applicant. Claims 6, 13 and 19 are presently canceled. Claims 1, 8 and 14 are currently amended. Claims 1-5, 7-12, 14-18 and 20-22 are currently pending and have been examined. 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 . 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 12/18/2025 has been entered. Response to Argument Rejection under 103: The applicant argues that Prado does not teach “wherein the request to transfer the portion of the one or more digital resource partitions comprises an identification of a unique portion of the digital resource”. The examiner respectfully disagrees. Prado clearly discloses the transfer can be a particular NFT or fractional NFTs [0117 0170 0174]. Prado also discloses each NFT includes metadata which includes: a NFT title; a NFT type; and/or NFT properties including a NFT name, NFT description, a NFT image uniform resource indicator (URI) which addresses a digital asset, and/or NFT attributes [0035]. Therefore, Prado teaches the above limitation and it is understood the request will comprise an identification of a unique portion of the digital resource. The applicant further argues that Prado does not teach claim 22. The examiner respectfully disagrees. Prado clearly discloses a user device requesting NFT [0170] which implicitly discloses the feature of 22 to display interface element for user to select. The examiner agrees that the previously cited prior art does not teach claim 21. New prior art is provided, see 103 rejections. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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. Claim(s) 1-5, 7-12, 14-18, 20 and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pardo (US 20230034621 A1), and further in view of Nagle et al. (US 20190073152 A1). With respect to claim 1, 8 and 14: Pardo teaches: at least one non-transitory storage device; and at least one processor coupled to the at least one non-transitory storage device, wherein the at least one processor is configured to. (The node 112 can include a memory 301, a processor 302. [0152-0158] Fig. 3) generate, using a custom set of executable code, a digital resource comprising one or more digital resource partitions, wherein the generating the digital resource comprises […]. (In another example, the NFT method includes the nodes 112 minting a first NFT 120 and generating fractions of the NFT 120. The minting includes generating NFT metadata 122 for the NFT. A first fraction of the NFT 120 is transferred to an owner (client device 118). In some examples, a single NFT may be divided into fractions, such that the fractions themselves may indicate partial ownership of the NFT, and indirectly partial ownership of the item or digital asset represented by the NFT. When an NFT is fractionalized, the NFT is first locked in a smart contract. That smart contract then splits the ERC-721 token into multiple fractions in the form of ERC-20 tokens. Each fraction represents partial ownership of the NFT. Shareholders will possess a fraction of the NFT, equal to the value of their ERC-20 tokens divided by the total number of those tokens produced when the NFT was locked in the smart contract. In an example, each fraction is fungible. In other examples, each fraction is non-fungible. [0113-0114, 0203]) present a graphical interface of a networked resource platform on a display device of a first endpoint device. (The NFT manager 206 can also interact with the user through a user interface of the client device 118 (not shown here). The client device 118 can include user interface devices for user input and user output. [0146 0148]) receive, from the first endpoint device through the networked resource platform, a request to transfer a portion of the one or more digital resource partitions to a cryptographic address associated with the first endpoint device. (At step 504, the client device 118 requests an NFT 120, and advises of the wallet address of the client device 118. In another example of the NFT method 500, the NFT 120 has a plurality of fractions or fractional NFTs. The rule 124 or the smart contract 150 relates to the client device 118 owning more than one fraction of the NFT 120, such as a first fractional NFT and a second fractional NFT of a particular NFT 120. The rest of the NFT method 500 can be implemented in a similar fashion. [0170 0174]) wherein the request to transfer the portion of the one or more digital resource partitions comprises an identification of a unique portion of the digital resource. (The nodes 112 can execute transactions on the blockchain 130, to transfer the NFTs 120. The NFTs 120 can be currency tokens, blockchain tokens, Ethereum tokens, ERC-721 NFTs or ERC-1155 NFTs. In an example, a particular NFT 120 can be further split into fractional NFTs. the NFT metadata includes: a NFT title; a NFT type; and/or NFT properties including a NFT name, NFT description, a NFT image uniform resource indicator (URI) which addresses a digital asset, and/or NFT attributes. [0035 0117 0170 0174]) execute one or more validation checks on (i) the cryptographic address comprising (a) verifying the cryptographic address and (b) verifying an amount of alternate resources associated with the cryptographic address that required to acquire ownership of the portion of the one or more digital resource partitions. (For example, the client device 118 may present a number of NFTs to prove that the client device 118 owns a defined subset of the NFTs 120 (or all of the NFTs 120 in a set of NFTs). For example, the node 112 verifies the subset of the NFTs 120 or performs aspects of the smart contract 150. For example, the node 112 may determine that the client device 118 is the owner of a particular subset of the NFTs 120, and the new NFT 120 represents that the particular subset of the NFTs 120 is owned by the owner. Nodes (miners or sealers) validate a transaction by walking down the blockchain to verify whether the said “from” account has sufficient balance required for the transaction from all previous transactions involving the account. [0095, 0152, 0171-0172]) ii) the portion of the one or more digital resource partitions comprising (a) authenticating an object associated with the one or more digital resource partitions. (In an example, the off-chain storage 102 stores at least one digital asset 104, each digital asset 104 being secured by an NFT 120. Examples of the digital asset 104 include an image, a video file, an audio file, a multimedia file, alpha-numeric file, a hologram, a deed, a word, or words. In some examples, the digital asset is immutable. In some examples, the digital asset is editable. [0118]) (b) verifying that the portion of the one or more digital resource partitions are eligible for transfer. (In an example embodiment of any of the above methods, the determining includes querying the blockchain to verify that a wallet address of the first NFT belongs to the owner. In an example, the node 112 can determine the ownership of the first NFT 120 by querying the blockchain 130 to verify that the wallet address of the first NFT 120 matches the wallet address of the client device 118. [0022 0135]) based on executing the one or more validation checks, transfer the portion of the one or more digital resource partitions to the cryptographic address associated with the first endpoint device. (In some examples, at step 510 the new NFT 120 was pre-minted or is owned by a different owner, which is then transferred to the client device 118, automatically based on the smart contract 150 or a rule 124. [0173]) Pardo does not teach executing a duplicate check on the digital resource. However, Nagle further teaches executing a duplicate check on the digital resource. (In some embodiments, distributed storage systems may implement data deduplication techniques to identify a data block received in a write request to determine whether a duplicate copy of the data block is currently stored in the storage system. The deduplication process may use a hash function that generates a hash value based on the data block. The generated hash value may be compared with hash values of a deduplication map that identifies currently stored data blocks at the storage system. If the generated hash value matches with any of the hash values in the deduplication map, then the data block may be considered to be a copy or duplicate of another data block that is currently stored at the storage system. [0021-0022]) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Pardo to executing duplicate check with the technique as disclosed by Nagle to improve the utilization of storage resources as Nagle suggested [0021]. Claim 8, a computer product with the same scope as claim 1, is rejected. Claim 14, a method with the same scope as claim 1, is rejected. With respect to claim 2, 9 and 15: Pardo does not teach retrieving a copy of a digital object associated with the digital resource from an object address within the custom set of executable code; generating a hash output value by inputting the copy of the digital object into a hash algorithm; and comparing the hash output value with one or more authentication hash values within an authentication repository. However, Nagle further teaches retrieving a copy of a digital object associated with the digital resource from an object address within the custom set of executable code; generating a hash output value by inputting the copy of the digital object into a hash algorithm; and comparing the hash output value with one or more authentication hash values within an authentication repository. (In some embodiments, distributed storage systems may implement data deduplication techniques to identify a data block received in a write request to determine whether a duplicate copy of the data block is currently stored in the storage system. The deduplication process may use a hash function that generates a hash value based on the data block. The generated hash value may be compared with hash values of a deduplication map that identifies currently stored data blocks at the storage system. If the generated hash value matches with any of the hash values in the deduplication map, then the data block may be considered to be a copy or duplicate of another data block that is currently stored at the storage system. [0021-0022]) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Pardo to compare the hash to detect duplication with the technique as disclosed by Nagle to improve the utilization of storage resources as Nagle suggested [0021]. Claim 9, a computer product with the same scope as claim 2, is rejected. Claim 15, a method with the same scope as claim 2, is rejected. With respect to claim 3, 10 and 16: Nagle further teaches wherein comparing the hash output value with the one or more authentication hash values comprises: detecting a match between the hash output value and an authentication hash value of the one or more authentication hash values within the authentication repository; and determining that the digital object has already been used to generate an existing digital resource. (In some embodiments, distributed storage systems may implement data deduplication techniques to identify a data block received in a write request to determine whether a duplicate copy of the data block is currently stored in the storage system. The deduplication process may use a hash function that generates a hash value based on the data block. The generated hash value may be compared with hash values of a deduplication map that identifies currently stored data blocks at the storage system. If the generated hash value matches with any of the hash values in the deduplication map, then the data block may be considered to be a copy or duplicate of another data block that is currently stored at the storage system. [0021-0022]) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system to detect match between hash output values with the technique as disclosed by Nagle to improve the utilization of storage resources as Nagle suggested [0021]. Claim 10, a computer product with the same scope as claim 3, is rejected. Claim 16, a method with the same scope as claim 3, is rejected. With respect to claim 4, 11 and 17: Nagle further teaches wherein comparing the hash output value with the one or more authentication hash values comprises: detecting no match between the hash output value and an authentication hash value of the one or more authentication hash values within the authentication repository; determining that the digital object has not been used to generate an existing digital resource; and adding the hash output value to the authentication repository. (In some embodiments, distributed storage systems may implement data deduplication techniques to identify a data block received in a write request to determine whether a duplicate copy of the data block is currently stored in the storage system. The deduplication process may use a hash function that generates a hash value based on the data block. The generated hash value may be compared with hash values of a deduplication map that identifies currently stored data blocks at the storage system. If the generated hash value matches with any of the hash values in the deduplication map, then the data block may be considered to be a copy or duplicate of another data block that is currently stored at the storage system. [0021-0022]) Nagle does not explicitly discloses adding hash output to authentication repository, but it would have been obvious that in order to establishing deduplication map of Nagle, all new hashes will be stored into deduplication map (i.e., adding the hash output value to the authentication repository). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed to detect match between hash output values with the technique as disclosed by Nagle to improve the utilization of storage resources as Nagle suggested [0021]. Claim 11, a computer product with the same scope as claim 4, is rejected. Claim 17, a method with the same scope as claim 4, is rejected. With respect to claim 5, 12 and 18: Pardo further teaches wherein transferring the portion of the one or more digital resource partitions to the cryptographic address associated with the first endpoint device comprises setting an ownership parameter value for each of the digital resource partitions within the portion of the one or more digital resource partitions to the cryptographic address associated with the first endpoint device. (In some examples, the node 112 or the client device 118 also modifies the NFT metadata 122, for example in the NFT attributes to indicate ownership of the new NFT 120 or one of the other NFTs 120. [0173]) Claim 12, a computer product with the same scope as claim 5, is rejected. Claim 18, a method with the same scope as claim 5, is rejected. With respect to claim 6, 13 and 19: Pardo further teaches wherein the one or more validation checks comprises verifying an amount of alternate resources associated with the cryptographic address. (For example, the client device 118 may present a number of NFTs to prove that the client device 118 owns a defined subset of the NFTs 120 (or all of the NFTs 120 in a set of NFTs). For example, the node 112 verifies the subset of the NFTs 120 or performs aspects of the smart contract 150. In an example, at step 510, the node 112 mints a new NFT 120. For example, the node 112 may determine that the client device 118 is the owner of a particular subset of the NFTs 120, and the new NFT 120 represents that the particular subset of the NFTs 120 is owned by the owner. A command such as “ownerOf(tokenId)” from ERC 721 can be used, which uses the blockchain address of the NFT 120 to return the wallet address of the current owner, which can be matched to the wallet address of the client device 118. [0171-0172]) Claim 13, a computer product with the same scope as claim 6, is rejected. Claim 19, a method with the same scope as claim 6, is rejected. With respect to claim 7 and 20: Pardo further teaches wherein the digital resource is a non-fungible token. (In another example of the NFT method 500, the NFT 120 has a plurality of fractions or fractional NFTs. The rule 124 or the smart contract 150 relates to the client device 118 owning more than one fraction of the NFT 120, such as a first fractional NFT and a second fractional NFT of a particular NFT 120. [0174]) Claim 20, a method with the same scope as claim 7, is rejected. With respect to claim 22: Pardo further teaches wherein the networked resource platform displays one or more interface elements corresponding to one or more available digital resource partitions associated with one or more digital resources, and wherein the request to transfer the portion of the one or more digital resource partitions comprises a selection of one or more interface elements corresponding to the unique portion of the digital resource. (At step 504, the client device 118 requests an NFT 120. [0170]). Requesting an NFT on client device implies displaying interface elements and selection of interface elements. Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pardo and Nagle as applied to claim 1 above, and further in view of Bailey et al. (US 20240348887 A1). With respect to claim 21: Pardo in view of Nagle does not teach wherein the unique portion identified of the digital resource comprises a unique portion of pixels of an image corresponding to the digital resource, a unique timeframe of an audio file corresponding to the digital resource, or a unique sequence of frames of a video file corresponding to the digital resource. However, Bailey further teaches wherein the unique portion identified of the digital resource comprises a unique portion of pixels of an image corresponding to the digital resource, a unique timeframe of an audio file corresponding to the digital resource, or a unique sequence of frames of a video file corresponding to the digital resource. (In an example, one could take a video collection in a container 130 and assign NFTs to it, such as a whole collection of LeBron James dunks and assign that container 130 with an NFT. That then becomes commoditized and exchangeable. In other words any grid 100, container 130, node 140, video snippet, fractional video snippet part, etc., having been designated with a NFT now becomes trackable and tradable. So the NFT can really be applied to any of grid 100, container 130, or node 140, or a video snippet that has been fractionalized and assigned fractional NFT parts, in which that video snippet could indeed have multiple owners (e.g., I just bought three seconds of this video clip; I bought seconds 10 through 12. That's my fractionalized token.). [0093]) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Pardo in view of Nagle to associate portion of video to portion of digital resource with the technique as disclosed by Bailey to fractionalize the video for sale as Bailey suggested [0093]. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20190287175 A1: As illustrated below line 804 on FIG. 8, the debt buyers 814 may collect periodic loan repayments 816 from the borrower 806. The debt buyer 814 or may sell the loan token 812 to another buyer 818. In some implementations, the smart contract used by the fund 802 to issue the loan token allows for splitting the loan token into smaller tokens (e.g., by a splitToken( ) function that burns a token and returns fractional parts of the token to a token sender). Subsequent repayments on the loan 804 may then be divided and paid to the owners of the fractional parts of the loan token 812. Fractional non-fungible token ownership may be handled in a smart contract by, for example, replacing an owner field of a list with a cardinality of one with no weighting parameter to a list of owners with relative weights. US 20220198559 A1: In some embodiments, a participant of the DLTN owning the genesis UTXO token 202a in his/her DLTN account may wish to break the genesis UTXO token 202a into UTXO tokens with less value than that of the genesis UTXO token 202a. For example, the participant may wish to transfer a portion of the genesis UTXO token 202a to another DLTN account as a payment for a purchased product or service, and in such cases, the genesis UTXO token 202a may be partitioned or split into lesser valued UTXO tokens (e.g., child UTXO tokens 202b, 202c), initiating the generation of the family of UTXO tokens 202a-202h. In some embodiments, the term “child UTXO token” may be understood to mean as a UTXO token that is generated from an existing UTXO token using the child UTXO token generation process discussed below. Further, in some embodiments, the terms “partitioning” or “splitting” a UTXO token may be understood as the process of generating multiple child UTXO tokens from a single UTXO token using the child UTXO token generation process. In such cases, the total aggregate value of the child UTXO tokens may be same as the value of the single UTXO token (i.e., the “parent” UTXO token) and the parent UTXO token may be deactivated or rendered invalid or expired on the DLTN so that no token value is created or destroyed on the DLTN as a result of the UTXO token partitioning or splitting process (i.e., token value is conserved on the DLTN). US 20220370778 A1: Further, in some embodiments, the marketplace may offer fractional sale of an NFT, for example ⅓ or 1/10.sup.th of the NFT. In this instance, the associated assets and services may be partially consumable or not at all. For example, an NFT containing the right for 2 tattooing services associated with its art may be sold in four fractional parts. The ownership of one fraction of this NFT may carry the right for half a tattooing service, which is not sufficient for performing the tattoo associated with the art. The ownership of two fraction of this NFT carries the right for one tattooing service, which is sufficient for performing one tattooing service. Note that in the case of fractional NFT, the fraction may be restricted such as to maximize the consumption of the associated services and assets. For example, an NFT containing N services may have a number of fractions divisible by N such that 1/Nth of the NFT's ownership is sufficient to execute the service. Note that the fraction of an NFT is, in fact fungible, such that fractional NFTs are in fact semi-fungible. This means that a fraction of one NFT may not be interchangeable with the fraction of another NFT but may be interchangeable for the fraction of the same NFT. US 20230119843 A1: Also in some implementations, users may fractionalize the NFTs and sell a portion of an NFT to several users. For example, user A can transfer 0.1 of the first NFT to ten users. Each user that receives 0.1 of the first NFT may have 10% of the 2−2i digital tokens which the NFT represents or 0.2−0.2i digital tokens. US 20230267450 A1: Recently, some marketplaces have allowed digital assets, such as NFTs, to be split or separated into n-fractions or shards, which are then sold separately on the marketplace. The fractional NFTs (f-NFTs) allow users to own a piece of an NFT and trade them on the marketplace. Such technology enables the treatment of an NFT as a financial asset, slightly similar to a cryptocurrency, where the value of the fraction goes up or down depending on demand. US 20230308276 A1: A node in a blockchain network may send an operation for geometrically fractionalizing an non-fungible token (NFT) into geometric shards to a blockchain network. The geometric fractionalization associates each geometric shard with a specific part of the NFT. The node may also record, on distributed ledger of the blockchain network, the fractionalization of the NFT and the association between each geometric shard with the specific part of the NFT. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZESHENG XIAO whose telephone number is (571)272-6627. The examiner can normally be reached 10:00am-4:30pm M-F. 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, Patrick McAtee can be reached on (571) 272-7575. 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. /Z.X./Examiner, Art Unit 3698 /PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Read full office action

Prosecution Timeline

Aug 24, 2022
Application Filed
Mar 15, 2025
Non-Final Rejection — §103
Jun 23, 2025
Response Filed
Sep 07, 2025
Final Rejection — §103
Dec 18, 2025
Request for Continued Examination
Jan 05, 2026
Response after Non-Final Action
Jan 08, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12597020
AUTHENTICATED DATA FEED FOR BLOCKCHAINS
2y 5m to grant Granted Apr 07, 2026
Patent 12536528
Cross-Blockchain Transaction Rebroadcasting
2y 5m to grant Granted Jan 27, 2026
Patent 12524768
ON-DEMAND APPLICATIONS TO EXTEND WEB SERVICES
2y 5m to grant Granted Jan 13, 2026
Patent 12518268
PERSONALLY IDENTIFIABLE INFORMATION SECURE PERSON-TO-PERSON PAYMENT TECHNOLOGY
2y 5m to grant Granted Jan 06, 2026
Patent 12499443
SECURE CONTROL OF TRANSACTIONS USING BLOCKCHAIN
2y 5m to grant Granted Dec 16, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

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

Prosecution Projections

3-4
Expected OA Rounds
42%
Grant Probability
75%
With Interview (+32.9%)
4y 1m
Median Time to Grant
High
PTA Risk
Based on 113 resolved cases by this examiner. Grant probability derived from career allow 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