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 .
This action is in reply to the application filed on 07/03/2024.
Claims 1-15 have been examined.
Claims 1-15 are pending.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that use the word “means” or “step” but are nonetheless not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitation(s) recite(s) sufficient structure, materials, or acts to entirely perform the recited function. Such claim limitation(s) is/are: “a secure transaction unit”, “storage means”, “control means” in claim 1. These could be interpreted as “a mobile device” or a “terminal”, “cloud storage” or “database”, a “CPU” subsequently. These are found in the specification. The applicant is advised to specify which structures these “means” and units refer to.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim limitation “a secure transaction unit”, “storage means”, “control means” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The applicant did not positively recite structure(s) to perform the functionality claimed in the independent claim. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
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-15 are directed to a system which is one of the statutory categories of invention. (Step 1: YES).
Claims 1-15 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-15 are directed to an abstract idea, Method of Organizing Human Activity. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional computer elements, which are recited at a high level of generality, provide conventional computer functions that do not add meaningful limits to practicing the abstract idea.
Claim 1, for instance, recites, in part, A secure transaction unit in an electronic transaction system, the secure transaction unit comprising: storage means for storing one or more token; and control means configured to: establishing an online communication with a central unit of the electronic payment transaction system; and receiving a blacklist-status in response to the established online communication; automatically transmitting all tokens that are currently stored in the storage means to an online hosted target secure transaction unit, if the blacklist-status is fulfilled. These limitations are directed to concepts performed in the human mind, via the use of generic computer components, such as Methods of Organizing Human Activity (isolating suspicious transactions). Hence, it falls within the “Commercial Interaction” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Next the claim as a whole is analyzed to determine whether any element, or combination of elements, is sufficient to ensure the claim amounts to significantly more than an abstract idea. Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements are merely performing the abstract idea on a generic device i.e., abstract idea and apply it. See Electric Power Group, LLC v. Alstom, S.A., 830 F.3d 1350, 1356, 119 USPQ2d 1739, 1743-44 (Fed. Cir. 2016); Intellectual Ventures I v. Symantec, 838 F.3d 1307, 1327, 120 USPQ2d 1353, 1366 (Fed. Cir. 2016); Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1417 (Fed. Cir. 2015). There is no improvement to computer technology or computer functionality MPEP 2106.05(a) nor a particular machine MPEP 2106.05(b) nor a particular transformation MPEP 2106.05(c). Thus, the claim is not patent eligible.
The dependent claims have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea.
The dependent claim(s) 2. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite receiving command form the central unit when considered individually and as ordered combination do not amount to significantly more than the abstract idea. The claim(s) does/do not include additional elements (such as a system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 3. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite transmitting tokens. The claim(s) does/do not include additional elements (such as a system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 4. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite checking whether the blacklist is fulfilled. The claim(s) does/do not include additional elements (such as a processor, a display) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 5. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite retrieving information. The claim(s) does/do not include additional elements (such as a system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 6. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite automatically transmitting information. The claim(s) does/do not include additional elements (such as a system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 7. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite assigning transaction unit to a participant. The claim(s) does/do not include additional elements (such as a processor, a mobile device) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 8. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite registering token to the system. The claim(s) does/do not include additional elements (such as a system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 9. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite receiving all tokens. The claim(s) does/do not include additional elements (such as a system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 10. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite assigning a unique identifier. The claim(s) does/do not include additional elements (such as a system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 11. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite assigning a unique identifier. The claim(s) does/do not include additional elements (such as a system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 12. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite establishing an online communication. The claim(s) does/do not include additional elements (such as a system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 13. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite registering tokens. The claim(s) does/do not include additional elements (such as a system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 14. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite registering with protocol data. The claim(s) does/do not include additional elements (such as a system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
The dependent claim(s) 15. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The claims recite assigning black-list when the transaction is lost. The claim(s) does/do not include additional elements (such as a system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply 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).
Therefore, Claims 1-15 are not drawn to eligible subject matter as they are directed to an abstract idea without significantly more.
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.
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-7, 9-14 are rejected under 35 U.S.C. 103 as being unpatentable over Kala et al. (US 2021/0081948 A1) in view of Madisetti et al. (US 2022/0138733 A1).
Claim 1 is taught: Kala teaches: A secure transaction unit in an electronic transaction system, the secure transaction unit comprising: storage means for storing one or more token (Kala, see at least par. [0018] “. . . The risk management server 85, the issuer server 80, and the risk management server 85 may be connected via the payment network, but it is contemplated that other entities, such as acquirers, issuers, or token managers, may be connected as well . . .” & see at least par. [0020] “. . . A database 1525 for digitally storing structured data may be stored in the memory 1510 or 1515 or may be separate. The database 1525 may also be part of a cloud of servers and may be stored in a distributed manner across a plurality of servers . . .”) database corresponds to a storage mean, under BRI, and is connected to token manager which manages one or more token ;
and control means configured to: establishing an online communication with a central unit of the electronic payment transaction system (Kala, see at least par. [0018] “. . . Various computer servers may be connected via a digital communication network 60, such as one or more merchant servers 55, a fraud server 70, a transaction data server 65, an issuer server 80, and a merchant data server 90. The servers may interface with a digital communications network, such as the digital communication network 60 . . .”) transaction data server corresponds to payment transaction system;
and receiving a blacklist-status in response to the established online communication (Kala, see at least par. [0025] “At 104, the risk management server 85 may receive fraudulent transaction data from the fraud server 70. At 106, the risk management server 85 may receive test transaction data from the transaction data server 65. In some embodiments, the fraud server 70 and/or the transaction data server 65 may be a part or partition of the risk management server 85, or may be a database stored within the risk management server or in another suitable location. The fraud data may include a set of transactions that have previously been found to be fraudulent . . .”) the risk management data server receives fraudulent transaction data. Fraudulent transaction list stored in the risk manager corresponds to blacklist status ;
Kala does not disclose the following; however, Madisetti teaches:
automatically transmitting all tokens that are currently stored in the storage means to an online hosted target secure transaction unit, if the blacklist-status is fulfilled (Madisetti, see at least par. [0151] “. . . The server 2806 may further comprise inter- and intra-blockchain messaging services 2824 and connectors for databases, cloud services & blockchain networks 2826. The server 2806 may further comprise Workers 2808 for processing requests and a list of blockchain clients 2812 of participating networks 2802. The server 2806 may further be positioned in communication with private and/or permissioned blockchain network for user identity management and secure transaction processing 2804. The server 2806 may use various smart contracts 2818 to bolster security. These smart contracts may be executed for each request from users 2800 and perform additional verification (such as verifying sender and receiver's address). The smart contracts may enforce checks such as time limits or quantity restrictions. Some smart contracts may perform functions similar to virus filters, for filtering out suspicious transactions . . .” & par. [0152] “ Referring now to FIG. 35 an illustration of an approach for securing multi-party linked smart contracts where transaction filters are part of a smart contract, is described in more detail. A filter smart contract 2904 may receive transfer requests from users 2900 for transfers on a blockchain network 2910 and check the transfer requests for suspicious activities using a filter and report identified suspicious transfer requests to the SQL or NoSQL or an Analytics Service 2912. Filters can be updated with new smart contracts. Some filters can be used to identify updates and some filters to flag security issues. Filters can block suspicious transactions, freeze funds stolen from smart contracts and even reverse the stolen funds back to the legitimate owners . . .”) The filters act as a secure transaction unit which is smart contract and stored in a online server.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kala by transmitting all tokens to a secure server as taught by Madisetti helps to better implement a security response to any inconsistency in transfer request (Abstract). Therefore, the claimed invention is obvious in view of the cited references.
Claim 2 is taught. Kala in view of Madisetti teaches: The secure transaction unit of claim 1. However, Madisetti teaches: wherein the blacklist-status is received as a command from the central unit, wherein based on the received command, the automatically transmitting is directly initiated (Madisetti, see at least par. [0153] “. . . The filtering code can be embedded into the DeFi application smart contract itself (such as a swap contract). The embedded filters can block suspicious transactions, freeze funds of hacker and reverse stolen funds. An external Artificial Intelligence (AI) and Machine Learning (ML) based component can be used for development of filters by learning patterns in transactions . . .”) the code acts as a command to initiate the filtering of the suspicious transactions.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kala in view of Madisetti by receiving a command as taught by Madisetti helps to better implement a security response to any inconsistency in transfer request (Abstract). Therefore, the claimed invention is obvious in view of the cited references.
Claim 3 is taught. Kala in view of Madisetti teaches: The secure transaction unit of claim 2. However, Madisetti teaches: wherein the command further comprises information about the online target secure transaction unit to which all tokens are automatically transmitted (Madisetti, see at least par. [0152] “. . . A filter smart contract 2904 may receive transfer requests from users 2900 for transfers on a blockchain network 2910 and check the transfer requests for suspicious activities using a filter and report identified suspicious transfer requests to the SQL or NoSQL or an Analytics Service 2912. Filters can be updated with new smart contracts. Some filters can be used to identify updates and some filters to flag security issues. Filters can block suspicious transactions, freeze funds stolen from smart contracts and even reverse the stolen funds back to the legitimate owners . . .”) Filter contract corresponds to target secure transaction unit.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kala in view of Madisetti by receiving a command as taught by Madisetti helps to better implement a security response to any inconsistency in transfer request (Abstract). Therefore, the claimed invention is obvious in view of the cited references.
Claim 4 is taught. Kala in view of Madisetti teaches: The secure transaction unit of claim 1. Furthermore, Kala teaches: wherein the blacklist-status is received as an information from the central unit, wherein the control means is further configured to: checking the information whether the blacklist-status is fulfilled; and if the blacklist-status is fulfilled, generating a command to initiate the automatically transmitting (Kala, see at least par. [0024] “. . . The test transaction data may be used to test the selected fraud rules, for example, to determine what proportion of known fraudulent transactions in the test transaction data (e.g., the fraud data) were identified correctly, and/or how many false positives (e.g., non-fraudulent transaction identified as fraudulent under the fraud rules) are identified by the fraud rules. Once an issuer is satisfied with the test results, the issuer may apply the fraud rules to live transactions on an ongoing bases to help detect new fraudulent transactions and take action.”) the rules correspond to blacklist status conditions.
Claim 5 is taught. Kala in view of Madisetti teaches: The secure transaction unit of claim 1. However, Madisetti teaches: further comprising information about the online target secure transaction unit to which all tokens are automatically transmitted, wherein prior the automatically transmitting, the control means is further configured to retrieving this information (Madisetti, see at least par. [0152] “. . . Filters can be updated with new smart contracts. Some filters can be used to identify updates and some filters to flag security issues. Filters can block suspicious transactions, freeze funds stolen from smart contracts and even reverse the stolen funds back to the legitimate owners. The filtering approach may be offered as a service to different DeFi applications and smart contracts which can pay per filtered transaction in the form of “Filter Token”. The filter contract can be split into different contracts 2902, 2906, 2908 as described in the updates approach in FIG. 33 to ease the process of releasing updated to filters . . .”) the filter smart contract is configured to retrieve the transaction data.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kala in view of Madisetti by transmitting a command as taught by Madisetti helps to better implement a security response to any inconsistency in transfer request. Therefore, the claimed invention is obvious in view of the cited references.
Claim 6 is taught. Kala in view of Madisetti teaches: The secure transaction unit of claim 1. Kala further teaches: wherein the automatically transmitting occurs without any further user interaction or user-input or user-acceptance (Kala, see at least par. [0029] “. . . In some embodiments, the specific upper and lower bounds for each transaction amount level may be automatically set by the risk management system . . .”) .
Claim 7 is taught. Kala in view of Madisetti teaches: The secure transaction unit of claim 1. Kala further teaches: wherein the secure transaction unit is uniquely assigned to a participant of the electronic transaction system, wherein the online target secure transaction unit is a transaction unit that is assigned to the same participant, the online target secure transaction unit is preferably hosted at a service provider unit within the electronic transaction system (Kala, see at least par. [0022] “In some embodiments, the risk management system may be hosted on or otherwise run by the risk management server 85 under the control of a risk management service or payment processor. In some embodiments, the risk management system may be hosted by another entity, such as an issuer using an issuer server 80 or a merchant using a merchant server 55. The servers 55, 80, 65, 70 may be able to communicate with a plurality of other servers, such as the risk management server 85, and the one or more other merchant servers 55 . . .”) Issuer server corresponds to electronic transaction system.
Claim 9 is taught. Kala in view of Madisetti teaches: claim 1. Kala further teaches: A service provider unit as a central unit in an electronic transaction system comprising: one or more online hosted target transaction units comprising a storage means for storing one or more token; a service provider transaction unit configured to receiving all tokens that are stored in a storage means of a secure transaction unit according to claim 1 (Kala, see at least par. [0018] “. . . the risk management server 85, the issuer server 80, and the risk management server 85 may be connected via the payment network, but it is contemplated that other entities, such as acquirers, issuers, or token managers, may be connected as well. In some embodiments, the issuer server 80 may be a controlled by a bank, payment account issuer, or credit card issuer.”) the token manager corresponds to token storage which could be controlled by a bank.
Claim 10 is taught. Kala in view of Madisetti teaches: The service provider unit according to claim 9. Kala further teaches: wherein the secure transaction unit is uniquely assigned to a participant of the electronic transaction system, wherein the online target secure transaction unit is a transaction unit that is assigned to the same participant (Kala, see at least par. [0022] “. . . the risk management system may be hosted by another entity, such as an issuer using an issuer server 80 or a merchant using a merchant server 55.”) The merchant corresponds to a participant.
Claim 11 is taught. Kala in view of Madisetti teaches: The service provider unit of claim 9. Kala further teaches: further comprising a blacklist-register for registering a blacklist-status of respective transaction units, the transaction units preferably being registered based on a unique identifier of the transaction units; the transaction units more preferably being managed and/or issued by the service provider unit (Kala, see at least par. [0031] “. . . In some embodiments, the high risk merchants may be identified as those merchants of the plurality of merchants that have a fraud rate that exceeds a threshold fraud rate, where the fraud rate may be defined as a number of transactions previously determined to be fraudulent per total transactions . . .”) the merchants could be identified by the riskiness status and the risk is managed by the fraud rule.
Claim 12 is taught. Kala in view of Madisetti teaches: An electronic transaction system incorporating features of claim 9. Kala teaches: comprising of: a plurality of secure transaction units; one or more service provider units; a central unit, preferably being one of the service provider units, the central unit being configured to(Kala, see at least par. [0018] “. . . Various computer servers may be connected via a digital communication network 60, such as one or more merchant servers 55, a fraud server 70, a transaction data server 65, an issuer server 80, and a merchant data server 90. The servers may interface with a digital communications network, such as the digital communication network 60 . . .”) transaction data server corresponds to payment transaction system;: establishing an online communication with one of the plurality of transaction units; transmitting a blacklist-status in response to the established online communication to the one of the plurality of transaction units(Kala, see at least par. [0025] “At 104, the risk management server 85 may receive fraudulent transaction data from the fraud server 70. At 106, the risk management server 85 may receive test transaction data from the transaction data server 65. In some embodiments, the fraud server 70 and/or the transaction data server 65 may be a part or partition of the risk management server 85, or may be a database stored within the risk management server or in another suitable location. The fraud data may include a set of transactions that have previously been found to be fraudulent . . .”) the risk management data server receives fraudulent transaction data. Fraudulent transaction list stored in the risk manager corresponds to blacklist status ;
Claim 13 is taught. Kala in view of Madisetti teaches: The electronic transaction system of claim 12. Madisetti further teaches: wherein the central unit is further configured to: requesting the blacklist-status from a blacklist register of the electronic transaction system, wherein the blacklist register preferably being: a centralized blacklist register within the electronic transaction system; a blacklist register of one or more service provider units issuing and/or managing the one of the plurality the secure transaction unit; upon receiving the blacklist-status from the blacklist register, generating, by means of a command-generator, a command for automatically transmitting all tokens that are currently stored in a storage means of the one of the plurality of transaction units to an online hosted target secure transaction unit, if the blacklist-status is fulfilled, wherein preferably the command further comprises information about the online target secure transaction unit to which all tokens are automatically transmitted (Madisetti, see at least par. [0151] “. . . The server 2806 may further comprise inter- and intra-blockchain messaging services 2824 and connectors for databases, cloud services & blockchain networks 2826. The server 2806 may further comprise Workers 2808 for processing requests and a list of blockchain clients 2812 of participating networks 2802. The server 2806 may further be positioned in communication with private and/or permissioned blockchain network for user identity management and secure transaction processing 2804. The server 2806 may use various smart contracts 2818 to bolster security. These smart contracts may be executed for each request from users 2800 and perform additional verification (such as verifying sender and receiver's address). The smart contracts may enforce checks such as time limits or quantity restrictions. Some smart contracts may perform functions similar to virus filters, for filtering out suspicious transactions . . .” & par. [0152] “ Referring now to FIG. 35 an illustration of an approach for securing multi-party linked smart contracts where transaction filters are part of a smart contract, is described in more detail. A filter smart contract 2904 may receive transfer requests from users 2900 for transfers on a blockchain network 2910 and check the transfer requests for suspicious activities using a filter and report identified suspicious transfer requests to the SQL or NoSQL or an Analytics Service 2912. Filters can be updated with new smart contracts. Some filters can be used to identify updates and some filters to flag security issues. Filters can block suspicious transactions, freeze funds stolen from smart contracts and even reverse the stolen funds back to the legitimate owners . . .”) The filters act as a secure transaction unit which is smart contract and stored in a online server.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kala in view of Madisetti by transmitting a command for black-listing as taught by Madisetti helps to better implement a security response to any inconsistency in transfer request. Therefore, the claimed invention is obvious in view of the cited references.
Claim 14 is taught. Kala in view of Madisetti teaches: The electronic transaction system of claim 11. Kala teaches: wherein the central unit is at least one of the following: a service provider unit providing one or more services for the one of the plurality of transaction units; a service provider unit issuing the one of the plurality of transaction units; a token issuer unit; a blacklist-register; a certificate revocation register; one or more token registers for registering tokens in the electronic transaction system; one or more protocol data registers for storing protocol data of transactions performed between secure transaction units (Kala, see at least par. [0018] “. . . Various computer servers may be connected via a digital communication network 60, such as one or more merchant servers 55, a fraud server 70, a transaction data server 65, an issuer server 80, and a merchant data server 90. The servers may interface with a digital communications network, such as the digital communication network 60 . . .”) transaction data server corresponds to payment transaction system.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Kala et al. (US 2021/0081948 A1) in view of Madisetti et al. (US 2022/0138733 A1) in further view of Bacastow (US 2022/0012740 A1).
Claim 8. Kala in view of Madisetti teaches: The secure transaction unit of claim 1. Bcastow, however, teaches: further comprising: transceiver means for directly transferring of tokens with other secure transaction units of the electronic transaction system to cause an exchange of the one or more tokens between secure transaction units in the electronic transaction system (Bacastow, see at least par. [0241] “. . . Tokens may be associated with the Mobile Device and used by the SPCD to validate the device. Tokens may also be associated with the Mobile PAN number to prevent fraudulent use of the Mobile PAN. Tokens may also be sent in lieu of sending biometric factors which may be validated locally on the mobile device. SPCD (25.6) validates the Mobile Approval Message in Step (25.22); validation completed using data received in Action Line (25.21), data comprised of one or more of a Mobile PIN, tokens, biometrics, or other factors such as the velocity of payment transactions submitted using this Mobile PAN and/or device . . .”); and preferably means for transmitting one or more registration requests to a token reference register of the electronic transaction system as the central unit, wherein each registration request comprises one or more token references, each token reference being uniquely assigned to a token in the electronic payment transaction system; and more preferably the control means further configured to generate protocol data related to payment transactions performed between the secure transaction unit and other secure transaction units, wherein the protocol data being sent to a protocol data register in the electronic payment transaction system as the central unit (par. [0241] “. . . For example, if the Mobile PAN is registered in the Venue, Biometric Table (FIG. 61), a body temperature reading may be required for a payment in excess of a specific amount at a POS location. Having approved the payment transaction for further processing, the SPCD (25.6) formats the Payment Approval Transaction by inserting a registered payment card number (e.g. Issuer PAN) or payment account unique identifier (such as PayPal Account registered email address or Bitcoin account no) and forwards Payment Approval Transaction to Acquirer (25.4) using Action Line (25.23). If the registered payment card number is one of a PIN Debit Account, payment approval data may be further formatted to include one of an alternate PIN, partial PIN, Issuer PIN, or other approved PIN Debit field (such as a null value, sequence number, or static value) as prescribed by and available in the Settings and Data Base Tables (25.7). The Payment Network (25.5) receives the Payment Transaction data contained in the Payment Approval Transaction and sends Payment Transaction to the appropriate Issuer for approval; Payment Transaction comprised of one more of an Issuer PAN, Tender Amount, and PIN Debit field (if required) . . .”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kala in view of Madisetti by transmitting a command for registration as taught by Bacastow to register the token for usage. Therefore, the claimed invention is obvious in view of the cited references.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Kala et al. (US 2021/0081948 A1) in view of Madisetti et al. (US 2022/0138733 A1) in further view of Liu, (US 2014/0033291 A1).
Claim 15 is taught: Kala in view of Madisetti teaches: The electronic transaction system of claim 11. Liu, however, teaches: wherein a blacklist-status is changed upon request from a participant to which the one of the plurality of transaction units is uniquely assigned, wherein the blacklist-status is fulfilled, if the one of the plurality of transaction units is stolen or is lost (Liu, par. [0083] “. . . In examples of the present disclosure, the third party application server may generate the access token with respect to the third party application password. Thus, even if the access token is stolen by a Trojan horse at the user's browser, the stealer cannot log on other third party application servers except for the third party application bound with the cloud platform, which effectively ensures the security of the user when visiting other third party applications and protect the user's experience from being hurt . . .”) the token could change its status when it is stolen by a virus or malware and secured in the platform.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kala in view of Madisetti by requesting black-list status when the transaction is stolen or lost as taught by Madisetti helps to better implement a security response to any inconsistency in transfer request. Therefore, the claimed invention is obvious in view of the cited references.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TOAN DUC BUI whose telephone number is (571)272-0833. The examiner can normally be reached M-F 8-5:00 PM.
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, Mike W. Anderson, can be reached at (571) 270-0508. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TOAN DUC BUI/Examiner, Art Unit 3693 /Mike Anderson/Supervisory Patent Examiner, Art Unit 3693