DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Application No. 19/095,756 filed on 03/31/2025.
Claims 1-20 have been examined and are pending in this application.
Priority
Acknowledgment is made of Applicant’s claim for priority under 35 U.S.C. 120 to parent Application No. 17/843,713, filed on 06/17/2022.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,294,643. Although the claims at issue are not identical, they are not patentably distinct from each other because claim(s) 1-20 are broader and similar in scope to claim(s) 1-20 in U.S. Patent No. 12,294,643 (see table below). If the claims in Application No. 19/095,756 are allowed, it could improperly extend the “right to exclude” for the same invention in two different Patents.
Claims 1-20 are directed to a computer-implemented method, a computer storage medium, and a computer system; said computer-implemented method, computer storage medium, and computer system are associated with the computer-implemented method and computer storage medium claimed in claim(s) 1-20 of the U.S. Patent No. 12,294,643.
The subject matter claimed in the instant application is fully disclosed in U.S. Patent No. 12,294,643 and is covered by U.S. Patent No. 12,294,643 since U.S. Patent No. 12,294,643 and the instant application are claiming common subject matter, as follows:
Application No.: 19/095,756 (Instant App.)
US Patent No.: 12,294,643
Claim 1: A computer-implemented method for populating a blockchain-focused knowledge repository, the method comprising: obtaining a detection seed; determining that the detection seed is associated with a target blockchain context; storing the detection seed in a knowledge repository along with metadata identifying the target blockchain context; searching at least one content source associated with the target blockchain context for at least one additional content item related to the detection seed; retrieving data describing relationships between the detection seed and the at least one additional content item; classifying at least a portion of the at least one additional content item based on its relationship to the detection seed; and updating the knowledge repository with the classified at least one additional content item and associated relationships.
Claim 1: A computer-implemented method comprising:
receiving a first content item;
extracting first metadata from the first content item;
detecting a match between the first metadata and at least one predetermined metadata element in a knowledge repository pertaining to a target blockchain context;
determining a first blockchain wallet address associated with the first content item;
providing the first blockchain wallet address to a blockchain search engine;
receiving from the blockchain search engine a second blockchain wallet address having a transactional relationship to the first blockchain wallet address recorded in a blockchain searchable by the blockchain search engine;
querying at least one content source based on the second blockchain wallet address;
responsive to querying the at least one content source based on the second blockchain wallet address, receiving the second content item from the at least one content source;
extracting second metadata from the second content item; and
updating the knowledge repository based on the second metadata extracted from the second content item.
Claim 19: A computer storage medium embodying computer-readable instructions configured, when executed on at least one computer processor, to cause the at least one computer processor to: obtain a detection seed; determine that the detection seed is associated with a target blockchain context; store the detection seed in a knowledge repository along with metadata identifying the target blockchain context; search at least one content source associated with the target blockchain context for at least one additional content item related to the detection seed; retrieve data describing relationships between the detection seed and the at least one additional content item; classify at least a portion of the at least one additional content item based on its relationship to the detection seed; and update the knowledge repository with the classified at least one additional content item and associated relationships.
Claim 12: A computer storage medium embodying computer-readable instructions configured, when executed on at least one computer processor, to cause the at least one computer processor to:
receive a first content item;
extract first metadata from the first content item;
detect a match between the first metadata and at least one predetermined metadata element in a knowledge repository pertaining to a target blockchain context;
determine a first blockchain wallet address associated with the first content item;
provide the first blockchain wallet address to a blockchain search engine;
receive from the blockchain search engine a second blockchain wallet address having a transactional relationship to the first blockchain wallet address recorded in a blockchain searchable by the blockchain search engine;
query at least one content source based on the second blockchain wallet address;
responsive to querying the at least one content source based on the second blockchain wallet address, receive the second content item from the at least one content source;
extract second metadata from the second content item; and
update the knowledge repository based on the second metadata extracted from the second content item.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
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.
Claim(s) 1-5, 8-14, and 17-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kim et al. (US 2022/0101326; Hereinafter “Kim”).
Regarding claim 1, ** teaches a computer-implemented method for populating a blockchain-focused knowledge repository, the method comprising:
obtaining a detection seed (Kim: Fig. 8-9, Para. [0252], Step S810 is explained in detailed with reference to FIG. 9. At a step S902, content of a tweet reply is retrieved. Alternatively, content of a plurality of tweet replies are retrieved and scheduled for investigation, where each tweet reply is identifiable by a tweet ID. At a step S904, tweet content (or replies) of a twitter account is checked for key words (such as send, airdrop, wallet) stored in TRDB. [detection seed may include keyword or text string] Para. [0272], Para. [0232],);
determining that the detection seed is associated with a target blockchain context (Kim: Fig. 8-9, Para. [0252], At a step S904, tweet content (or replies) of a twitter account is checked for key words (such as send, airdrop, wallet) stored in TRDB. It is possible for a user and/or a Sentinel to add, remove or edit keywords to be checked through the tweet content using a Keyword Management Feature of the TRDB. Typical keyword search algorithms (such as exact matches, partial matches, keyword search using wildcard and the like) may also be used to determine if there are any keyword(s) detected in a tweet reply by the Twitter Crawler System. Para. [0260], At a step S908, tweet content is also checked for URL links. For every URL detected in each tweet, the respective URL link is expanded and redirected, for example, through a sandbox at a step S910 to retrieve corresponding HTML code. Subsequently, at a step S912, after retrieving HTML code corresponding to the redirected URL link, the Twitter Crawler System is configured to check if the retrieved HTML codes include any malicious patterns defined in the TRDB. Some examples of malicious patterns are detection of text strings such as “verify your address”, “copy address to clipboard”, and “waiting for your payment”. Para. [0253], Subsequently, at a step S906, tweet content is also checked for presence of a wallet address. In one example, using regex, wallet address of a prescribed format can be detected.). Some examples of the prescribed formats are listed below: [target blockchain context may include wallet address that is associated with Blockchain Context] Para. [0260], If the Twitter Crawler System detects a possible threat, it is configured to scan the HTML for wallet address (can be ETH address, Bitcoin Address, or the link) at a step S914 and/or to take a screenshot of the site at a step S916. Para. [0261], At a step S918, the Twitter crawler system is configured to execute a program (instructions) stored in a memory to determine if a tweet reply to an influencer twitter account that is stored in the TRDB for monitoring fulfils any one of the conditions to flag a suspicious tweet.);
storing the detection seed in a knowledge repository along with metadata identifying the target blockchain context (Kim: Para. [0082], The data validated/evaluated by the Sentinel may be stored as a data block in the Blockchain network. For instance, the validated/evaluated data may be stored in a Threat Reputation Database. Such Threat Reputation Database may be committed on a Blockchain, for instance, an EOS Blockchain. An example on the EOS Block chain is https://eosflare.io/account/eosioupptrdb. In one example, the threat reputation database may support threat data comprising Crypto Wallet Addresses, Domains, Hostnames, IP addresses, URLs and the like. Para. [0111], [0232], [0247]-[0252]);
searching at least one content source associated with the target blockchain context for at least one additional content item related to the detection seed (Kim: Para. [0232], In one example, at a step S806, all tweet replies for all monitored influencers are retrieved at S806. Para. [0251], For instance, only when the tweet reply is determined to contain at least one keyword stored in TRDB and at least one URL, and if the detected URL of the tweet reply is determined to include at least one malicious html pattern stored in the TRDB, the tweet reply is flagged as potentially malicious. Using a combination of conditions can lower a rate of detection of false positives. The above conditions can be termed collectively in the present disclosure as conditions to flag suspicious tweets. Para. [0261], Para. [0262]-[0265]);
retrieving data describing relationships between the detection seed and the at least one additional content item (Kim: Para. [0232], In one example, at a step S806, all tweet replies for all monitored influencers are retrieved at S806. Para. [0261], At a step S918, the Twitter crawler system is configured to execute a program (instructions) stored in a memory to determine if a tweet reply to an influencer twitter account that is stored in the TRDB for monitoring fulfils any one of the conditions to flag a suspicious tweet. The conditions to flag a suspicious tweet are. Para. [0251], Para. [0262]-[0265]);
classifying at least a portion of the at least one additional content item based on its relationship to the detection seed (Kim: Para. [0251], For instance, only when the tweet reply is determined to contain at least one keyword stored in TRDB and at least one URL, and if the detected URL of the tweet reply is determined to include at least one malicious html pattern stored in the TRDB, the tweet reply is flagged as potentially malicious. Using a combination of conditions can lower a rate of detection of false positives. The above conditions can be termed collectively in the present disclosure as conditions to flag suspicious tweets. Para. [0261], At a step S918, the Twitter crawler system is configured to execute a program (instructions) stored in a memory to determine if a tweet reply to an influencer twitter account that is stored in the TRDB for monitoring fulfils any one of the conditions to flag a suspicious tweet. The conditions to flag a suspicious tweet are Para. [0262]-[0265]); and
updating the knowledge repository with the classified at least one additional content item and associated relationships (Kim: Para. [0262], If it is determined that a retrieved tweet reply fulfils any one of the conditions to flag a suspicious tweet, the tweet reply will be flagged for further verification by the Sentinels at a step S920. In one example, the tweet id of a corresponding suspicious tweet is recorded in a TRDB. In another example, the tweet id of a tweet reply that has been determined by the twitter crawler API to be non-suspicious may be recorded.).
Regarding claim 2, Kim teaches the method of claim 1, further comprising:
determining that the detection seed is associated with a malicious content type selected from the group consisting of ransomware, phishing, fraudulent giveaway, crypto scam, known malicious entity, known malicious website, known malicious wallet address, and combinations thereof, and storing the malicious content type in the knowledge repository (Kim: Para. [0121], Through collective intelligence, TRDB 110 can efficiently collect hacker's wallet address, malicious URI, phishing address, malware hashes, and prevent a user from accessing such malicious data (such as wallet addresses, phishing addresses, malicious URIs, and malware hashes) and lose valuable data. Para. [0159], After the Sentinels 150 analyze the root cause of the reported threat, the result of the analysis is registered in the Threat Reputation Database (TRDB) 110. If the result of the analysis determines that the unknown threat is indeed malicious, the online community where the malicious file was originally detected may be alerted. The result of the analysis (or analyzed information) may comprise an indicator for adding to a blacklist of the TRDB 110 and/or an indicator for adding to a whitelist of the TRDB 110.8. Updating: The updated threat information, which include the result of the analysis by the Sentinels, is sent to the Threat DB 110 (S208).).
Regarding claim 3, Kim teaches the method of claim 1, further comprising: extracting metadata from the at least one additional content item (Kim: Fig. 8-9, Para. [0252], Step S810 is explained in detailed with reference to FIG. 9. At a step S902, content of a tweet reply is retrieved. Alternatively, content of a plurality of tweet replies are retrieved and scheduled for investigation, where each tweet reply is identifiable by a tweet ID. At a step S904, tweet content (or replies) of a twitter account is checked for key words (such as send, airdrop, wallet) stored in TRDB.);
comparing the extracted metadata with metadata in the knowledge repository (Kim: Fig. 8-9, Para. [0252], At a step S904, tweet content (or replies) of a twitter account is checked for key words (such as send, airdrop, wallet) stored in TRDB. It is possible for a user and/or a Sentinel to add, remove or edit keywords to be checked through the tweet content using a Keyword Management Feature of the TRDB. Typical keyword search algorithms (such as exact matches, partial matches, keyword search using wildcard and the like) may also be used to determine if there are any keyword(s) detected in a tweet reply by the Twitter Crawler System. Para. [0260], At a step S908, tweet content is also checked for URL links. For every URL detected in each tweet, the respective URL link is expanded and redirected, for example, through a sandbox at a step S910 to retrieve corresponding HTML code. Subsequently, at a step S912, after retrieving HTML code corresponding to the redirected URL link, the Twitter Crawler System is configured to check if the retrieved HTML codes include any malicious patterns defined in the TRDB. Some examples of malicious patterns are detection of text strings such as “verify your address”, “copy address to clipboard”, and “waiting for your payment”.); and
classifying each additional content item based on whether the extracted metadata matches previously stored metadata indicative of malicious or benign behavior (Kim: Para. [0261], At a step S918, the Twitter crawler system is configured to execute a program (instructions) stored in a memory to determine if a tweet reply to an influencer twitter account that is stored in the TRDB for monitoring fulfils any one of the conditions to flag a suspicious tweet).
Regarding claim 4, Kim teaches the method of claim 1, further comprising: identifying a blockchain wallet address within the at least one additional content item (Kim: Fig. 8-9, Para. [0253], Subsequently, at a step S906, tweet content is also checked for presence of a wallet address. In one example, using regex, wallet address of a prescribed format can be detected.). Some examples of the prescribed formats are listed below: Para. [0260], If the Twitter Crawler System detects a possible threat, it is configured to scan the HTML for wallet address (can be ETH address, Bitcoin Address, or the link) at a step S914 and/or to take a screenshot of the site at a step S916. Para. [0267], Turning back to FIG. 8A, the twitter crawler system is configured to generate threat results at a step S812. The generated threat results include flagged twitter accounts and suspicious tweets. The generated threat results are transmitted to the TRDB for validation by the Sentinels (e.g. 150 in FIG. 1, A-J in FIG. 2) at a step S814. The validation process by the Sentinels is described in detail with reference to FIG. 10A. Para. [0297], Optionally, the Sentinel Protocol is configured to detect on-page malicious crypto wallet addresses.); and
storing the blockchain wallet address in the knowledge repository in association with the detection seed (Kim: Para. [0232], In one example, at a step S806, all tweet replies for all monitored influencers are retrieved at S806. Para. [0251], For instance, only when the tweet reply is determined to contain at least one keyword stored in TRDB and at least one URL, and if the detected URL of the tweet reply is determined to include at least one malicious html pattern stored in the TRDB, the tweet reply is flagged as potentially malicious. Using a combination of conditions can lower a rate of detection of false positives. The above conditions can be termed collectively in the present disclosure as conditions to flag suspicious tweets. Para. [0261], Para. [0262]-[0265].)
Regarding claim 5, Kim teaches the method of claim 4, further comprising: submitting the blockchain wallet address to a blockchain search engine to identify one or more additional blockchain wallet addresses having a recorded transaction relationship with the blockchain wallet address (Kim: Para. [0207], A search function for whitelisted and blacklisted crypto addresses. Para. [0314], A blockchain explorer application herein refers to an application that acts like a search engine for viewing and querying a blockchain to allow a user to retrieve transaction information about a wallet or node in the blockchain and track transactions of the wallet or node. Para. [0314], A blockchain explorer application herein refers to an application that acts like a search engine for viewing and querying a blockchain to allow a user to retrieve transaction information about a wallet or node in the blockchain and track transactions of the wallet or node.); and
updating the knowledge repository with any identified additional blockchain wallet addresses in association with the detection seed (Kim: Para. [0315], In the example of FIG. 19B, immediate source neighbour wallets S1 and S2 received tokens through direct transactions from exchange wallets. Such behaviours of S1 and S2 are deemed by the CARA algorithm to be similar to a normal wallet (i.e. non-malicious wallet). However, the immediate source neighbour wallet S3 is deemed by the CARA algorithm to be a malicious wallet S3 as this wallet S3 directly interacts with a known malicious wallet M, which is listed in a blacklist of the TRDB.).
Regarding claim 8, Kim, in combination with Kuchar, teaches the method of claim 1, further comprising: providing at least a portion of the updated knowledge repository to a security agent configured to block, remediate, or alert on malicious content or blockchain addresses identified therein (Kim: Para. [0121], TRDB 110 uses an incentive scheme that encourages Security experts, ordinary users and/or vendors to contribute to the TRDB 110 under a consensus mechanism and feedback from participants, or through Delegated Proof of Stake (DPOS), which will be discussed later. Through collective intelligence, TRDB 110 can efficiently collect hacker's wallet address, malicious URI, phishing address, malware hashes, and prevent a user from accessing such malicious data (such as wallet addresses, phishing addresses, malicious URIs, and malware hashes) and lose valuable data. Para. [0122], In one example, to maintain data integrity in the TRDB 110, the TRDB 110 is configured to be updated solely by security experts 150 in order to eliminate systematic errors such as false positives. General users can also participate by allowing auto reporting of a detected security risk and/or manual reporting of a detected security risk. The more users contribute to the TRDB 110, the more robust it will be to protect individuals and/or organizations from scams and fraud. Para. [0123] Para. [0081], Para. [0081], Through the Sentinel Protocol, the public can report malicious activities such as Phishing Domains, Wallet Addresses, Malicious Social Media URLs in to the SIPB and each reported case would be evaluated by a Sentinel (Crowdsource Cybersecurity Expert). The Sentinel may be a system administrator. The Sentinel Protocol may incorporate features of the Blockchain. The Sentinel may be a user of a node in a Blockchain network. Para. [0087], Para. [0123], In such example, if users allow auto reporting, unknown threats that are automatically detected from a machine learning-based security wallet 120 (to be discussed later) are recorded in the TRDB 110. Through manual reporting, an user can report risk information that will be validated by the community (comprising the Sentinels 150). This means that reported data would be subject to review or validation by the Sentinels 150 (and/or systems administrator of the Sentinel Protocol before registering as a data block of a blockchain in the TRDB 110.).
Regarding claim 9, Kim, in combination with Kuchar, teaches the method of claim 1, wherein searching at least one content source comprises automatically crawling one or more social media platforms, video-sharing platforms, or web servers based on the detection seed, and identifying additional content items referencing the detection seed (Kim: Para. [0269], the twitter crawler system is configured to crawl all tweets of the newly-blacklisted twitter account. Advantageously, the twitter crawler system is able to uncover malicious tweets that are not replying to tweets by influencers stored in the TRDB. Para. [0260]-[0261], Para. [0488], In the above examples described, a Wallet Crawler System (WCS) may be further implemented to collect and increase the number of annotated wallets in the threat reputation database (TRDB) i.e. the database 110 in FIG. 1.).
Regarding claims 10-14, Claims 10-14 are rejected under the same rational as claims 1-5, respectively.
Regarding claims 17-18, Claims 17-18 are rejected under the same rational as claims 8-9, respectively.
Regarding claim 19, Claim 19 is rejected under the same rational as claim 1.
Regarding claim 20, Kim teaches the computer storage medium of claim 19, wherein the knowledge repository is empty (Kim: Para. [0143], Then, the Sentinels 150, the group of trusted security experts, analyzes the root cause of the threat. This analyzed information is registered in the Threat Reputation Database (TRDB) 110 and also reported to the online community where the file was originally found. [database is empty prior to first analyzed information being registered or a zero value token or element being stored] Para. [0307]).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claim(s) 6-7 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al. (US 2022/0101326; Hereinafter “Kim”) in view of Kuchar et al. (US 2020/0027089; Hereinafter “Kuchar”).
Regarding claim 6, Kim teaches the method of claim 1 Kim does not explicitly teach further comprising: representing the detection seed, the at least one additional content item, and the relationships therebetween as nodes and edges in a graph data structure stored in the knowledge repository.
In an analogous art Kuchar teaches representing the detection seed, the at least one additional content item, and the relationships therebetween as nodes and edges in a graph data structure stored in the knowledge repository (Kuchar: Para. [0078], In some implementations, the trust score determination module 300 may generate a blockchain graph data structure based on the blockchain data (e.g., see FIG. 15B). The trust score determination module 300 may also process the graph to determine one or more graph-based values (e.g., importance values) that may be used to generate local trust scores. Para. [0191], FIG. 15B illustrates an example representation of the graph data structure. In FIG. 15B, the graph data structure is represented by nodes and edges. The graph data structure includes blockchain addresses as nodes of the graph. The transactions between blockchain addresses are edges between the nodes, where the arrows indicate the direction of the transaction (e.g., the receiver is at the arrowhead). The amount for each transaction is labeled adjacent to the arrow. The fraud label for each blockchain address is included above the node. FIG. 15B includes 4 transactors with blockchain addresses A, X, Y, Z. Blockchain address Y has been labeled as a fraudulent address. [0158]).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Kuchar with the system and method of Kim to include representing the detection seed, the at least one additional content item, and the relationships therebetween as nodes and edges in a graph data structure stored in the knowledge repository because this functionality enables visual graphic mechanisms to safeguard against fraud while preserving user anonymity and autonomy (Kuchar: Para. [0037]).
Regarding claim 7, Kim, in combination with Kuchar, teaches the method of claim 6, further comprising: analyzing the graph data structure to identify clusters of nodes representing suspected malicious activity, and updating the knowledge repository based on the identified clusters (Kuchar: Para. [0053], In some implementations, the trust request module 126 can generate a graphical user interface (GUI) that the user may interact with in order to send the trust request 130 and view the trust report 132. (Kuchar: Para. [0078], In some implementations, the trust score determination module 300 may generate a blockchain graph data structure based on the blockchain data (e.g., see FIG. 15B). The trust score determination module 300 may also process the graph to determine one or more graph-based values (e.g., importance values) that may be used to generate local trust scores. Para. [0191], The fraud label for each blockchain address is included above the node. FIG. 15B includes 4 transactors with blockchain addresses A, X, Y, Z. Blockchain address Y has been labeled as a fraudulent address.).
Regarding claims 15-16, Claims 15-16 are rejected under the same rational as claims 6-7, respectively.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Application Publication No. US 2023/0298016 by Osborn et al.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Nelson Giddins whose telephone number is (571)272-7993. The examiner can normally be reached on Monday - Friday, 9:00 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards can be reached at (571) 270-5440. 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.
/NELSON S. GIDDINS/ Primary Examiner, Art Unit 2408
