EP3490191A1 - Processing method of service requests performed by a service provider node - Google Patents
Processing method of service requests performed by a service provider node Download PDFInfo
- Publication number
- EP3490191A1 EP3490191A1 EP17203081.9A EP17203081A EP3490191A1 EP 3490191 A1 EP3490191 A1 EP 3490191A1 EP 17203081 A EP17203081 A EP 17203081A EP 3490191 A1 EP3490191 A1 EP 3490191A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- control data
- user
- service
- service request
- receiving
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/407—Cancellation of a transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1458—Denial of Service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Definitions
- Various embodiments of the invention relate to a controlled processing of service requests in an IT-based environment by taking into account a correlation of service requests and financial deposits concerning the respective service requests.
- IT-based services are used by many users. Most users have a legitimate interest in using such services, while others harmfully intend to overload such a service, e.g., in order to trigger collapse of such a service. As an example, Denial-of-service (DoS) attacks may be used to overload such an IT-based service due to a huge plurality of requests, which result in an immoderate processing effort.
- DoS Denial-of-service
- Denial of Service attacks are known.
- an attacker sends multiple service requests to a service provider node to cause overload and prevent the service provider node from processing legitimate service requests.
- An attacker may improve the efficiency of the attack by creating service requests that require little or limited processing power at the originator, but require significant processing power at the service provider node.
- a large count of service requests can be generated and remitted in parallel, e.g., using a plurality of originating nodes.
- the service provider node can be congested and overload can be caused. Often, an attacker may use the situation that remitting service requests requires fewer computational resources if compared to processing service requests.
- a further technique implements a service provider node using cloud-based computational resources. Then, in case of a Denial of Service attack, additional hardware resources can be dynamically provisioned to process all service requests.
- additional hardware resources can be dynamically provisioned to process all service requests.
- Thresholds for additional hardware resources are often required in order to avoid unexpected costs.
- a still further technique requires caching- /proxy providers for minimizing the service requests that have to be processed by the service provider node.
- Dynamic content typically, has to be processed by the service provider node and cannot be remanded to caching-/proxy providers.
- an attacker may have knowledge on the address of the service provider node and may therefore transmit service requests directly to the service provider node, thereby circumnavigating any caching- /proxy providers.
- a method for processing of service requests by a service provider node comprises receiving a first service request, which is remitted by a user.
- the method further comprises receiving first control data indicative of a first financial deposit, which is remitted by the user, wherein the first control data is referenced to at least one service request.
- the method further comprises processing the received first service request, if the received first control data is referenced to the received first service request.
- Such an approach is based on the fact that the operational point of time for processing a service request remitted or provided by a user may be controlled using control data related to a financial deposit of the respective service request.
- the controlled processing of service requests may be admitted when a financial deposit concerning or associated with the respective service request is remitted or executed by the user. Therefore, the method provides reliable services including protection against fraud including Denial of Service attacks. By requesting a financial deposit before processing a service request, Denial of Service attacks can be effectively mitigated service processing is protected by requiring the financial deposit.
- a service provider node adapted to process service requests.
- the service provider node comprises a control unit, which is adapted to receive a first service request, which is remitted by a user.
- the control unit is further adapted to receive a first control data indicative of a first financial deposit, which is remitted by the user, wherein the first control data is referenced to at least one service request.
- the control unit is further adapted to process the received first service request, if the received first control data is referenced to the received first service request.
- a service request within the meaning of the present disclosure may refer to any user-based inquiry which may intend the provision of a certain service.
- a service may relate to an IT-based service, e.g. a call of a web page sensor control, actuator control, Application Interface (API) access, HTTP GET or POST transactions, etc.
- the service request may be remitted by a user, i.e. triggered and received from a user.
- a service provider node within the meaning of the present disclosure may refer to any device, which is adapted to provide IT based services.
- the service provider node may be adapted to receive service requests and control data indicative of a financial deposit.
- the service provider node may also be adapted to provide a financial deposit.
- the service provider node may also be adapted to dispense control data indicative of a financial deposit.
- the service provider node may also be adapted to dispense a financial deposit.
- the service preorder node may be implemented by a server.
- a financial deposit within the meaning of the present disclosure may refer to a transaction of any financial value transferred from a first location to a second location or from a first holder to a second holer.
- the first location and/or the second location may be accessible to a user.
- the first location and/or the second location may also be accessible to a service provider.
- the method further comprises storing the received first control data, if the received first control data is not referenced to the received first service request. Hence, it is possible that processing of the service request is delayed. In another embodiment of the method, receiving the first service request is performed after receiving the first control data.
- the method further enables prepayments for services.
- the method therefore provides for a preferably flexible and user-friendly demand of services with costs.
- receiving the first service request and receiving the first control data is performed simultaneously.
- the method enables a preferably quick and simple processing of services protected by the financial deposits.
- the method further comprises receiving a second service request, which is remitted by the user.
- the method further comprises receiving a second control data indicative of a second financial deposit, which is remitted by the user, wherein the second control data is referenced to the at least one service request.
- This method further comprises processing the received second service request, if the received second control data is referenced to the received second service request.
- receiving the second service request and receiving the second control data is performed simultaneously.
- receiving the first control and the second control data is enabled by a token dispensed from the service provider node to the user in response to a collective financial transfer performed by the user to the service provider node.
- processing of a plurality of service request may be performed, wherein only a single financial transaction of a user has to be remitted.
- the method may reduce efforts dedicated by the user. Therefore, an improved user-friendliness may be achieved.
- the method further comprising dispensing a third control data indicative of a third financial deposit to the user in response to receiving the first control data based on an evaluation of a user criterion.
- the method may enable a refund of financial efforts to a user based on the specifications of the respective user.
- a refund of financial efforts of a user may be correlated with the legitimacy of a user for performing the service.
- Financial incentives may be provided, which may enable not to misapply such a service, wherein on the other hand, legitimated users may be reimbursed and may therefore be able to use the service in a preferably cost-efficient manner.
- the user criterion includes at least one of a) at least one service request remitted by the user, b) at least one login attempt of the user and c) financial resource information of the user.
- the behavior of the user concerning his requests for using a service may be analyzed in order to check whether such a user may be legitimated to use the respective service.
- the type of request, the point of time of such a request, variances with respect to the type of request as well as time difference in between two request may be analyzed in order to reliably examine the legitimacy of the respective user for using this service.
- success with respect to login attempts of the respective service may be analyzed in order to reliably examine whether such a user is legitimated for using this service.
- characteristics of an IT-based wallet of a user may be taken into consideration in order to evaluate whether such a user may be legitimated to use the respective service.
- the amount of financial resources deposited in the wallet, dynamics concerning these financial resources and the time of existence of such a wallet may be taken into account, in order to reliably examine the legitimacy of the respective user for using this service.
- the first control data and the third control data are identical.
- the method may therefore provide for a charge-free service in case that a user is legitimately using the respective service.
- the method further comprises dispensing a fourth control data indicative of a fourth financial deposit to the user in response to receiving the second control data based on an evaluation of at least one user criterion, wherein dispensing the third control data and the fourth control data is performed simultaneously.
- receiving the first service request and receiving the first control data is enabled by a data transfer using a distributed database.
- the method is configured more flexibly.
- receiving the first service request and receiving the first control data is enabled by a data transfer using a database based on a distributed ledger technology such as blockchain technology and/or a Directed Acyclic Graph.
- a distributed ledger technology such as blockchain technology and/or a Directed Acyclic Graph.
- a distributed ledger technology may be characterized by replicated, shared, and/or synchronized digital data that is reproduced at multiple sites. There may be no centralized control.
- data originating from different users may be processed at a high security level.
- the use of the database based on distributed ledger technology includes accessing a Smart Contract service.
- the processing power of the respective method may be reduced.
- an improved efficiency of the respective method may be achieved.
- receiving the first service request and receiving the first control data is enabled by a data transfer using a database based on Directed Acyclic Graph.
- Such an approach may e.g. be based on IOTA and may enable fast processing of service requests, in particular in case that service requests are remitted by a large count of users.
- the service provider node is adapted to perform the method according to any of the embodiments outlined above.
- a token within the meaning of the present disclosure may refer to any data object which is adapted to operate as an agent for supporting an IT-based trading. Such a token may be provided to a user as a trade-off compensating a financial transfer performed by the user. Such a token may enable the operation of IT-based services with costs. The token may also enable a plurality of such operations. The token may include unique checksums.
- a collective financial transfer within the meaning of the present disclosure may refer to any single financial transfer, which is operated to achieve a plurality of trade-offs.
- Such a financial transfer may be IT-based.
- a user, who intends to use an IT-based service, may perform such a financial transfer.
- a distributed database within the meaning of the present disclosure may refer to any database in which storage devices are not all attached to a common processor. Instead, they may be stored in multiple computers, located in the same physical location or may be dispersed over a network of interconnected computers.
- this involves use of financial deposits - e.g., facilitated by block chain technology, micro-transactions, and/or smart contracts.
- a legitimate service request is identified, it would be possible to reimburse any previously remitted financial deposit.
- a legitimate user can be identified based on behavior, a successful login, variances in the service request or based on a blockchain wallet. For example, it could be determined how long the block chain wallet has been in existence, whether it has a positive balance, etc,.
- an analysis of the behavior includes: during use of a service it is recorded which resources have been accessed by the user and what time offsets are between access to the various resources.
- Figure 1 schematically illustrates a processing network 18 according to various examples, which is adapted for interaction of a plurality of users 4 and a service provider node 2.
- Interaction of the plurality of user 4 and the service provider node 2 via data lines 19 may either be implemented in a direct manner (not depicted in Figure 1 ), or may be implemented via a database 16 collecting data of the respective user 4 in an organized manner.
- a distributed database or a database 16 based on blockchain technology may be used, or, generally, another kind of distributed ledger technology. With respect to the latter, it is also intended to include operation according to a Smart Contract service.
- the database 16 may also operate based on Directed Acyclic Graph, such as IOTA.
- the service provider node may comprise a control unit 17, which may be adapted to perform a processing method 100, 200 according to various examples of the present disclosure. For doing so, any service request 1 may be remitted by a user 4 and may then be received for processing the service provider node 2.
- Figure 2 represents a flowchart of a processing method 100 of service requests 1 by a service provider node 2 according to various examples.
- the service provider node 2 may receive first control data 5 indicative of a first financial deposit 6, which may be remitted by the user 4.
- the first control data may be referenced to at least one service request 1.
- the service provider node 2 may receive a first service request 1, which may be remitted by the user 4.
- receiving 120 the first service request 1 may be performed after receiving 110 the first control data 5.
- receiving 120 the first service request 1 and receiving 110 the first control data 5 may be performed simultaneously.
- the service provider node 2 may investigate whether the received first control data 5 can be referenced to or associated with the received fist service request 1. Hence, it can be checked if the at last one service request associated with the first control data watches the first service request. For example, checksums or tokes may be determined and compared. Links between the first control data 5 and the first service request may be checked. If the received first control data 5 may be referenced to the received first service request 3, the received first service request 3 may be processed 130 by the service provider node 2. Otherwise, the service provider node 2 may or may not store 135 the received first control data 5.
- Figure 3 represents a flowchart of another processing method 200 of service requests 1 by a service provider node 2 according to various examples.
- the service provider node 2 may receive first control data 5 indicating of a first financial deposit 6, which may be remitted by the user 4.
- the first control data may be referenced to at least one service request 1.
- the service provider node 2 may receive a first service request 3, which may be remitted by the user 4. As can be deduced from Figure 3 , it may be intended that receiving 220 the first service request 3 and receiving 210 the first control data 5 may be performed simultaneously.
- the service provider node 2 may investigate whether the received first control data 5 can be referenced to the received fist service request 3. If the received first control data 5 can be referenced to the received first service request 3, the received first service request 3 may be processed 230 by the service provider node 2. Otherwise, the service provider node 2 may or may not store 235 the received first control data 5.
- the service provider node 2 may receive 240 a second control data 8 indicative of a second financial deposit 9, which may be remitted by the user 4, wherein the second control data 8 may be referenced to the at least one service request 1.
- receiving 210, 240 the first control data 5 and the second control data 8 may be enabled by a token 10 dispensed from the service provider node 2 to the user 4 in response to a collective financial transfer 11 performed by the user 4 to the service provider node.
- the service provider node 2 may receive 250 a second service request 7, which may be remitted by the user 4.
- receiving 250 the second service request 7 by the service provider node 2 and receiving 240 the second control data 8 by the service provider node 2 may be performed simultaneously.
- the service provider node 2 may investigate whether the received second control data 8 can be referenced to the received second service request 7.
- the received second service request 7 may be selectively processed by the service provider node 2, if the received second control data 8 can be referenced to the received second service request 7.
- the service provider node 2 may dispense a third control data 12 to the user 4.
- a third control data 12 may be indicative of a third financial deposit 13.
- dispensing the third control data 12 may be performed in response to receiving 210 the first control data 5 based on an evaluation of a user criterion.
- a user criterion may include at least one of a) at least one service request 1 remitted by the user 4, b) at least one login attempt of the user 4 and c) financial resource information of the user 4.
- the first control data 5 and the third control data 12 may be identical: The respective financial deposits may be balanced.
- the service provider node 2 may dispense a fourth control data 14 to the user 4.
- the fourth control data 14 may be indicative of a fourth financial deposit 15.
- the fourth control data 14 may be dispensed in response to receiving 240 the second control data 8 based on an evaluation of at least one user criterion.
- dispensing 270, 280 the third control data 12 and the fourth control data 14 may be performed simultaneously.
- Figure 4 schematically illustrates a signaling diagram of a user 4 - i.e., a user device such as a computer, smartphone, laptop, etc. - and a service provider 2 node according to various examples.
- the signaling explained herein may or may not be performed in a processing network 18 according to Figure 1 .
- Signaling explained herein is depicted over an arbitrary time scale.
- a collective financial transfer 11 may be transferred from the user 4 to the service provider node 2.
- the service provider node 2 may subsequently transfer a token 10 to the user 4.
- Such a token 10 may be used by the user 4 to remit first control data 5 for transferring to the service provider node 2, wherein this first control data 5 are indicative of a first financial deposit 6.
- the user 4 may remit the transfer of a first service request 3 to the service provider node 2.
- Figure 5 schematically illustrates another signaling diagram of a user 4 and a service provider node 2 according to various examples.
- the signaling explained herein may or may not be performed in a processing network 18 according to Figure 1 .
- Signaling explained herein is depicted over an artificial time scale.
- a collective financial transfer 11 may be transferred from the user 4 to the service provider node 2.
- the service provider node 2 may subsequently transfer a token 10 to the user 4.
- Such a token 10 may be used by the user 4 to remit first control data 5 for transferring to the service provider node 2, wherein this first control data 5 are indicative of a first financial deposit 6.
- the user 4 may remit the transfer of a first service request 3 to the service provider node 2.
- Such a token 10 may also be used by the user 4 to remit second control data 8 for transferring to the service provider node 2, wherein this second control data 8 are indicative of a second financial deposit 9.
- the user 4 may remit the transfer of a second service request 7 to the service provider node 2.
- the service provider node 2 may then dispense a third control data 12 indicative of a third financial deposit 13 to the user 4 based on an evaluation of a user criterion as well as a fourth control data 14 indicative of a fourth financial deposit 15 to the user 4 based on an evaluation of at least one user criterion.
- dispensing the third control data 12 and the fourth control data 14 may be performed simultaneously.
- a user may remit a certain financial deposit within the block chain and, thereby, acquire a token.
- the token can then be used to remit a number of service requests to the service provider node. If during use of the service the user is identified as being legitimate, the remitted financial deposit can be reimbursed; if, however, the user is identified as being illegitimate, the remitted financial deposit can be locked and not be reimbursed.
- a user initially transmits the address of a bitcoin wallet to the service provider node.
- the service provider node can then create a user session being bound to or associated with that address of the wallet.
- the user remits prior to or substantially contemporaneously with each service request a financial deposit in the block chain, e.g., a few cents or dollars.
- the service provider node processes a service only if the respective financial deposit has been remitted and received. If the user is identified as being legitimate, the financial deposit can be reimbursed; or otherwise locked.
- the available attack vectors for denial of service attacks are effectively reduced to the initial request; the initial request can be implemented resource-efficiently and supported by sufficient computational resources.
- a proof can be required from the user that he/she is the legitimate owner of the wallet; such a proof can be implemented using a signed message from the respective address, or otherwise.
- a smart contract is implemented as an interface to the service provider node.
- a user accesses the service provider node via the smart contract and, for each service request, remits an accompanying financial deposit.
- Smart contracts enable, by design, to be only executed if a certain accompanying financial deposit has been remitted.
- Smart contracts are processed and executed from an associated block chain network which is typically in possession of more computational resources if compared to the service provider node or an attacker. The security of the block chain network is based on the fact that no attacker has the possibility to provide more than 50% of the total computational resources.
- the various techniques are based on the finding that it is possible to impose any financial damage caused by a Denial of Service attack on the attacker. Thus, costs at the service provider are avoided.
- the techniques described herein thus effectively protect processing of service request against Denial of Service attacks.
- the techniques described herein are easily implemented in the provisioning of a service. It is not required to provide a third party node.
- the techniques described herein are powerful and service continuity is insured. They are transparent, because smart contracts and coin-based financial deposits can be verified by the public and provide a large level of security. For example, any reimbursement of previously remitted financial deposits can be associated with the smart contract such that the claim can be easily enforced by the legitimate user.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Finance (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
- Various embodiments of the invention relate to a controlled processing of service requests in an IT-based environment by taking into account a correlation of service requests and financial deposits concerning the respective service requests.
- IT-based services are used by many users. Most users have a legitimate interest in using such services, while others harmfully intend to overload such a service, e.g., in order to trigger collapse of such a service. As an example, Denial-of-service (DoS) attacks may be used to overload such an IT-based service due to a huge plurality of requests, which result in an immoderate processing effort.
- Various kinds of Denial of Service attacks are known. Generally, an attacker sends multiple service requests to a service provider node to cause overload and prevent the service provider node from processing legitimate service requests. An attacker may improve the efficiency of the attack by creating service requests that require little or limited processing power at the originator, but require significant processing power at the service provider node. Alternatively or additionally, a large count of service requests can be generated and remitted in parallel, e.g., using a plurality of originating nodes. Using Denial of Service attacks, the service provider node can be congested and overload can be caused. Often, an attacker may use the situation that remitting service requests requires fewer computational resources if compared to processing service requests.
- Various techniques are known in order to protect processing of service requests against Denial of Service attacks. For example, additional hardware resources may be provided. This, however, is costly and requires additional administrative work. Thus, scalability is limited and, typically, even large-scale hardware resources can be overloaded when an attack is using a plurality of nodes for remitting service requests.
- A further technique implements a service provider node using cloud-based computational resources. Then, in case of a Denial of Service attack, additional hardware resources can be dynamically provisioned to process all service requests. However, also such a technique is costly, in particular where the additional hardware resources are dynamically allocated. Thresholds for additional hardware resources are often required in order to avoid unexpected costs.
- A still further technique requires caching- /proxy providers for minimizing the service requests that have to be processed by the service provider node. However, such an approach has limited efficiency if an attacker requests dynamic content. Dynamic content, typically, has to be processed by the service provider node and cannot be remanded to caching-/proxy providers. Furthermore, sometimes an attacker may have knowledge on the address of the service provider node and may therefore transmit service requests directly to the service provider node, thereby circumnavigating any caching- /proxy providers.
- Therefore, in order to provide a reliable, customer-oriented IT service, there is a need to control processing of IT-based service requests. Specifically, there is a need of protecting processing of service request against DoS attacks.
- It is an object to provide a method for processing of service requests in a controlled and reliable manner.
- A method and a service provider node according to the independent claims are provided. Further embodiments are defined in the dependent claims.
- According to an embodiment, a method for processing of service requests by a service provider node is disclosed. The method comprises receiving a first service request, which is remitted by a user. The method further comprises receiving first control data indicative of a first financial deposit, which is remitted by the user, wherein the first control data is referenced to at least one service request. The method further comprises processing the received first service request, if the received first control data is referenced to the received first service request.
- Such an approach is based on the fact that the operational point of time for processing a service request remitted or provided by a user may be controlled using control data related to a financial deposit of the respective service request. The controlled processing of service requests may be admitted when a financial deposit concerning or associated with the respective service request is remitted or executed by the user. Therefore, the method provides reliable services including protection against fraud including Denial of Service attacks. By requesting a financial deposit before processing a service request, Denial of Service attacks can be effectively mitigated service processing is protected by requiring the financial deposit.
- According to another embodiment, a service provider node adapted to process service requests is disclosed. Hereby, the service provider node comprises a control unit, which is adapted to receive a first service request, which is remitted by a user. The control unit is further adapted to receive a first control data indicative of a first financial deposit, which is remitted by the user, wherein the first control data is referenced to at least one service request. The control unit is further adapted to process the received first service request, if the received first control data is referenced to the received first service request.
- Such an approach enables the implementation of preferably simple technical means to perform the method outlined above in a reliable manner.
- A service request within the meaning of the present disclosure may refer to any user-based inquiry which may intend the provision of a certain service. Such a service may relate to an IT-based service, e.g. a call of a web page sensor control, actuator control, Application Interface (API) access, HTTP GET or POST transactions, etc. The service request may be remitted by a user, i.e. triggered and received from a user.
- A service provider node within the meaning of the present disclosure may refer to any device, which is adapted to provide IT based services. The service provider node may be adapted to receive service requests and control data indicative of a financial deposit. The service provider node may also be adapted to provide a financial deposit. The service provider node may also be adapted to dispense control data indicative of a financial deposit. The service provider node may also be adapted to dispense a financial deposit. The service preorder node may be implemented by a server.
- A financial deposit within the meaning of the present disclosure may refer to a transaction of any financial value transferred from a first location to a second location or from a first holder to a second holer. The first location and/or the second location may be accessible to a user. The first location and/or the second location may also be accessible to a service provider.
- In an embodiment of the method, the method further comprises storing the received first control data, if the received first control data is not referenced to the received first service request. Hence, it is possible that processing of the service request is delayed. In another embodiment of the method, receiving the first service request is performed after receiving the first control data.
- Thereby, the method further enables prepayments for services. The method therefore provides for a preferably flexible and user-friendly demand of services with costs.
- In another embodiment of the method, receiving the first service request and receiving the first control data is performed simultaneously.
- Thereby, since these transactions may be performed in a single shot, the method enables a preferably quick and simple processing of services protected by the financial deposits.
- In another embodiment of the method, the method further comprises receiving a second service request, which is remitted by the user. Hereby, the method further comprises receiving a second control data indicative of a second financial deposit, which is remitted by the user, wherein the second control data is referenced to the at least one service request. This method further comprises processing the received second service request, if the received second control data is referenced to the received second service request. Hereby, receiving the second service request and receiving the second control data is performed simultaneously. Further, receiving the first control and the second control data is enabled by a token dispensed from the service provider node to the user in response to a collective financial transfer performed by the user to the service provider node.
- Thereby, processing of a plurality of service request may be performed, wherein only a single financial transaction of a user has to be remitted. Thus, the method may reduce efforts dedicated by the user. Therefore, an improved user-friendliness may be achieved.
- In another embodiment of the method, the method further comprising dispensing a third control data indicative of a third financial deposit to the user in response to receiving the first control data based on an evaluation of a user criterion.
- Thereby, the method may enable a refund of financial efforts to a user based on the specifications of the respective user. As an example, a refund of financial efforts of a user may be correlated with the legitimacy of a user for performing the service. Financial incentives may be provided, which may enable not to misapply such a service, wherein on the other hand, legitimated users may be reimbursed and may therefore be able to use the service in a preferably cost-efficient manner.
- In another embodiment of the method, the user criterion includes at least one of a) at least one service request remitted by the user, b) at least one login attempt of the user and c) financial resource information of the user.
- Based on a), the behavior of the user concerning his requests for using a service may be analyzed in order to check whether such a user may be legitimated to use the respective service. Hereby, the type of request, the point of time of such a request, variances with respect to the type of request as well as time difference in between two request may be analyzed in order to reliably examine the legitimacy of the respective user for using this service.
- Based on b), success with respect to login attempts of the respective service may be analyzed in order to reliably examine whether such a user is legitimated for using this service.
- Based on c), characteristics of an IT-based wallet of a user may be taken into consideration in order to evaluate whether such a user may be legitimated to use the respective service. Hereby, the amount of financial resources deposited in the wallet, dynamics concerning these financial resources and the time of existence of such a wallet may be taken into account, in order to reliably examine the legitimacy of the respective user for using this service.
- In another embodiment of the method, the first control data and the third control data are identical.
- Thereby, it may be enabled that a user fulfilling the user criterion may completely be reimbursed from the remitted financial effort. The method may therefore provide for a charge-free service in case that a user is legitimately using the respective service.
- In another embodiment of the method, the method further comprises dispensing a fourth control data indicative of a fourth financial deposit to the user in response to receiving the second control data based on an evaluation of at least one user criterion, wherein dispensing the third control data and the fourth control data is performed simultaneously.
- Thereby, various reimbursements to a user fulfilling a certain user criterion, e.g. due to his evaluated legitimation for the respective service, may be executed contemporaneously. Thereby, the number of transactions in between the service provider node and the respective use may be reduced; thus an improved efficiency of the method is achieved.
- In another embodiment of the method, receiving the first service request and receiving the first control data is enabled by a data transfer using a distributed database.
- Thereby, the method is configured more flexibly.
- In another embodiment of the method, receiving the first service request and receiving the first control data is enabled by a data transfer using a database based on a distributed ledger technology such as blockchain technology and/or a Directed Acyclic Graph.
- A distributed ledger technology may be characterized by replicated, shared, and/or synchronized digital data that is reproduced at multiple sites. There may be no centralized control.
- Using such a decentralized database, data originating from different users may be processed at a high security level.
- In another embodiment of the method, the use of the database based on distributed ledger technology includes accessing a Smart Contract service.
- Using these means, the processing power of the respective method may be reduced. Thus, an improved efficiency of the respective method may be achieved.
- In an embodiment of the method, receiving the first service request and receiving the first control data is enabled by a data transfer using a database based on Directed Acyclic Graph.
- Such an approach may e.g. be based on IOTA and may enable fast processing of service requests, in particular in case that service requests are remitted by a large count of users.
- In another embodiment of the service provider node, the service provider node is adapted to perform the method according to any of the embodiments outlined above.
- Such an approach enables the implementation of preferably simple technical means to perform any of the methods outlined above in a reliable manner.
- A token within the meaning of the present disclosure may refer to any data object which is adapted to operate as an agent for supporting an IT-based trading. Such a token may be provided to a user as a trade-off compensating a financial transfer performed by the user. Such a token may enable the operation of IT-based services with costs. The token may also enable a plurality of such operations. The token may include unique checksums.
- A collective financial transfer within the meaning of the present disclosure may refer to any single financial transfer, which is operated to achieve a plurality of trade-offs. Such a financial transfer may be IT-based. A user, who intends to use an IT-based service, may perform such a financial transfer.
- A distributed database within the meaning of the present disclosure may refer to any database in which storage devices are not all attached to a common processor. Instead, they may be stored in multiple computers, located in the same physical location or may be dispersed over a network of interconnected computers.
- The above summary is merely intended to give a short overview over some features of some embodiments and implementations and is not to be construed as limiting. Other embodiments may comprise other features than the ones explained above.
- The above and other elements, features, steps and characteristics of the present disclosure will be more apparent from the following detailed description of embodiments with reference to the following figures:
-
Figure 1 schematically illustrates a processing network according to various examples, which is adapted for interaction of a plurality of users and a service provider node. -
Figure 2 represents a flowchart of a processing method of service requests by a service provider node according to various examples. -
Figure 3 represents a flowchart of another processing method of service requests by a service provider node according to various examples. -
Figure 4 schematically illustrates a signaling diagram of a user and a service provider node according to various examples. -
Figure 5 schematically illustrates another signaling diagram of a user and a service provider node according to various examples. - In the following, embodiments of the invention will be described in detail with reference to the accompanying drawings. It is to be understood that the following description of embodiments is not to be taken in a limiting sense. The scope of the invention is not intended to be limited by the embodiments described hereinafter or by the drawings, which are taken to be illustrative only.
- The drawings are to be regarded as being schematic representations and elements illustrated in the drawings, which are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose become apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components, or other physical or functional units shown in the drawings or described herein may also be implemented by an indirect connection or coupling. A coupling between components may also be established over a wireless connection. Functional blocks may be implemented in hardware, firmware, software, or a combination thereof.
- Hereinafter, techniques of processing service requests are described. Specifically, techniques of protecting said processing of the service requests against Denial of Service attacks are described.
- According to various embodiments, this involves use of financial deposits - e.g., facilitated by block chain technology, micro-transactions, and/or smart contracts.
- It is, e.g., possible to accompany a service request with a financial deposit. Processing of the service requires remittance of the financial deposit. Thereby, illegitimate service requests may be penalized by loss of the financial deposit. Such techniques are based on the finding that, in particular, Denial of Service attacks are typically implemented using a large count of service requests; such that the aggregated financial penalty may effectively prevent the Denial of Service attack. The high security level of distributed ledger technology such as blockchain technology may be used to protect the processing of the service requests.
- If a legitimate service request is identified, it would be possible to reimburse any previously remitted financial deposit. A legitimate user can be identified based on behavior, a successful login, variances in the service request or based on a blockchain wallet. For example, it could be determined how long the block chain wallet has been in existence, whether it has a positive balance, etc,. In an example, an analysis of the behavior includes: during use of a service it is recorded which resources have been accessed by the user and what time offsets are between access to the various resources. If, for example, during the entire use of the service the same resources accessed over and over, and there are only a few milliseconds between the different accesses, then there is a large possibility that the use of the resources related to illegitimate service requests triggered, e.g., by an automatic script and not by human behavior.
-
Figure 1 schematically illustrates aprocessing network 18 according to various examples, which is adapted for interaction of a plurality of users 4 and aservice provider node 2. Interaction of the plurality of user 4 and theservice provider node 2 viadata lines 19 may either be implemented in a direct manner (not depicted inFigure 1 ), or may be implemented via adatabase 16 collecting data of the respective user 4 in an organized manner. Hereby, a distributed database or adatabase 16 based on blockchain technology may be used, or, generally, another kind of distributed ledger technology. With respect to the latter, it is also intended to include operation according to a Smart Contract service. Further, thedatabase 16 may also operate based on Directed Acyclic Graph, such as IOTA. The service provider node may comprise acontrol unit 17, which may be adapted to perform aprocessing method service provider node 2. -
Figure 2 represents a flowchart of aprocessing method 100 of service requests 1 by aservice provider node 2 according to various examples. - At 110, the
service provider node 2 may receivefirst control data 5 indicative of a firstfinancial deposit 6, which may be remitted by the user 4. Hereby, the first control data may be referenced to at least one service request 1. - At 120, the
service provider node 2 may receive a first service request 1, which may be remitted by the user 4. Hereby, receiving 120 the first service request 1 may be performed after receiving 110 thefirst control data 5. However, it is also intended that receiving 120 the first service request 1 and receiving 110 thefirst control data 5 may be performed simultaneously. - At 125, the
service provider node 2 may investigate whether the receivedfirst control data 5 can be referenced to or associated with the received fist service request 1. Hence, it can be checked if the at last one service request associated with the first control data watches the first service request. For example, checksums or tokes may be determined and compared. Links between thefirst control data 5 and the first service request may be checked. If the receivedfirst control data 5 may be referenced to the receivedfirst service request 3, the receivedfirst service request 3 may be processed 130 by theservice provider node 2. Otherwise, theservice provider node 2 may or may not store 135 the receivedfirst control data 5. -
Figure 3 represents a flowchart of anotherprocessing method 200 of service requests 1 by aservice provider node 2 according to various examples. - At 210, the
service provider node 2 may receivefirst control data 5 indicating of a firstfinancial deposit 6, which may be remitted by the user 4. Hereby, the first control data may be referenced to at least one service request 1. - At 220, the
service provider node 2 may receive afirst service request 3, which may be remitted by the user 4. As can be deduced fromFigure 3 , it may be intended that receiving 220 thefirst service request 3 and receiving 210 thefirst control data 5 may be performed simultaneously. - At 225, the
service provider node 2 may investigate whether the receivedfirst control data 5 can be referenced to the receivedfist service request 3. If the receivedfirst control data 5 can be referenced to the receivedfirst service request 3, the receivedfirst service request 3 may be processed 230 by theservice provider node 2. Otherwise, theservice provider node 2 may or may not store 235 the receivedfirst control data 5. - At 240, the
service provider node 2 may receive 240 asecond control data 8 indicative of a second financial deposit 9, which may be remitted by the user 4, wherein thesecond control data 8 may be referenced to the at least one service request 1. Hereby, receiving 210, 240 thefirst control data 5 and thesecond control data 8 may be enabled by a token 10 dispensed from theservice provider node 2 to the user 4 in response to a collectivefinancial transfer 11 performed by the user 4 to the service provider node. - At 250, the
service provider node 2 may receive 250 asecond service request 7, which may be remitted by the user 4. Hereby, receiving 250 thesecond service request 7 by theservice provider node 2 and receiving 240 thesecond control data 8 by theservice provider node 2 may be performed simultaneously. - At 255, the
service provider node 2 may investigate whether the receivedsecond control data 8 can be referenced to the receivedsecond service request 7. - At 260, the received
second service request 7 may be selectively processed by theservice provider node 2, if the receivedsecond control data 8 can be referenced to the receivedsecond service request 7. - At 270, the
service provider node 2 may dispense a third control data 12 to the user 4. Such a third control data 12 may be indicative of a third financial deposit 13. Hereby, dispensing the third control data 12 may be performed in response to receiving 210 thefirst control data 5 based on an evaluation of a user criterion. Such a user criterion may include at least one of a) at least one service request 1 remitted by the user 4, b) at least one login attempt of the user 4 and c) financial resource information of the user 4. Thefirst control data 5 and the third control data 12 may be identical: The respective financial deposits may be balanced. - At 280, the
service provider node 2 may dispense a fourth control data 14 to the user 4. Hereby, the fourth control data 14 may be indicative of a fourth financial deposit 15. The fourth control data 14 may be dispensed in response to receiving 240 thesecond control data 8 based on an evaluation of at least one user criterion. Hereby, dispensing 270, 280 the third control data 12 and the fourth control data 14 may be performed simultaneously. -
Figure 4 schematically illustrates a signaling diagram of a user 4 - i.e., a user device such as a computer, smartphone, laptop, etc. - and aservice provider 2 node according to various examples. The signaling explained herein may or may not be performed in aprocessing network 18 according toFigure 1 . Signaling explained herein is depicted over an arbitrary time scale. - At first, a collective
financial transfer 11 may be transferred from the user 4 to theservice provider node 2. For trade-off reasons, theservice provider node 2 may subsequently transfer a token 10 to the user 4. Such a token 10 may be used by the user 4 to remitfirst control data 5 for transferring to theservice provider node 2, wherein thisfirst control data 5 are indicative of a firstfinancial deposit 6. Simultaneously or subsequently, the user 4 may remit the transfer of afirst service request 3 to theservice provider node 2. -
Figure 5 schematically illustrates another signaling diagram of a user 4 and aservice provider node 2 according to various examples. The signaling explained herein may or may not be performed in aprocessing network 18 according toFigure 1 . Signaling explained herein is depicted over an artificial time scale. - At first, a collective
financial transfer 11 may be transferred from the user 4 to theservice provider node 2. For trade-off reasons, theservice provider node 2 may subsequently transfer a token 10 to the user 4. Such a token 10 may be used by the user 4 to remitfirst control data 5 for transferring to theservice provider node 2, wherein thisfirst control data 5 are indicative of a firstfinancial deposit 6. Simultaneously, the user 4 may remit the transfer of afirst service request 3 to theservice provider node 2. Such a token 10 may also be used by the user 4 to remitsecond control data 8 for transferring to theservice provider node 2, wherein thissecond control data 8 are indicative of a second financial deposit 9. Simultaneously, the user 4 may remit the transfer of asecond service request 7 to theservice provider node 2. Theservice provider node 2 may then dispense a third control data 12 indicative of a third financial deposit 13 to the user 4 based on an evaluation of a user criterion as well as a fourth control data 14 indicative of a fourth financial deposit 15 to the user 4 based on an evaluation of at least one user criterion. Hereby, dispensing the third control data 12 and the fourth control data 14 may be performed simultaneously. - Summarizing, above, various techniques of protecting processing of service requests against Denial of Service attacks by requiring accompanying financial deposits have been described. Various examples of implementation are possible.
- For example, a user may remit a certain financial deposit within the block chain and, thereby, acquire a token. The token can then be used to remit a number of service requests to the service provider node. If during use of the service the user is identified as being legitimate, the remitted financial deposit can be reimbursed; if, however, the user is identified as being illegitimate, the remitted financial deposit can be locked and not be reimbursed.
- In a further example, a user initially transmits the address of a bitcoin wallet to the service provider node. The service provider node can then create a user session being bound to or associated with that address of the wallet. During the user session the user remits prior to or substantially contemporaneously with each service request a financial deposit in the block chain, e.g., a few cents or dollars. The service provider node processes a service only if the respective financial deposit has been remitted and received. If the user is identified as being legitimate, the financial deposit can be reimbursed; or otherwise locked. In such an implementation the available attack vectors for denial of service attacks are effectively reduced to the initial request; the initial request can be implemented resource-efficiently and supported by sufficient computational resources. For avoiding intentional spam for creation of a large count of user sessions having randomized addresses of wallets, a proof can be required from the user that he/she is the legitimate owner of the wallet; such a proof can be implemented using a signed message from the respective address, or otherwise.
- In yet a further example, a smart contract is implemented as an interface to the service provider node. A user accesses the service provider node via the smart contract and, for each service request, remits an accompanying financial deposit. Smart contracts enable, by design, to be only executed if a certain accompanying financial deposit has been remitted. Smart contracts are processed and executed from an associated block chain network which is typically in possession of more computational resources if compared to the service provider node or an attacker. The security of the block chain network is based on the fact that no attacker has the possibility to provide more than 50% of the total computational resources.
- Thus, the various techniques are based on the finding that it is possible to impose any financial damage caused by a Denial of Service attack on the attacker. Thus, costs at the service provider are avoided. The techniques described herein thus effectively protect processing of service request against Denial of Service attacks. The techniques described herein are easily implemented in the provisioning of a service. It is not required to provide a third party node. By its underlying design, the techniques described herein are powerful and service continuity is insured. They are transparent, because smart contracts and coin-based financial deposits can be verified by the public and provide a large level of security. For example, any reimbursement of previously remitted financial deposits can be associated with the smart contract such that the claim can be easily enforced by the legitimate user.
Claims (15)
- A method (100, 200) for processing of service requests (1) by a service provider node (2), the method (100, 200) comprising:Receiving (120, 220) a first service request (3), which is remitted by a user (4);Receiving (110, 210) first control data (5) indicative of a first financial deposit (6), which is remitted by the user (4), wherein the first control data (5) is referenced to at least one service request (1); andProcessing (130, 230) the received first service request (3), if the received first control data (5) is referenced to the received first service request (3).
- The method (100, 200) of claim 1, further comprising storing (135, 235) the received first control data (5), if the received first control data (5) is not referenced to the received first service request (3).
- The method (100, 200) of any of claims 1 and 2, wherein receiving (120, 220) the first service request (3) is performed after receiving (110, 210) the first control data (5).
- The method (100, 200) of any of claims 1 and 2, wherein receiving (120,220) the first service request (3) and receiving (110, 210) the first control data (5) is performed simultaneously.
- The method (100, 200) of claim 4, further comprising
Receiving (250) a second service request (7), which is remitted by the user (4);
Receiving (240) second control data (8) indicative of a second financial deposit (9), which is remitted by the user (4), wherein the second control data (8) is referenced to the at least one service request (1); and
Processing (260) the received second service request (7), if the received second control data (8) is referenced to the received second service request (7),
wherein receiving (250) the second service request (7) and receiving (240) the second control data (8) is performed simultaneously, and
wherein receiving (110, 210, 240) the first control data (5) and the second control data (8) is enabled by a token (10) dispensed from the service provider node (2) to the user (4) in response to a collective financial transfer (11) performed by the user (4) to the service provider node (2). - The method (100, 200) of any of the preceding claims, further comprising dispensing (270) a third control data (12) indicative of a third financial deposit (13) to the user (4) in response to receiving (110, 210) the first control data (5) and based on an evaluation of a user criterion.
- The method (200) of claim 6, wherein the user criterion includes at least one of a) at least one service request (1) remitted by the user (4), b) at least one login attempt of the user (4) and c) financial resource information of the user (4).
- The method (200) of any of claims 6 and 7, wherein the first control data (5) and the third control data (12) are identical.
- The method (200) of claim 5 and any of claims 6 to 8, further comprising dispensing (280) fourth control data (14) indicative of a fourth financial deposit (15) to the user (4) in response to receiving (240) the second control data (8) based on an evaluation of at least one user criterion, wherein dispensing (270, 280) the third control data (12) and the fourth control data (14) is performed simultaneously.
- The method (100, 200) of any of the preceding claims, wherein receiving (120, 220) the first service request (3) and receiving (110, 210) the first control data (5) is enabled by a data transfer using a distributed database.
- The method (100, 200) of any of claims 1 to 9, wherein receiving (120, 220) the first service request (3) and receiving (110, 210) the first control data (5) is enabled by a data transfer using a database (16) based on distributed ledger technology.
- The method (100, 200) of claim 11, wherein the use of the database (16) based on distributed ledger technology includes accessing a Smart Contract service.
- The method (100, 200) of any of claims 1 to 9, wherein receiving (120, 220) the first service request (3) and receiving (110, 210) the first control data (5) is enabled by a data transfer using a database (16) based on Directed Acyclic Graph.
- A service provider node (2) adapted to process service requests (1) and comprising a control unit (17), which is adapted to:Receive a first service request (3), which is remitted by a user (4);Receive a first control data (5) indicative of a first financial deposit (6), which is remitted by the user (4), wherein the first control data (5) is referenced to at least one service request (1); andProcess the received first service request (3), if the received first control data (5) is referenced to the received first service request (3).
- The service provider node (2) of claim 14, which is adapted to perform the method (100, 200) according to any of claims 1 to 13.
Priority Applications (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP17203081.9A EP3490191B1 (en) | 2017-11-22 | 2017-11-22 | Processing method of service requests performed by a service provider node |
LTEP17203081.9T LT3490191T (en) | 2017-11-22 | 2017-11-22 | Processing method of service requests performed by a service provider node |
BR112020009961-9A BR112020009961A2 (en) | 2017-11-22 | 2018-10-17 | method of processing service requests made by a service provider node |
KR1020207017688A KR102189203B1 (en) | 2017-11-22 | 2018-10-17 | How to process service requests performed by service provider nodes |
PCT/EP2018/078348 WO2019101446A1 (en) | 2017-11-22 | 2018-10-17 | Processing method of service requests performed by a service provider node |
US16/764,452 US20200364715A1 (en) | 2017-11-22 | 2018-10-17 | Processing method of service requests performed by a service provider node |
RU2020120151A RU2735181C1 (en) | 2017-11-22 | 2018-10-17 | Method of processing service requests executed by service provider unit |
SG11202004235VA SG11202004235VA (en) | 2017-11-22 | 2018-10-17 | Processing method of service requests performed by a service provider node |
CN201880087352.1A CN111602369A (en) | 2017-11-22 | 2018-10-17 | Method for processing service requests performed by a service provider node |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP17203081.9A EP3490191B1 (en) | 2017-11-22 | 2017-11-22 | Processing method of service requests performed by a service provider node |
Publications (2)
Publication Number | Publication Date |
---|---|
EP3490191A1 true EP3490191A1 (en) | 2019-05-29 |
EP3490191B1 EP3490191B1 (en) | 2020-01-15 |
Family
ID=60473312
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP17203081.9A Active EP3490191B1 (en) | 2017-11-22 | 2017-11-22 | Processing method of service requests performed by a service provider node |
Country Status (9)
Country | Link |
---|---|
US (1) | US20200364715A1 (en) |
EP (1) | EP3490191B1 (en) |
KR (1) | KR102189203B1 (en) |
CN (1) | CN111602369A (en) |
BR (1) | BR112020009961A2 (en) |
LT (1) | LT3490191T (en) |
RU (1) | RU2735181C1 (en) |
SG (1) | SG11202004235VA (en) |
WO (1) | WO2019101446A1 (en) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5715314A (en) * | 1994-10-24 | 1998-02-03 | Open Market, Inc. | Network sales system |
US20150278397A1 (en) * | 2014-03-31 | 2015-10-01 | Amazon Technologies, Inc. | Namespace management in distributed storage systems |
WO2017145018A1 (en) * | 2016-02-23 | 2017-08-31 | nChain Holdings Limited | A method and system for the secure transfer of entities on a blockchain |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6986040B1 (en) * | 2000-11-03 | 2006-01-10 | Citrix Systems, Inc. | System and method of exploiting the security of a secure communication channel to secure a non-secure communication channel |
US8996423B2 (en) * | 2005-04-19 | 2015-03-31 | Microsoft Corporation | Authentication for a commercial transaction using a mobile module |
US8977567B2 (en) * | 2008-09-22 | 2015-03-10 | Visa International Service Association | Recordation of electronic payment transaction information |
EA021508B1 (en) * | 2011-08-24 | 2015-07-30 | Открытое Акционерное Общество "Инфотекс" | Method of protected data exchange in e-auction and system for implementation thereof |
WO2017145020A1 (en) * | 2016-02-23 | 2017-08-31 | nChain Holdings Limited | Methods and systems for efficient transfer of entities on a peer-to-peer distributed ledger using the blockchain |
IL261210B (en) * | 2016-02-23 | 2022-08-01 | Nchain Holdings Ltd | Blockchain-based exchange with tokenisation |
RU2634174C1 (en) * | 2016-10-10 | 2017-10-24 | Акционерное общество "Лаборатория Касперского" | System and method of bank transaction execution |
-
2017
- 2017-11-22 EP EP17203081.9A patent/EP3490191B1/en active Active
- 2017-11-22 LT LTEP17203081.9T patent/LT3490191T/en unknown
-
2018
- 2018-10-17 SG SG11202004235VA patent/SG11202004235VA/en unknown
- 2018-10-17 BR BR112020009961-9A patent/BR112020009961A2/en active Search and Examination
- 2018-10-17 CN CN201880087352.1A patent/CN111602369A/en active Pending
- 2018-10-17 RU RU2020120151A patent/RU2735181C1/en active
- 2018-10-17 KR KR1020207017688A patent/KR102189203B1/en active IP Right Grant
- 2018-10-17 WO PCT/EP2018/078348 patent/WO2019101446A1/en active Application Filing
- 2018-10-17 US US16/764,452 patent/US20200364715A1/en not_active Abandoned
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5715314A (en) * | 1994-10-24 | 1998-02-03 | Open Market, Inc. | Network sales system |
US20150278397A1 (en) * | 2014-03-31 | 2015-10-01 | Amazon Technologies, Inc. | Namespace management in distributed storage systems |
WO2017145018A1 (en) * | 2016-02-23 | 2017-08-31 | nChain Holdings Limited | A method and system for the secure transfer of entities on a blockchain |
Also Published As
Publication number | Publication date |
---|---|
BR112020009961A2 (en) | 2020-10-13 |
RU2735181C1 (en) | 2020-10-28 |
LT3490191T (en) | 2020-04-10 |
KR20200078673A (en) | 2020-07-01 |
WO2019101446A1 (en) | 2019-05-31 |
KR102189203B1 (en) | 2020-12-09 |
SG11202004235VA (en) | 2020-06-29 |
CN111602369A (en) | 2020-08-28 |
US20200364715A1 (en) | 2020-11-19 |
EP3490191B1 (en) | 2020-01-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3520060B1 (en) | Method and system for providing a transaction forwarding service in blockchain implementations | |
US10749884B2 (en) | Systems and methods for detecting and preventing spoofing | |
US10270792B1 (en) | Methods for detecting malicious smart bots to improve network security and devices thereof | |
Xuan et al. | Detecting application denial-of-service attacks: A group-testing-based approach | |
CN112363991B (en) | Block chain data registration method and device | |
KR20120085821A (en) | Network communication system, server system and terminals | |
US20160352775A1 (en) | Identifying suspicious activity in a load test | |
CN110033280B (en) | Payment anti-shake method and device | |
CN110365712A (en) | A kind of defence method and system of distributed denial of service attack | |
CN111260475A (en) | Data processing method, block chain node point equipment and storage medium | |
CN110351364A (en) | Date storage method, equipment and computer readable storage medium | |
CN112948499A (en) | Information acquisition method and device, electronic equipment and storage medium | |
Taneja et al. | Information Security in cloud computing: A Systematic Literature Review and analysis | |
CN107623693A (en) | Domain name mapping means of defence and device, system, computing device, storage medium | |
JP7102780B2 (en) | Unauthorized communication countermeasure system and method | |
CN102243738A (en) | Safety payment system and method | |
EP3490191B1 (en) | Processing method of service requests performed by a service provider node | |
EP2701068B1 (en) | Network access system | |
CN114827259B (en) | Data processing method, computer readable storage medium and device | |
JP6870386B2 (en) | Malware unauthorized communication countermeasure system and method | |
CN114157482A (en) | Service access control method, device, control equipment and storage medium | |
CN112637316B (en) | Communication method and device | |
CN116032570B (en) | Network access management method, device, electronic equipment and storage medium | |
CN118842864A (en) | Telephone number privacy protection method, system, equipment and medium | |
CN113489726A (en) | Flow limiting method and device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20180219 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
INTG | Intention to grant announced |
Effective date: 20190916 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE PATENT HAS BEEN GRANTED |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP Ref country code: GB Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 602017010893 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: REF Ref document number: 1226131 Country of ref document: AT Kind code of ref document: T Effective date: 20200215 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: NV Representative=s name: SIEMENS SCHWEIZ AG, CH |
|
REG | Reference to a national code |
Ref country code: SE Ref legal event code: TRGR |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: MP Effective date: 20200115 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: RS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 Ref country code: FI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 Ref country code: NO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200415 Ref country code: PT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200607 Ref country code: NL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200515 Ref country code: LV Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 Ref country code: GR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200416 Ref country code: BG Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200415 Ref country code: HR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 602017010893 Country of ref document: DE |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 Ref country code: ES Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 Ref country code: CZ Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 Ref country code: RO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 Ref country code: DK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 Ref country code: SM Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 Ref country code: EE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: MK05 Ref document number: 1226131 Country of ref document: AT Kind code of ref document: T Effective date: 20200115 |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
26N | No opposition filed |
Effective date: 20201016 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: AT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: FR Payment date: 20201112 Year of fee payment: 4 Ref country code: LT Payment date: 20201022 Year of fee payment: 4 Ref country code: SE Payment date: 20201105 Year of fee payment: 4 Ref country code: IT Payment date: 20201130 Year of fee payment: 4 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: PL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: CH Payment date: 20210202 Year of fee payment: 4 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: DE Payment date: 20210119 Year of fee payment: 4 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MC Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LU Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20201122 |
|
REG | Reference to a national code |
Ref country code: BE Ref legal event code: MM Effective date: 20201130 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20201122 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: TR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 Ref country code: MT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 Ref country code: CY Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R119 Ref document number: 602017010893 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: LT Ref legal event code: MM4D Effective date: 20211122 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 Ref country code: AL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: PL |
|
GBPC | Gb: european patent ceased through non-payment of renewal fee |
Effective date: 20211122 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20211123 Ref country code: LT Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20211122 Ref country code: BE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20201130 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: GB Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20211122 Ref country code: DE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20220601 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: FR Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20211130 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IT Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20211122 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LI Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20220630 Ref country code: CH Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20220630 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200115 |