DETAILED ACTION
Status of Claims
The present application, filed on or after 3/16/2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the RCE, Remarks, and Amendments filed 03/23/2026.
Claims 1-13 have been amended.
Claims 1-13 have been examined and are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/23/2026, has been entered.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, or 365(c) is acknowledged.
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(b) is acknowledged.
(AIA ) Examiner Note
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were effectively filed absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned at the time a later invention was effectively filed in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea (i.e. a judicial exception) without significantly more.
Per step 1 of the 2019 Revised Patent Subject Matter Eligibility Guidance, the claims are directed towards a process, machine, or manufacture.
Per step 2A Prong One, the claims recite specific limitations which fall within at least one of the groupings of abstract ideas enumerated in the 2019 PEG, as follows:
Per Independent claims 1, 12, and 13:
generate at least one key for transaction of a first token of a plurality of tokens, wherein the transaction is based on a blockchain;
generate, based on the at least one key, a wallet address of the wallet on the blockchain
generate first setting data related to a page of the first user of the social network service, wherein the first setting data is associated with presentation of the first token on the page of the first user of the social network service;
As noted supra, these limitations fall within at least one of the groupings of abstract ideas enumerated in the 2019 PEG. Specifically, these limitations fall within the group Certain Methods Of Organizing Human Activity (e.g. fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
That is, these steps, as drafted, are nothing more than a business decision to create generic “setting data” in a business scheme of attesting to a transaction recorded in a business ledger (albeit a digital distributed ledger called a blockchain). Because the invention as a whole as claimed does not pertain to technical improvements in a ledger per se nor to any technical feature but only pertains to business decisions regarding what information to store and retrieve from a ledger for the purpose of attesting to user transactions (i.e. the business decision), the claims fall within the realm of general commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations) and hence recite an abstract idea. Note. per applicant’s own Specification, the claims as a whole are directed only towards a manner for attesting that information which a user is posting on a webpage of a social network service (e.g. Twitter™, Facebook™, Instagram™ ) is also stored in a digital ledger, e.g. a stored non-fungible token NFT (i.e. applicant’s recited “token”) per applicant’s Spec at [0004], [0009]-[0013], and [0042] where NFTs are not applicant’s invention; thus the claims fall into Certain Methods of Organizing Human Activity.
Again note, the claims as a whole are not technical in nature although they generically reference high-level ideas necessary for storing and retrieving information from blockchains (digital ledgers) in general secure manners such as creating keys, tokens, and digital wallets which are necessary to locate and retrieve information, e.g. stored tokens, from such digital ledger blockchains. However, applicant’s entire original disclosure is devoid of any description of any technical improvement to the process of creating/generating such keys, tokens, and wallet addresses, etc.... Instead, these are generic descriptions of processes necessary to enable some level of secure storage and retrieval of information from digital ledger blockchain systems. There is no technical problem here and no technical solution being claimed to solve a technical problem.
Applicant has not invented NFTs, has not invented digital ledger blockchains, but is only using them to facilitate his abstract idea. There is not technical solution for “generating” the claimed “setting data”, where the “setting data” itself appears to be nothing more than generic instruction regarding business decisions pertaining to whether to present data regarding an NFT, e.g. attestation data, on a webpage of a user. Furthermore, the mere nominal recitation of generic computer components (e.g. information processing apparatus; a non-transitory computer-readable medium, etc…) does not take the claim limitation out of the enumerated grouping. Thus, the claims recite an abstract idea.
Per step 2A Prong 2, the Examiner finds that the judicial exception is not integrated into a practical application. Although there are additional elements, other than those noted supra, recited in the claims, none of these additional element(s) or a combination of elements as recited in the claims apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception. As drafted, the claims as a whole merely describe how to generally “apply” the aforementioned concepts or link them to a field of use (i.e. in this case attesting to data displayed on a social network website matches data stored in a digital ledger – a business decision) or serve as insignificant extra-solution activity (e.g. data-gathering, transmittal, and storage). The claimed computer components are recited at a high level of generality and are merely invoked as tools to implement the idea but are not technical in nature. Simply implementing the abstract idea on or with generic computer components is not a practical application of the abstract idea.
These additional limitations are as follows: “An information processing apparatus, comprising: a processor configured to: control a wallet application to log into an account of a first user on a social network service, wherein the wallet application is associated with a wallet of the first user; transmit the wallet address to a server of the social network service to link the wallet to the social network service; acquire, based on the linked wallet to the social network service, information of the first token of the plurality of tokens owned by the first user, wherein the first token is associated with the wallet address, the acquisition of the information of the first token is from the blockchain, and each token of the plurality of tokens is unique; … control transmission of the generated first setting data to the server, wherein the server sets, based on the transmission of the first setting data, the first token for presentation on the page of the first user of the social network service.”
However, these elements do not present a technical solution to a technical problem; i.e. Applicant’s invention is not a technique nor technical solution for logging into a social network service at this high level of generality, instead, logging into such service appears to be a generic transfer of information when recited at this high level of generality and recited for the purpose of providing context for the abstract idea but it is not significantly more than the abstract idea. Similarly, transmitting the wallet address to a sever is merely transmission of data. There is no technical solution recited for transmitting such data. Furthermore, there is no particular solution to the desired “linking” of the wallet to the social network service; this is recited as a wish but not as any particular solution to effect the desired linking and as such is either a generic data transmittal step or part of the abstract idea neither of which are significantly more than the already recited abstract idea. Similarly, the acquire step is merely data acquisition. And the description of the acquired data is not significantly more than the already recited abstract idea. Finally, the control transmission of data step is just data transmission. The desired result of displaying data according to some generic setting data is at such a high level of generality as to be nothing more than an abstract idea and/or part of information necessary to effect generic display; either way this is not significantly more than the already recited abstract idea. Applicant has not invented “control” technology for transferring data and therefore this feature is nothing more than insignificant extra-solution activity when recited at this high-level of generality. The additional elements do not recite a specific manner of performing any of the steps core to the already identified abstract idea. Instead, these features merely serve to generally “apply” the aforementioned concepts within a computing environment, using known protocols to collect and transmit data, or are insignificant pre-solution or insignificant extra-solution activities (e.g. data-gathering, and data-transfer, data display) as relates to the already identified abstract idea and do not integrate the abstract idea into a practical application thereof.
Per Step 2B, the Examiner does not find that the claims provide an inventive concept, i.e., the claims do not recite additional element(s) or a combination of elements that amount to significantly more than the judicial exception recited in the claim. As discussed with respect to Step 2A Prong Two, the additional elements in the independent claims were considered as merely serving to generally “apply” the aforementioned concepts via generically described computer components or “link” them to a field of use, or as insignificant pre-solution and extra-solution activity. For the same reason these elements are not sufficient to provide an inventive concept; i.e. the same analysis applies here in 2B. Mere instructions to apply an exception using a generic computer component and conventional data gathering cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. So, upon revaluating here in step 2B, these elements are determined to amount to no more than mere instructions to apply the exception using generic computer components (i.e. a server) and/or gather and transmit data which is well-understood, routine, conventional activity in the field; i.e. note the Symantec, TLI, and OIP Techs Court decisions cited in MPEP 2106.05(d)(ll) indicate that mere receipt or transmission of data over a network is a well-understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here).
Accordingly, alone and in combination, these elements do not integrate the abstract idea into a practical application, as found supra, nor provide an inventive concept, and thus the claims are not patent eligible.
As for the dependent claims, the dependent claims do recite a combination of additional elements. However, these claims as a whole, considered either independently or in combination with the parent claims, do not integrate the identified abstract idea into a practical application thereof nor do they provide an inventive concept.
For example, dependent claim 2 recites the following: “…the processor is further configured to: set a condition to present the first token on the page of the first user of the social network service.” However, this is nothing more than a business decision and therefore part of the abstract idea but not significantly more than that. There is no technical solution being claimed and the decision to set a condition is a business decision and not a technical problem. Therefore, this feature is not found to be significantly more than the already recited abstract idea.
Therefore, the Examiner does not find that these additional claim limitations integrate the abstract idea into a practical application nor provide an inventive concept. Instead, these limitations, as a whole and in combination with the already recited claim elements of the parent claims, are not significantly more than the already identified abstract idea. A similar finding is found for the remaining dependent claims.
For these reasons, the claims are not found to include additional elements that are sufficient to amount to significantly more than the judicial exception and therefore the claims are not found to be patent eligible.
Please see the 2019 Revised Patent Subject Matter Eligibility Guidance published in the Federal Register (84 FR 50) on January 7, 2019 (found at http://www.uspto.gov/patent/laws-and-regulations/examination-policy/examination-guidance-and-training-materials).
Claim Rejections - 35 USC § 103 (AIA )
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claims 1-8, 10-13 are rejected under 35 U.S.C. 103 as obvious over Smith et al. (U.S. 2021/0067511 A1; hereinafter, "Smith") in view of Hruska et al. (U.S. 2013/0262316 A1; hereinafter, "Hruska")
Claims 1, 12, 13 (currently amended)
Pertaining to claims 1, 12, 13 exemplified in the limitations of claim 1, Smith as shown teaches the following:
An information processing apparatus, comprising:
a processor configured to:
[…]
generate at least one key for transaction of a first token1 2 of a plurality of tokens, wherein the transaction is based on a blockchain (Smith, see at least Fig. 3 and [0067]-[0086] in view of at least [0093] and [0185] pertaining to smart contracts regarding transactions of user’s PII attestations on a blockchain, e.g. per [0082]-[0086]: “…In some examples, requester 116 creates [generates] the attest key [at least one key] using the hashed user PII and the validator's public key, and this attest key is an address on attestation blockchain 114. If requester 116 is able to find the transaction [i.e. the key is for a transaction] for user 102a at this address on blockchain 114, then requester 116 can be certain that the plain text PII sent to them by user 102a has been attested to and can be trusted,… If requester 116 finds the attestations on the attestation blockchain 114 at the attest address and it has not been revoked, then the PII from user 102a is verified, and the requester provides the user with the desired service…”; Note also [0067]: “…tokens are digital assets, cryptographically secured upon the blockchain, which can represent whatever the issuer wants and is prepared to back (if necessary), and which can play whatever role in the system that its rule-set determines…”; i.e. the unique signed attestation of a user’s PII is a type of non-fungible asset token [applicant’s token]. See also [0197]. Applicant’s “tokens”, in view of his Specification, see footnotes, include “NFTs” i.e. non-fungible tokens, and this reads on Smith’s “signed attestation to that PII” [an NFT token] on the attestation blockchain 114 – again see [0197]; i.e. a validator attests to certain user PII, which per [0072] “User 102a's PII” may include any “information that is personal or tied to a specific user.”; an attestation to this PII tied to the user and is recorded [a transaction] in a blockchain via signed attestation by a validator; the attestation of this unique relationship of this PII to a user as recorded in a blockchain is a type of non-fungible token (NFT) conforming to the definition of NFTs, e.g. as provided by Merriam Webster Dictionary – see footnote. Note, Smith also discusses an additional different idea which he also groups under the idea of “tokens”, but which is a type of fungible token used as currency, not to be confused with Smith’s unique identifiers of non-fungible assets such as “signed attestations of user’s PII”, etc…, types of non-fungible tokens and applicant’s “NFT tokens”);
generate, based on the at least one key, a wallet address of the wallet on the blockchain (Smith, see citations noted supra, in view of at least [0185], e.g. per [0082]-[0086]: “…this attest key [the at least one key] is an address [wallet address] on attestation blockchain 114 …”; and per [0185]: “…an attestation address [wallet address] is the address at which a record from attestor 1001 can be found on centralized or distributed ledger 1006… for a single signature record, a hash function, for example the P2PKH algorithm, maybe applied to an input to create [generate] an attestation address [wallet address]…”; the “attestation address” [wallet address] is based on the created [generated] “the attest key” [at least one key]);
transmit the wallet address to a server of the social network service to link the wallet to the social network service (Smith, see citations noted supra, including [0079]-[0084]: “…The attestation and its metadata which includes the public key of the validator 100 may also be stored on the user's device 306 as the user 102a has to provide [transmit] this information [i.e. including the attestation address which is a type of wallet address] to the requester 116 to be able to validate PII against the attestation blockchain 114…”; therefore, the Examiner understands Smith provides motivation to transmit the “attestation address” [wallet address] to a server of a social network if that is the requester wishing to validate the user’s PII; this transmittal may be to link the “attestation address” [wallet address] to the requesting social network’s services; e.g. as noted per [0197]: for the purpose of to show “…a picture for connection 2025, the name of connection 2025, the relationship between connection 2025 and company/organization 2020, the email address for connection 2025, and optionally any other profile information for connection 2025, for
example a link to connection 2025's Linkedln profile [social network service], or twitter feed, or any other social network feed for connection…”. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have performed this step as noted per the motivation provided by Smith because per MPEP 2143(I) (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference teachings to arrive at the claimed invention is obvious. The motivation may be implicit and may be found in the knowledge of one of ordinary skill in the art, or, in some cases, from the nature of the problem to be solved. Id. at 1366, 80 USPQ2d at 1649.)
acquire, based on the [wallet, linked] to the social network service, information of the first token of the plurality of tokens owned by the first user, wherein the first token is associated with the wallet address, the acquisition of the information of the first token is from the blockchain (Smith, see citations noted supra, e.g. again per at least [0082]-[0086]: “…requester 116 is able to find [acquire] the transaction [information of the first token] for user 102a at this address [based on wallet address] on blockchain 114,… If requester 116 finds the attestations [more information of the first token(s), e.g. attested user PII] on the attestation blockchain 114 at the attest address [wallet address] and it has not been revoked, then the PII from user 102a is verified, and the requester provides the user with the desired service…”; Again, as noted supra, Smith’s transaction on the blockchain includes recorded validator attested user PII, i.e. validator attested personally identifiable information of the user, which as noted per at least [0072]-[0077]: “…This allows user 102a to share PII information with another participant in the system and prove that it is the same data that was previously attested to by validator 100…”; Smith’s attested to user PII as signed by a validator and recorded in a blockchain is a type of non-fungible token), and each token of the plurality of tokens is unique (Smith, see citations noted supra, e.g. again per at least [0082]-[0086] further in view of at least [0093]: “…In step 402, service provider A 302 calculates hashes of the user's PII…” ; i.e. the attested user PII is hashed and therefore unique because of the hash and additionally because it is a hash of unique information of a particular user – i.e. the user’s PII; and see again [0197].);
generate first setting data related to a page of the first user of the social network service, wherein the first setting data is associated with presentation of the first token on the page of the first user of the social network service (Smith, see citations noted supra, in view of Figs. 15, 25 and at least [0201]-[0214], teaching, e.g.: “…In step 1555, identity verification platform 2000 generates [generate] customized code in the form of a badge [setting data associated with presentation of the token] for the individual… the company [social network service] imports the code for the individual's badge on its website to enable verification that the claimed relationship to the individual is genuine… Once the validator has attested to this information, the company [social network service] is issued an ID code or badge [setting data associated with presentation of the first token] for that individual. The company may display the ID code or badge [setting data associated with the presentation of the first token] on their website [social network service]. In some embodiments, the ID code or badge may only be displayed on their website, or on a website associated with the company…”; note that a user may per his “My settings page” of Fig. 25 register, with the identity verification platform, the user’s relationships and accounts which the user holds with various entities [social network services], e.g. a user’s job title held at a particular company, as well as company and personal email addresses, as well as verified accounts with at least LinkedIn [social network service] and other social network services
PNG
media_image1.png
736
870
media_image1.png
Greyscale
); and
control transmission of the generated first setting data to the server (Smith, see again citations noted supra in view of again at least [0189]-[0199] and [0202], teaching e.g.: “…In step 1555, identity verification platform 2000 generates customized code [setting data] in the form of a badge for the individual. The company exports [controls transmission to another server] code from the individual's badge [the generated setting data] on the company dashboard of identity verification platform 2000 in step 1560…”), wherein the server sets, based on the transmission of the first setting data, the first token for presentation on the page of the first user of the social network service (Smith, see again citations noted supra, including Figs. 27, 32, 33 and [0197], teaching: “the rendered badge [setting data for presenting the token] on… platform 2020 shows a picture for connection 2025, the name of connection 2025, the relationship between connection 2025 and company/organization 2020, the email address for connection 2025, and optionally any other profile information for connection 2025, for example a link to connection 2025's Linkedln profile, or twitter feed, or any other social network feed for connection 2025… connections that are advisors to company/organization 2020 may be shown on one page, and connections that are team members [may be] shown on a second page,…”; Per Figs. 32-33 Smith show’s a user’s page with badge which displays the user’s verified and attested PII [token], including: name, photo, job title, and e-mail, all presented on a page of the user, within the company’s website [social network service],
PNG
media_image2.png
536
874
media_image2.png
Greyscale
).
Although Smith teaches the above limitations, including a “digital wallet provider client” [wallet application] and also teaches a user’s “attestation address” [a wallet address] on an attestation blockchain where the user’s PII may be stored, attested and verified by 3rd parties, Smith may not explicitly teach the below nuances of controlling such digital wallet provider client as recited. However, regarding this feature, Smith in view of Hruska teaches the following:
control a wallet application to log into an account of a first user on a social network service, wherein the wallet application is associated with a wallet of the first user (Hruska, see at least Figs. 2 and 3b and [0010], e.g.: “…the product for sale can be uploaded from a personal computer through the Mobile Wallet web account [controlling a wallet application] on a social network website [i.e. implying requiring wallet to login to such social network website; e.g. login to user’s account on such site]…” and “…While using the Mobile Wallet application in order to make the purchase, a Mobile Wallet user can log into their Mobile Wallet application and may view the listed products being sold on existing social network sites, as shown in FIG. 3b. By selecting the item displayed on the user's social network public wall while viewing it from within the Mobile Wallet application, in a similar fashion as described above, the Mobile Wallet backend provides a description/confirmation page for the user to purchase the product...”; In view of these teachings, Examiner understands that Hruska provides motivation for his mobile wallet application to enable a user to control it to log into the user’s social network account(s) of the user to enable the user to upload through such mobile wallet web account and to the user’s social network public wall, the products the user wishes to sell; i.e. Hruska’s teaching regarding: “the product for sale can be uploaded from a personal computer through the Mobile Wallet web account on a social network website” i.e. of a user such that others may purchase such uploaded products from the user’s public wall of the social network website; i.e. as described as noted per [0010] and shown in FIG. 3b. Therefore, in view of these findings, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have enabled Hruska’s user to control Hruska’s wallet application to log into the user’s social network account(s) of the user, thereby performing the limitation in question, for the reasons noted supra and because per MPEP 2143(I) (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference teachings to arrive at the claimed invention is obvious. The motivation may be implicit and may be found in the knowledge of one of ordinary skill in the art, or, in some cases, from the nature of the problem to be solved. Id. at 1366, 80 USPQ2d at 1649.)
Therefore, the Examiner understands that the limitation in question is merely applying a known technique of Hruska (directed towards a user using [controlling] a wallet application to log into an account of the user on a social network service, wherein the wallet application is associated with a wallet of the user) which is applicable to a known base device/method of Smith (already directed towards a system/method making use of digital wallet provider clients [wallet applications] as well as attestation addresses [wallet addresses] where a user may securely store attested PII of the user; e.g. for the purpose of attesting and verifying user PII presented on the user’s social network accounts such as the user’s LinkedIn profile, or twitter feed, or any other social network feed, etc… as noted per Smith at [0197] and Fig. 27) to yield predictable results. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the technique of Hruska to the device/method of Smith such that Smith’s user is also able to control an application, e.g. his digital wallet provider client, to enable the functionality rendered obvious by Hruska, e.g. to log into an account of a first user on a social network service, because Hruska is pertinent to the teachings of Smith and Smith and Hruska are analogous art in the same field of endeavor (at least H04L 63/0884) and because according to MPEP 2143(I) (C) and/or (D), the use of known technique to improve a known device, methods, or products in the same way (or which is ready for improvement) is obvious.
Claim 2 (currently amended)
Smith/Hruska teaches the limitations upon which this claim depends. Furthermore, as shown, Smith teaches the following:
The information processing apparatus according to claim 1, wherein the processor is further configured to: set a condition to present the first token on the page of the first user of the social network service. (Smith, see citations noted supra e.g. [0202]: “…When a company attempts to render a badge, the identity verification platform verifies that the domain matches what was approved in step 1570. The badge can only be rendered on the web site within the domain or domains belonging to the company. In some embodiments, the identity verification platform is responsible for maintaining a list of domains that each badge is authorized to be rendered on. In step 1575, if the domain matches what was approved, the ID Codes verification badge for the individual is rendered on the company website…”; and per [0228], e.g.: “…In some implementations, the method includes determining that the relationship between the user and the entity is existent responsive to identifying the presence of a non-zero value stored with the retrieved record in the centralized or distributed ledger…”).
Claim 3 (currently amended)
Smith/Hruska teaches the limitations upon which this claim depends. Furthermore, as shown, Smith teaches the following:
The information processing apparatus according to claim 1, wherein the processor is further configured to: restrict a viewer to which the first token is presented on the page of the first user of the social network service (Smith, see citations noted supra including also at least Figs. 32-33 and associated disclosure; e.g. “the badge is only [a restrictino] displayed on approved company domain”, etc…).
Claim 4 (currently amended)
Smith/Hruska teaches the limitations upon which this claim depends. Furthermore, as shown, Smith teaches the following:
The information processing apparatus according to claim 1, wherein the processor is further configured to generate second setting data for each of a plurality of social network services, the plurality of social network services includes the social network
service, and the second setting data includes the first setting data (Smith, see again at least [0202], teaching e.g.: “…In step 1565, the company [i.e. the server] imports the code for the individual's badge [setting data for presenting a token] on its website to enable verification that the claimed relationship [i.e. the token; user attested PII] to the individual is genuine. When a company [e.g. a social network service of a plurality] attempts to render a badge, the identity verification platform verifies that the domain matches what was approved in step 1570. The badge can only be rendered on the web site within the domain or domains belonging to the company...”; no difference between first and second setting data is required because “the second setting data includes the first setting data” and nothing more.)
Claim 5 (currently amended)
Smith/Hruska teaches the limitations upon which this claim depends. Furthermore, as shown, Smith teaches the following:
The information processing apparatus according to claim 1, wherein the processor is further configured to set, based on a type of the social network service, the first token on the social network service (Smith, see citations noted supra, including also e.g. [0197], teaching: “…FIG. 27 shows an illustration of badges for connections for company/organization 2020 rendered on identity verification platform 2020. …In embodiments, the rendered badge on identity verification platform 2020 shows a picture for connection 2025, the name of connection 2025, the relationship between connection 2025 and company/organization 2020, the email address for connection 2025, and optionally any other profile information for connection 2025, for example a link to connection 2025's Linkedln profile, or twitter feed, or any other social network feed for connection 2025…”).
Claim 6 (currently amended)
Smith/Hruska teaches the limitations upon which this claim depends. Furthermore, as shown, Smith teaches the following:
The information processing apparatus according to claim 5, wherein the processor is further configured to set, based on a selection process of the first user, the first token that is presented on the social network service (Smith, see citations noted supra, including also e.g. [0197], teaching: “…FIG. 27 shows an illustration of badges for connections for company/organization 2020 rendered on identity verification platform 2020. In some examples, user 1002 of company/organization 2020 may export a badge of connection 2025, for example by clicking on the badge for connection 2025…”).
Claim 7 (currently amended)
Smith/Hruska teaches the limitations upon which this claim depends. Furthermore, as shown, Smith teaches the following:
The information processing apparatus according to claim 1, wherein the processor is further configured to: analyze a preference of the first user based on the first token (Smith, see citations noted supra, e.g. per Fig. 25 and associated disclosure, the user’s settings [preferences] include claimed relationships); and execute at least one of an: advertisement or a recommendation based on the preference of the first user (Smith, see citations noted supra, in view of also at least [0008]: “…There is significant value to the individual with whom the relationship is claimed as it protects their own reputation from misuse. There is significant value to a third party visiting the web site as they may make decisions based upon the claimed relationship, endorsement or recommendation presented to them…”; i.e. the recommendations are based upon claimed relationships, e.g. the user’s “settings” [preferences])
Claim 8 (currently amended)
Smith/Hruska teaches the limitations upon which this claim depends. Furthermore, as shown, Smith teaches the following:
The information processing apparatus according to claim 7, wherein the recommendation indicates a connection with a second user, and preference of the second user is associated with the preference of the first user (Smith, see citations noted supra, further in view of at least [0041]-[0044]: “…FIG. 24 illustrates an interface showing [a type of recommendation] a user's personal connections in an identity verification platform, according to some implementations… FIG. 26 illustrates an entity dashboard in an identity verification platform that is operable to enable a user to invite new connections to the entity, according to some implementations… FIG. 27 illustrates an entity dashboard in an identity verification platform illustrating connections of an entity, according to some implementations…”; a possible new connection with a connection of an entity to which the user is also connected is a type of recommendation based on similar preference – i.e. similar by virtue of being connected with the same entity, etc…).
Claim 10 (currently amended)
Smith/Hruska teaches the limitations upon which this claim depends. Furthermore, as shown, Smith teaches the following:
The information processing apparatus according to claim 1, wherein an image associated with the first token is next to a profile icon of the first user on the page (Smith, see citations noted supra including again at least Fig. 33 and associated disclosure; e.g. per [0210]: “In some examples, the company may put a picture of the individual on the website and the picture may appear with a check mark beside it, or a badge icon, or any other representation, visual or audio, that indicates to a viewer of the website that that person has been authenticated by a validator…”; e.g. an image of a “checkmark” [an image associated with the token] is displayed next to a profile icon of the user on the page of the user of the social network; note “the badge is only displayed on approved company domain”, etc… the social network may be “Twitter”, etc…e.g. per [0181]; See pertinent part of Fig. 33 provided below:
PNG
media_image3.png
596
1024
media_image3.png
Greyscale
)
Claim 11 (currently amended)
Smith/Hruska teaches the limitations upon which this claim depends. Furthermore, as shown, Smith teaches the following:
The information processing apparatus according to claim 1, wherein the first token is associated with a first image (Smith, see citations noted supra, e.g. per at least [0197]-[0210]: “…identity verification platform 2000 creates a custom badge [image associated with token] representing the approved relationship between connection 2025 and company/organization 2020. …The company may display [i.e. the token is associated with a displayable first image] the ID code or badge [first token] on their website. In some embodiments, the ID code or badge [first token] may only be displayed on their website, or on a website associated with the company… the company may put a picture of the individual on the website and the picture may appear with a check mark beside it, or a badge icon, or any other representation, visual or audio, that indicates to a viewer of the website that that person has been authenticated by a validator…”) the plurality of tokens includes a second token, the second token is associated with a second image (Smith, see citations noted supra, including also at least [0074], e.g. “…if user 102a wants to update only a portion of their PII, they can revoke and change only this portion of the PII, while not having to revoke and have re-attested the entirety of the PII that is stored. For example, if user 102a moves and has a new physical address, but their other PII has stayed the same, validator 100 may be used to authenticate the new physical address [a second token] and then revoke the node of the existing attestation that contained user 102a's previous physical address. A new node is then added with the attested new [second token] physical address…”) the server concurrently displays each of the first image and the second image (Regarding this latter feature, although perhaps not explicitly taught by Smith, Examiner finds that in view of the preponderance of teachings of Smith, as already shown supra, e.g in part per at least [0197]-[0210], a person of ordinary skill in the art would recognize that Smith’s teachings regarding the “badge” [image associated with token], e.g. as noted per [0197]-[0210], which reflects attested user PII as being verified and true, may represent e.g. user’s “relationship with company/organization” as well as “email address”,etc… and any other PII and each may have its own badge or image as displayed on website; Therefore, Examiner finds that concurrent display of two such badges representing first and second tokens, e.g. a first displayed image/badge representing token of user’s attested and verified “relationship with company/organization” as well as a second displayed image/badge representing a token of user’s attested and verified “email address” may be concurrently displayed is within the level of skill of a person of ordinary skill in the art and, is also at least suggested by Smith’s teachings as noted supra. Therefore, in view of these findings, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have performed this step of concurrently displaying each of the first image and the second image e.g. with motivation as suggested by Smith, and because per MPEP 2143(I) (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference teachings to arrive at the claimed invention is obvious. The motivation may be implicit and may be found in the knowledge of one of ordinary skill in the art, or, in some cases, from the nature of the problem to be solved. Id. at 1366, 80 USPQ2d at 1649.)
Claim 9 is rejected under 35 U.S.C. 103 as obvious over Smith in view of Hruska, further in view of McDonald (WO 2021/016225 A1; hereinafter, “McDonald”).
Claim 9 (currently amended)
Although Smith/Hruska teaches the limitations upon which this claim depends, including a token system, e.g. per Smith [0067] and Smith teaches there is significant value to recommending and making endorsements based on verified and authenticated relationships and/or qualifications which may be indicated by “badges” [setting data regarding presentation of a user’s token], etc… (e.g. per [0008], [0030], [0189], [0197], etc…), he may not teach the below nuance of recommending a connection who has the same qualification/badge/token. However, regarding this feature, Smith in view of McDonald teaches the following:
The information processing apparatus according to claim 7, wherein the recommendation indicates a connection with a second user, and the second user is associated with the first token (McDonald, see at least [157] teaching, e.g.: “…the system determines match recommendations based on entity qualifications [tokens]. For example, the system may recommend matches between entities with similar or the same qualifications [tokens]… As another example, the system may recommend a match between a company in a seed round and an investor that is qualified as a seed round investor based on the investor’s behavioral trends…”)
Therefore, the Examiner understands that the limitation in question is merely applying a known technique of McDonald (directed towards determines match recommendations based on entity qualifications [tokens]. For example, the system may recommend matches between entities with similar or the same qualifications [tokens]) which is applicable to a known base device/method of Smith (already directed towards verifying user relationships and qualifications which may be represented by tokenized “badges”) to yield predictable results. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the techniques of McDonald to the device/method of Smith in order to perform the limitation in question because Smith and McDonald are analogous art in the same field of endeavor (at least H04L 63/0884) and because according to MPEP 2143(I) (C) and/or (D), the use of known technique to improve a known device, methods, or products in the same way (or which is ready for improvement) is obvious.
Response to Arguments
Applicant amended all claims – i.e. claims 1-13 on 03/23/2026. Applicant's arguments (hereinafter “Remarks”) also filed 03/23/2026, have been fully considered but are moot in view of the new grounds of rejection necessitated by applicant’s amendments. Note the new 35 USC 101 and 103 rejections in view of Smith and Hruska.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J SITTNER whose telephone number is (571)270-3984. The examiner can normally be reached M-F; ~9:30-6:30. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Waseem Ashraf can be reached on (571) 270-3948. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Michael J Sittner/
Primary Examiner, Art Unit 3621
1 Specification: [0011]: “…non-fungible token (NFT) images 22 and 23 associated with the NFT owned by the user are displayed beside the profile image…”; and per [0014]: “… In the present embodiment, a token that is an encrypted asset having uniqueness is referred to as an NFT…”
2 NFT definition per https://www.merriam-webster.com/dictionary/NFT: “An NFT (Non-Fungible Token) is a unique digital identifier that cannot be copied, substituted, or subdivided, that is recorded in a blockchain, and that is used to certify authenticity and ownership (as of a specific digital asset and specific rights relating to it)”
Prosecution Insights