DETAILED ACTION
The present application, filed on 4/12/2022 is being examined under the AIA first inventor to file provisions.
The following is a FINAL Office Action in response to Applicant’s amendments filed on 3/11/2026.
a. Claims 1, 10 are amended
b. Claims 19-20 are cancelled
Overall, claims 1-18, 21-22 are pending and have been considered below.
Claim Rejections - 35 USC § 101
35 USC 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, 21-22 are rejected under 35 USC 101 because the claimed invention is not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception, i.e. an abstract idea, not integrated into a practical application, and without significantly more.
Per Step 1 of the multi-step eligibility analysis, claims 1-9, 21-22 are directed to a system and claims 10-18 are directed to computer executable instructions stored on a non-transitory storage medium.
Thus, on its face, each independent claim and the associated dependent claims are directed to a statutory category of invention.
[INDEPENDENT CLAIMS]
Per Step 2A.1. Independent claim 1, (which is representative of independent claims 10) is rejected under 35 USC 101 because the independent claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The limitations of the independent claim 1 (which is representative of independent claims 10) recite an abstract idea, shown in bold below:
[A] 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
[B] receive, at a node in the wireless telecommunications network, a request to create an NFT from a mobile device associated with a user,
[C] wherein the request is generated by a software operating on the mobile device in a secure protected boot mode,
[D] wherein the secure protected boot mode ensures integrity of the software using a cryptographic key;
[E] 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, a time associated with the request, a code indicating an activity occurring at the location at the time, an identifier (ID) associated with the mobile device, an ID associated with a Wi-Fi connection of the mobile device, and an ID associated with the user,
[F] wherein the software operates in the secure protected boot mode;
[G] 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,
[H] wherein the entity is distinct from the user;
[I] validate, at the node in the wireless telecommunications network and based on the multiple authentication factors, that the mobile device is within an area associated with the activity occurring at the location at the time;
[J] retrieve, by the node in the wireless telecommunications network and from a Policy Control Function (PCF) of the wireless telecommunications network, the block chain;
[K] determine whether the block chain includes an authorization to record the activity occurring at the location at the time,
[L] wherein the entity grants the authorization,
[M] wherein the authorization is associated with the mobile device;
[N] 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,
[O] 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,
[P] wherein the recording is obtained by the mobile device;
[Q] transmit the authorization from the UDR to the PCF; and
[R] upon determining that the block chain includes the authorization to record the activity occurring at the location at the time,
[S] 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.
Independent claim 1 (which is representative of independent claims 10) recites: resolving an entity and validating the geophysical location of the mobile device ([G], [I]); retrieving the blockchain and checking if it includes a recording authorization ([J], [K]); storing the authorization and receiving a recording ([N], [O]) and transmitting the authorization and creating a blockchain block ([Q], [S]), which, based on the claim language and in view of the application disclosure, represents a process aimed at: authorizing the creation of digital files and securely documenting the transfer thereof.
This is a combination that, under its broadest reasonable interpretation, covers agreements in the form of contracts, legal obligations, sales activities or behaviors, business relationships (e-commerce), which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is concluded that independent claim 1 (which is representative of independent claims 10) recites an abstract idea that corresponds to a judicial exception.
[INDEPENDENT CLAIMS – Additional Elements]
Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)).
For example, the added elements “hardware processor”, “non-transitory memory”, “network node” recite computing elements at a high level of generality, generally linking the use of a judicial exception to a particular technological environment (see MPEP 2106.05(h)), or merely using a computer as a tool to perform an abstract idea (MPEP 2106.05(f)). Further, the additional elements “wherein the request is generated by a software operating on the mobile device in a secure protected boot mode”; “wherein the secure protected boot mode ensures integrity of the software using a cryptographic key”; “wherein the software operates in the secure protected boot mode”; “wherein the entity is distinct from the user”; “wherein the entity grants the authorization”; “wherein the authorization is associated with the mobile device”; “wherein the recording is obtained by the mobile device”, as applied to the request, the boot mode, the software, the entity, the authorization, and the recording, are nothing more than (a) descriptive limitations of claim elements, such as describing the nature, structure and/or content of other claim elements, or (b) general links to the computing environment, which amount to instructions to “apply it,” or equivalent (MPEP 2106.05(f)).
These additional elements of the independent claims do not preclude from carrying out the identified abstract idea authorizing the creation of digital files and securely documenting the transfer thereof , and do not serve to integrate the identified abstract idea into a practical application.
The additional elements in the independent claims, shown not bolded above, recite: receive a request to create an NFT ([B]), obtain multiple authentication factors ([E]). When considered individually, they amount to nothing more than receiving data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ) into a practical application (see MPEP 2106.05(f)(2)).
Therefore, the additional claim elements of independent claim 1, (which is representative of independent claims 10), evaluated individually, as well as a whole, as an ordered combination, do not integrate the identified abstract idea into a practical application and the claims are directed to the recited judicial exception.
Per Step 2B. Independent claim 1 (which is representative of claims independent 10) does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Overall, it is concluded that independent claims 1, 10 are deemed ineligible.
[DEPENDENT CLAIMS]
Dependent claim 2, which is representative of dependent claim 11, recites:
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;
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.
The elements in these dependent claims are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ) into a practical application (see MPEP 2106.05(d) II)). When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claims continue to recite the identified abstract idea.
The dependent claims elements have the same relationship to the underlying abstract idea as outlined in the independent claims analysis above. It is readily clear that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claims further elaborate on the previously identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ).
Therefore, dependent claim 2 (which is representative of dependent claim 11) is deemed ineligible. As a result, it is concluded that the dependent claim elements do not integrate the identified abstract idea into a practical application (see MPEP 2106.05(f)(2)).
Dependent claim 3, which is representative of dependent claim 12, recites:
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;
distribute information about an auction associated with the NFT to multiple mobile devices,
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.
The elements in these dependent claims are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, “sorting information” i.e. comparing data, “determining an estimated outcome and setting a price”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ) into a practical application (see MPEP 2106.05(d) II)). When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claims continue to recite the identified abstract idea.
The dependent claims elements have the same relationship to the underlying abstract idea as outlined in the independent claims analysis above. It is readily clear that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claims further elaborate on the previously identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ).
Therefore, dependent claim 3 (which is representative of dependent claim 12) is deemed ineligible. As a result, it is concluded that the dependent claim elements do not integrate the identified abstract idea into a practical application (see MPEP 2106.05(f)(2)).
Dependent claim 4, which is representative of dependent claim 13, recites:
create a unique ID corresponding to the NFT;
obtain multiple block chains;
search the multiple block chains for a block associated with the NFT; and
create a second block chain including an indication of the block associated with the NFT,
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.
The elements in these dependent claims are comparable to receiving/transmitting data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ) into a practical application (see MPEP 2106.05(f)(2)).. When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claims continue to recite the identified abstract idea.
The dependent claims elements have the same relationship to the underlying abstract idea as outlined in the independent claims analysis above. It is readily clear that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claims further elaborate on the previously identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ).
Therefore, dependent claim 4 (which is representative of dependent claim 13) is deemed ineligible. As a result, it is concluded that the dependent claim elements do not integrate the identified abstract idea into a practical application (see MPEP 2106.05(f)(2)).
Dependent claim 5, which is representative of dependent claim 14, recites:
receive a request to enter an operation associated with the NFT;
check whether the request includes a unique ID associated with the NFT and a participant associated with the operation;
check whether the unique ID associated with the NFT is recorded in the block chain;
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;
determine whether the participant associated with the operation corresponds to the second entity, thereby verifying that the operation associated with the NFT conforms to permissions associated with the NFT and recorded in the block chain; 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.
The elements in these dependent claims are comparable to receiving/transmitting data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ) into a practical application (see MPEP 2106.05(f)(2)). When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claims continue to recite the identified abstract idea.
The dependent claims elements have the same relationship to the underlying abstract idea as outlined in the independent claims analysis above. It is readily clear that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claims further elaborate on the previously identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ).
Therefore, dependent claim 5 (which is representative of dependent claim 14) is deemed ineligible. As a result, it is concluded that the dependent claim elements do not integrate the identified abstract idea into a practical application (see MPEP 2106.05(f)(2)).
Dependent claim 6, which is representative of dependent claim 15, recites:
receive a request to authenticate the user by receiving a second ID associated with the user and a second ID associated with the mobile device of the user;
retrieve the ID associated with the user and the ID associated with the mobile device of the user from the block chain;
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;
determine whether a second match exists by determining whether the second ID associated with the mobile device matches the ID associated with the mobile device stored in the block chain; and
upon determining that the first match exists and the second match exists,
authenticate the user.
The elements in these dependent claims are comparable to receiving/transmitting data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ) into a practical application (see MPEP 2106.05(f)(2)). When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claims continue to recite the identified abstract idea.
The dependent claims elements have the same relationship to the underlying abstract idea as outlined in the independent claims analysis above. It is readily clear that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claims further elaborate on the previously identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ).
Therefore, dependent claim 6 (which is representative of dependent claim 15) is deemed ineligible. As a result, it is concluded that the dependent claim elements do not integrate the identified abstract idea into a practical application (see MPEP 2106.05(f)(2)).
Dependent claim 7, which is representative of dependent claim 16, recites:
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.
The elements in these dependent claims are comparable to receiving/transmitting data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ) into a practical application (see MPEP 2106.05(f)(2)). When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claims continue to recite the identified abstract idea.
The dependent claims elements have the same relationship to the underlying abstract idea as outlined in the independent claims analysis above. It is readily clear that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claims further elaborate on the previously identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ).
Therefore, dependent claim 7 (which is representative of dependent claim 16) is deemed ineligible. As a result, it is concluded that the dependent claim elements do not integrate the identified abstract idea into a practical application (see MPEP 2106.05(f)(2)).
Dependent claim 8, which is representative of dependent claim 17, recites:
create an end-of-life block in the block chain indicating that the NFT creation is complete;
receive a request from the user to read the end-of-life block;
determine whether the user has a permission to read the end-of-life block; and
upon determining that the user has the permission,
send to the user an indication of the end- of-life block in the block chain.
The elements in these dependent claims are comparable to receiving/transmitting data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ) into a practical application (see MPEP 2106.05(f)(2)). When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claims continue to recite the identified abstract idea.
The dependent claims elements have the same relationship to the underlying abstract idea as outlined in the independent claims analysis above. It is readily clear that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claims further elaborate on the previously identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ).
Therefore, dependent claim 8 (which is representative of dependent claim 17) is deemed ineligible. As a result, it is concluded that the dependent claim elements do not integrate the identified abstract idea into a practical application (see MPEP 2106.05(f)(2)).
Dependent claim 9, which is representative of dependent claim 18, recites:
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.
The elements in these dependent claims are comparable to receiving/transmitting data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ) into a practical application (see MPEP 2106.05(f)(2)). When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claims continue to recite the identified abstract idea.
The dependent claims elements have the same relationship to the underlying abstract idea as outlined in the independent claims analysis above. It is readily clear that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claims further elaborate on the previously identified abstract idea (authorizing the creation of digital files and securely documenting the transfer thereof ).
Therefore, dependent claim 9 (which is representative of dependent claim 18) is deemed ineligible. As a result, it is concluded that the dependent claim elements do not integrate the identified abstract idea into a practical application (see MPEP 2106.05(f)(2)).
Dependent claims 21-22 recite:
wherein the subscriber data storage element comprises a Unified Data Repository (UDR) or an Unstructured Data Storage Function (UDSF).
wherein the node in the wireless telecommunications network comprises the PCF.
These further elements in the dependent claims do not perform any claimed method steps. They describe the nature, structure and/or content of other claim elements (in this instance – the data storage, the node) and as such, cannot change the nature of the identified abstract idea (see MPEP 2106.07). The nature, form or structure of the other claim elements themselves do not practically or significantly alter how the identified abstract idea would be performed and do not provide more than a general link to a technological environment.
Therefore, dependent claims 21-22 are deemed ineligible.
When the dependent claims are considered as a whole, as an ordered combination, the claim elements noted above appear to merely apply the abstract concept to a technical environment in a very general sense. The most significant elements, which form the abstract concept, are set forth in the independent claims. The fact that the computing devices and the dependent claims are facilitating the abstract concept is not enough to confer statutory subject matter eligibility, since their individual and combined significance do not transform the identified abstract concept at the core of the claimed invention into eligible subject matter. Therefore, it is concluded that the dependent claims of the instant application, considered individually, or as a as a whole, as an ordered combination, do not amount to significantly more (see MPEP 2106.07(a)II).
In sum, claims 1-18, 21-22 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
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 difference 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 the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized as follows:
i. Determining the scope and contents of the prior art.
ii. Ascertaining the differences between the prior art and the claims at issue.
iii. Resolving the level of ordinary skill in the pertinent art.
iv. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4-7, 10-11, 13-16, 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov et al (US 2021/0044976), in view of Panchencko et al (US 2024/0311819) in further view of Patel et al (US 2023/0066272), in further view of Kunz et al (US 2024/0313969).
Regarding Claims 1, 10: Avetisov discloses: 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, when executed by at least one data processor of a system, cause the system to: {see at least fig1, rc155, [0068]-[0069]}
receive, at a node in the wireless telecommunications network, a request to create an NFT from a mobile device associated with a user, {see at least [0050] “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.”}
wherein the request is generated by a software operating on the mobile device in a secure protected boot mode, wherein the secure protected boot mode ensures integrity of the software using a cryptographic key; {see at least [0007] “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.”}
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, a time associated with the request, a code indicating an activity occurring at the location at the time, an identifier (ID) associated with the mobile device, an ID associated with a Wi-Fi connection of the mobile device, and an ID associated with the user, wherein the software operates in the secure protected boot mode; {see at least [0007] “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”; [0052] “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.”}
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, {see at least [0089] “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.”}
validate, at the node in the wireless telecommunications network and based on the multiple authentication factors, that the mobile device is within an area associated with the activity occurring at the location at the time; {see at least [0040] geofence within proximity of device; [0162]}
determine whether the block chain includes an authorization to record the activity occurring at the location at the time, {see at least [0281] “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.”}
wherein the entity grants the authorization, wherein the authorization is associated with the mobile device; {see at least [0125] 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.”}
store, in response to the determination, the authorization in a Unified Data Repository (UDR) of the wireless telecommunications network; {see at least [0061] “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.”}
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 mobile device, a recording associated with the activity occurring at the location at the time, {see at least [0120] “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.”}
wherein the recording is obtained by the mobile device; {see at least fig7, rc707, [0350] obtain registration information}
transmit the authorization from the UDR to the PCF; and {see at least fig1, rc155, [0089] policies implemented by the authorization server}
upon determining that the block chain includes the authorization to record the activity occurring at the location at the time, {see at least fig2, rc202, [0007]-[0008] user device transmitting credentials to a server (based on BRI (MPEP 2111), the PCF is part of a server)}
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. {see at least [0218] “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.”}
Avetisov does not disclose, however, Panchencko discloses:
requesting an NFT prior to an activity and creating a new block for the activity {see at least [0059] “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.”}
retrieve, by the node in the wireless telecommunications network and from a Policy Control Function (PCF) of the wireless telecommunications network, the block chain; {see at least [0047] “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.”}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Avetisov to include the elements of Panchencko. One would have been motivated to do so, in order to enhance security. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Avetisov evidently discloses creating securely a nonfungible token on a blockchain. Panchencko is merely relied upon to illustrate the functionality of requesting an NFT in the same or similar context. Since both creating securely a nonfungible token on a blockchain, as well as requesting an NFT 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 Avetisov, as well as Panchencko would function in the same manner in combination as they do in their separate embodiments, it is concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Avetisov / Panchencko.
Avetisov, Panchencko does not disclose, however, Patel discloses:
determining an entity, wherein the entity is distinct from the user; {see at least [0058] 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.”}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Avetisov, Panchencko to include the elements of Patel. One would have been motivated to do so, in order to order to perform the function. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Avetisov, Panchencko evidently discloses creating securely a nonfungible token on a blockchain. Patel is merely relied upon to illustrate the functionality of creating an entity in the same or similar context. Since both creating securely a nonfungible token on a blockchain, as well as creating an entity 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 Avetisov, Panchencko, as well as Patel would function in the same manner in combination as they do in their separate embodiments, it is concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Avetisov, Panchencko / Patel.
Avetisov, Panchencko, Patel does not disclose, however, Kunz discloses:
… Policy Control Function (PCF) to retrieve data {see at least [0056] 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.”}
… storing in a Unified Data Repository (UDR) {see at least [0057] “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.”}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Avetisov, Panchencko, Patel to include the elements of Kunz. One would have been motivated to do so, in order to provide the function with the necessary data. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Avetisov, Panchencko, Patel evidently discloses creating securely a nonfungible token on a blockchain. Kunz is merely relied upon to illustrate the functionality of retrieving and storing the data in the same or similar context. Since both creating securely a nonfungible token on a blockchain, as well as retrieving and storing the data 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 Avetisov, Panchencko, Patel, as well as Kunz would function in the same manner in combination as they do in their separate embodiments, it is concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Avetisov, Panchencko, Patel / Kunz.
Regarding Claims 2, 11: Avetisov, Panchencko, Patel, Kunz discloses the limitations of Claims 1, 10. Avetisov further discloses:
upon determining that the block chain includes the authorization to record the activity occurring at the location at the time, {see at least [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; {see at least [0072] “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.”}
receive an indication of a transfer of funds associated with the recording from a third party to the user; and {see at least [0281] “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.”}
distribute the funds to the user and the entity based on the first indication of interest and the second indication of interest. {see at least [0281] “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.”}
Regarding Claims 4, 13: Avetisov, Panchencko, Patel, Kunz discloses the limitations of Claims 1, 10. Avetisov further discloses:
create a unique ID corresponding to the NFT; {see at least [0237] “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.”}
obtain multiple block chains; {see at least [0125]}
Panchencko further discloses:
search the multiple block chains for a block associated with the NFT; and {see at least [0053] “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.”}
create a second blockchain including an indication of the block associated with the NFT, {see at least [0059] created with the “new blockchain block”}
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. {The reference does not disclose the content of the name or of the blockchain. However, this difference is only found in the non-functional descriptive material and does not affect how the claimed invention functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2111.05). Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability.}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Avetisov, Panchencko, Patel, Kunz to include additional elements of Panchencko. One would have been motivated to do so, in order to enhance security. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, creating securely a nonfungible token on a blockchain evidently discloses creating securely a nonfungible token on a blockchain. Avetisov, Panchencko, Patel, Kunz is merely relied upon to illustrate the additional functionality of creating an additional blockchain in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 5, 14: Avetisov, Panchencko, Patel, Kunz discloses the limitations of Claims 1, 10. Avetisov further discloses:
receive a request to enter an operation associated with the NFT; {see at least [0050] “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.”}
check whether the request includes a unique ID associated with the NFT and a participant associated with the operation; {see at least [0052] 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.”}
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; determine whether the participant associated with the operation corresponds to the second entity, thereby verifying that the operation associated with the NFT conforms to permissions associated with the NFT and recorded in the block chain; and {see at least [0089] 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. As an example, passwords not meeting certain criteria (e.g., length, randomness, number of unique characters, etc.) specified by a policy to access a given secure asset may be denied. As a result, the user may choose to establish new credentials 109 meeting the policy or a different credential 109 (e.g., of a different type) that meets criteria of the policy may be used. In another specific example, a policy for accessing a given secure asset may dictate that facial recognition credentials may be denied for a subset of mobile device 101 models, brands, or operating systems that are determined to provide insufficient results in securing the device against attack methods (e.g., are easily thwarted by a printed picture or model of a user's face). As a result, for users of devices belonging to that subset of mobile devices, different credentials 109 that meet criteria of the policy may be used.}
Avetisov does not disclose, however, Panchencko discloses:
check whether the unique ID associated with the NFT is recorded in the block chain; {see at least [0045]-[0046] 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.”}
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 at least [0059] created with the “new blockchain block”}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Avetisov, Panchencko, Patel, Kunz to include additional elements of Panchencko. One would have been motivated to do so, in order to securely expanding the number of blocks. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Avetisov, Panchencko, Patel, Kunz evidently discloses creating securely a nonfungible token on a blockchain. Panchencko is merely relied upon to illustrate the additional functionality of creating an additional block upon checking the ID in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 6, 15: Avetisov, Panchencko, Patel, Kunz discloses the limitations of Claims 1, 10. Avetisov further discloses:
receive a request to authenticate the user by receiving a second ID associated with the user and a second ID associated with the mobile device of the user; {see at least [0007], [0050], [0052] duplication of parts}
retrieve the ID associated with the user and the ID associated with the mobile device of the user from the block chain; {see at least [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; {see at least [0057] “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.”}
determine whether a second match exists by determining whether the second ID associated with the mobile device matches the ID associated with the mobile device stored in the block chain; and {see at least [0057]}
upon determining that the first match exists and the second match exists, authenticate the user. {see at least [0120] “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.”}
Regarding Claims 7, 16: Avetisov, Panchencko, Patel, Kunz discloses the limitations of Claims 1, 10. Avetisov further discloses:
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. {see at least [0206] 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”}
Regarding Claim 21: Avetisov, Panchencko, Patel, Kunz discloses the limitations of Claim 10. Kunz further discloses:
wherein the subscriber data storage element comprises a Unified Data Repository (UDR) or an Unstructured Data Storage Function (UDSF). {see at least [0057] “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.”}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Avetisov, Panchencko, Patel, Kunz to include additional elements of Kunz. One would have been motivated to do so, in order to store just the desired elements. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Avetisov, Panchencko, Patel, Kunz evidently discloses creating securely a nonfungible token on a blockchain. Kunz is merely relied upon to illustrate the additional functionality of the composition of the data storage in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 22: Avetisov, Panchencko, Patel, Kunz discloses the limitations of Claims 10. Kunz further discloses:
wherein the node in the wireless telecommunications network comprises the PCF. {see at least [0056] “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.”}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Avetisov, Panchencko, Patel, Kunz to include additional elements of Kunz. One would have been motivated to do so, in order to keep the nodes efficient. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Avetisov, Panchencko, Patel, Kunz evidently discloses creating securely a nonfungible token on a blockchain. Kunz is merely relied upon to illustrate the additional functionality of the composition of a node in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Claims 3, 12 are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov et al (US 2021/0044976), in view of Panchencko et al (US 2024/0311819) in further view of Patel et al (US 2023/0066272), in further view of Kunz et al (US 2024/0313969), in further view of Mahajan et al (US 2019/0392511)
Regarding Claims 3, 12: Avetisov, Panchencko, Patel, Kunz discloses the limitations of Claims 1, 10. Avetisov further discloses:
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 at least [0281]}
transfer the interest in the NFT to the first party among the multiple parties; and {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.}
Avetisov, Panchencko, Patel, Kunz does not disclose, however, Mahajan discloses:
distribute information about an auction associated with the NFT to multiple mobile devices, wherein the information includes an ID “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.”}
receive multiple bids “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.”}
determine a highest bid among the multiple bids, wherein the highest bid is associated with a first party among the multiple parties; {see at least [0039] “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.”}
distribute the highest bid to the entity and the user based on the first indication of interest and the second indication of interest. {see at least [0039] winning bid … highest bid}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Avetisov, Panchencko, Patel, Kunz to include the elements of Mahajan. One would have been motivated to do so, in order to achieve the highest possible sales price. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Avetisov, Panchencko, Patel, Kunz evidently discloses creating securely a nonfungible token on a blockchain. Mahajan is merely relied upon to illustrate the functionality of an NFT auction in the same or similar context. Since both creating securely a nonfungible token on a blockchain, as well as an NFT auction 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 Avetisov, Panchencko, Patel, Kunz, as well as Mahajan would function in the same manner in combination as they do in their separate embodiments, it is concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Avetisov, Panchencko, Patel, Kunz / Mahajan.
Claims 8, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov et al (US 2021/0044976), in view of Panchencko et al (US 2024/0311819) in further view of Patel et al (US 2023/0066272), in further view of Kunz et al (US 2024/0313969), in further view of Marquardt et al (US 10,958,434).
Regarding Claims 8, 17: Avetisov, Panchencko, Patel, Kunz discloses the limitations of Claims 1, 10. Avetisov, Panchencko, Patel, Kunz does not disclose, however, Marquardt discloses:
create an end-of-life block in the block chain indicating that the NFT creation is complete; {see at least [4:9-27] “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.”}
receive a request from the user to read the end-of-life block; {see at least [4:9-27] 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.”}
determine whether the user has a permission to read the end-of-life block; {see at least [4:9-27] “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.”}
and upon determining that the user has the permission send to the user an indication of the end-of-life block in the block chain. {see at least [4:9-27] “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.”}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Avetisov, Panchencko, Patel, Kunz to include the elements of Marquardt. One would have been motivated to do so, in order to retire the system. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Avetisov, Panchencko, Patel, Kunz evidently discloses creating securely a nonfungible token on a blockchain. Marquardt is merely relied upon to illustrate the functionality of creating an end-of-life block in the same or similar context. Since both creating securely a nonfungible token on a blockchain, as well as creating an end-of-life block 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 Avetisov, Panchencko, Patel, Kunz, as well as Marquardt would function in the same manner in combination as they do in their separate embodiments, it is concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Avetisov, Panchencko, Patel, Kunz / Marquardt.
Claims 9, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov et al (US 2021/0044976), in view of Panchencko et al (US 2024/0311819) in further view of Patel et al (US 2023/0066272), in further view of Kunz et al (US 2024/0313969), in further view of Kong et al (US 2022/0067570).
Regarding Claims 9, 18: Avetisov, Panchencko, Patel, Kunz discloses the limitations of Claims 1, 10. Avetisov, Panchencko, Patel, Kunz does not disclose, however, Kong discloses:
obtain a memory footprint associated with the NFT; {see at least [0046] “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).”}
determine whether the memory footprint exceeds a predetermined threshold; and {see at least [0080] “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.”}
upon determining that the memory footprint exceeds the predetermined threshold, store the NFT in an interplanetary file system. {see at least [0080] the process needs storage size to transmit, and storage is used during transmission}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Avetisov, Panchencko, Patel, Kunz to include the elements of Kong. One would have been motivated to do so, in order to control the management of the network resources. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Avetisov, Panchencko, Patel, Kunz evidently discloses creating securely a nonfungible token on a blockchain. Kong is merely relied upon to illustrate the functionality of the memory footprint of an NFT in the same or similar context. Since both creating securely a nonfungible token on a blockchain, as well as the memory footprint of an NFT 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 Avetisov, Panchencko, Patel, Kunz, as well as Kong would function in the same manner in combination as they do in their separate embodiments, it is concluded that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Avetisov, Panchencko, Patel, Kunz / Kong.
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20190363894 A1 KUMAR UJJWAL; Rajeev METHOD AND SYSTEM FOR PROTECTING COMPUTING DEVICES FROM MALWARES This disclosure relates method and system for protecting a computing device from a malware. In one embodiment, the method may include determining a digital trust certificate of a set of computing instructions to be executed by the computing device. The set of computing instructions may form a part of a boot process of the computing device, and may be a firmware, a boot loader, a kernel, a system driver, a start-up file, or an antimalware. The method may further include establishing a chain of trust by validating the digital trust certificate with the computing device. The digital trust certificate may be pre-registered with a local database, accessible by the computing device, by communicating with a centralized certificate authority and policy server. Upon a positive establishment of the chain of trust, the method may further include allowing an execution of the set of computing instructions by the computing device.
US 20240154806 A1 Qiu; Xin et al. ANTI-CLONING OF DEVICE CRYPTOGRAPHIC KEYS FOR COUNTERFEIT PREVENTION A method and apparatus, and system for providing device credentials to a plurality of devices is disclosed. The system comprises a credential builder, for generating the credentials or procuring the credentials from a source external to the credential distribution system; a credential loader; a credential server, for accepting credential requests from the devices and for receiving the requested credentials from the credential loader; a first secured interface, communicatively coupling the credential loader and the credential server; a second secured interface, communicatively coupling the credential server and the device; a central credential database, communicatively coupled to the credential loader, for storing each the credentials and a provisioning history of each of the credentials; a credential server database, communicatively coupled to the credential server, for storing the credentials local to the credential server; and a cloning detection system, communicatively coupled to the central credential database and the credential server database, the cloning detection system for detecting duplicate credentials using the credentials stored in the central credential database and the credential server database.
US 20120137119 A1 Doerr; Michael B. et al. Disabling Communication in a Multiprocessor System Disabling communication in a multiprocessor fabric. The multiprocessor fabric may include a plurality of processors and a plurality of communication elements and each of the plurality of communication elements may include a memory. A configuration may be received for the multiprocessor fabric, which specifies disabling of communication paths between one or more of: one or more processors and one or more communication elements; one or more processors and one or more other processors; or one or more communication elements and one or more other communication elements. Accordingly, the multiprocessor fabric may be automatically configured in hardware to disable the communication paths specified by the configuration. The multiprocessor fabric may be operated to execute a software application according to the configuration.
US 20230325814 A1 Vijayan; Madhu et al. Systems and Methods for Instant NFTs and Protection Structure, Detection of Malicious Code within Blockchain Smart Contracts, Tokens with Transfer Limitations, Mirror Tokens and Parallel Addresses, Smart Contract Risk Scoring Method, and Cross-Device Digital Rights Management Non-fungible token (NFT) platforms in accordance with various embodiments of the invention are described. In an embodiment of the NFT platform includes generating an instant NFT that includes data, at least one record, and a first timestamp, where the instant NFT is privately maintained and not publicly accessible; determine a modification to the at least one record associated with the instant NFT to generate several records associated with the instant NFT, where the modification is indicative of a transaction associated with the instant NFT; protect the instant NFT and the modification to the at least one record associated with the instant NFT, where the modification to the at least one record is associated with a second timestamp; detect an indication to mint the instant NFT as an NFT; and mint the instant NFT as an NFT on a public blockchain.
US 20250112783 A1 Sprague; Michael et al. System to Assure a Response from an Identified, Measured and Verified AI An AI verification system using existing capabilities provided by trusted computing and blockchain technology. The AI verification system can be optimized to assure that input from a client system sent to an AI system to make a request is not tampered with in creation or transmission. The response from the AI system is processed by the AI verification system to ensure that it is secure for delivery and presentation back to the client including the cyber assurance data collected from the operating environment of the AI system. The AI verification system can produce sufficient forensic data to assure a response from AI systems and services is trusted and verified. The AI verification system may be encapsulated in and implemented as an AI verification embedded microcontroller.
US 20230327893 A1 Paczkowski; Lyle Walter et al. SECURELY CREATING A NONFUNGIBLE TOKEN ON A BLOCK CHAIN USING A 5G INFRASTRUCTURE OF A WIRELESS TELECOMMUNICATION NETWORK Disclosed here is a system to receive an input from a user, indicating a request to create a recording and an NFT from the recording. The system can operate in a rich environment mode, and a hardware root of trust mode that verifies a software running in the hardware root of trust mode using cryptographic keys. The system switches the operation into a hardware root of trust mode. The system sends to a server a request to create the NFT, including multiple authentication factors. The server authenticates the request based on the multiple authentication factors and determines an entity having an interest in the NFT. The system receives a permission to make the recording and an indication of the entity having the interest in the NFT, makes the recording, and causes creation of the NFT.
Response to Amendments/Arguments
Applicant’s submitted remarks and arguments have been fully considered.
Applicant disagrees with the Office Action conclusions and asserts that the presented claims fully comply with the requirements of 35 U.S.C. § 101 regrading judicial exceptions. Further, Applicant is of the opinion that the prior art fails to teach Applicant’s invention.
Examiner respectfully disagrees in both regards.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101.
Applicant submits:
a. The pending claims are not directed to an abstract idea.
b. The identified abstract idea is integrated into a practical application.
c. The pending claims amount to significantly more.
Furthermore, Applicant asserts that the Office has failed to meet its burden to identify the abstract idea and to establish that the identified abstract idea is not integrated into a practical application and that the pending claims do not amount to significantly more.
Examiner responds – The arguments have been considered in light of Applicants’ amendments to the claims. The arguments ARE NOT PERSUASIVE. Therefore, the rejection is maintained.
The pending claims, as a whole, are directed to an abstract idea not integrated into a practical application. This is because (1) they do not effect improvements to the functioning of a computer, or to any other technology or technical field (see MPEP 2106.05 (a)); (2) they do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or a medical condition (see the Vanda memo); (3) they do not apply the abstract idea with, or by use of, a particular machine (see MPEP 2106.05 (b)); (4) they do not effect a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05 (c)); (5) they do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the identified abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designated to monopolize the exception (see MPEP 2106.05 (e) and the Vanda memo).
In addition, the pending claims do not amount to significantly more than the abstract idea itself.
As such, the pending claims, when considered as a whole, are directed to an abstract idea not integrated into a practical application and not amounting to significantly more.
More specific:
Applicant submits “Applicant respectfully submits that the amended 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).”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Based on the claim language (“determine whether the block chain includes an authorization to record the activity occurring at the location at the time”, “transmit the authorization from the UDR to the PCF”, “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. ”) and in light of the specification (specification at [0011]-[0013]), the claims are unambiguously directed to authorizing the creation of digital files and securely documenting the transfer thereof. This is a combination that, under its broadest reasonable interpretation, covers agreements in the form of contracts, legal obligations, sales activities or behaviors, business relationships (e-commerce), which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)). Accordingly, it is concluded that independent claim 1 (which is representative of independent claims 10) recites an abstract idea that corresponds to a judicial exception.
Thus, the rejection is proper and has been maintained.
Applicant submits “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,”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
“specific methods and related systems” is not an eligibility criterion (see MPEP 2106.04-07)
Thus, the rejection is proper and has been maintained.
Applicant submits “The amended claims recite technical operations performed by specific telecommunications network components.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Operations performed by “specific telecommunications network components” are not an eligibility criterion (see MPEP 2106.04-07)
Thus, the rejection is proper and has been maintained.
Applicant submits “Even assuming for the sake of argument that the claims recite a judicial exception, Applicant respectfully submits that the amended claims are eligible at least at Step 2A, Prong Two because they integrate any alleged judicial exception into a practical application.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
First, MPEP 2106.05(a) discloses that the additional claim elements bring about “improvements to the functioning of a computer, or any other technology or technical field.” Creating and transferring files is a BUSINESS problem, rather than a technology or technical field problem. As such, the limitations which have not been deemed as being part of the identified abstract idea, i.e., the “additional elements,” do not integrate the identified abstract idea into a practical application, as disclosed by MPEP 2106.05(a).
Second, MPEP 2106.04(d)(1) discloses:
An important consideration to evaluate when determining whether the claim as a whole integrates a judicial exception into a practical application is whether the claimed invention improves the functioning of a computer or other technology .... In short, first the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art .... Second, if the specification sets forth an improvement in technology. the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement. (Emphasis added)
That is, the claimed invention may integrate the judicial exception into a practical application by demonstrating that it improves the relevant existing technology although it may not be an improvement over well-understood, routine, conventional activity. (Emphasis added)
Thus, the rejection is proper and has been maintained.
Applicant submits “As such, they could be considered analogous to eligible claim 1 of Example 42 of the USPTO's Subject Matter Eligibility Examples.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
It is not proper practice to go and find a particular Example from the Office published material and use the specific arguments from that Example to determine eligibility of a particular claimed invention, unless the particular claimed invention uniquely matches (i.e. a case that involves identical or similar facts or similar legal issues) the subject matter claimed in that particular Example, which in the instant situation it does not. The Office periodically publishes Examples with detailed analyses only to serve as rational and argumentation models to determine eligibility. Each application has to be considered on its own merits. Examples provided by the Office are nothing more than the name suggests: EXAMPLES, that are to be considered or not, as they are neither laws, nor rules, nor regulations.
Thus, the rejection is proper and has been maintained.
Applicant submits “Amended Claim 1 eligible under Step 2B of the Alice/Mayo Test”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The eligibility analysis in the instant office action has determined at Step 2B:
Per Step 2B. Independent claim 1 (which is representative of claims independent 10) does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Overall, it is concluded that independent claims 1, 10 are deemed ineligible.
Thus, the rejection is proper and has been maintained.
Applicant submits “In particular, Applicant submits that at least the combination of … demonstrate an inventive concept.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
See response immediately above.
Thus, the rejection is proper and has been maintained.
Applicant submits “These limitations demonstrate unconventional use of wireless telecommunications network components 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.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
The eligibility analysis in the instant office action does not make such an allegation.
Thus, the rejection is proper and has been maintained.
It follows from the above that there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself. Therefore, the rejection under 35 U.S.C. § 101 is maintained.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits remarks and arguments geared toward the amendments. Examiner has carefully reviewed and considered Applicant’s remarks, however they ARE MOOT in light of the fact that they are geared towards the amendments.
The other arguments presented by Applicant continually point back to the above arguments as being the basis for the arguments against the other 103 rejections, as the other arguments are presented only because those claims depend from the independent claims, and the main argument above is presented against the independent claims. Therefore, it is believed that all arguments put forth have been addressed by the points above.
Examiner has reviewed and considered all of Applicant’s remarks. The changes of the grounds for rejection, if any, have been necessitated by Applicant’s extensive amendments to the claims. Therefore, the rejection is maintained, necessitated by the extensive amendments and by the fact that the rejection of the claims under 35 USC § 101 has not been overcome.
Conclusion
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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.
Inquiries
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Radu Andrei whose telephone number is 313.446.4948. The examiner can normally be reached on Monday – Friday 8:30am – 5pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Hayes can be reached at 571.272.6708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
As disclosed in MPEP 502.03, communications via Internet e-mail are at the discretion of the applicant. Without a written authorization by applicant in place, the USPTO will not respond via Internet e-mail to any Internet correspondence which contains information subject to the confidentiality requirement as set forth in 35 U.S.C. 122. A paper copy of such correspondence will be placed in the appropriate patent application. The following is a sample authorization form which may be used by applicant:
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with me concerning any subject matter of this application by electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center information webpage. Status information for unpublished applications is available to registered users through Patent Center information webpage only.
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.
Any response to this action should be mailed to:
Commissioner of Patents and Trademarks
P.O. Box 1450
Alexandria, VA 22313-1450
or faxed to 571-273-8300
/Radu Andrei/
Primary Examiner, AU 3697
Prosecution Insights