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 PDF

Info

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
Application number
EP17203081.9A
Other languages
German (de)
French (fr)
Other versions
EP3490191B1 (en
Inventor
Michael Kirchner
Benedikt Vamos
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority to EP17203081.9A priority Critical patent/EP3490191B1/en
Application filed by Siemens AG filed Critical Siemens AG
Priority to LTEP17203081.9T priority patent/LT3490191T/en
Priority to BR112020009961-9A priority patent/BR112020009961A2/en
Priority to PCT/EP2018/078348 priority patent/WO2019101446A1/en
Priority to US16/764,452 priority patent/US20200364715A1/en
Priority to CN201880087352.1A priority patent/CN111602369A/en
Priority to KR1020207017688A priority patent/KR102189203B1/en
Priority to RU2020120151A priority patent/RU2735181C1/en
Priority to SG11202004235VA priority patent/SG11202004235VA/en
Publication of EP3490191A1 publication Critical patent/EP3490191A1/en
Application granted granted Critical
Publication of EP3490191B1 publication Critical patent/EP3490191B1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/401Transaction verification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/401Transaction verification
    • G06Q20/4014Identity check for transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/407Cancellation of a transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • H04L63/1458Denial of Service
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3236Cryptographic 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/3239Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3247Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial 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.

Abstract

An object of the present application is to provide a method for processing of service requests by a service provider node. Hereby, 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.

Description

    TECHNICAL FIELD
  • 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.
  • BACKGROUND
  • 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.
  • SUMMARY
  • 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.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • 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.
    DETAILED DESCRIPTION OF EMBODIMENTS
  • 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 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. Hereby, 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. Further, 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.
  • At 110, 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. 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 the first control data 5. However, it is also intended that receiving 120 the first service request 1 and receiving 110 the first control data 5 may be performed simultaneously.
  • At 125, 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.
  • At 210, 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. Hereby, the first control data may be referenced to at least one service request 1.
  • At 220, 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.
  • At 225, 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.
  • At 240, 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. Hereby, 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.
  • At 250, the service provider node 2 may receive 250 a second service request 7, which may be remitted by the user 4. Hereby, 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.
  • At 255, the service provider node 2 may investigate whether the received second control data 8 can be referenced to the received second service request 7.
  • At 260, 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.
  • 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 the first 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. The first 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 the second 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 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.
  • At first, a collective financial transfer 11 may be transferred from the user 4 to the service provider node 2. For trade-off reasons, 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. Simultaneously or subsequently, 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.
  • At first, a collective financial transfer 11 may be transferred from the user 4 to the service provider node 2. For trade-off reasons, 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. Simultaneously, 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. Simultaneously, 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. 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)

  1. 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); and
    Processing (130, 230) the received first service request (3), if the received first control data (5) is referenced to the received first service request (3).
  2. 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).
  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).
  4. 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.
  5. 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).
  6. 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.
  7. 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).
  8. The method (200) of any of claims 6 and 7, wherein the first control data (5) and the third control data (12) are identical.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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); and
    Process the received first service request (3), if the received first control data (5) is referenced to the received first service request (3).
  15. 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.
EP17203081.9A 2017-11-22 2017-11-22 Processing method of service requests performed by a service provider node Active EP3490191B1 (en)

Priority Applications (9)

Application Number Priority Date Filing Date Title
LTEP17203081.9T LT3490191T (en) 2017-11-22 2017-11-22 Processing method of service requests performed by a service provider node
EP17203081.9A EP3490191B1 (en) 2017-11-22 2017-11-22 Processing method of service requests performed by a service provider node
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
BR112020009961-9A BR112020009961A2 (en) 2017-11-22 2018-10-17 method of processing service requests made 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
KR1020207017688A KR102189203B1 (en) 2017-11-22 2018-10-17 How to process service requests performed by service provider nodes
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

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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
EP3420518B1 (en) * 2016-02-23 2023-08-23 nChain Licensing AG Methods and systems for efficient transfer of entities on a peer-to-peer distributed ledger using the blockchain
US11625694B2 (en) * 2016-02-23 2023-04-11 Nchain Licensing Ag Blockchain-based exchange with tokenisation
RU2634174C1 (en) * 2016-10-10 2017-10-24 Акционерное общество "Лаборатория Касперского" System and method of bank transaction execution

Patent Citations (3)

* Cited by examiner, † Cited by third party
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
KR20200078673A (en) 2020-07-01
RU2735181C1 (en) 2020-10-28
CN111602369A (en) 2020-08-28
BR112020009961A2 (en) 2020-10-13
WO2019101446A1 (en) 2019-05-31
EP3490191B1 (en) 2020-01-15
US20200364715A1 (en) 2020-11-19
LT3490191T (en) 2020-04-10
KR102189203B1 (en) 2020-12-09
SG11202004235VA (en) 2020-06-29

Similar Documents

Publication Publication Date Title
US10749884B2 (en) Systems and methods for detecting and preventing spoofing
US11128603B2 (en) Method and system for providing a transaction forwarding service in blockchain implementations
US10270792B1 (en) Methods for detecting malicious smart bots to improve network security and devices thereof
CN104601601B (en) The detection method and device of web crawlers
Xuan et al. Detecting application denial-of-service attacks: A group-testing-based approach
KR20120085821A (en) Network communication system, server system and terminals
CN112363991B (en) Block chain data registration method and device
CN110033280B (en) Payment anti-shake method and device
US20160352775A1 (en) Identifying suspicious activity in a load test
CN110365712A (en) A kind of defence method and system of distributed denial of service attack
US20170289354A1 (en) System and Method for Allocation And Management Of Shared Virtual Numbers
CN111260475A (en) Data processing method, block chain node point equipment and storage medium
CN107623693A (en) Domain name mapping means of defence and device, system, computing device, storage medium
CN109302300A (en) Data distributing method and device, data processing method and server
Taneja et al. Information Security in cloud computing: A Systematic Literature Review and analysis
CN110351364A (en) Date storage method, equipment and computer readable storage medium
CN112948499A (en) Information acquisition method and device, electronic equipment and storage medium
JP2019152912A (en) Unauthorized communication handling system and method
EP3490191B1 (en) Processing method of service requests performed by a service provider node
US10477024B1 (en) Dynamic resource allocation
CN105933298A (en) Devices And Methods For Performing Tcp Handshakes
EP2701068B1 (en) Network access system
CN102243738A (en) Safety payment system and method
JP6870386B2 (en) Malware unauthorized communication countermeasure system and method
CN105939315A (en) Method and device for protecting against HTTP attack

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