Detailed Action
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Acknowledgments
This submission (Amendment) filed on 03/24/26 is acknowledged.
Status of Claims
Claims 1, 3-10 and 12-18 are pending.
In the Amendment filed on 03/24/26, claims 1 and 10 were amended, claims 2 and 11 were cancelled, and no claims were added.
Claims 1, 3-10 and 12-18 are rejected.
Response to Arguments
Regarding the rejection under 35 U.S.C. 112
In view of the claim amendments, the rejection is withdrawn.
Regarding the rejection under 35 U.S.C. 101
Applicant's arguments have been fully considered but are not persuasive.
The Office addresses Applicant's arguments below. Headings and page numbers in the discussion below refer to Applicant's Response unless otherwise indicated.
I. Step 2A - Prongs One and Two
Applicant argues:
Applicant respectfully contests the Office's assertions and maintains that the claims do not recite a judicial exception. The Office asserts that the claims relate to "fundamental economic practices" or "commercial interactions," but the claims do not recite any such activity. Instead, the claims require a processing server to perform specific technical operations, including network traffic analysis of a marketplace (with analysis of unique visitors and visitor frequency), analysis of domain registration data, social media traffic, and popularity rankings, comparison of visual features of NFTs against trusted NFTs, and analysis of blockchain wallet transaction histories. These operations involve processing of digital data specific to computer networks, blockchain systems, and digital media. The mere fact that the output may be used to inform a purchasing decision does not render the claims directed to a fundamental economic practice. (Response, p. 9)
The Office respectfully disagrees. As described above by Applicant, the claims are directed to determining whether an NFT is authentic (as per the specification, to permit users to avoid making fraudulent purchases, where the inauthentic NFT lacks the value falsely attributed to it, see 0002-0005). Specifically, the claims analyze various data to determine a likelihood of authenticity. As such, the claims recite an abstract idea. The analysis and determination are performed by additional elements recited at a high level of generality and not described (e.g., processor, blockchain wallet), such that the relationship between the abstract idea and the additional elements is either 'apply it' or 'generally linking the use of a judicial exception to a particular technological environment or field of use'.
Applicant further argues:
Even assuming arguendo that the claims recite an abstract idea, the claims integrate any such idea into a practical application under Step 2A, Prong Two. Applicant's specification identifies a technical problem in computer-based NFT ecosystems: existing systems, including blockchain-based systems, are unable to determine whether an NFT, its associated marketplace, or its seller are genuine, particularly in the presence of phishing marketplaces, copied digital assets, and fraudulent blockchain wallets. See, e.g., paragraphs [0002]-[0004] of the originally filed specification. Applicant's claims provide a specific technical solution implemented by a processing server that gathers and analyzes multiple disparate digital data sets corresponding to different fraud vectors. These include network-level data (e.g., traffic analysis including unique visitors and visit frequency), domain and marketplace metadata (e.g., registration data, popularity rankings), visual-feature analysis of digital content, and blockchain transaction history analysis. The claims further require combining the resulting authenticity scores into a unified confidence score. This constitutes a specific improvement in how computer systems process and correlate heterogeneous digital data to detect authenticity issues in NFT environments, as further emphasized in the specification's description of a "significant technological improvement over existing systems." See, e.g., paragraph [0033]. (Response, p. 10; emphasis added)
Applicant's words above (and the portions of the specification cited therein) confirm that the claimed invention is a matter of gathering and analyzing data to generate scores indicating the degree of authenticity of an NFT. This is not an improvement in the functioning of a computer or other technology. Rather, the recited additional elements, including the computer and technology elements, are used off-the-shelf, in their ordinary capacities, and the putative improvement is of the abstract idea.
Applicant further argues:
Applicant respectfully submits that the Office's characterization of the problem as non- technical does not fully account for the technical nature of the challenges described in the specification. The problem addressed by Applicant's claims arises specifically in computer and networked environments involving digital assets, blockchain systems, and online marketplaces, where authenticity cannot be reliably determined using existing computerized tools. The claimed solution is likewise technical, involving specific data processing operations applied to digital artifacts and network-derived data. This is not a case where a generic computer is used merely as a tool to perform an alleged judicial exception; rather, the claims recite a particular manner of configuring a processing server to perform multiple distinct analyses that are inherently computer-based. (Response, p. 10)
The Office respectfully disagrees. The problem addressed by Applicant's claims does not arise specifically in the realm of computer networks. Rather, the problem of determining authenticity, including the specific sub-types of authenticity (marketplace authenticity, visual authenticity, wallet (transaction history) authenticity), predated the computers and the internet. Furthermore, the claims do not contain any "particular manner of configuring a processing server" that improves the server or changes it from an off-the-shelf element used in its ordinary capacity, or otherwise amounts to a practical application or significantly more. Rather, the processing server is merely used in its ordinary capacity as a generic computer element to analyze data and output a score based on the analysis. The other additional elements are likewise merely used in their ordinary capacity as generic elements in the context/service of the authenticity determination. As such, the additional elements amount to nothing more than 'apply it' or 'generally linking the use of a judicial exception to a particular technological environment or field of use'.
Applicant further argues:
Applicant respectfully submits that the Office's rebuttal on pages 5-6 of the Office Action, which states that the claims merely improve an "abstract idea," overlooks the specific technical processing steps recited in the claims and the corresponding technological improvements described in the specification. The improvement is not to a business concept, but to the underlying computer-implemented fraud detection technique. The claims improve how computer systems analyze authenticity by introducing a multi-dimensional scoring framework that integrates marketplace traffic analytics, domain-level data, social media signals, visual similarity detection, and blockchain transaction analysis. As described in Applicant's specification, this combination of disparate data sources makes it significantly more difficult for fraudulent actors to evade detection and enables improved detection of phishing marketplaces, plagiarized NFTs, and suspicious wallet activity. This constitutes a technological improvement in computer-based analysis, not merely a refinement of an abstract idea. (Response, pp. 10-11; emphasis changed from original)
Again, Applicant's words (shown in bold above) merely confirm that the putative improvement is indeed in the abstract idea, not in the functioning of a computer or other technology. The novelty lies in, and the alleged advantage is provided by, the particular data analyses, which together constitute the "fraud detection technique" / "multi-dimensional scoring framework," which is merely carried out ("implemented") on a generic computer.
Applicant further argues:
In Applicant's previous response, it was noted that that the courts have found that "improvements in technology beyond computer functionality may demonstrate patent eligibility." MPEP 2106.05(a)(II). Specifically, claims directed to an improvement in computer network technology are patent-eligible if the "claims are directed to using a specific technique-using a plurality of network monitors that each analyze specific types of data on the network and integrating reports from the monitors-to solve a technological problem arising in computer networks..." SRI International, Inc. v. Cisco Systems, Inc., 930 F.3d 1295, 1303 (Fed. Cir. 2019) (citing Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335-36 (Fed. Cir. 2016)).
Applicant respectfully submits that the Office's rebuttal to Applicant's arguments that the claims, similar to SRI International, improve upon the above and address a technological problem arising in computer networks is likewise misplaced. The Office asserts:
Unlike SRI, Applicant's claims have nothing to do with technical content/aspects of computer network technology, but merely baldly include an "online marketplace" (Response, p. 14), specifically, "a marketplace that includes a webpage or application program." Again, Applicant's reference to a "specific" technique is not persuasive, because the specificity is of the abstract idea. Response, p. 14. Again, Applicant's description of the problem allegedly solved by the instant claims -- "current fraud scoring methodologies are quite generalized and do not take into (Response, pp. 11-12; emphasis in original) consideration certain risk factors" and the like --confirms that the instant claims address a non-technical problem. Response, p. 14.
While SRI International involved network intrusion detection, Applicant's claims similarly address detection of malicious or fraudulent activity in networked computing environments using network-derived data (e.g., traffic analysis, domain data, and marketplace metrics). The claims improve how computer systems process such data to identify inauthentic or fraudulent conditions associated with NFTs and online marketplaces. Thus, like SRI, the claims are directed to improving computer functionality in analyzing network and system behavior, even if applied in a different technological domain. (Response, pp. 11-12; emphasis changed from original)
The instant claims are not analogous to SRI's claims. The subject matter of the instant claims is distinct from that of SRI. For example, the instant claims have nothing analogous to SRI's network monitors across a distributed network, and, moreover, unlike SRI they do not address a technical problem and do not provide a technical solution. Further, the instant claims do not involve an improvement in computer network technology; they do not even involve a computer network to any significant degree (but rather only "network-derived data"). Finally, an improvement in "how computer systems process data" as claimed by Applicant is an improvement in the abstract idea, not in the functioning of a computer or other technology.
The remaining paragraphs in this section ("I. Step 2A - Prongs One and Two") at pp. 12-13 constitute a conclusion and as such merely summarize the content previously argued and do not present new content/ argument.
II. Step 2B Analysis
As for step 2B (Response, pp. 13-14), Applicant presents no further substantive argument.
Regarding the rejections under 35 U.S.C. 103
Applicant's arguments are moot and/or not persuasive in view of the additional portions of the previously applied references cited in the instant rejections and in view of the responses to Applicant's arguments set forth below.
Initially, the claim amendments are taught by the previously applied references as follows:
"domain registration data" is taught by Jakobsson 0268-0270 (see also 0281-0283) with reference to 0002: similarity of entity names suggesting impersonation and hence fraud risk (e.g., 0268) applies also where the entity is a webpage/domain name (0002). Note "domain registration data" is also taught by Zawoad 0023: malicious activity information includes list of malicious URLs associated with a network domain name.
"social media traffic" is taught by Jakobsson 0268-0270: "reputation score" and/or "complaint score" (marketplace authenticity score) is computed based on various factors ("various different types of information") (0270) including "being associated with … a large number of social media posts" (0269).
"popularity rankings" are taught by Zawoad 0023, 0083, 0110-0111: malicious activity information or features include popularity score or page rank that reflects popularity.
The Office addresses Applicant's arguments below. Page numbers in the discussion below refer to Applicant's Response unless otherwise indicated.
Note: the following arguments pertain to Jakobsson
Applicant argues:
Jakobsson is directed to blockchain security mechanisms for NFTs, including fraud detection, transaction verification, and bridging between blockchains. The document does not disclose or suggest analyzing marketplace web traffic characteristics such as visitor counts or visitor frequency. Instead, Jakobsson focuses on assessing risk associated with transactions using factors such as identity verification, reputation data, and token-related metrics, not marketplace traffic analytics or popularity indicators. (pp. 15-16; emphasis added)
In response:
Jakobsson was not cited as teaching the subject matter in question (see underlined portion of Applicant's argument above). Therefore, Applicant's argument (see underlined content above), even if it were correct, is not relevant.
Applicant further argues:
Jakobsson fails to disclose or suggest the amended limitation of "based on one or more marketplace metrics including at least said network traffic analysis, domain registration data, social media traffic and popularity rankings, determining ... a marketplace authenticity score for the marketplace." Jakobsson does not disclose determining any score based on marketplace-level metrics, let alone a score derived from a combination of heterogeneous external data sources such as network traffic analytics, domain registration data, social media activity, and popularity rankings. Rather, Jakobsson's analysis is focused on transaction-specific and token- specific verification processes. Even assuming, arguendo, Jakobsson discloses some form of "reputation" or "confidence" score, such scoring pertains to tokens, users, or transactions-not to a marketplace itself-and is not based on the claimed combination of marketplace metrics (i.e., network traffic analytics, domain registration data, social media activity, and popularity rankings). (p. 16; emphasis changed from original)
In response:
In the previous Office Action Jakobsson was not cited as teaching the subject matter indicated in bold above in its entirety. Therefore, this part of Applicant's argument, even if it were correct, is not relevant. In the instant Office Action Jakobsson is cited as teaching domain registration data and social media traffic, as explained above.
Regarding "marketplace-level metrics"/"marketplace itself" (underlined above), the Office respectfully disagrees. As per the rejection, Jakobsson's "reputation score" and/or "complaint score" taught in 0268-0270 may indicate a likelihood of impersonation of identity, in particular, of a marketplace, as per 0263:
In many embodiments, NFT platforms can include security platforms that include identity tokens that can be utilized to provide a mechanism to address abuse associated with impersonation. In particular, in an attack, an attacker can impersonate a trusted entity, such as a marketplace or a famous NFT owner, and offers an intended victim to purchase an NFT. This can be one type of imitation, namely of the identity of this entity [i.e., "this entity" refers to "a marketplace or a famous NFT owner"].
Again, as per the rejection, 0422 teaches "detect[ing] risk of fraudulent activity based upon characteristics of a market(s)." Although Applicant quotes a portion of the rejection that cites 0263 and 0422, Applicant fails to address the teachings of 0263 and 0422 cited in the rejection. Thus, Applicant's argument that Jakobsson does teach marketplace-level metrics is not persuasive.
Applicant further argues:
In its rejection of dependent claim 2, the Office alleges that Jakobsson, citing paragraphs [0281]-[0283], discloses that "one or more marketplace metrics includes at least one of a popularity rank, domain registration data, network activity, and social media traffic." Applicant respectfully contests this assertion and submits that Jakobsson, particularly the cited portions, does not disclose or suggest these claimed marketplace metrics. Paragraphs [0281]-[0283] describe comparing entity or party names (e.g., detecting misspellings such as "Acme Inc." versus "Acme inc.") in the context of identifying potential impersonation. However, such comparison of textual identifiers does not constitute "domain registration data," nor does it disclose or suggest "popularity rank," "network activity," or "social media traffic" as recited in the claims. (pp. 16-17; emphasis added)
In response:
In the previous Office Action Jakobsson was not cited as teaching the subject matter indicated in bold above. Therefore, this part of Applicant's argument, even if it were correct, is not relevant. In the instant Office Action Jakobsson is cited as teaching social media traffic, as explained above.
As for the underlined portion of Applicant's argument above, this misrepresents the rejection: the mere "comparison of textual identifiers" alone was not what was cited as teaching the "domain registration data"; rather, the rejection explicitly stated that Jakobsson teaches that this comparison of entity names may pertain to domain names:
although the discussion of 0281-0283 highlights the comparison in the context of an email, 0002 teaches that it may also occur in the context of a webpage or domain name; "domain name" teaches domain registration data) (Office Action issued 01/28/2026, p. 22; emphasis added)
Thus, this portion of Applicant's argument is not persuasive. Note this line of argument continues in the following paragraph of Applicant's Response, discussed immediately below.
Applicant further argues:
[1] Specifically, domain registration data refers to structured information associated with domain ownership or registration (e.g., registrar data, registration dates, ownership records), whereas Jakobsson merely compares names or strings for similarity. [2] The mere presence of a "domain name" or textual identifier does not equate to analysis of domain registration data. Likewise, Jakobsson is entirely silent as to analyzing network traffic characteristics (such as visitor counts or frequency), social media traffic, or popularity rankings associated with a marketplace. These are distinct categories of data that require separate data sources and analytical techniques, none of which are disclosed or suggested in the cited portions of Jakobsson. (p. 17; emphasis added; bracketed numerals added to facilitate discussion below)
In response:
In the previous Office Action Jakobsson was not cited as teaching the subject matter indicated in bold above. Therefore, this part of Applicant's argument, even if it were correct, is not relevant. In the instant Office Action Jakobsson is cited as teaching social media traffic, as explained above.
As for the underlined portion of Applicant's argument above, the Office respectfully disagrees. First, regarding sentence [1], the claim does not recite "structured information." Under broadest reasonable interpretation (BRI), the claim term "domain registration data" is not limited to "structured information." Second, regarding sentence [2], the claim does not recite "analysis," and one of ordinary skill in the art understands that "domain registration data" includes the domain name that is being registered. Therefore, this portion of Applicant's argument is not persuasive.
Note: the following arguments pertain to Zawoad
Applicant argues:
Regardless of whether Zawoad may disclose aggregating various types of malicious activity information (including web traffic data) to determine a maliciousness score for network identifiers, the document does not disclose or suggest determining a marketplace authenticity score, nor does it teach combining the specific categories of data recited in the claims-namely, domain registration data, social media traffic, and popularity rankings-in the context of evaluating a marketplace. Zawoad's scoring is directed to assessing whether a domain or IP address is malicious, not whether a marketplace is authentic or trustworthy. (pp. 17-18; emphasis added)
In response:
In the previous Office Action Zawoad was not cited as teaching the subject matter indicated above in bold. Therefore, Applicant's argument, even if it were correct, is not relevant. In the instant Office Action Zawoad is cited as teaching popularity rankings and, alternatively to Jakobsson, domain registration data, as explained above.
Note: the following arguments pertain to combining Jakobsson and Zawoad
Applicant further argues:
Applicant respectfully disagrees with the Office and submits that one of ordinary skill in the art would not have looked to Zawoad to remedy the deficiencies of Jakobsson. The Office's reasoning to combine improperly assumes that because both documents relate generally to "risk" or "fraud," their teachings are readily combinable. However, the mere fact that two documents address security-related concerns does not provide a sufficient motivation to combine their disparate techniques. Jakobsson operates in a blockchain transaction context, focusing on verifying NFTs and transaction legitimacy, whereas Zawoad operates in a network security context, focusing on identifying malicious domains or IP addresses. The types of data used, the problems addressed, and the outputs generated are materially different. There is no teaching or suggestion in Jakobsson that marketplace authenticity should be evaluated based on website traffic characteristics such as unique visitors or visit frequency, nor is there any indication in Zawoad that its domain-level maliciousness scoring could be applied to NFT marketplaces or integrated into blockchain-based transaction verification systems. (pp. 18-19; emphasis changed from original)
In response:
As for the bold portion of Applicant's argument above, the rejection did not allege that Jakobsson contained the indicated "teaching or suggestion" or that Zawoad contained the indicated "indication," nor does the combination require that Jakobsson or Zawoad contain such content.
As for the underlined portion of Applicant's argument above:
Both Jakobsson and Zawoad relate to fraud risk in respect of websites (see the rejection, e.g., Jakobsson 0263 marketplace, e.g., Craigslist or Amazon; 0425 browser for interacting with marketplace; Zawoad 0022-0025 re web traffic). Thus, both Jakobsson and Zawoad address the same problem or comparable problems, and pertain to the same field or comparable fields of endeavor. Zawoad's teachings may be applied to any website/domain.
The fact that the "data" is "different" merely reflects the fact that the rejection is a combination -- the rejection combines Zawoad's particular data relevant for fraud detection with Jakobsson, which deals with other particular data relevant for fraud detection. It is not understood what is meant by saying that the data of Jakobsson and the data of Zawoad is "materially different." No "material" difference is seen in these data. Applicant does not elaborate on this point.
Applicant further argues:
[1] Furthermore, the Office's rationale that Zawoad's traffic-based analysis would "bolster" Jakobsson's reputation score is conclusory and lacks the required articulated reasoning with rational underpinning. The cited portions of Zawoad describe generating a maliciousness score for network identifiers using a machine learning model trained on features derived from malicious activity information, including web traffic data. [2][a] There is no disclosure or suggestion that such traffic metrics are indicative of authenticity of a marketplace, [b] nor that they would meaningfully improve the transaction-level verification processes described in Jakobsson. [3] The proposed modification would therefore require substantial redesign of Jakobsson 's system to incorporate unrelated domain-level analytics, which goes beyond a simple substitution or predictable use of prior art elements. (p. 19; emphasis changed from original; bracketed numerals added to facilitate discussion below)
In response:
As for sentence [1]:
Jakobsson performs a risk analysis based on various risk factors. On its face, adding to Jakobsson's risk analysis the risk analysis of an additional risk factor taught by Zawoad and not taught by Jakobsson, all other things being equal, bolsters/ compliments Jakobsson's risk analysis so as to improve it and thus improve security.
As for [2][a]: the references were not cited as teaching this, nor does the combination require that they teach it. Again, this point of Applicant's merely reflects the fact that the rejection is a combination -- the rejection combines (or applies) Zawoad's traffic metrics with (to) Jakobsson, which addresses authenticity of a marketplace.
As for [2][b], this point has been addressed above:
The references were not cited as teaching this, nor does the combination require that they teach it. Jakobsson performs a risk analysis for a website transaction based on various risk factors. On its face, adding to Jakobsson's risk analysis the risk analysis of an additional risk factor pertaining to websites, which is taught by Zawoad and not taught by Jakobsson, all other things being equal, bolsters/compliments Jakobsson's risk analysis so as to improve it and thus improve security.
As for sentence [3], as stated, the combination merely adds to Jakobsson's risk analysis the risk analysis of an additional factor taught by Zawoad. This does not require redesign of Jakobsson's system but is merely a simple combination of known elements, as well as an improvement by virtue of adding analysis of an additional risk factor (of Zawoad) into Jakobsson's analysis. Applicant provides no explanation of why/ how this combination would require a redesign of Jakobsson; accordingly, Applicant's assertion appears to be merely conclusory. Note also that the rejection did not assert that the combination is a substitution of elements.
The paragraph bridging pages 19 and 20 is a conclusion paragraph and does not present new substantive content. In response to this paragraph: as discussed above, Jakobsson does teach evaluating a marketplace (see (i), p. 20), and Jakobsson and Zawoad were not cited as teaching the amended claim language (see (ii) and (iii), p. 20), although they do teach respective portions of the amended claim language as explained above.
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, 3-10 and 12-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1, 3-10 and 12-18 are directed to a method or system, which are/is one of the statutory categories of invention. (Step 1: YES)
Claims 1 and 10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite a method and system for determining whether an NFT is authentic (as per the specification, to permit users to avoid making fraudulent purchases, where the inauthentic NFT lacks the value falsely attributed to it, see 0002-0005).
For claims 1 and 10 (claim 1 being deemed representative), the limitations (indicated below in bold) of:
receiving, by a receiver of a processing server, a scoring request for the NFT including at least one of the NFT or an identification value associated with the NFT;
performing, by a processor of the processing server, network traffic analysis of a marketplace that includes at least one of a webpage and an application program where the NFT is available for purchase, wherein said network traffic analysis includes analysis of at least (i) a number of unique visitors accessing the at least one of the webpage and the application program and (ii) visitor frequency;
based on one or more marketplace metrics including at least said network traffic analysis, domain registration data, social media traffic and popularity rankings, determining, by the processor of the processing server, a marketplace authenticity score for the marketplace;
determining, by the processor of the processing server, a visual authenticity score for the NFT based on at least a comparison of one or more visual features of the NFT to visual features of a plurality of trusted existing NFTs indicating the likelihood that the NFT is a copy of an already existing NFT;
determining, by the processor of the processing server, a wallet authenticity score for a blockchain wallet associated with ownership of the NFT based on at least a transaction history for the blockchain wallet, said wallet authenticity score representing a likelihood that the blockchain wallet is genuine and is either a creator of the NFT or an authorized owner;
subsequent to determining the marketplace authenticity score, the visual authenticity score and the wallet authenticity score calculating, by the processor of the processing server, a confidence score for the NFT based on a combination of at least the determined marketplace authenticity score, the visual authenticity score, and the wallet authenticity score, wherein the confidence score represents a likelihood that the NFT is authentic; and
transmitting, by a transmitter of the processing server, the calculated confidence score in response to the received scoring request.
as drafted, constitute a process that, under the broadest reasonable interpretation, covers "certain methods of organizing human activity," specifically, "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components or generally linking the use of a judicial exception to a particular technological environment or field of use. The Examiner notes that "fundamental economic practices" or "fundamental economic principles" describe concepts relating to the economy and commerce, including hedging, insurance, and mitigating risks, and "commercial interactions" or "legal interactions" include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. MPEP 2106.04(a)(2)II.A.,B. If a claim limitation, under its broadest reasonable interpretation, covers "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components or generally linking the use of a judicial exception to a particular technological environment or field of use, then it falls within the "certain methods of organizing human activity" grouping of abstract ideas. Accordingly, claims 1 and 10 recite an abstract idea. (Step 2A - Prong 1: YES. The claims recite an abstract idea.)
This judicial exception is not integrated into a practical application. Claims 1 and 10 recite the additional elements of a receiver of a processing server, a processor of the processing server, network traffic [analysis], a marketplace that includes at least one of a webpage and an application program, accessing the at least one of the webpage and the application program, social media traffic, a blockchain wallet, and a transmitter of the processing server (the foregoing recited by claims 1 and 10); a marketplace and a processing server (the foregoing additionally recited by claim 10), that implement the abstract idea. These additional elements are not described by the applicant and they are recited at a high level of generality (i.e., one or more generic computer elements performing generic computer functions), such that they amount to no more than mere instructions to apply the exception using generic computer elements (all additional elements) and/or generally linking the use of a judicial exception to a particular technological environment or field of use (marketplace, network traffic, social media traffic, blockchain wallet). Accordingly, even in combination these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (Step 2A - prong 2: NO. The additional elements do not integrate the abstract idea into a practical application.)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a receiver of a processing server, a processor of the processing server, network traffic [analysis], a marketplace that includes at least one of a webpage and an application program, accessing the at least one of the webpage and the application program, social media traffic, a blockchain wallet, and a transmitter of the processing server (the foregoing recited by claims 1 and 10); a marketplace and a processing server (the foregoing additionally recited by claim 10), to perform the noted steps amount to no more than mere instructions to apply the exception using generic computer elements and/or generally linking the use of a judicial exception to a particular technological environment or field of use. Mere instructions to apply an exception using generic computer elements or generally linking the use of a judicial exception to a particular technological environment or field of use cannot provide an inventive concept ("significantly more"). Accordingly, even in combination, these additional elements do not provide significantly more. As such, claims 1 and 10 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more.)
Dependent claims 3-9 and 12-18 are similarly rejected because they further define/narrow the abstract idea of independent claims 1 and 10 as discussed above, and/or do not integrate the abstract idea into a practical application or provide an inventive concept such as would render the claims eligible, whether each is considered individually or as an ordered combination.
As for further defining/narrowing the abstract idea:
Dependent claims 3-6 and 12-15 merely describe how the marketplace authenticity score is determined.
Dependent claims 7 and 16 merely describe the comparison of visual features of the NFT.
Dependent claims 8 and 17 merely describe determining a transaction authenticity score and how the confidence score is determined.
Dependent claims 9 and 18 merely describe how the wallet authenticity score is determined.
As for additional elements:
Claims 4, 5, 13 and 14 recite “the marketplace” and “a plurality of trusted marketplaces.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element (marketplace, plurality of trusted marketplaces) and/or generally linking the use of a judicial exception to a particular technological environment or field of use (marketplace, plurality of trusted marketplaces). Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 6 and 15 recite “the marketplace,” and “a database of trusted marketplaces.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element (marketplace, database of trusted marketplaces) or generally linking the use of a judicial exception to a particular technological environment or field of use (marketplace, trusted marketplaces). Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 8 and 17 recite “the processor of the processing server.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 9 and 18 recite “the blockchain wallet,” and “a database of suspicious wallets.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element (blockchain wallet, database of suspicious wallets) or generally linking the use of a judicial exception to a particular technological environment or field of use (blockchain wallet, suspicious wallets). Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 3, 7, 12 and 16 do not recite any additional elements, and accordingly, for the reasons provided above with respect to the independent claims, are not patent eligible.
Therefore, dependent claims 3-9 and 12-18 are not patent eligible.
Claim Rejections - 35 USC § 103
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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 nonobviousness.
Claims 1, 4, 6, 8-10, 13, 15, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Jakobsson et al. (U.S. Patent Application Publication No. 2023/0006976 A1), hereafter Jakobsson, in view of Zawoad et al. (U.S. Patent Application Publication No. 2019/0387005 A1), hereafter Zawoad.
Regarding Claims 1 and 10
Jakobsson teaches:
receiving, by a receiver of a processing server, a scoring request for the NFT including at least one of the NFT or an identification value associated with the NFT; (0020; 0280, Fig. 18, receive tokens (NFTs) as inputs to determine a confidence score as to whether token is deceptive (inauthentic) or not; 0144 "When the user wishes to purchase an NFT using fungible tokens, media wallet applications can request authentication of the NFT"; note: such request necessarily identifies the NFT (including at least one of the NFT or an identification value associated with the NFT); note: per 0022, 0026, 0119, 0122-0123, see also 0104, 0108, 0226, 0279, 0280, 0282, 0283, 0303, 0326 (as cited and explained for claims 9 and 18 below), authentication (verification) involves scoring, therefore the request is a scoring request for the NFT; 0120-0121 "[0120] …security platforms process P … receiving requests from a wallet to transfer ownership of one or more tokens, performing a verification and, conditional on the outcome of the verification, determining whether to approve the ownership transfer. [0121] In many embodiments of the security platforms, the process of performing a verification/approval can include one or more of … (c) detecting inconsistencies associated with the transfer, such as an offer of a token for sale by a first party different from a second party that the content service understands to be the proper owner, (d) querying one or more databases in order to determine whether or not any smart contract is listed in a database as being malicious or “legitimate”, … (f) displaying a message to a current owner of the digital asset, wherein the message identifies the transfer request and at least some of the terms of the transfer and receiving a response thereto from the current owner, (g) determining a discrepancy between a value of the digital asset and an offered price for the digital asset, …." note: the request for transferring ownership is also a request for performing verification, which, per 0022, 0026, 0119, 0122-0123, see also 0104, 0108, 0226, 0279, 0280, 0282, 0283, 0303, 0326 (as cited and explained for claims 9 and 18 below), involves scoring, therefore the request is a scoring request for the NFT; note: performance of the above-indicated items (c), (d), (f), (g) require identification of the NFT, therefore, the request must have included at least one of the NFT or an identification value associated with the NFT; 0418 "receiving requests from the security platforms to determine the safety of a given pending transaction"; 0323; 0410; 0414; 0423, Fig. 31, 3110)
… a marketplace that includes at least one of a webpage and an application program where the NFT is available for purchase, …; (0263 "In particular, in an attack, an attacker can impersonate a trusted entity, such as a marketplace …. The criminal may either initiate communication with the intended victim, or create an advertisement, e.g., on Craigslist™, Amazon™ or marketplaces developed for selling of NFTs, …."; 0425 "In several embodiments, security platforms can be implemented in a browser by means of which a user interacts with his/her wallet and/or a marketplace for trading NFTs." -- "browser" indicates website; 0422 "The security platforms may include processes that … detect risk of fraudulent activity based upon characteristics of a market(s)")
based on one or more marketplace metrics including at least … domain registration data, social media traffic …, determining, by a processor of the processing server, a marketplace authenticity score (0268-0270 "reputation score" and/or "complaint score") for a marketplace; (0422 "The security platforms may include processes that … detect risk of fraudulent activity based upon characteristics of a market(s)" (marketplace metrics); 0263, 0268-0270: score (e.g., reputation score and/or complaint score) indicating likelihood of impersonation of identity as taught in 0268-0270 applies not only to seller/creator/owner but also to trusted entities generally, including marketplace as per 0263, thus the score is a marketplace authenticity score; the score is based on various factors (0268, 0270 "different types of information") including "a large number of social media posts" (0269) (social media traffic); regarding domain registration data: the score may be based on based in part on comparison of (e.g., spelling/misspelling of) entity/party names (e.g., "CarniverousElephant" versus "CarniveruosElephant") where, per 0002, the entity subject to impersonation can be a webpage or domain name (relatedly, see 0281-0283 "Acme Inc." versus "Acme 1nc."), thus teaching domain registration data)
determining, by the processor of the processing server, a visual authenticity score (0040 "similarity score") for the NFT based on at least a comparison of one or more visual features of the NFT to visual features of a plurality of trusted existing NFTs indicating the likelihood that the NFT is a copy of an already existing NFT; (0032, 0037, 0040 "[0032] … performs a verification to authenticate at least one of the first token and the second token using a similarity aspect associated with the first token and the second token. … [0037] In still a further embodiment still, the similarity aspect corresponds to a verification of visual similarity."; 0272 "To address these types of activities, in many embodiments, security platforms can create a registry of NFTs and compare newly observed NFTs to the entries in the registry. For example, the registry may include one entry related to NFT A2, where the entry includes a collection of metrics related to the associated artwork A1. The metrics can include a Fast Fourier Transform (FFT) of A1, a cryptographic hash of A1, a fuzzy hash related to A1, a spectrometry representation of A1, among various other metrics. … Many embodiments of the security platforms may use metrics similar to those used for copyright infringement on social media, detection of modifications of media, as is used in automated fake news detection, …. An example approach to detect forged imagery, …." (based on at least a comparison of one or more visual features of the NFT to visual features of a plurality of trusted existing NFTs indicating the likelihood that the NFT is a copy of an already existing NFT); 0105 teaches content similar to 0272; 0305 "identify what tokens, among a collection of similar tokens, is most likely to be an original," i.e., identifies trusted existing tokens (NFTs), and performs similarity assessments (comparisons) between a given token and such other trusted existing tokens, indicating the likelihood that the NFT is a copy of an already existing NFT; 0271-0272, 0274 note: registry of NFTs teaches plurality of trusted existing NFTs)
determining, by the processor of the processing server, a wallet authenticity score (0064, 0123 "risk score") for a blockchain wallet associated with ownership of the NFT based on at least a transaction history for the blockchain wallet, said wallet authenticity score representing a likelihood that the blockchain wallet is genuine and is either a creator of the NFT or an authorized owner; (0022, 0064-0065 (in reference to 0059), 0104, 0123, risk score based on transaction history, 0326, 0419; regarding authorized owner: 0123, 0419 "owning wallet," regarding genuine: verification of identity / preventing fraud indicates likelihood that wallet is genuine)
subsequent to determining the marketplace authenticity score, the visual authenticity score and the wallet authenticity score calculating, by the processor of the processing server, a confidence score for the NFT based on a combination of at least the determined marketplace authenticity score, the visual authenticity score, and the wallet authenticity score, wherein the confidence score represents a likelihood that the NFT is authentic; and (0302-0303 "mesh of certifications … such meshes can be used in the context of other assessments of importance. Such a structure can be referred to as a token mesh as described. … it can be desirable to form recommendation meshes. … a mesh of recommendations can be commonly combined with a mesh of certifications. [0303] … generate an assessment from a mesh, whether of certificate tokens, recommendation tokens, and/or other tokens such as inheritance tokens, or a combination of such, … In several embodiments of the security platforms, the weights may be used in artificial intelligence (AI) assessments of complex meshes, where the assessment generates one or more scores. Scores in accordance with numerous embodiments of the invention may include (but are not limited to) cumulative trust scores related to certification, cumulative quality scores related to recommendation, and/or cumulative combinations of scores, corresponding, for example, to an estimated benevolence of a token in the context of a given environment." Here Jakobsson is deemed to be referring to scores taught elsewhere throughout the document and, in any event, it would be obvious to combine embodiments, i.e., combine the embodiment described in 0302-0303 with the embodiments describing the marketplace authenticity score (reputation score or complaint score) (0268-0270) and the embodiments describing the wallet authenticity score (risk score) (0064, 0123), because the combination would carry out Jakobsson's purpose of providing security against fraud/abuse that is based on deception (positing a false identity) (see e.g., title, 0022, 0032-0040, 0059-0065), by using scores reflecting appropriate substantive measures in calculating a cumulative score. Regarding "confidence" score: 0280 teaches a confidence score determined from reputation and other data, and in this context states "a variety of assessments can be made, as will be understood by skilled artisans"; again, it would be obvious to combine embodiments, i.e., combine the embodiment described in 0302-0303 with the embodiment described in 0280, to arrive at the cumulative combination in 0302-0303 being a confidence score determined from reputation and other data, because the cumulative combination in 0302-0303 is indeed a measure of confidence, and the description of a confidence score in 0280 ("a variety of assessments can be made") suggests that the confidence score is a cumulative combination of scores; regarding subsequent to determining the marketplace authenticity score, the visual authenticity score and the wallet authenticity score calculating: the combining of scores as taught by Jakobsson can only occur after the scores being combined have been determined)
transmitting, by a transmitter of the processing server, the calculated confidence score in response to the received scoring request. (0280, Fig. 18, "determine confidence score" and "output alerts and notifications"; 0428 "the verification may quickly return a reliable result of the verification, wherein a user may rest assured that they should not go ahead with the transfer of ownership e.g., by means of getting notified about the result of the verification and optionally having to disapprove or stop the transaction"; 0322, 0412 transmit information, i.e., of "the method [for mitigating abuse of a digital asset (NFT)] described herein")
(claim 10) a blockchain wallet associated with ownership of the NFT; (Fig. 13, e.g., 0198, Fig. 30, e.g., 0408, 0140-0141, 0149)
(claim 10) a marketplace; and (0422, 0260, 0263, 0281, 0283)
(claim 10) a processing server (Fig. 11, 0020, 0048, 0120, 0423)
Jakobsson does not explicitly disclose but Zawoad teaches:
performing, by a processor of the processing server, network traffic analysis of a … that includes at least one of a webpage and an application program (0022 "analyze performance of a website") …, wherein said network traffic analysis includes analysis of at least (i) a number of unique visitors accessing the at least one of the webpage and the application program (0022 "estimated average of daily unique visitors") and (ii) visitor frequency (0022 "frequency of visits"); (0022; regarding by a processor of the processing server: "web traffic reporting provider," which performs the analysis in 0022, is a third-party server, as taught by 0035, and the term "server" (0015) is understood by a person having ordinary skill in the art to include a processor that performs the analysis)
… including at least said network traffic analysis, domain registration data, … and popularity metrics …; (regarding network traffic analysis: 0022 web traffic information (e.g., "average of daily unique visitors" and "frequency of visits") is per 0023 a kind of malicious activity information; regarding domain registration data: 0023 malicious activity information includes list of malicious URLs associated with a network domain name; regarding popularity metrics: 0023, 0083, 0110-0111 malicious activity information or features include popularity score or page rank that reflects popularity; regarding all the foregoing, the malicious activity information is used to determine authenticity of website, see, e.g., 0027, 0029, 0031-0032, 0040, 0046, 0083-0084) (Note Zawoad's teaching of "domain registration data" is cited as an alternative teaching to that of Jakobsson cited above.)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified Jakobsson's systems and methods for preventing deception/abuse in tokenized environments, by incorporating therein these teachings of Zawoad regarding network traffic analysis, domain registration data, and popularity metrics, because these data as taught by Zawoad represent malicious activity information and correspondingly a maliciousness score that reflects a level of risk that a website is malicious/fraudulent/inauthentic (e.g., 0024-0025), and therefore the incorporation of the analysis of these data into Jakobsson's analysis of other relevant data would complement/bolster the marketplace reputation score and other metrics obtained and employed by Jakobsson to prevent deception/ abuse (and thus the combination, by bringing to bear a more comprehensive/robust set of relevant data, would improve upon the results otherwise obtained by Jakobsson), see also Jakobsson, 0002, 0006, 0101, MPEP 2143.I.C.,D.
Regarding Claims 4 and 13
Jakobsson in view of Zawoad teaches the limitations of base claims 1 and 10 as set forth above. Jakobsson further teaches:
wherein the marketplace authenticity score (0281-0283 risk score or second risk score) is further based on a comparison of one or more visual features (e.g., logo, color palette, etc.) of the marketplace to visual features of a plurality of trusted marketplaces. (0002, 0281-0283; note per 0281 the discussion of 0281-0283 pertains to service providers, i.e., marketplace, also per 0263 the discussion of 0281-0283 pertains to marketplace; note although the discussion of 0281-0283 highlights marketplace features present in an email, 0002 teaches that the features may also be present in a webpage)
Regarding Claims 6 and 15
Jakobsson in view of Zawoad teaches the limitations of base claims 1 and 10 as set forth above. Jakobsson further teaches:
wherein the marketplace authenticity score is further based on whether or not the marketplace is identified in a database of trusted marketplaces. (0427 "user may select a use for the security platforms for one or more types of transactions, such as … transactions that are in response to requests from parties that are not whitelisted with the security platforms, and/or with a wallet"; note: Jakobsson's "parties" includes marketplace, as demonstrated by, e.g., (i) 0422 "The security platforms may include processes that … detect risk of fraudulent activity based upon characteristics of a market(s), an origination wallet(s), a destination wallet(s), previous transaction(s), among various others," (ii) 0260, 0263, 0281 the entities (parties) subject to impersonation abuse that Jakobsson is directed to addressing include applications that access/include NFTs, middlemen who buy/sell NFTs, marketplace, service provider (all of which teach marketplace), and (iii) 0283 entity (party) may be seller of Acme products (marketplace) rather than Acme itself (owner/creator); note the term "whitelist" indicates a database of trusted entities; 0428 "query a database including … lists of malicious smart contracts and/or user identities and find out that the imminent transfer is associated with a malicious smart contract and/or a user identity being known for criminal actions"; 0121 "the process of performing a verification/approval can include one or more of … (d) querying one or more databases in order to determine whether or not any smart contract is listed in a database as being malicious or “legitimate"; 0414; regarding Jakobsson's "smart contracts" in 0428, 0121, 0414, note 0110 "an owner/creator or other party to an NFT may specify contractual conditions, such as in a smart contract or associated metadata, under which an NFT may change ownership," that is to say, the smart contract may reference an other party to an NFT (e.g., a marketplace))
Regarding Claims 8 and 17
Jakobsson in view of Zawoad teaches the limitations of base claims 1 and 10 as set forth above. Jakobsson further teaches:
determining, by the processor of the processing server, a transaction authenticity score based on at least a transaction history for a transaction account associated with the NFT, wherein the confidence score is further based on the transaction authenticity score. (0022, 0064-0065, 0104, 0123, 0268-0270 reputation score and/or complaint score based on transaction history of seller/owner CarniveruosElephant, 0318, 0326, 0419; note that 0022, 0104, 0268 and 0270 teach multiple reputation scores and multiple complaint scores, such that the marketplace authenticity score can be taught by one of these and the transaction authenticity score can be taught by another one of these)
Regarding Claims 9 and 18
Jakobsson in view of Zawoad teaches the limitations of base claims 1 and 10 as set forth above. Jakobsson further teaches:
wherein the wallet authenticity score is further based on whether or not the blockchain wallet is identified in a database of suspicious blockchain wallets. (0282 "verification includes identifying the payee [wallet associated with ownership of NFT] …, to determine whether the associated party [i.e., the payee] is associated with high risk [suspicious], as described. This can be done using certification tokens, reputation tokens, and/or databases indicating past activity, past complaints, and more. A risk score can be generated …."; 0428 "query a database including … lists of malicious smart contracts and/or user identities and find out that the imminent transfer is associated with a malicious smart contract and/or a user identity being known for criminal actions"; 0427 "A user may select a use for the security platforms for one or more types of transactions, such as … transactions that are in response to requests from parties that are not whitelisted with the security platforms; 0121 "the process of performing a verification/approval can include one or more of … (d) querying one or more databases in order to determine whether or not any smart contract is listed in a database as being malicious or “legitimate"; 0414; regarding Jakobsson's "smart contracts" in 0428, 0121, 0414, note 0110 "an owner/creator or other party to an NFT may specify contractual conditions, such as in a smart contract or associated metadata, under which an NFT may change ownership," that is to say, the smart contract references the owner/creator (wallet associated with ownership of NFT); note per 0022, 0026, 0119, 0122-0123 verification process uses scores (e.g., reputation scores, complaint scores, assessment scores, risk scores, etc.), thus the teachings that the verification involves the wallet being identified in a database teaches that the score is based on the wallet being identified in a database), see also 0104, 0108, 0226, 0279, 0280, 0282, 0283, 0303, 0326, teaching also inter alia that verification process uses certification tokens which in turn involve scoring, such that the teachings that the verification involves the wallet being identified in a database teaches that the score is based on the wallet being identified in a database)
Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Jakobsson et al. (U.S. Patent Application Publication No. 2023/0006976 A1), hereafter Jakobsson, in view of Zawoad et al. (U.S. Patent Application Publication No. 2019/0387005 A1), hereafter Zawoad, and further in view of Hearty et al. (U.S. Patent Application Publication No. 2021/0042757 A1), hereafter Hearty.
Regarding Claims 3 and 12
Jakobsson in view of Zawoad teaches the limitations of base claims 1 and 10 as set forth above. Jakobsson further teaches:
… marketplace …. (0002, 0281-0283; teaches marketplace in context of generation of risk score based on fraud risk feature values (e.g., spelling/misspelling of) entity/party names (e.g., "Acme Inc." versus "Acme 1nc."); although the discussion of 0281-0283 highlights the comparison in the context of an email, 0002 teaches that it may also occur in the context of a webpage or domain name; per 0263 and 0425, marketplace may be webpage)
Jakobsson in view of Zawoad does not explicitly disclose but Hearty teaches:
wherein the … authenticity score is determined using an Extreme Gradient Boosting model. (0040, claim 3)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Jakobsson's systems and methods for preventing deception/abuse in tokenized environments, as modified by Zawoad's teachings regarding network traffic analysis, domain registration data, and popularity metrics, by incorporating therein these teachings of Hearty regarding using Extreme Gradient Boosting to determine a fraud score based on analyzing fraud risk feature values, (i) because Jakobsson uses machine learning (e.g., 0326) including gradient boosting (0360) and accordingly Hearty's teachings are in the spirit of Jakobsson, (ii) because the combination would improve upon the results otherwise obtained by Jakobsson since Hearty's teachings represent an advanced machine learning analysis, and (iii) because the combinations are merely a matter of (A) Combining prior art elements according to known methods to yield predictable results; and/or (B) Simple substitution of one known element (Hearty's XGB ML analysis) for another (Jakobsson's non-XGB ML analysis) to obtain predictable results; as well as (C) Use of known technique to improve similar devices (methods, or products) in the same way; and (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results. See Jakobsson, 0002, 0006, 0101, Hearty, 0002, 0007, MPEP 2143.I.A.,B.,C.,D.
Claims 5, 7, 14 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Jakobsson et al. (U.S. Patent Application Publication No. 2023/0006976 A1), hereafter Jakobsson, in view of Zawoad et al. (U.S. Patent Application Publication No. 2019/0387005 A1), hereafter Zawoad, and further in view of Suk (U.S. Patent Application Publication No. 2023/0145439 A1).
Regarding Claims 5 and 14
Jakobsson in view of Zawoad teaches the limitations of base claims 1 and 10 and intervening claims 4 and 13 as set forth above. Jakobsson further teaches:
… the marketplace … marketplaces …. (0002, 0281-0283 teaches marketplace in context of comparing visual features (e.g., logo, color palette, etc.); note per 0281 the discussion of 0281-0283 pertains to service providers, i.e., marketplace, also per 0263 the discussion of 0281-0283 pertains to marketplace; note although the discussion of 0281-0283 highlights marketplace features present in an email, 0002 teaches that the features may also be present in a webpage; per 0263 and 0425, marketplace may be webpage)
Jakobsson in view of Zawoad does not explicitly disclose but Suk teaches:
wherein the comparison of the one or more visual features of … to visual features of a plurality of trusted … uses one of: a Siamese model, a Deep Learning model, and Feature Maps. (0050-0056 (e.g., 0056), 0063-0064 (for context see 0060-0067))
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Jakobsson's systems and methods for preventing deception/abuse in tokenized environments, as modified by Zawoad's teachings regarding network traffic analysis, domain registration data, and popularity metrics, by incorporating therein these teachings of Suk regarding using CNN deep learning for determining/ analyzing similarity of visual images, (i) because Jakobsson uses machine learning (e.g., 0326) and accordingly Suk's teachings are in the spirit of Jakobsson, (ii) because the combination would improve upon the results otherwise obtained by Jakobsson since Suk's teachings represent an advanced visual image similarity analysis, and (iii) because the combinations are merely a matter of (A) Combining prior art elements according to known methods to yield predictable results; and/or (B) Simple substitution of one known element (Suk's (visual) image similarity analysis) for another (Jakobsson's visual (image) similarity analysis) to obtain predictable results; as well as (C) Use of known technique to improve similar devices (methods, or products) in the same way; and (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results. See Jakobsson, 0002, 0006, 0101, Suk, 0002-0005, MPEP 2143.I.A.,B.,C.,D.
Regarding Claims 7 and 16
Jakobsson in view of Zawoad teaches the limitations of base claims 1 and 10 as set forth above. Jakobsson in view of Zawoad does not explicitly disclose but Suk teaches:
wherein the comparison of the one or more visual features of the NFT to visual features of a plurality of trusted NFTs uses one of: a Siamese model, a Deep Learning model, and Feature Maps. (0050-0056, 0063-0064 (for context see 0060-0067))
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Jakobsson's systems and methods for preventing deception/abuse in tokenized environments, as modified by Zawoad's teachings regarding network traffic analysis, domain registration data, and popularity metrics, by incorporating therein these teachings of Suk regarding using CNN deep learning for determining/ analyzing similarity of visual images, (i) because Jakobsson uses machine learning (e.g., 0326) and accordingly Suk's teachings are in the spirit of Jakobsson, (ii) because the combination would improve upon the results otherwise obtained by Jakobsson since Suk's teachings represent an advanced visual image similarity analysis, and (iii) because the combinations are merely a matter of (A) Combining prior art elements according to known methods to yield predictable results; and/or (B) Simple substitution of one known element (Suk's (visual) image similarity analysis) for another (Jakobsson's visual (image) similarity analysis) to obtain predictable results; as well as (C) Use of known technique to improve similar devices (methods, or products) in the same way; and (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results. See Jakobsson, 0002, 0006, 0101, Suk, 0002-0005, MPEP 2143.I.A.,B.,C.,D.
Conclusion
The prior art made of record and not relied upon, as set forth in the accompanying Notice of References Cited (PTO-892), is considered pertinent to applicant's disclosure. Among the cited references:
Goldston (US-20220374503-A1) teaches subject matter similar to that taught by Jakobsson (primary reference hereinabove).
Emanuel (US-20240256741-A1) teaches using Extreme Gradient Boosting to determine whether an NFT is an original or a duplicate.
Cancel (US-20080189254-A1) (e.g., 0013) and Jiang (US-20190334948-A1) (e.g., 0081) teach subject matter similar to that taught by Zawoad (secondary reference) as set forth hereinabove.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS W PINSKY whose telephone number is (571)272-4131. The examiner can normally be reached on 8:30 am - 5:30 pm ET.
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, Jessica Lemieux can be reached on 571-270-3445. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DOUGLAS W PINSKY/
Examiner, Art Unit 3626
/JESSICA LEMIEUX/Supervisory Patent Examiner, Art Unit 3626
Prosecution Insights