DETAILED ACTION
This is an office action on the merits in response to the communication filed on 10/28/2024.
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 .
Claims’ Status
Claims 1-20 are canceled. Claims 21-40 are pending and are considered in this office action.
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 21-40 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture or composition of matter? MPEP 2106.03
Per Step 1, Claims 21-34 and 40 are drawn to method claims; claim 35-39 are drawn to system claims, which are all within the four statutory categories (i.e., a process).
Independent claim 21 recites: (claims 35 and 40 being similar in scope):
Claim 21:
obtaining, by one or more processors, a node data set comprising one or more nodes and one or more edges, each edge comprising data indicating a source node address, a target node address, and an edge weight;
associating, by the one or more processors, a first node of the one or more nodes with a first weight factor;
identifying, by the one or more processors, a first edge of the one or more edges, wherein the first edge comprises data indicating a source node address corresponding to the first node, a target node address corresponding to a second node of the one or more nodes in the node data set, and a first edge weight;
determining, by the one or more processors, a source value for the second node based on the first weight factor and the first edge weight;
generating, by the one or more processors, a risk value for the second node based on the source value; and
upon determining that the risk value for the second node exceeds a predetermined risk threshold, halting transactions to and from the second node.
Step 2A Prong 1: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04
The limitations, as drafted, constitute a process that, under its broadest reasonable interpretation, covers: fundamental economic principles by mitigating risk under the Certain methods of organizing human activity, but for the recitation of generic computer components. The abstract idea, recited above, includes: obtaining a node data set comprising one or more nodes and one or more edges; associating a first node of the one or more nodes with a first weight factor; identifying a first edge of the one or more edges; determining a source value for the second node based on the first weight factor and the first edge weight; generating a risk value for the second node based on the source value. If a claim limitation, under its broadest reasonable interpretation, covers performance of limitations: fundamental economic principles by mitigating risk, but for the recitation of generic computer components, it falls within the Certain methods of organizing human activity, grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong 2: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
The recited computing elements (claim 21: one or more processors; claim 35: at least one memory storing instructions; and at least one processor) are recited at a high-level of generality, i.e. as generic computing element performing generic computer functions such that it amounts to no more than mere instructions to apply the exception using generic computer components (see MPEP 2106.05(f)). Simply adding a general purpose computer or computer components after the fact to an abstract idea does not integrate a judicial exception into a practical application or provide significantly more, since it amounts to no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer, as set forth in MPEP 2106.05(f).
The other additional positive element(s): “upon determining that the risk value for the second node exceeds a predetermined risk threshold, halting transactions to and from the second node” in claim 21, which amounts to linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h) or simply “applying it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f)
Accordingly, these additional claim elements, alone and in combination do not integrate the abstract idea into a practical application, because (1) they do not effect improvements to the functioning of a computer, or to any other technology or technical field (see MPEP 2106.05(a)); (2) they do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or a medical condition (see the Vanda memo); (3) they do not apply the abstract idea with, or by use of, a particular machine (see MPEP 2106.05(b)); (4) they do not effect a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05(c)); (5) they do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the identified abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designated to monopolize the exception (see MPEP 2106.05(e) and the Vanda memo). Therefore, per Step 2A, Prong Two, the claim is directed to an abstract idea not integrated into a practical application.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05.
Step 2B of the eligibility analysis concludes that the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. Examiner carries over the analysis from Step 2A related to the generic computing elements being no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer (MPEP 2106.05(f)). The additional claim elements are simply linking the use of the judicial exception to a particular technological environment or field of use” are mere instructions to implement an abstract idea on a computer, are carried over for further analysis in Step 2B.
When the independent claims are considered as a whole, as a combination, the claim elements noted above do not amount to any more than they amount to individually. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified as an abstract idea. Therefore, it is concluded that the elements of the independent claims are directed to one or more abstract ideas and do not amount to significantly more. (MPEP 2106.05)
Further, Step 2B of the analysis takes into consideration all dependent claims as well, both individually and as a whole, as a combination:
Claims 21-34 are further directed to additional abstract ideas because the steps performed are simply narrowing the scope of the abstract idea of claim 21 since their individual and combined significance is still not significantly more than the abstract concept at the core of the claimed invention. For example, claim 22 further associating the first/second node with various weight factor; claim 23 describes halting transaction when determining the risk value of the third node exceeds a certain risk threshold; claim 26 describes associating the first node with a fraudulent activity; claim 27 describes presenting a graphical depiction of the risk value; claim 28 on determining a total amount received value for the second node; claim 29 describes the total amount received value is further determined based on a combined edge weight of each edge; claim 30 describes presenting a notification indicating that the source value for the second node exceeds the predetermined risk threshold ; claim 31 on displaying a window on a maximum number of hops input element; claim 32 on presenting a graphical depiction of the first node, the second node, and the first edge; claim 34 on presenting, based on the user selection, additional information on the graphical user interface; etc; which all of the limitation are narrowing the steps performed in claim 21.
Claims 24 is directed to nonfunctional descriptive material “each of the one or more nodes comprises one or more cryptocurrency addresses.” Claim 25 is also directed to nonfunctional descriptive material “each one of the one or more edges corresponds to a financial transaction.” Claim 33 describes the graphical depiction of the first node comprises a circle or a rectangle. While these descriptive elements may provide further helpful context for the claimed invention, these elements do not serve to confer subject matter eligibility to the invention since their individual and combined significance is still not significantly more than the abstract concept at the core of the claimed invention.
The other dependent claims, claim 36-39 are similar in scope to the claim 21-34 are also rejected for the same reasons provided above.
The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the associated computing devices are facilitating the abstract concept is not enough to confer statutory subject matter eligibility. In sum, the additional elements do not serve to confer subject matter eligibility to the invention since their individual and combined significance is still not heavier than the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly more either. (see MPEP 2106.05)
In sum, claims 21-40 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 21-26, 28-30, and 35-39 are rejected under 35 U.S.C 103 as being obvious over Chugunov et al. (WO2020065242A1) in view of Seiver et al. (US20170214710A1) in view of Anstey et al. (US20200111066A1).
With respect to claim 21 and 35
Chugunov teaches the limitations of:
at least one memory storing instructions; and at least one processor executing the instructions to perform a process including (see pg.5 ln31- pg.6 ln8):
obtaining a node data set comprising nodes and edges (pg.22 ln14-ln30, let us plot a directed graph….where a set of vertexes V of graph….Each of the graph nodes is assigned a four-component vector of node weights w= (w1, w2, w3, w4)….satisfies the following….; see also pg.5 ln19-21, the transaction further contains information about at least one of the following: the sending node address, the smart contract address, or such parameters as may be necessary to execute the transaction.);
associating a first node of the node data set with a first weight factor (pg.22 ln14-ln30, let us plot a directed graph….where a set of vertexes V of graph….Each of the graph nodes is assigned a four-component vector of node weights w= (w1, w2, w3, w4)….satisfies the following….);
identifying a first edge of the node data set, wherein the first edge comprises data indicating a source node address corresponding to the first node, a target node address corresponding to a second node of the node data set, and a first edge weight (pg.22 ln14-ln30, let us plot a directed graph….where a set of vertexes V of graph….Each of the graph nodes is assigned a four-component vector of node weights w= (w1, w2, w3, w4)….satisfies the following….);
Chugunov does not explicitly disclose, but Seiver teaches:
determining a source value for the second node based on the first weight factor and the first edge weight ([0132], In some implementations the system can apply weights to each of the obtained compromise values, e.g., scaling factors, to determine the total compromise value. Examples of determining a total compromise value are described below, with reference to FIG. 7); generating a risk value for the second node based on the source value ([0102], In one embodiment, the compromise risk value is a scaled version of the total compromise value, scaled by the compromise likelihood (e.g., probability that the node, or user account, can be compromised). Examples of determining compromise risk values are described below, with reference to FIG. 6.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Chugunov with the teaching of Seiver as they relate to a system of managing network nodes/devices in a network. One of ordinary skill in the art before the effective filing date would have recognized the transaction processing in decentralized network by network nodes in Chugunov to include a method of generating a risk value for the second node as taught by Seiver for the predicated result of improved systems of estimating risk of a transaction.
Chugunov in view of Seiver do not explicitly disclose, but Anstey teaches:
upon determining that the risk value for the second node exceeds a predetermined risk threshold, halting transactions to and from the second node ([0087], In some embodiments, the Bitcoin transaction data analysis software 1006 may provide a convenient Application Programming Interface (API) for use by, e.g., law enforcement, governments, or Bitcoin users, executing their own software. For example, an API call may accept as a parameter a unique cryptocurrency transaction identifier (e.g. a Bitcoin hash) and may provide, as a result, an indication of the approximate geographic origin of a transaction of interest or a score indicative of a degree of risk, akin to a credit score, associated with the approximate geographic origin. The invoker of such an API call may use the result to flag suspect transactions as possibly fraudulent. Alternatively, a cryptocurrency user could possibly use the result of such an API call as a basis for rejecting a future transaction from an associated Bitcoin address or wallet. In this context, “rejecting” a transaction may mean checking a Bitcoin address a priori and not sending any money to it if a score exceeds a threshold. “Rejecting” a transaction may also mean, before accepting any money from a prospective payer, asking for the Bitcoin address that will be used to pay, using the API call to obtain a “degree of risk” score for that address, and decline to accept payment for a score that exceeds a threshold. The foregoing steps could be automated in some embodiments. “Rejecting” may also mean automatically flagging or suspending an account pending review at a hosted wallet provider; see also [0103], In some embodiments, the identities of each of the possible originating nodes (e.g. all nodes mentioned in Table 5) may be presented in a graphical user interface along with their associated computed probabilities of being the originator node.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Chugunov/ Seiver with the teaching of Anstey as they relate to a system of managing network nodes/devices in a network. One of ordinary skill in the art before the effective filing date would have recognized the combined systems of Chugunov/ Seiver, for example transaction processing in decentralized network by network nodes in Chugunov, to include a method of halting transactions if determining that the risk value for the second node exceeds a predetermined risk threshold as taught by Anstey for the predicated result of improved systems of estimating risk of a transaction.
With respect to claim 22 and 36
The combination of Chugunov, Seiver, and Anstey teaches the limitations of claim 21 and 35 respectively. Chugunov further teaches: upon associating the first node with the first weight factor, designating, by the one or more processors, the first node and the first weight factor as a first item (pg.22 ln14-ln30, let us plot a directed graph….where a set of vertexes V of graph….Each of the graph nodes is assigned a four-component vector of node weights w= (w1, w2, w3, w4)….satisfies the following….);
placing, by the one or more processors, the first item into a queue (pg.1 ln33 – pg.2 ln7);
upon identifying the first edge of the one or more edges, removing, by the one or more processors, the first item from the queue (pg.23 ln1 – ln7);
associating, by the one or more processors, the second node with a second weight factor (pg.24 ln12-14);
designating, by the one or more processors, the second node and the second weight factor as a second item (pg.22 ln14-ln30; pg.24 ln12-ln14); and
placing, by the one or more processors, the second item into the queue (pg.1 ln33-pg.2 ln7).
With respect to claim 23 and 37
The combination of Chugunov, Seiver, and Anstey teaches the limitations of claim 22 and 36 respectively. Chugunov further teaches: upon placing the second item into the queue, identifying, by the one or more processors, a second edge of the one or more edges, wherein the second edge comprises a source node address corresponding to the second node and a target node address corresponding to a third node of the one or more nodes in the node data set (pg.23 ln27 – pg.24 ln2);
removing, by the one or more processors, the second item from the queue (pg.23 ln1-ln7);
upon removing the second item from the queue, determining, by the one or more processors, a source value of the third node based on the second weight factor (pg.22 ln14-ln30);
Seiver further teaches: generating, by the one or more processors, a risk value for the third node based on the source value of the third node ([0102], In one embodiment, the compromise risk value is a scaled version of the total compromise value, scaled by the compromise likelihood (e.g., probability that the node, or user account, can be compromised). Examples of determining compromise risk values are described below, with reference to FIG. 6.)
Anstey further teaches: upon determining that the risk value for the third node exceeds a predetermined risk threshold, halting transactions to and from the third node ([0087], In some embodiments, the Bitcoin transaction data analysis software 1006 may provide a convenient Application Programming Interface (API) for use by, e.g., law enforcement, governments, or Bitcoin users, executing their own software. For example, an API call may accept as a parameter a unique cryptocurrency transaction identifier (e.g. a Bitcoin hash) and may provide, as a result, an indication of the approximate geographic origin of a transaction of interest or a score indicative of a degree of risk, akin to a credit score, associated with the approximate geographic origin. The invoker of such an API call may use the result to flag suspect transactions as possibly fraudulent. Alternatively, a cryptocurrency user could possibly use the result of such an API call as a basis for rejecting a future transaction from an associated Bitcoin address or wallet. In this context, “rejecting” a transaction may mean checking a Bitcoin address a priori and not sending any money to it if a score exceeds a threshold. “Rejecting” a transaction may also mean, before accepting any money from a prospective payer, asking for the Bitcoin address that will be used to pay, using the API call to obtain a “degree of risk” score for that address, and decline to accept payment for a score that exceeds a threshold. The foregoing steps could be automated in some embodiments. “Rejecting” may also mean automatically flagging or suspending an account pending review at a hosted wallet provider; see also [0103], In some embodiments, the identities of each of the possible originating nodes (e.g. all nodes mentioned in Table 5) may be presented in a graphical user interface along with their associated computed probabilities of being the originator node.)
With respect to claim 24 and 38
The combination of Chugunov, Seiver, and Anstey teaches the limitations of claim 21 and 35 respectively. Chugunov further teaches: wherein each of the one or more nodes comprises one or more cryptocurrency addresses (pg.5 ln19-ln21).
With respect to claim 25 and 39
The combination of Chugunov, Seiver, and Anstey teaches the limitations of claim 21 and 35 respectively. Chugunov further teaches: wherein each one of the one or more edges corresponds to a financial transaction, and further wherein the edge weight is predetermined based on a transaction amount associated with the financial transaction (pg.7 ln25-ln27).
With respect to claim 26
The combination of Chugunov, Seiver, and Anstey teaches the limitations of claim 21. Anstey further teaches: associating, by the one or more processors, the first node with a first activity, wherein the first activity is one or more of fraudulent activity, illicit activity, or illegal activity (see [0024], The approximate geographic location of an originating cryptocurrency node may be used, optionally in combination with other factors, to flag the associated cryptocurrency transaction as possibly being fraudulent. This may for example be done when the geographic location is known to be in a high-crime area. In the case of Bitcoin, future Bitcoin transactions originating from the same Bitcoin address, or another Bitcoin address associated with the same Bitcoin wallet as that Bitcoin address, may also be automatically flagged as possibly fraudulent. An intended recipient of cryptocurrency could possibly use this information in the future reject a proposed transaction on the basis that it is likely to be fraudulent.)
With respect to claim 28
The combination of Chugunov, Seiver, and Anstey teaches the limitations of claim 21. Chugunov further teaches: determining, by the one or more processors, a total amount received value for the second node, wherein the source value for the second node is further generated based on the total amount received value for the second node (pg.4 ln18-ln25, where one or more candidate transactions are validated, with node balance remaining after all candidate transactions for such trusted node are confirmed and one or more transactions being sent by such node, the amount of which transaction exceeds the above-mentioned remaining node balance, it being guaranteed that added to the balance were one or more transactions in an amount which can cover such balance up to a positive value, the total balance of sent and received transactions is calculated in respect of the aforesaid transactions within the same block and, if the total balance is positive, all transactions within such block are treated as validated.)
With respect to claim 29
The combination of Chugunov, Seiver, and Anstey teaches the limitations of claim 28. Chugunov further teaches: wherein the total amount received value for the second node is further determined based on a combined edge weight of each edge for which the second node is a target node (pg.23 ln1-ln7, The weight vector of the participating nodes is built similarly to the process of computing the participant’ s balance assuming that all transaction edges of the current graph are already embedded in the next blockchain except that these values of the fourth component of weights in the current graph can be negative and our process is tailored to remove a certain (where possible, the minimum) number of transaction edges with the aim of procuring the fourth components of weight vector for each vertex to be strictly positive in the remaining transactions graph.)
With respect to claim 30
The combination of Chugunov, Seiver, and Anstey teaches the limitations of claim 29. Anstey further teaches: upon determining that the source value for the second node exceeds the predetermined risk threshold, presenting, by the one or more processors, on a graphical user interface, a notification indicating that the source value for the second node exceeds the predetermined risk threshold ([0087], In some embodiments, the Bitcoin transaction data analysis software 1006 may provide a convenient Application Programming Interface (API) for use by, e.g., law enforcement, governments, or Bitcoin users, executing their own software. For example, an API call may accept as a parameter a unique cryptocurrency transaction identifier (e.g. a Bitcoin hash) and may provide, as a result, an indication of the approximate geographic origin of a transaction of interest or a score indicative of a degree of risk, akin to a credit score, associated with the approximate geographic origin. The invoker of such an API call may use the result to flag suspect transactions as possibly fraudulent. Alternatively, a cryptocurrency user could possibly use the result of such an API call as a basis for rejecting a future transaction from an associated Bitcoin address or wallet. In this context, “rejecting” a transaction may mean checking a Bitcoin address a priori and not sending any money to it if a score exceeds a threshold. “Rejecting” a transaction may also mean, before accepting any money from a prospective payer, asking for the Bitcoin address that will be used to pay, using the API call to obtain a “degree of risk” score for that address, and decline to accept payment for a score that exceeds a threshold. The foregoing steps could be automated in some embodiments. “Rejecting” may also mean automatically flagging or suspending an account pending review at a hosted wallet provider; see also [0103], In some embodiments, the identities of each of the possible originating nodes (e.g. all nodes mentioned in Table 5) may be presented in a graphical user interface along with their associated computed probabilities of being the originator node.)
Claim 27 is rejected under 35 U.S.C 103 as being obvious over Chugunov et al. (WO2020065242A1) in view of Seiver et al. (US20170214710A1) in view of Anstey et al. (US20200111066A1), and further in view of Hunn et al. (US20200057994A1).
With respect to claim 27
The combination of Chugunov, Seiver, and Anstey teaches the limitations of claim 21. The combination doesn’t explicitly disclose, but Hunn teaches: presenting, by the one or more processors, on a graphical user interface, a graphical depiction of the risk value for the second node ([0102], the graph for each contract may be traversed and queried (e.g. via API or through use of a graph processing engine, or similar) to provide analytics such as causation (e.g. ‘versioning’ links) and other relationships between objects (which may be beneficial for contractual analytics, counterparty assessment, internal workflows, contractual enforcement and other reasons). Other examples may include (but are not limited to): negotiation analytics and modeling, execution analytics, assessing contractual performance, predictive analytics, modeling risk profiles, modeling event-based permutations, modeling exposure, and/or other forms of analytics; see also [0222], The graph may be queried by an API so that data can be displayed via a graphical user interface, command line Interface, or any appropriate manner as shown in FIG. 29.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Chugunov/ Seiver/ Anstey with the teaching of Hunn as they relate to a system of managing network nodes/devices in a network. One of ordinary skill in the art before the effective filing date would have recognized the combined systems of Chugunov/ Seiver/ Anstey, for example transaction processing in decentralized network by network nodes in Chugunov, to include a method of presenting a graphical depiction of the risk value as taught by Hunn for the predicated result of improved systems of estimating risk of a transaction.
Claim 31 is rejected under 35 U.S.C 103 as being obvious over Chugunov et al. (WO2020065242A1) in view of Seiver et al. (US20170214710A1) in view of Anstey et al. (US20200111066A1), and further in view of Andersen et al. (US20120182865A1).
With respect to claim 31
The combination of Chugunov, Seiver, and Anstey teaches the limitations of claim 21. The combination doesn’t explicitly disclose, but Andersen teaches: displaying, by the one or more processors, on a graphical user interface, a window, wherein the window comprises one or more of: a minimum dilution input element; a maximum number of hops input element; or a minimum transfer amount input element ([0081], An Origination-Destination Pair (OD pair) defines an ordered pair of nodes (Origin node, Destination node) possibly with administrative groups attributes and/or end-to-end attributes as, e.g., maximum hop count and/or maximum latency. These attributes are sometimes referred to as constraints. The administrative groups determine which links the paths associated with the OD pair are allowed to be used. The end-to-end attributes determine the applicability of a given path to the OD pair.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Chugunov/ Seiver/ Anstey with the teaching of Andersen as they relate to a system of managing network nodes/devices in a network. One of ordinary skill in the art before the effective filing date would have recognized the combined systems of Chugunov/ Seiver/ Anstey, for example transaction processing in decentralized network by network nodes in Chugunov, to include a method of displaying a minimum dilution input element; a maximum number of hops input element; or a minimum transfer amount input element as taught by Andersen for the predicated result of improved systems of estimating risk of a transaction.
Claims 32-34 are rejected under 35 U.S.C 103 as being obvious over Chugunov et al. (WO2020065242A1) in view of Seiver et al. (US20170214710A1) in view of Anstey et al. (US20200111066A1), and further in view of Larson et al. (US10693872B1).
With respect to claim 32
The combination of Chugunov, Seiver, and Anstey teaches the limitations of claim 21. The combination doesn’t explicitly disclose, but Larson teaches: presenting, on a graphical user interface, a graphical depiction of the first node, the second node, and the first edge, wherein the graphical depiction of the first edge comprises an arrow originating from the graphical depiction of the first node and terminating at the graphical depiction of the second node (see col.30 ln37-ln44, FIG. 2B illustrates an example consolidated enrollment and sign-on process 200B according to various embodiments. In FIG. 2B, a message being conveyed from one entity to another entity is represented by solid or dashed line between the two entities with an arrowhead at one end of the line. The end of the line without the arrowhead is the source entity (or transmitter) and the end with the arrowhead is a target entity (or receiver)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Chugunov/ Seiver/ Anstey with the teaching of Larson as they relate to a system of managing network nodes/devices in a network. One of ordinary skill in the art before the effective filing date would have recognized the combined systems of Chugunov/ Seiver/ Anstey, for example transaction processing in decentralized network by network nodes in Chugunov, to include a method of presenting a graphical depiction of the first node, the second node, and the first edge as taught by Larson for the predicated result of improved systems of estimating risk of a transaction.
With respect to claim 33
The combination of Chugunov, Seiver, Anstey, and Larson teaches the limitations of claim 32. Anstey further teaches: wherein the graphical depiction of the first node comprises a circle or a rectangle ([0027], FIG. 1 is a simplified schematic diagram of a portion of the Bitcoin network. Five conventional cryptocurrency (Bitcoin) nodes A, B, C, D and E are illustrated, each represented by an unfilled circle.)
With respect to claim 34
The combination of Chugunov, Seiver, Anstey, and Larson teaches the limitations of claim 32. Seiver further teaches: receiving, by the one or more processors, a user selection of the graphical depiction of the first node, the graphical depiction of the second node, or the graphical depiction of the first edge; and presenting, by the one or more processors, based on the user selection, additional information on the graphical user interface (see [0088—0090])
Claim 40 is rejected under 35 U.S.C 103 as being obvious over Chugunov et al. (WO2020065242A1) in view of Seiver et al. (US20170214710A1) in view of Fang et al. (US20220067752A1), and further in view of Anstey et al. (US20200111066A1).
With respect to claim 40
Chugunov teaches the limitations of:
obtaining, by one or more processors, a node data set comprising nodes and edges (pg.22 ln14-ln30, let us plot a directed graph….where a set of vertexes V of graph….Each of the graph nodes is assigned a four-component vector of node weights w= (w1, w2, w3, w4)….satisfies the following….; see also pg.5 ln19-21, the transaction further contains information about at least one of the following: the sending node address, the smart contract address, or such parameters as may be necessary to execute the transaction.), wherein each node of the node data set comprises one or more cryptocurrency addresses (pg.5 ln19-ln21);
associating, by one or more processors, a first node of the node data set with a first weight factor (pg.22 ln14-ln30, let us plot a directed graph….where a set of vertexes V of graph….Each of the graph nodes is assigned a four-component vector of node weights w= (w1, w2, w3, w4)….satisfies the following….);
identifying, by the one or more processors, a first edge of the node data set, wherein the first edge comprises data indicating a source node address corresponding to the first node, a target node address corresponding to a second node of the node data set, and a first edge weight (pg.22 ln14-ln30, let us plot a directed graph….where a set of vertexes V of graph….Each of the graph nodes is assigned a four-component vector of node weights w= (w1, w2, w3, w4)….satisfies the following….);
Chugunov does not explicitly disclose, but Seiver teaches:
determining a risk value for the second node based on the first weight factor and the first edge weight ([0132], In some implementations the system can apply weights to each of the obtained compromise values, e.g., scaling factors, to determine the total compromise value. Examples of determining a total compromise value are described below, with reference to FIG. 7),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Chugunov with the teaching of Seiver as they relate to a system of managing network nodes/devices in a network. One of ordinary skill in the art before the effective filing date would have recognized the transaction processing in decentralized network by network nodes in Chugunov to include a method of generating a risk value for the second node as taught by Seiver for the predicated result of improved systems of estimating risk of a transaction.
Chugunov in view of Seiver do not explicitly disclose, but Fang teaches:
wherein the risk value is at least partially automatically generated by a trained machine learning model ([0035], The risk classification engine includes a machine learning model and is configured to analyze the digital data and transform the digital data to an identified behavior category, thereby creating classified risk data.); wherein the trained machine learning model is trained based on (i) first data that includes information regarding one or more prior nodes and one or more prior edges as test data; and (ii) second data that includes prior risk values corresponding to the one or more nodes, to learn relationships between the first data and the second data, such that the trained machine learning model is configured to use the learned relationships to generate a risk value for the first node ([0026], A risk classification engine including a machine learning model, analyzes the digital data and transforms the digital data to an identified behavior category, thereby creating classified risk data. A risk scoring regression engine with machine learning analyzes the classified risk data and assigns a risk score to each classified risk data. A risk policy engine analyzes the classified risk data and determines if any deviations from rules or standards have or will occur, wherein the risk policy engine is a rules based engine; see claim 1, extracting digital data from the digital on blockchain information and the digital off blockchain information; contextualizing relationships based on the digital data and the digital off blockchain information and the digital on blockchain information, the contextualizing including an entity knowledge base; analyzing the digital data and transforming the digital data to an identified behavior category, thereby creating classified risk data, wherein the analyzing and transforming includes a risk classification engine including a machine learning model; analyzing the classified risk data and assigning a risk score to each classified risk data, wherein the analyzing and assigning includes a risk scoring regression engine and machine learning; see also [0146-0147])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Chugunov/ Seiver with the teaching of Fang as they relate to a system of managing network nodes/devices in a network. One of ordinary skill in the art before the effective filing date would have recognized the combined systems of Chugunov/ Seiver, for example transaction processing in decentralized network by network nodes in Chugunov, to include method of employing machine learning model on analyzing risk data as taught by Fang for the predicated result of improved systems of estimating risk of a transaction.
Chugunov in view of Seiver in view of Fang do not explicitly disclose, but Anstey teaches:
upon determining that the risk value for the second node exceeds a predetermined risk threshold, halting transactions to and from the second node ([0087], In some embodiments, the Bitcoin transaction data analysis software 1006 may provide a convenient Application Programming Interface (API) for use by, e.g., law enforcement, governments, or Bitcoin users, executing their own software. For example, an API call may accept as a parameter a unique cryptocurrency transaction identifier (e.g. a Bitcoin hash) and may provide, as a result, an indication of the approximate geographic origin of a transaction of interest or a score indicative of a degree of risk, akin to a credit score, associated with the approximate geographic origin. The invoker of such an API call may use the result to flag suspect transactions as possibly fraudulent. Alternatively, a cryptocurrency user could possibly use the result of such an API call as a basis for rejecting a future transaction from an associated Bitcoin address or wallet. In this context, “rejecting” a transaction may mean checking a Bitcoin address a priori and not sending any money to it if a score exceeds a threshold. “Rejecting” a transaction may also mean, before accepting any money from a prospective payer, asking for the Bitcoin address that will be used to pay, using the API call to obtain a “degree of risk” score for that address, and decline to accept payment for a score that exceeds a threshold. The foregoing steps could be automated in some embodiments. “Rejecting” may also mean automatically flagging or suspending an account pending review at a hosted wallet provider; see also [0103], In some embodiments, the identities of each of the possible originating nodes (e.g. all nodes mentioned in Table 5) may be presented in a graphical user interface along with their associated computed probabilities of being the originator node.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Chugunov/ Seiver/Fang with the teaching of Anstey as they relate to a system of managing network nodes/devices in a network. One of ordinary skill in the art before the effective filing date would have recognized the combined systems of Chugunov/ Seiver/Fang, for example transaction processing in decentralized network by network nodes in Chugunov, to include a method of halting transactions if determining that the risk value for the second node exceeds a predetermined risk threshold as taught by Anstey for the predicated result of improved systems of estimating risk of a transaction.
Conclusion
THIS ACTION IS MADE Non-FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YIN Y CHOI whose telephone number is (571)272-1094 or yin.choi@uspto.gov. The examiner can normally be reached on M-F 7:30 - 5:30pm EST.
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, Neha Patel can be reached on 571-270-1492. 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.
/YIN Y CHOI/Examiner, Art Unit 3699 1/21/2026