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
The following detailed action acknowledges the amendments of the response filed on 10/23/2025. The amendments in the filed response have been entered.
Claims 1 and 10 have been amended.
Claims 19-20 are confirmed to have been canceled.
Claims 21 and 22 have been added.
Claims 1-18 and 21-22 are pending in the application and the status of the application is currently pending.
Response to Arguments
Applicant’s Remarks, filed 10/23/2025, with respect to the rejections under 35 USC 101, 35 USC 112 and 35 USC 103 have been fully considered.
Regarding the rejection under 35 USC 101, the Applicant argues: Claims 1-18 were rejected under 35 U.S.C. § 101 as allegedly being directed to an abstract idea without significantly more. The Office Action alleges that under the broadest reasonable interpretation, the previously-pending claims recite processes that cover commercial and legal interactions that describe certain methods of organizing human activity.
Applicant respectfully disagrees and traverses this characterization and the present rejection. However, in order to expedite prosecution of the present application, Applicant has amended the claims as set forth above. For example, independent claim 1 has been amended to include additional features specifying the use of particular technical elements of a telecommunications network. Support for the amendments can be found in at least paragraphs [0015], [0036], [0043], and [0044] of Applicant's as-filed disclosure.
In Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 133 S. Ct. 2347 (2014) and Mayo Collaborative Servs. v. Prometheus Labs., Inc., 566 U.S. 66 (2012), the Supreme Court established a two-part test (hereinafter "Alice/Mayo test") for determining eligibility with respect to judicially excepted subject matter. In 2019, the USPTO published the 2019 Revised Patent Subject Matter Eligibility Guidance to provide additional clarity on how the Alice/Mayo test should be applied.
Step 2A of the Alice/Mayo test is a two-prong test. The first prong ("step 2A(1)") involves a determination of whether the claims are directed to a judicial exception (e.g., an abstract idea). The example groupings of abstract ideas provided in the MPEP include "mathematical concepts," "mental processes," and "certain methods of organizing human activity" (limited to the subgroupings of "fundamental economic principles or practices," "commercial or legal interactions," or "managing personal behavior or relationships or interactions between people"). MPEP 2106.04(a)(2)(1)-(III). The claims are eligible under 35 U.S.C. §101 if they are not directed to a judicial exception.
If the claims are found to be directed to a judicial exception, then the second prong ("step 2A(2)") involves a determination of whether the recited judicial exception is integrated into a practical application of that exception. More specifically, a determination is made on whether the claim as a whole "utilizes the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception." MPEP 2106.04(d). Several examples are provided in which courts have found a judicial exception to be sufficiently integrated into a practical application, including instances where there has been "an improvement to the functioning of a computer, or an improvement to other technology or technical field." MPEP 2106.04(d) and 2106.04(d)(1). If the recited exception is integrated into a practical application, then the claims are not directed to an abstract idea and are eligible under 35 U.S.C. §101.
However, even if the recited exception is not integrated into a practical application, the claims can be eligible under Step 2B of the Alice/Mayo test. Step 2B is applied by making a determination on whether the elements of claim, when considered both individually and as an ordered combination, amount to "significantly more" than the judicial exception and transform the nature of the claim into a patent-eligible application. MPEP 2106.05. Several examples are provided in which courts have found the limitations of the claims to qualify as "significantly more," including instances involving "improvements to the functioning of a computer," "improvements to any other technology or technical field," and "adding a specific limitation other than what is well-understood, routine, conventional activity in the field, or adding unconventional steps that confine the claim to a particular useful application". MPEP 2106.05. Claims that recite "significantly more" than the judicial exception itself are eligible under 35 U. S.C. § 101.
In response: The amendments to the claims do not add or improve on the functional elements that were determined to be an abstract idea.
The limitation obtain, by the node in the wireless telecommunications network and from the software operating on the mobile device, multiple authentication factors including a location associated with the mobile device… is describing a function of gathering data;
the limitation resolve, at the node in the wireless telecommunications network and based on the multiple authentication factors, an entity having an interest in the activity occurring at the location at the time is describing the function of identifying data;
the limitation retrieve, by the node in the wireless telecommunications network and from a Policy Control Function (PCF) of the wireless telecommunications network, the block chain describes the function of collecting information;
the limitation store, in response to the determination, the authorization in a Unified Data Repository (UDR) of the wireless telecommunications network describes the function of storing the authorization data;
the limitation receive, at the node in the wireless telecommunications network and from the software operating on the mobile device, a recording associated with the activity occurring at the location at the time… describes the function of gathering data;
the limitation create, at the node in the wireless telecommunications network, a block chain block including the multiple authentication factors describes the function of the blockchain to create a new block.
The limitations are part of a process that is part of the blockchain rather than an improvement, describing elements that are determined as a blockchain process, without any improvements. The amendments do not change the original interpretation that the claims recite an abstract idea, on of the Certain Methods of Organizing Human Activity. Thus, the amendments further support reciting an abstract idea.
The Applicant further argues: The Office Action asserts that the previously pending claims are directed to "commercial or legal interactions," which falls under the "Certain Methods of Organizing Human Activity" grouping of abstract ideas. Applicant respectfully submits that the claims do not recite one of the certain methods of organizing human activity or any other judicial exception at Step 2A, Prong One of the Alice test. A claim that merely involves a judicial exception, as distinct from a claim that recites a judicial exception, should be found eligible at Step 2A.
Applicant respectfully submits that the pending claims do not recite a certain method of organizing human activity or any other category of abstract idea, as described at MPEP 2106.04(a)(2). For example, unlike the examples of commercial interactions and business relations, Applicant's claimed technology relates to specific methods and related systems for leveraging a block chain to both authorize the creation of data and to record authorized data, including receiving a request at a node in a wireless telecommunications network, searching a block chain to determine whether a block includes an authorization, and creating a block chain block that includes a recording.
The amended claims recite technical operations performed by specific telecommunications network components. For example, amended claim I recites "obtain, by a node in the wireless telecommunications network and from the software operating on the mobile device, multiple authentication factors" and "retrieve, by the node in the wireless telecommunications network and from a Policy Control Function (PCF) of the wireless telecommunications network, the block chain." These limitations specify concrete technical operations performed by specific network infrastructure components, not abstract commercial interactions. Thus, the claims do not recite commercial or legal interactions between people, but rather describe specific technical solutions for authorizing and recording information using a telecommunications network.
Accordingly, Applicant respectfully submits that the amended claims are patent-eligible at least because they are not directed to any one of the certain methods of organizing human activity, as described in MPEP 2106.04, or any other judicial exception. Applicant therefore submits that the claims should be found patent-eligible at Step 2A, Prong One of the Alice test.
In response: regarding Step 2A(prong 1), the creation of a NFT (non-fungible token) is recited in a broad manner where the details of creating the NFT are not recited. The amendments do not show an improvement to the process of creating and storing the NFT. The process of the claims 1 and 10 describe authentication and authorization of the activity that would use the NFT, steps that are performed within a specific technical field but not changing the process of authentication and authorization considered to be used with the block chain functions. The amendments do not improve this process. And the process as recited does not show any differences to the determined abstract idea.
The Applicant further argues: Applicant respectfully submits that the claims are eligible at least at Step 2A, Prong Two because they integrate any alleged judicial exception into a practical application. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception.
Assuming for the sake of argument that Applicant's pending claims recite a judicial exception, the claims nonetheless integrate any alleged judicial exception into a practical application. The amended claims recite specific improvements to the creation of authorized NFTs through integration with telecommunications network infrastructure. As described in the specification, "NFT ledgers claim to provide a public certificate of authenticity or proof of ownership, but the legal rights conveyed by an NFT can be uncertain. NFTs do not restrict the sharing or copying of the underlying digital files, do not necessarily convey the copyright of the digital files, and do not prevent the creation of NFTs with identical associated files."2 The claimed invention supplies a solution to the uncertainty of the legal rights of NFT ownership. As described in the specification, "The system 300 can enable the user to create the NFT 320 with the agreement of the entity 330 organizing the event [ ... ] Based on the activity to be recorded, the network 100 can determine whether another entity 330 has an interest in the recording 390, such as a copyright. [ ... ] If the other entity 330 has agreed to the creation of the recording 390, the network 100 can grant the authority to the UE 310 to create the NFT 320."3 This demonstrates that the claimed invention is a practical application of any alleged judicial exception and is furthermore a technical solution to a known problem.
Amended claim 1 specifically recites "retrieve, by the node in the wireless telecommunications network and from a Policy Control Function (PCF) of the wireless telecommunications network, the block chain," "store, in response to the determination, the authorization in a Unified Data Repository (UDR) of the wireless telecommunications network," and "transmit the authorization from the UDR to the PCF ." These limitations demonstrate that the claimed system leverages the technical architecture of a 5G telecommunications network to verify authorization before NFT creation, utilizing specific network functions to implement blockchain operations. By integrating these telecommunications network components with blockchain technology, the claimed system can verify that proper authorization exists before creating an NFT, addressing technical problems related to unauthorized NFT creation. Therefore, Applicant's amended claims should be found eligible at least because they include one or more "other meaningful limitations" that integrate any alleged judicial exception into a practical application.
In response: regarding Step 2A(prong 2), the amendments do not impose a meaningful limit to the abstract idea. By including the functions of a blockchain, the claims attempt to recite the abstract idea in a technical field, but the claims do not show the improvement to the technology nor a solution to a known problem, two of the many methods where the abstract idea is not implemented into a practical application. The claims are interpreted to describe a simple device or system executing the abstract idea. The amendments in combination with the claim language still do not implement the abstract idea into a practical application.
The Applicant further argues: Even if the claims do not integrate any alleged judicial exception into a practical application, they are nonetheless eligible at Step 2B because they provide significantly more than any judicial exception, including features that are not well-understood, routine, or conventional, The amended claims recite specific technical operations that are not routine or conventional, including "resolve, at the node in the wireless telecommunications network and based on the multiple authentication factors, an entity having an interest in the activity," "retrieve, by the node in the wireless telecommunications network and from a Policy Control Function (PCF) of the wireless telecommunications network, the block chain," and "store, in response to the determination, the authorization in a Unified Data Repository (UDR) of the wireless telecommunications network," as recited by amended claim 1. These limitations demonstrate unconventional use of 5G network components to perform blockchain operations, which is not a merely routine or conventional use of generic computer technology. Accordingly, Applicant's amended claims should be found eligible at Step 2B at least this because they include features that are not routine, conventional, or well-understood.
For at least the foregoing three reasons, Applicant's claims recite eligible subject matter under Section 101 and the Alice/Mayo test. Amended claim 1 should be found eligible at least because it includes specific features discussed above. Amended claim 10 should be found eligible at least because it includes features similar to the specific features discussed above. Claims depending from amended claims 1 and 10 should be found eligible for the same reasons and for additional features they contain. Accordingly, Applicant respectfully requests withdrawal of the Section 101 rejections.
In response: regarding Step 2B, there was no indication in the rejection that the technical elements or additional elements are “well-understood, routine and conventional”, regardless of the evidence in the form PTO-892 prior art recited. However, the amendments to the claims as recited do not show an improvement to the process of authentication and authorization, which also does not show an improvement the technology. The functions of resolve, retrieve and store are not improvements to the process, where the use of a generic computer can perform these functions and are not an improvement to the technology. Thus, these additional elements do not provide significantly more than the abstract idea.
The new claims 21 and 22 recite descriptive elements that are non-functional and do not recite elements that improve on the abstract idea to be implemented into a practical application. In review of the amendments, and in view of the arguments, the claims 1-18 remain rejected and new claims 21-22 are rejected under 35 USC 101.
Regarding the rejection under 35 USC 103, the Applicant argues: Claims 1-2, 4-7, 10-11 and 13-16 were rejected under 35 U.S.C. § 103 as being unpatentable over Avetisov, in view of Panchencko, in view of Patel.
To expedite prosecution, and without commenting on the merits of the rejection, claims 1 and 10 have been amended to further distinguish the claimed subject matter from Avetisov, Panchencko, and Patel. For example, and as recited in amended claim 1, Avetisov, Panchencko, and Patel, whether considered individually or in combination, fail to teach or suggest:
resolve, at the node in the wireless telecommunications network and based on the multiple authentication factors, determine an entity having an interest in the activity occurring at the location at the time, wherein the entity is distinct from the user;
retrieve, by the node in the wireless telecommunications network and from a Policy Control Function (PCF) of the wireless telecommunications network, the block chain;
determine whether the block chain includes an authorization to record the activity occurring at the location at the time,
wherein the entity grants the authorization,
wherein the authorization is associated with the mobile device;
store, in response to the determination, the authorization in a Unified Data Repository (UDR) of the wireless telecommunications network;
Similarly, and as recited in amended claim 10, Avetisov, Panchencko, and Patel, whether considered individually or in combination, fail to teach or suggest:
search, by the node in the wireless telecommunications network, a block chain to determine whether the block chain includes an authorization to record the activity occurring at the location at the time,
wherein the block chain is stored at a Policy Control Function (PCF) of the wireless telecommunications network,
wherein the entity grants the authorization,
wherein the authorization is associated with the UE;
store, in response to the determination, the authorization in a subscriber data storage element of the wireless telecommunications network;
As a result, the Section 103 rejection of these claims should be withdrawn for at least the foregoing reasons and for the additional features of these claims.
Claims 3 and 12 were rejected under 35 U.S.C. § 103 as being unpatentable over Avetisov, in view of Panchencko, in view of Patel, and further in view of U.S. Patent Publication No. 2019/0392511 to Mahajan et al. (hereinafter "Mahajan"). However, Mahajan does not cure the deficiencies of Avetisov, Panchenko, and Patel, as applied to independent claims 1 and 10. Therefore, Avetisov, Panchenko, Patel, and Mahajan, whether considered individually or in combination, fail to disclose all features of claims 3 and 12. Accordingly, the Section 103 rejection of these claims should be withdrawn.
Claims 8 and 17 were rejected under 35 U.S.C. § 103 as being unpatentable over Avetisov, in view of Panchenko, in view of Patel, and in further view of Marquardt. However, Marquardt does not cure the deficiencies of Avetisov, Panchenko, and Patel, as applied to independent claims 1 and 10. Therefore, Avetisov, Panchenko, Patel, and Marquardt, whether considered individually or in combination, fail to disclose all features of claims 8 and 17. Accordingly, the Section 103 rejection of these claims should be withdrawn.
Claims 9 and 18 were rejected under 35 U.S.C. § 103 as being unpatentable over Avetisov in view of Panchenko, in view of Patel, and in further view of Kong. However, Kong does not cure the deficiencies of Avetisov, Panchenko, and Patel, as applied to independent claims 1 and 10. Therefore, Avetisov, Panchenko, Patel, and Kong, whether considered individually or in combination, fail to disclose all features of claims 9 and 18. Accordingly, the Section 103 rejection of these claims should be withdrawn.
Applicant has not necessarily discussed here every reason why every pending independent claim is patentable over the cited art; nonetheless, Applicant is not waiving any argument regarding any such reason or reasons. Applicant reserves the right to raise any such additional argument(s) during the future prosecution of this application, if Applicant deems it necessary or appropriate to do so.
In response: the amendments merely describe elements that do not improve or change the process that was rejected over the prior art. Thus, the rejection remains for the claims 1-18 as obvious over the prior art.
The limitations at the node in the wireless telecommunications network, retrieve, by the node in the wireless telecommunications network and from a Policy Control Function (PCF) of the wireless telecommunications network and the authorization in a Unified Data Repository (UDR) of the wireless telecommunications network are descriptive but do not show an improvement to the process that has been taught by the prior art. The amendments are recited as descriptive and non-functional.
The art of Avetisov could be combined with other art to teach this concept of determining the entity associated to the NFT. For the new claims 21-22, a rejection is presented in the rejection below.
In view of the amendments, claims 1-18 remain rejected as obvious over the prior art, and new claims 21-22 are also rejected as obvious over the prior art, thus rejected under 35 USC 103.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 and 21-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
The analysis of the claims is based on the subject matter eligibility test that is detailed in the 2024 Patent Subject Matter Eligibility (SME) Guidance Update Including Artificial Intelligence (2024 AI SME Update)(July 2024), the 2019 Revision to the SME Guidance (2019 PEG)(January 2019) and the October 2019 SME Guidance Update (October 2019). The current guidance is referenced in the Manual of Patent Examining Procedure (MPEP) sections 2103 through 2106.07.
In Step 1 of the test, the claims were found to be directed to one of the four statutory categories, which is a process. Claims 1-9 are directed to a computer-readable medium, excluding transitory signals, carrying instructions, which, when executed by at least one data processor of a system, perform the process; and claims 10-18 are directed to a system comprising at least one hardware processor and at least one non-transitory memory storing instructions, which, when executed by the at least one hardware processor, perform the process. Therefore, the result of Step 1 is the claims are directed to at least one statutory category.
In Step 2A(1), the claims were found to recite an abstract idea. The claims 1 and 10 include similar limitations that recite the process, using claim 10 for example as follows:
receive, at a node in the wireless telecommunications network, a request to create a non-fungible token (NFT) from a user equipment (UE) associated with a user,
wherein the request is generated by a software operating on the UE in a secure protected boot mode,
wherein the secure protected boot mode ensures integrity of the software using a cryptographic key;
obtain, by the node in the wireless telecommunications network and from the software operating on the UE multiple authentication factors including a location associated with the UE, an ID associated with the UE, and an ID associated with the user,
wherein the software operates in the secure protected boot mode;
resolve, at the node in the wireless telecommunications network and based on the multiple authentication factors, an entity having an interest in an activity occurring at the location at a time,
wherein the entity is distinct from the user;
retrieve, by the node in the wireless telecommunications network and from a Policy Control Function (PCF) of the wireless telecommunications network, the block chain;
determine whether the block chain includes an authorization to record the activity occurring at the location at the time,
wherein the entity grants the authorization,
wherein the authorization is associated with the UE;
store, in response to the determination, the authorization in a Unified Data Repository (UDR) of the wireless telecommunications network;
upon determining that the block chain includes the authorization to record the activity occurring at the location at the time, receive, at the node in the wireless telecommunications network and from the software operating on the UE a recording associated with the activity occurring at the location at the time;
transmit the authorization from the subscriber data storage element to the PCF; and
upon determining that the block chain includes the authorization to record the activity occurring at the location at the time, create a block chain block including the multiple authentication factors, the authorization to record the activity occurring at the location at the time, and the recording.
The emphasized limitations describe the elements that define an abstract idea. The limitation in the pre-amble of claim 1 recites At least one computer-readable storage medium, excluding transitory signals and carrying instructions to securely create a nonfungible token (NFT) on a block chain using a 5G infrastructure of a wireless telecommunication network, which is descriptive and does not show functions outside of a generic computer performing creating data and recording on a blockchain and managing a connection with a telecommunication network. The request for recording of created data from instructions of a user device are considered providing instructions and are considered “managing interactions” such as “following the rules”. The limitation receive… a request can be interpreted as a user requiring a record for a transaction from the user equipment (UE); limitation obtain… multiple authentication factors can be interpreted as a user providing entries from the UE; limitation based on… determine an entity having an interest can be interpreted as selecting a merchant or other entities that interact in a transaction, occurring at the time and place; limitation search… a blockchain to determine whether the blockchain includes can be interpreted as identifying the records data from the merchant; limitation store… the authorization is interpreted as part of the step to search, which describes identifying records; limitation upon determining… receive… a recording can be interpreted as the user completing the transaction with the merchant and sending a receipt of the transaction; limitation transmit the authorization is part of the receiving the recording, which describes determining the recipient of the data; limitation upon determining… create a block chain block is interpreted as creating the record and storing the record securely, where the creation and secure storage are part of the functions of the blockchain for a transaction. The elements in the limitations, as interpreted, can be described as commercial and legal interactions, where the commercial interactions could be defined as part of a transaction or sales activities or behaviors, and the legal obligations include the secure protected mode and secure data in a distributed ledger as part of legal obligations. The abstract idea is defined under the grouping of Certain Method of Organizing Human Activity.
The dependent claims 2-9, 11-18 and 21-22 further support the interpretation of the abstract idea. Therefore, the result of Step 2A(1) is the claims recite an abstract idea.
In Step 2A(2), the claims that recite the abstract idea do not integrate the abstract idea into a practical application. In example claim 10, the recited computer readable storage medium and data processor perform the functions of the claimed invention. In connection with the UE or the mobile device, the system is executed by a node in the wireless telecommunications network, including Policy Control Function (PCF) and a Unified Data Repository (UDR). Interpreting the UE is connected to a customer interacting with a merchant during a transaction, the authentication factors and the use of the blockchain are shown to be part of the transaction, and do not show an improvement to the generic computer. The additional elements further support the abstract idea as the creation of a NFT for a transaction, process to authenticate to perform the transaction and the process to store the transaction elements on blockchain are elements found in sales activities. As recited, there is no solution to a stated problem that is shown as a technical novelty or improvement, not an improvement on the technology.
The dependent claims 2-9, 11-18 and 21-22 attempt to generally link the use of the abstract idea to a particular technological environment or field of use. Therefore, the result of Step 2A(2) is the claims do not integrate the abstract idea into a practical application.
In Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the abstract idea. The claims recite at least one computer-readable storage medium, excluding transitory signals, carrying instructions to securely create a non-fungible token (NFT) on a blockchain using a 5G infrastructure of a wireless telecommunication network, executed by at least one data processor; and a system comprising: at least one hardware processor, and at least one non-transitory memory storing instructions, executed by the at least one hardware processor. The recited technology is interpreted to be similar to a generic computer system, which interacts with a user equipment/mobile device, a block chain of recorded activity and authentication, and an entity that is described to be interested in the activity and authorizing the activity. While the additional elements limit the abstract idea to a specific field of technology, there is no improvement to the functions of the recited technology, nor is there an improvement to another technology or technical field. Thus, the additional elements merely recite instructions to execute the abstract idea. Considering the additional elements individually, the claims do not include elements that are sufficient to amount to significantly more than the abstract idea. Considering the additional elements in combination, the steps do not add any meaningful limits on practicing the abstract idea more than the elements analyzed individually and thus do not add significantly more to the claimed invention. Therefore, the result of Step 2B is the claims do not add significantly more to the abstract idea. Concluding the claims 1-18 and 21-22 are patent ineligible.
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:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, 4-7, 10-11, 13-16 and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0044976 (“Avetisov”), in view of US_2024/0311819 (“Panchencko”), in view of US 2023/0066272 (“Patel”), in view of US_2024/0313969 (“Kunz”).
Regarding Claims 1 and 10, Avetisov teaches
receive a request to create an [token] from a user equipment (UE) associated with a user, (“In some example embodiments that include configurations where a device requesting authentication, like a mobile computing device engages the authentication server, that device may receive the results from the authentication server, which may be signed by the authentication server.” … “In some embodiments, such as those including payment terminals, the results may be structured in a standardized format accepted by those terminals on a given payment service. For example, a user may be authenticated to an account and a result, like a token, corresponding to that account may be provided to the mobile device.” See Avetisov in [0050])
wherein the request is generated by a software operating on the UE in a secure protected boot mode, wherein the secure protected boot mode ensures integrity of the software using a cryptographic key; (“requesting, by the application, from the trusted execution environment (TEE), a first key of a key-pair corresponding to a second key of the key-pair maintained in the secure memory and, for at least one credential in the set of credentials, a representation generated within the trusted execution environment, wherein the representation is indicative of a value of the corresponding credential, and the representation does not reveal the value.” See Avesitov in at least [0007])
obtain, by a node in the wireless telecommunications network and from the software operating on the UE multiple authentication factors including a location associated with the UE, an ID associated with the UE, and an ID associated with the user, wherein the software operates in the secure protected boot mode; (“establishing, by the application, a set of credentials within a secure memory by a co-processor of a trusted execution environment of the first computing device, the co-processor being a different processor from a central processing unit of the first computing device” See Avesitov in [0007]; “In some embodiments, the authentication process includes one or more authentication steps in addition to verifying the credentials received from the client computing device. Moreover, in some embodiments, the credentials received from the client computing device need only identify a particular user, identity, account, or other entity. As such, an authentication process may not require any verifying of user credentials received from a specific client computing device. Rather, another client device like a mobile computing device may be prompted to provide credentials (e.g., a zero-knowledge proof). In either instance, based on the received credentials, a server may identify account or user identity information of a user associated with those credentials. In some embodiments, the received credentials include an identifier operable to identify associated user account information or records.” See Avesitov in [0052])
search, by a node in the wireless telecommunications network, a block chain to determine whether the block chain includes an authorization to record the activity occurring at the location at the time, wherein the entity grants the authorization, wherein the authorization is associated with the UE; (“The authentication server 155 may store data for authentication operations in an authorization repository 165. The authorization repository 165 may include a vast number of UID Records 151. A UID Record 151 may include information associated with a particular user and the devices associated with that user. In some embodiments, a UID Record 151 for a particular user may be created for a particular relying party or used across multiple relying parties. For example, a given user may have a different UID Record 151 associated with the different relying parties utilizing the authentication system and which the user engages. One relying party may be an employer of the user, another relying party may be a financial institution used by the user, and yet another relying party may be an application developer from which the user has purchased an application for personal use. The different UID Records for a same user may have some same information, such as if the user uses the same mobile device 101 for authentication with each party, device information for the mobile device 101 may remain the same across the different UID Records. However, the different UID Records for different relying parties may be segmented within the repository 165 for a variety of different reasons, such as compliance with relying party requirements, government regulations, or user privacy in general.” See Avetisov in [0125])
store […] the authorization in a Unified Data Repository (UDR) of the wireless telecommunications network; (“In accordance with some example embodiments implemented with a decentralized computing architecture, such as on a blockchain-based computing platform, user identities, authenticating entity identities, and authentication policies thereof, may be committed to a blockchain ledger, in some cases along with time stamped authentication decisions by such entities for such users (e.g., for a given computing device of a user). As a result, authentication decisions may be based on data stored on a blockchain. However, it should be emphasized that embodiments are not limited to implementations on blockchain-based computing platforms and some embodiments may execute on monolithic, distributed, or non-blockchain-based decentralized physical architectures, none of which is to suggest that any other described feature serves to limit claim scope. Those authentication decisions may take into account one or more of the different informational items pertaining to user identifies stored on the blockchain.” See Avetisov in [0061])
upon determining that the block chain includes the authorization to record the activity occurring at the location at the time, receive, at the node in the wireless telecommunications network and from the software operating on the UE a recording associated with the activity occurring at the location at the time; (“The token may include an associated timestamp or time-stamps that indicate when the token was created or when it expires. In either instance, the server 145 may determine from a time stamp whether a token associated with a given identifier is inactive or active. In accordance with the above example, the server 145 may receive, from the client device 135 during an access attempt, a token in addition to information previously described. The server 145 may determine, from information stored within the UID repository 160 in response to receiving a token from the client device 135, whether the received token matches a valid token received from the authentication server 155. The server 145 may also determine, from an association between the valid token and an identifier within the UID repository 160, whether information received from or determined about the client device corresponds to the identifier stored within the UID repository 160.” See Avetisov in [0120]) and
upon determining that the block chain includes the authorization to record the activity occurring at the location at the time, create, at the node in the wireless telecommunications network, a block chain block including the multiple authentication factors, the authorization to record the activity occurring at the location at the time, and the recording. (“In some embodiments, transaction records may be stored as node content of leaf nodes of a binary tree data structure that is collectively appended to the directed acyclic graph of cryptographic hash pointers upon completion of the tree data structure (e.g., achieving a threshold number of nodes, such 2nth power of nodes to include in the tree data structure). Or in some cases, intermediate nodes of the tree data structure may include nodes having content in which published information is stored.” See Avetisov in [0218])
Avetisov substantially teaches a node in the wireless telecommunications network, where communications from a mobile device would connect to the wireless telecommunications network (See Avetisov in [0050]), and a node in the telecommunications network is interpreted as the server in connection with the mobile device (See Avetisov in [0050]).
Avetisov does not expressly teach receiving, […], a request for an NFT and creating a new node recording the activity on the blockchain.
However, Panchencko does teach requesting an NFT prior to an activity and creating a new block for the activity (“For example, in one embodiment, the bridges module 301 at logic 420 requests deposit via deposit interface 404. The deposit interface 404 at logic 422 determines if the module (to which the NFT is being deposited) supports custodial wallet locking. In such a case, at block 408 the NFT is transferred to a custodial wallet from the customer's wallet or minted for the first time. The deposit interface 404 at logic 424 determines if the module supports the locking state in internal storage. In such a case, at block 410, the NFT state is updated to the unlocked state in the storage or a new item record is created. The deposit interface 404 at logic 425 determines if the module supports other locking mechanisms, and responsive thereto at block 412 the other locking mechanisms are used to lock or create the NFT. The foregoing is replicated for numerous different possible modules, such that the bridges module 301 is able to invoke the correct logic for each type of module. Next, logic 428 gets the data of the NFT state and passes the data to monitoring interface 405, which at logic 426 provides information about the NFT being unlocked to the bridges module 301.” See Panchencko in at least [0059]).
Avetisov does teach retrieving data from the server (“Accordingly, the application 110 may be configured to retrieve data from the server 145 and present the data received from the server to the user. In some cases, the server 145 may redirect the application 110 to retrieve some or all data from one or more other servers, like server 155. The retrieved data, when executed or processed, may cause the application 110 to present on the display of the client device 135 a log-in page or other user interface including one or more fields or other user interface elements configured to receive user credential 111 input for accessing the online resource 147.” See Avetisov in [0110]), but Avetisov does not expressly teach retrieve, by the node in the wireless telecommunications network and from a Policy Control Function (PCF) of the wireless telecommunications network, the block chain.
However, Panchecnko does teach retrieve the block chain (interpreting retrieving as acquiring data from the blockchain: “Bridges module 206 uses the Withdrawal mechanism provided by the Sourcing module 208 to initiate withdrawal in the Sourcing module 208. Advantageously, various withdrawal mechanisms of different blockchain technologies are stored within the bridges module 206 to allow for interaction with different blockchain types, rather than being limited to a single blockchain technology.” See Panchenko in at least [0047]).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Avetisov to include “retrieving data from the blockchain”, as taught by Panchencko, to improve the process to secure the request and the authentication for the user’s account.
Avetisov, in view of Panchencko, substantially teaches resolve, at the node in the wireless telecommunications network and based on the multiple authentication factors, an entity having an interest in an activity occurring at the location at a time; (“In some embodiments, use of one or more of those credentials may be subject to policies implemented by an authorization server 155 providing authentication services or relying party 145 providing access to secured assets, such as online resources, subject to authentication by the authentication service. For example, the authentication server 155 or relying party 145 may accept or deny use of the different ones of the user credentials 109 or specify requirements for acceptance of different ones of the user credentials 109 for authentication for different secure assets.” See Avesitov in [0089])
Avetisov, in view of Panchencko, does not explicitly teach resolve an entity having an interest in the activity occurring at the location at the time, wherein the entity is distinct from the user.
However, Patel substantially teaches determine an entity (“For example, if a first user (e.g., user 102A) is about to transfer an electronic payment to a second user (e.g., user 102B) wherein the second user (e.g., user 102B) represents a merchant (e.g., a business, company, retailer, or a similar entity), trust signals may be generated and indicated to the first user (e.g., user 102A) via the payment applications 114A to enable the first user (e.g., a customer of the merchant) to confirm the identity of the merchant prior to initiating the payment transaction. This can help mitigate misdirected payments in transactions of customers with merchants, such as with electronic commerce (e-commerce) transactions where merchants offer items for sale via an electronic marketplace or via point-of-sale terminals at brick-and-mortar stores.” See Patel in [0058])
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Avetisov to include “confirm the identity of the merchant”, as taught by Patel, to improve the process to secure the request and the authentication for the user’s account.
Avetisov, in view of Panchencko, in view of Patel, does not explicitly teach Policy Control Function (PCF) and Unified Data Repository (UDR).
However, Kunz does teach
Policy Control Function (PCF) to retrieve data (“The PCF 146 is responsible for unified policy framework, providing policy rules to CP functions, access subscription information for policy decisions in UDR. The AUSF 147 acts as an authentication server.” See Kunz in [0056]) and
storing in a Unified Data Repository (UDR) (“The UDM is responsible for generation of Authentication and Key Agreement (“AKA”) credentials, user identification handling, access authorization, subscription management. The UDR is a repository of subscriber information and can be used to service a number of network functions. For example, the UDR may store subscription data, policy-related data, subscriber-related data that is permitted to be exposed to third party applications, and the like. In some embodiments, the UDM is co-located with the UDR, depicted as combined entity “UDM/UDR” 149.” See Kunz in [0057])
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Avetisov, in view of Panchencko, to include “Policy Control Function and Unified Data Repository”, as taught by Kunz, to secure the management of the blockchain, it prevents fraud storage of excess data in the secure block chain.
Regarding Claims 2 and 11, Avetisov, in view of Panchencko, in view of Patel, teaches the limitations of claims 1 and 10. Avetisov further teaches
upon determining that the block chain includes the authorization to record the activity occurring at the location at the time (See Avetisov in [0218]), retrieve from the block chain a first indication of interest associated with the entity in the recording and a second indication of interest associated with the user in the recording; (“Generally, embodiments of a trusted execution environment 103 may include any isolated execution environment, which may run in parallel with a client execution environment 113 (CEE). Compared to a user-facing client execution environment 113, which may execute the mobile device operating system and most user-facing mobile applications, the trusted execution environment 103 is more secure and may execute a subset of specific applications (e.g., applications, services, or software modules) on the mobile device, like trusted applications or modules for authentication operations, which may include user authentication, payments, digital rights management, and the like. Some of those authentication operations may be performed in an out-of-band authentication process, such as for granting user access to online resources and other assets, payments, digital rights management, and the like. Additionally, the trusted execution environment 103 may store within or cryptographically sign data associated with those applications or modules within the trusted execution environment, such as to protect the data from being tampered with, read, or modified by an unauthorized entity.” See Avetisov in [0072])
receive an indication of a transfer of funds associated with the recording from a third party to the user; and distribute the funds to the user and the entity based on the first indication of interest and the second indication of interest. (“If authenticated, the results may be published to the immutable data stored and honored by at least the party the user desired to authenticate. In some embodiments, the mobile device 101 may receive an indication of the result, like a token, identifier of the transaction, or other data which the mobile device 101 may present as proof of authentication. Some results may be signed in a way (e.g., by private key of an authoritative party like the authentication server or server of a relying party) such that they may be considered authoritative for a given function based on signature verification. Thus, for example, the mobile device may present the results to a terminal or electro-mechanical device for payment authorization or physical access.” See Avetisov in [0281])
Regarding Claims 4 and 13, Avetisov, in view of Panchencko, in view of Patel, teaches the limitations of claims 1 and 10. Avetisov, in view of Panchencko, further teaches
create a unique ID corresponding to the NFT; (“In some embodiments, the Net ID 271 includes a digital certificate, like a X.509 type certificate, which may be a User ID itself or include a User ID (e.g., an ID bound to a public key of a user), and can include a public key for a user for signature verification.” See Avetisov in [0237])
obtain multiple block chains; (perform for multiple blockchains, See Avetisov in [0125])
search the multiple block chains for a block associated with the NFT; (“Transfer metadata is stored in the DMarket blockchain 212 to unequivocally identify the location of the NFT. Requesting interface 202 is notified that the transfer is completed.” See Panchencko in [0053]) and
create a second block chain including an indication of the block associated with the NFT, (created with the “new blockchain block”, see Panchencko in [0059])
wherein a name associated with the second block chain indicates a location of a block chain among the multiple block chains containing the block associated with the NFT, wherein the second block chain includes permissions associated with the NFT and the multiple authentication factors. (Descriptive factors of the creation of the block chain, which are non-functional as they are not improving the use of NFT)
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Avetisov to include “identify the location of the NFT” and “create a new blockchain block”, as taught by Patel, to improve the process to secure the request and the authentication for the user’s account.
Regarding Claims 5 and 14, Avetisov, in view of Panchencko, in view of Patel, teaches the limitations of claims 1 and 10. Avetisov, in view of Panchencko, further teaches
receive a request to enter an operation associated with the NFT; (“For example, the result may be presented by the mobile computing device via a native application, which may be a trusted application within the trusted execution environment, like a wallet-type application configured to provide the result and corresponding identity to which the result pertains to other devices. Examples of those other devices may be door locks, payment terminals, and the like configured for near-field-communications over protocols like Bluetooth, Zigbee, WiFi, etc., and which may be coupled to a network or include a processor, by which such a result received from a mobile computing device may be verified prior to effecting an operation (e.g., unlocking a door, confirming a payment, etc.). In some embodiments, such as those including payment terminals, the results may be structured in a standardized format accepted by those terminals on a given payment service.” See Avetisov in [0050]; “Next, the blockchain bridges module 612 at logic 624 mints the requested NFT and it is stored on the DMarket or market blockchain 606, and is available to the customer to use in the game, transfer or withdraw, or use in marketplace operations.” See Panchenko in [0061])
check whether the request includes a unique ID associated with the NFT and a participant associated with the operation; (See Avetisov in [0052])
check whether the unique ID associated with the NFT is recorded in the block chain; (NFT details: “1. User request NFT transfer from Sourcing module 208 to Destination module 210 using Requesting Interface 202. Requesting interface 202 calls Integration Module 204 with data that contains NFT details, Source module details, and Destination module details. 2. Integration module 204 orchestrates request's data to the Bridges module 206 while enriching data with modules specifics like their type or the way how monitor response from each module.” See Panchecko in [0045]-[0046]; further see Avetisov in [0236])
upon determining that the unique ID associated with the NFT is recorded in the block chain, retrieve a second entity having an interest in the NFT; (See Avesitov in [0089])
determine whether a participant associated with the operation corresponds to the second entity; (See Avesitov in [0089]) and
upon determining that the participant associated with the operation corresponds to the second entity, create a second block in the block chain including the operation associated with the NFT. (See Avetisov in [0218])
Regarding Claims 6 and 15, Avetisov, in view of Panchencko, in view of Patel, teaches the limitations of claims 1 and 10. Avetisov further teaches
receive a request to authenticate the user by receiving a second ID associated with the user and a second ID associated with the UE of the user; (Duplication of parts, See Avetisov in [0007], [0050] and [0052])
retrieve the ID associated with the user and the ID associated with the UE of the user from the block chain; (See Avetisov in [0125])
determine whether a first match exists by determining whether the second ID associated with the user matches the ID associated with the user stored in the block chain; (“In some embodiments, the trusted execution environment may determine whether supplied credential values match previously obtained credential values stored within the trusted execution environment. For example, the trusted execution environment may determine whether supplied credentials values or a cryptographic hash value corresponding to supplied credential values match a valid credential stored within the trusted execution environment.” See Avetisov in [0057])
determine whether a second match exists by determining whether the second ID associated with the UE matches the ID associated with the UE stored in the block chain; (See Avetisov in [0057]) and
upon determining that the first match exists and the second match exists, authenticate the user. (“In turn, the server 145 may wait for an authentication result from the authentication server 155 and grant or deny the client device access based on the received result or time out the access attempt if not result is received within a threshold amount of time.” … “As the identifier can uniquely identify the client device 135 from other client devices, the relying party server 145 can determine to grant the client device 135 access if the token presented by the client device matches a valid token in the repository 160 and an identifier determined for the client device matches the identifier associated with the valid token in the repository 160.” See Avetisov in [0120])
Regarding Claims 7 and 16, Avetisov, in view of Panchencko, in view of Patel, teaches the limitations of claims 1 and 10. Avetisov further teaches create a consensus within the block chain using a process of minimum viable consensus method, without using proof of work, thereby reducing carbon footprint in creating the consensus. (It would have been an obvious matter of design choice to create a consensus within the blockchain, using proof of work, since applicant has not disclosed that the process of minimum viable consensus solves any stated problem or is for any particular purpose and it appears that the invention would perform equally well with “implementing a consensus algorithm among the computing nodes”, see Avetisov in at least [0206])
Regarding Claim 21, Avetisov, in view of Panchencko, in view of Patel, in view of Kunz, teaches the limitations of claim 10. Avetisov, in view of Kunz, teaches wherein the subscriber data storage element comprises a Unified Data Repository (UDR) or an Unstructured Data Storage Function (UDSF). (“The UDM is responsible for generation of Authentication and Key Agreement (“AKA”) credentials, user identification handling, access authorization, subscription management. The UDR is a repository of subscriber information and can be used to service a number of network functions. For example, the UDR may store subscription data, policy-related data, subscriber-related data that is permitted to be exposed to third party applications, and the like. In some embodiments, the UDM is co-located with the UDR, depicted as combined entity “UDM/UDR” 149.” See Kunz in [0057])
Regarding Claim 22, Avetisov, in view of Panchencko, in view of Patel, in view of Kunz, teaches the limitations of claim 10. Avetisov, in view of Kunz, teaches wherein the node in the wireless telecommunications network comprises the PCF. (“The PCF 146 is responsible for unified policy framework, providing policy rules to CP functions, access subscription information for policy decisions in UDR. The AUSF 147 acts as an authentication server.” See Kunz in [0056])
Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov, in view of Panchencko, in view of Patel, and further in view of US_2019/0392511 (“Mahajan”).
Regarding Claims 3 and 12, Avetisov, in view of Panchencko, in view of Patel, teaches the limitations of claims 1 and 10. Avetisov further teaches upon determining that the block chain includes the authorization to record the activity occurring at the location at the time, retrieve from the block chain a first indication of interest associated with the entity in the recording and a second indication of interest associated with the user in the recording; (See Avetisov in [0281])
Avetisov, in view of Panchencko, in view of Patel, does not expressly teach distribute information about an auction associated with the NFT to multiple UEs, wherein the information includes an ID associated with the NFT, a time, and a location; receive multiple bids for the NFT from multiple parties; determine a highest bid among the multiple bids, wherein the highest bid is associated with a first party among the multiple parties; transfer the interest in the NFT to the first party among the multiple parties; and distribute the highest bid to the entity and the user based on the first indication of interest and the second indication of interest.
However, Mahajan does teach
distribute information about an auction […] to multiple UEs, wherein the information includes an ID […], a time, and a location; (“Once the blockchain-based good/asset is listed for an auction sale, the web service 315 can publish the item (and its auction details) at a user interface so that potential buyers can view the item and bid on it.” See Mahajan in [0032])
receive multiple bids […] from multiple parties; (“One or more buyers 320 can bid on one or more blockchain-based goods/assets listed for an auction sale. In several embodiments, buyer 320 submits bids for a listed blockchain-based good/asset in the form of a decreasing price transaction or an increasing price transaction.” See Mahajan in [0032])
determine a highest bid among the multiple bids, wherein the highest bid is associated with a first party among the multiple parties; (“Bid matching service 325 can select a winning bid based on one or more parameters, such as highest bid amount, timestamp associated with the bid transaction, credit rating of buyer, past performance of buyer, buyer review(s), location of buyer, location of seller, shipping cost, and so on. For example, bid matching service 325 selects the highest and earliest bid as the winning bid.” See Mahajan in [0039])
distribute the highest bid to the entity and the user based on the first indication of interest and the second indication of interest. (“After selecting the winning bid, bid matching service 325 can execute the winning bid to automatically consummate the purchase of the listed blockchain-based good/asset. For example, bid matching service 325 publishes a signed transaction corresponding to the winning bid with the blockchain smart contract platform 310 when the bidding process concludes (for example, when a reserve price match is met or when the auction expires) (act 2(b)). The bid matching for blockchain-based goods/assets system can utilize various trading strategies to select a winning bid, such as, but not limited to, limit, market, stop market, stop limit, opportunistic, time-weighted average price (TWAP), float, instant, and so on.” See Mahajan in [0039])
The limitation transfer the interest of the NFT to the first party among the multiple parties is not clear where claim 1 recites the entity and the UE already have an interest. Since Avetisov teaches the creation and distribution of the NFT, Avetisov teaches the limitation.
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Avetisov to include “the activity as an auction”, as taught by Mahajan, to improve the process to secure the request and the authentication for the user’s account.
Claims 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov, in view of Panchencko, in view of Patel, and further in view of US_10,958,434 (“Marquardt”).
Regarding Claims 8 and 17, Avetisov, in view of Panchencko, in view of Patel, teaches the limitations of claims 1 and 10. Avetisov further teaches determine whether the user has a permission to read the […] block. (See Avetisov in [0089]) and upon determining that the user has the permission, send to the user an indication of the […] block in the block chain. (See Avetisov in [0090]).
Avetisov, in view of Panchencko, in view of Patel, does not expressly teach
create an end-of-life block in the block chain indicating that the NFT creation is complete; (“After the block chain of an IoT device has been terminated by attachment of an end-of-life block, the system may restrict access to the block chain.” See Marquardt in at least Col 4 Ln 9-27)
receive a request from the user to read the end-of-life block; (interpreting the user is attempting to access the blockchain of the NFT after the end-of-life block for information: “For example, after termination of the block chain of the IoT device by attachment of the end-of-life block, requests to add to the block chain may be rejected, requests to read from the block chain which comprise appropriate archival access credentials may be allowed, and requests to read from the block chain which lack appropriate archival access credentials may be rejected.” See Marquardt in at least Col 4 Ln 9-27)
determine whether the user has a permission to read the end-of-life block; (See Marquardt in at least Col 4 Ln 9-27)
The termination of the NFT is a combination between Marquardt and Panchencko, where Panchencko teaches about the NFT.
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Avetisov to include “the end-of-life block”, as taught by Marquardt, because the process should have the termination procedures to secure the user and the entity information and actions.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov, in view of Panchencko, in view of Patel, and further in view of US_2022/0067570 (hereinafter “Kong”).
Regarding Claims 9 and 18, Avetisov, in view of Panchencko, in view of Patel, teaches the limitations of claims 1 and 10. Avetisov, in view of Panchencko, does not expressly teach obtain a memory footprint associated with the NFT; determine whether the memory footprint exceeds a predetermined threshold; and upon determining that the memory footprint exceeds the predetermined threshold, store the NFT in an interplanetary file system.
However, Kong does teach
obtain a memory footprint associated with the NFT; (“In one embodiment, the training component 122 may determine the size of the machine learning model 125 (e.g., a storage size, the amount of storage space used to store the machine learning model 125, etc.) before the machine learning model 125 was trained using the training data 111 (e.g., may determine a first size).” See Kong in [0046])
determine whether the memory footprint exceeds a predetermined threshold; (“If the difference in sizes is not less than a threshold size (e.g., the size of the trained machine learning model exceeds a threshold), the process 700 ends. If the difference in sizes is less than a threshold size (e.g., the size of the trained machine learning model does not exceed a threshold), the process 700 may transmit the trained machine learning model to the computing device.” See Kong in [0080]) and
upon determining that the memory footprint exceeds the predetermined threshold, store the NFT in an interplanetary file system. (the process needs storage size to transmit, and storage is used during transmission, See Kong in [0080])
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Avetisov, in view of Panchencko, to include “machine learning process to store data”, as taught by Kong, because in combination with blockchain security, it prevents fraud storage of excess data in the secure block chain.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDGAR R. MARTINEZ-HERNANDEZ whose telephone number is (571)270-0658. The examiner can normally be reached M-F from 9:00 am - 5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 571-272-6708. 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.
/ERM/Examiner, Art Unit 3697
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697
Prosecution Insights