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 .
DETAILED CORRESPONDENCE
Acknowledgements
The Amendment of claims 1-3, filed on 02/11/2026 is acknowledged.
Claims 1-3 are pending.
Claims 4-5, are newly added, therefore
Claims 1-5 are hereby examined.
Examiner’s Claim Objection
Claim 3, has been amended with a first , a third, and a fourth, module strikeout. It is the believe of the Examiner that the second module should also be struck out so the claim reads “instructions, that when executed by the processor: … create an entity private key/wallet address pair …” Accordingly, applicant is advised to delete “a second module” from claim 3.
Examiner’s Response to Amendment/Remarks
35 USC § 112
The amendment to claims 1-3 filed on 02/11/2026 is acknowledged, and the amendment has overcome the 112 rejection. Therefore, the 112 rejection is hereby withdrawn.
Claim Rejections - 35 USC § 103 The Amendment of claims 1-3, filed on 02/11/2026 is acknowledged, and the remarks by the Applicants have been found not persuasive, by the Examiner. For example, in pages 4-5 of 6, of the response, Applicant disclose that:
The Cited Art Fails to Teach the Claimed Authorization Architecture,
“…Blaikie discloses a system where players tokenizes their own persona. As the Office Action notes, Blaikie teaches that "Different players may tokenize their persona... to make it available to marketers". Blaikie focuses on the player initiating the tokenization for monetization. Blaikie does not teach a workflow where a specific sports entity (distinct from the player) uses their own private key to authorize the minting of an NFT that is then sent to the player's wallet to serve as a verified scouting record. Nickerson…does not cure the deficiency in Blaikie regarding the specific authorization flow claimed. Nickerson teaches an owner sending a token to a user, but does not teach the generation of a new NFT based on new player data authorized by a verifying entity's private key as part of a smart contract relationship. Kumagai… does not suggest the specific application of a sports entity authorizing a sports history record via smart contract for delivery to a player's wallet to create an immutable scouting history.
The Combination Lacks Motivation for the Specific Claimed Workflow
The Examiner asserts that the combination is obvious to "access a token in a blockchain address" or "have an owner's wallet interact with an entity wallet". However, these are generic motivations that do not account for the specific claimed steps that provide the scouting utility.
The claimed method provides a specific solution to the problem of unreliable scouting records. By requiring the "entity private key" to authorize the generation of the NFT, the system ensures that the "player history" is not just a collection of self-minted tokens (as in Blaikie), but a verified record authorized by the entity (e.g., the scout). The cited art, even in combination, does not teach this specific validation-through-authorization workflow. Blaikie's self-tokenization combined with Nickerson/Kumagai's wallet mechanics results in a system where a user mints their own tokens and moves them between wallets, which fails to provide the external verification inherent in the claimed "entity... authorized" step. Therefore, the combination fails to teach or suggest the invention as claimed.
Examiner respectfully disagrees with these assertions, for example, Blaikie III teaches in ¶ 0059 that “…Smart contracts may be utilized with blockchain to ensure proper utilization and monetization of the data for verification purposes. The secured token generation process of the user data/profile provides proof of ownership to the user and ensures contract conditions are written into the smart contract code within the blockchain structure. The blockchain records maintain and track the creation, issuance, management, and monetization of each token throughout the lifetime of the user's involvement and ownership of their data. In one embodiment, a user may be rewarded with additional tokens for keeping their data/profile updated as well as keeping the data current through additional participation in surveys, watch a video, verify, a purchase, add studies, product marketing, expanded data provisioning, and questionnaires”, and also ¶ 0109 “ …. The agreement may specify that the data 154 may be processed, analyzed, purchased, licensed, rented, leased, or otherwise managed by the data platform 120 for the mutual benefit of the consumers 152 and the sellers…”, and also ¶ 0141 “…the platform vends the user data to a party utilizing the one or more tokens (step 708). The party may represent one of a number of parties that have purchased, leased, rented, licensed, or otherwise legally acquired access to the one or more tokens and associated data…”}. Emphasis added by the Examiner. Clearly this is not “the "player history" is not just a collection of self-minted tokens (as in Blaikie), but a verified record authorized by the entity (e.g., the scout)“ as asserted, by the Applicant and also not the case of “Blaikie teaches that "Different players may tokenize their persona... to make it available to marketers". Blaikie focuses on the player initiating the tokenization for monetization…”., Because Blaikie teaches generating a new NFT as indicated in ¶ 0229 “…receiving a request to generate a token for a sports player (step 2000). In one embodiment, the sports player may represent a developing, recreational, amateur, semi-professional, college, professional, expert, or other sports athlete regardless of skill level ¶ 0139 “…the platform creates one or more tokens based on the user data [e.g., players data] (step 704). Nickerson teaches in {¶ 0064 “…The person that owns the private key corresponding to the blockchain address may access the token(s) at the address. Thus, the blockchain address may represent an identity of the person that owns the token(s). Only the owner of the blockchain address may send the token to another person. The tokens may be accessible to the owner via the owner's wallet” And also the token is non fungible in ¶ 0066. Kumagai is relied upon to teach discloses creating an entity private key/wallet address pair associated with a […] entity [e.g. consumer] to interact with the system, wherein the entity private key/wallet pair is associated with the blockchain {see at least ¶ 0125-0126, as disclosed below
Therefore, the combination of Blaikie III in view of Nickerson, and in view of
Kumagai discloses all the subject matter as claimed. The 103 rejection is hereby maintained.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 3
U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-3 are rejected under 35 U.S.C. 103 as being unpatentable over Blaikie, III et al., (US 20220044334 A1) in view of Nickerson (US 20230359709 A1) and further
in view of Emi Kumagai (WO 2024232081 A1) a WIPO machine translation.
With respect to claims 1-3, Blaikie teaches a computer-implemented method in a player verification system, on a data communication network, for providing immutable sports player history transactions within a non-fungible cryptographic token (NFT) based sports player history,
a non-transitory computer-readable medium in a player verification system, on a data verification data communication network, storing code that when executed, performs a method for providing immutable sports player history transactions within a non- fungible cryptographic token (NFT) based sports player history, and
a player verification system, on a data communication network, for providing immutable sports player history transactions within a non-fungible cryptographic token (NFT) based sports player history , the method comprising {see at least Fig. 20, ¶ 0229 “…The process may begin by receiving a request to generate a token for a sports player (step 2000). In one embodiment, the sports player may represent a developing, recreational, amateur, semi-professional, college, professional, expert, or other sports athlete regardless of skill level. The player(s) [e.g., specific player or specific sports entity] may also represent non-sport related individuals, such as chess players, influencers, scientists, intellectuals, politicians, specialists (e.g., doctors, lawyers, crane operators, engineers, etc.), or any number of individuals, organizations, or entities…”}:
creating a smart contract for player data {Fig. 5 step 500-504, “create a smart contract controlling utilization of the data”} associated with a relationship between a specific player and a specific sports entity in a player history database {see at least ¶ 0059 “…Smart contracts may be utilized with blockchain to ensure proper utilization and
monetization of the data for verification purposes . The secured token generation process of the user data/profile provides proof of ownership to the user and ensures contract conditions are written into the smart contract code within the blockchain structure. The blockchain records maintain and track the creation, issuance, management, and monetization of each token throughout the lifetime of the user's involvement and ownership of their data. In one embodiment, a user may be rewarded with additional tokens for keeping their data/profile updated as well as keeping the data current through additional participation in surveys, watch a video, verify, a purchase, add studies, product marketing, expanded data provisioning, and questionnaires”, and also ¶ 0109 “ …. The agreement may specify that the data 154 may be processed, analyzed, purchased, licensed, rented, leased, or otherwise managed by the data platform 120 for the mutual benefit of the consumers 152 and the sellers…”, and also ¶ 0141 “…the platform vends the user data to a party utilizing the one or more tokens (step 708). The party may represent one of a number of parties that have purchased, leased, rented, licensed, or otherwise legally acquired access to the one or more tokens and associated data…”}.
receiving new player data for a player from two or more sources {¶ 0117 “…The data profile may also include user preferences, settings, parameters, and other applicable information that control what, when, and how data may be collected, shared, and monetized. The user profile may be generated or determined from already avail
able information for the user. For example, the user profile may represent one or more profiles compiled by devices, accounts, services, or so forth. The user may provide
answers utilizing one or more surveys, fields, questions, or other applicable information and data to determine applicable information and data”, and ¶ 0229 “…The process may begin by receiving a request to generate a token for a sports player (step 2000). In one embodiment, the sports player may represent a developing, recreational, amateur, semi-professional, college, professional, expert, or other sports athlete regardless
of skill level…In other embodiments, the token may also represent a moment (e.g., score, play, response, historical moment, sentimental moment, etc.), event, image, likeness, achievement, video, meme, file, physical items, or other content associated with the player. Teams may also tokenize their logo, stadium, roster, pictures, or other content for recreational, entertainment, amateur, college, semi-professional, professional, or other teams”}.
generating a new NFT in a series on the specific blockchain according to new player data {¶ 0229 “…The process may begin by receiving a request to generate a token for a sports player (step 2000). In one embodiment, the sports player may represent a developing, recreational, amateur, semi-professional, college, professional, expert, or other sports athlete regardless of skill level ¶ 0139 “…the platform creates one or more tokens based on the user data [e.g., players data] (step 704). In one embodiment, the token includes an indicator, such as a secure link, instructions, algorithm, key, secure identifier, or pointer that points to the user data. The indicator may also grant access to the holder/recipient to access the user data securely as an authorized party. In another embodiment, the token itself may include the user data…”, and also ¶¶ 0171 0172}, using the smart contract and authorized by the entity […] of the specific sports player or authorized by the entity private key/wallet key pair of the specific sports entity to activate the sports history {¶ 0124, Fig. 5 step 500-504, “create a smart contract controlling utilization of the data”} ., and also ¶ 0230 “…the platform generates one or more tokens associated with the sports player (step 2002). In one embodiment, the one or more tokens may represent the applicable content in any of the aforementioned formats. For example, the token may be associated with a player profile. The token may include the applicable content. For example, the content may be embedded, included, or integrated in the token [i.e., generating a new NFTs]. In another example, the token may include a reference or link to the content. The token may also include a smart contract. The smart contract may be utilized for sponsoring the player, licensing the content, paying royalties, purchasing the token (and/or associated content), and otherwise performing transactions for the content. In one embodiment, the token may be associated with physical or third-party ownership (e.g., items held in escrow, museums, etc.) or game or practice used items, such as signed balls, uniforms, shoes/footwear, skates, bases, rims, nets, tees, pads, pucks, helmets, hats, car parts, and so forth. The one or more tokens may represent nonfungible tokens or fungible tokens. For example, amateur, college, and professional sports players or personalities (e.g., referees, announcers, ball girls/boys, umpires, etc.) may create profiles. Different players may tokenize their persona to make it available to marketers, advertisers, companies, or others. For example, different offers, spokesperson roles, sponsorships, licenses, royalties, deals, or transactions may be performed virtually, electronically, and/or in person”, and {¶¶ 0064-0067}.
Blaikie III, does not explicitly disclose, however, Nickerson discloses creating a player private key/wallet address pair associated with a specific player to interact with the system, wherein the player private key/wallet address pair is associated with a blockchain {¶ 0064 “…The person that owns the private key corresponding to the blockchain address may access the token(s) at the address. Thus, the blockchain address may represent an identity of the person that owns the token(s). Only the owner of the blockchain address may send the token to another person. The tokens may be accessible to the owner via the owner's wallet. The owner of a token may send or transfer the token to a user via a blockchain transaction. For example, the owner may sign the transaction corresponding to the transfer of the token with the private key. When the token is received by the user, the token may be recorded in the blockchain at the blockchain address of the user”, and also ¶ 0066 Fig. 7 “…at block 708, the entity (e.g., the user) that possess the private key corresponding to the blockchain address may access the non-fungible token at the blockchain address and the data model associated with the non-fungible token”}.
sending the new NFT to the player private key/wallet pair address {see at least ¶0064 “…The owner of a token may send or transfer the token to a user via a blockchain transaction. For example, the owner may sign the transaction corresponding to the transfer of the token with the private key. When the token is received by the user, the token may be recorded in the blockchain at the blockchain address of the user”, and also ¶¶ 0065-0066 Fig. 7 “…at block 708, the entity (e.g., the user) that possess the private key corresponding to the blockchain address may access the non-fungible token at the blockchain address and the data model associated with the non-fungible token”}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Blaikie III, to include the elements of Nickerson. One would have been motivated to do so, in order to access a token in a blockchain address associated with the user’s private key. Furthermore, Blaikie III discloses a platform for personal data tokenization. Nickerson is merely relied upon to illustrate the functionality of having access to a token in a blockchain address associated with the user’s private key in the same or similar context. Because both having a platform for personal data tokenization, as well as having access to a token in a blockchain address associated with the user’s private key are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Blaikie III, as well as Nickerson would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Blaikie III/Nickerson.
Although, Blaikie, III et al., discloses all the subject matter of a player providing immutable sports player history transactions within a non-fungible cryptographic token (NFT) based sports player history, the combination of Blaikie III in view of Nickerson does not explicitly disclose the use of the user wallet and entity wallet in a transaction, however, Kumagai discloses creating an entity private key/wallet address pair associated with a […] entity [e.g. consumer] to interact with the system, wherein the entity private key/wallet pair is associated with the blockchain {see at least ¶ 0125 “…The blockchain wallet address may be allocated on the operator side of the system. The private key and the public key associated with the blockchain wallet address may be distributed to a user such as a manufacturer author, a logistics company, or a consumer who have a blockchain wallet address, for example, and may be recorded in a configuration used in the appraisal certification system 1 such as the dedicated platform 8 described above, and may be included in, for example, a small recording medium (for example, a two-dimensional code) or a part of NFT information, and can be arbitrarily set according to the application. In addition, each entity of the manufacturer, the manufacturer, the author, the logistics company, and the consumer may independently acquire the blockchain wallet address”, and also ¶ 0126 “…The digital item data is any digital content that requires appraisal certification such as a digital image, a digital audio, a digital music, and a digital video, and, for example, jpg, png, gif, mp3, mov, [e.g. player data] and the like are assigned as the respective extensions…”}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Blaikie III in view of Nickerson, to include the elements of Kumagai. One would have been motivated to do so, in order to have an owner’s wallet interact with an entity wallet in a blockchain transaction. Furthermore, Blaikie III discloses a platform for personal data tokenization, and Nickerson discloses having access to a token in a blockchain address associated with the user’s private key. Kumagai is merely relied upon to illustrate the functionality of having an owner’s wallet interact with an entity wallet in a blockchain transaction in the same or similar context. Because both having a platform for personal data tokenization, and having access to a token in a blockchain address associated with the user’s private key as well as have an owner’s wallet interact with an entity wallet in a blockchain transaction are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Blaikie III in view of Nickerson, as well as Kumagai would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Blaikie III/Nickerson/Kumagai.
With the respect to claim 4, the combination of Blaikie III in view of Nickerson, and in view of Kumagai discloses all the subject matter as disclosed in claim 1, above.
Furthermore, Blaikie III disclose wherein at least one source of the one or more sources of new player data is an artificial intelligence agent {¶ 0191 “…The platform may utilize various parameters, criteria, artificial intelligence, machine learning , or so forth…”}.
With the respect to claim 5, the combination of Blaikie III in view of Nickerson, and in view of Kumagai discloses all the subject matter as disclosed in claim 1, above.
Furthermore, Blaikie III disclose wherein the new player data comprises athlete’s prior events, event highlights, and athlete trainings {¶ 0205 “…The plat form may enable players to monetize their skills, efforts, games, highlights, or so forth. The platform may also enable various individuals or groups to sponsor a player through the purchase or license of tokens. The gaming data is monetized based on the preferences of the player. The player may have individual preferences, requirements (e.g., legal, moral, etc.), parameters, rules, or settings that govern how their gaming data may be monetized…”}.
Conclusion
THIS ACTION IS MADE FINAL. 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.
The prior art made of record and not relied upon:
1) (US 20170330174 A1) – Demarinis et al, Application Framework using Blockchain-Based Asset Ownership - relates to distributed ledger technology (such as blockchain technology), proof of work systems, cryptosystems, and electronic transaction systems.
2) (US 20180183587 A1) – Won et al., Blockchain-Assisted Public Key Infrastructure for Internet of Things Applications – relates to registering and authenticating Internet of things (IoT) devices.
3) (US 20190130698 A1) – Jordan Simons., Distributed Multi-Ledger Gambling Architecture – relates to generally to gaming systems. More specifically, some embodiments of the technology relate to systems and methods for a distributed multi-ledger gambling architecture.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT IDIAKE whose telephone number is (571)272-1284. The examiner can normally be reached on Mon-Fri from 10:30AM to 7:30PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK MCATEE, can be reached at telephone number (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 an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form
/V.I./Examiner, Art Unit 3698 /PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights