MONITORING IN DISTRIBUTED COMPUTING SYSTEM

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of, and priority to, European Patent Application No. 19206982.1 filed on November 4, 2019. The entire disclosure of the above-referenced application is incorporated herein by reference.

FIELD OF DISCLOSURE

The present disclosure relates to monitoring in a distributed computing system, in particular, a distributed computing system performing one or more secure processes.

BACKGROUND TO DISCLOSURE

There are multiple technical challenges with requiring a centralized system to provide sendees to a very large number of clients, particularly when these are widely geographically distributed. It is logical to consider distributing the system so that the relevant serv ices can be provided by a set of geographically distributed servers, rather than one central server or data centre.

In practice, such decentralisation may use a cloud architecture, which will typically use a number of geographically distributed servers - or data centres - to deliver services to clients. The cloud architecture may be considered as comprising a number of nodes - when using a cloud architecture, a node may be an aggregation of a number of computers and may cover more than one data centre with “real-time” connectivity and data sharing within a given node.

Decentralisation may itself be problematic, particularly if it is necessary for services to be provided in such a way that provision of the service has consequences beyond the server providing the service and the client receiving it. If, for example, other clients (or other system nodes) need to refer back to the service providing node to check on whether, or how, the service has been provided, or if it is necessary for a central system to have knowledge of how the service has been provided or of expected operation of the distributed server node, then new bottlenecks may appear in place of the former bottleneck at the central server, the overall quantity of messaging in the system may increase, and network latency can become a serious issue.

This is particular serious when the service relates to security (so it is necessary to be confident that it has been securely performed across the whole system) and when it relates to provision of a sendee over a short time frame. Both issues apply to transaction systems - it is necessary for transactions to be authorised over short time periods, and it is necessary to ensure that they have been performed legitimately - but apply to other technical contexts as well.

Performing activities securely in a distributed environment of this kind is challenging, because there is potential for malicious parties to exploit the possibility that an action may be performed in one of several places in a number of ways. It is desirable to address this challenge, but without resorting to approaches that would significantly erode the benefits of using a distributed environment.

SUMMARY OF DISCLOSURE

In a first aspect, the disc losure provides a method of monitoring a service performed at a computing node, wherein the computing node is one of a plurality of computing nodes in a distributed computing system each adapted to perform at least one service for clients, wiierein a monitoring process is adapted to monitor a service process performing the process, the method comprising the monitoring process: monitoring the service process for expected operation of the service; and providing monitoring information to a monitoring process for another service process.

Using such an approach involving peer-to-peer communication between monitoring processes, less monitoring information needs to be exchanged and the exchange of information can take place more rapidly. This allows an effective balance between practical processing requirements and security requirements.

In certain cases, the monitoring process provides the monitoring information directly after the service process is completed, In other cases, the monitoring process provides monitoring information after monitoring information is received from another service process. As is discussed below', embodiments are particularly relevant to complementary services, in which case one role may be taken for one service and the other for the other service.

In embodiments, the monitoring information is provided to a monitoring process in another computing node. In some embodiments, there is a

plurality of service processes in the computing node, and the monitoring information is provided to a monitoring process in the computing node. In some cases, the monitoring information may be provided to a plurality of monitoring processes.

In embodiments, the monitoring process has a monitoring process database, wherein the monitoring process may update the monitoring process database on monitoring the service process.

In embodiments, the sendee processes comprise a first service process for performing a first service and a second service process for performing a second sendee, wherein the first service process and the second service process are complementary to each other. Embodiments of the disclosure are particularly relevant to provision of complementary services by the distributed network in this way. In some cases, the computing node may contain a plurality of sendee processes, and these may comprise first service processes, second sendee processes, or both first sendees and second service processes. This first sendee process may comprise generation of a credential and the second sendee process may comprise verification of a credential. A credential here is here provided as a cryptographic proof, with verification as an establishment that the cryptographic proof is valid. This is particularly useful in the context of a payment system. In a payment system, a credential may be generated on behalf of a payment device user to indicate proof that they have authorised a payment to a merchant using a payment device. Verification is then required on behalf of the merchant or the merchant’s acquiring bank to determine that the transaction is legitimate and has been authorised by the payment device user.

In one such case, the sendee process may be a second service process, and the method comprise providing monitoring information to a monitoring process of a first sendee process that generated the credential. Here, the monitoring process may also receive a monitoring information response from the monitoring process from the first service process that generated the credential. After receiving the monitoring information response, the monitoring process may update the sendee process. This may be used to indicate a number of different situations. The monitoring information response may indicate that the credential was not valid. This could be because the credential was never generated. This may result from a guessing attack by a party asking for a verifying service - this may, for example, be a merchant (or one of a coalition of merchants) trying to obtain payment for a bogus transaction by generating a false proof of payment. Alternatively, the monitoring information response may indicate that the credential is not available for legitimate use - this may be because the credential has already been used, and in the payment case a rogue user may be trying to perform the same payment twice.

In another such case, the service process may be a first service process, and the method may comprise providing monitoring information to a monitoring process for a second sendee process that verified the credential. The monitoring information may then be provided as a monitoring information response in response to verification monitoring information received from the monitoring process for the second sendee process that verified the credential. Here, on receiving the verification monitoring information, the monitoring process may determine whether the credential has already been used, and if so, indicates this in the monitoring information. On receiving the verification monitoring information, the monitoring process may determine whether the credential is available for legitimate use, and if not, indicate this in the monitoring information.

As discussed in more detail below, this structure prevents a number of potential system abuses. It also addresses failures, such as data corruption which causes a credential to be identified wrongly. It also can be used to establish proper system use over an appropriate period, such as the period of validity of cryptographic keys used in the service processes.

In embodiments, the monitoring process is also adapted to provide an update message to update the service process that it monitors. In addition to having a peer-to-peer “horizontal” path between monitoring services, there is then a “vertical” path between the monitoring process and the service process itself. Typically, the monitoring process provides the update message after providing the monitoring information. The sendee process may have an associated sendee process database, wherein on receiving an update message from the monitoring process the service process updates the sendee process database.

In embodiments, the monitoring process is also adapted to provide an escalation message to, or receive an action message from, a coordinated monitoring process associated wdth multiple sendee processes. The monitoring process may provide the escalation message after providing the monitoring information. After providing the escalation message, the monitoring process may receive an action

message from the coordinated monitoring process to make an update. On receiving such an action message, the monitoring process may update the sendee process. This approach is particularly useful in cases where the impact is more extensive than between two related complementary services.

In a second aspect, the disclosure provides a method of monitoring sendees performed in a distributed computing system, wherein the distributed computing system comprises a plurality of computing nodes each adapted to perform at least one sendee for clients, wherein the service is performed by a sendee process having an associated monitoring process, wherein the method is performed by a coordinated monitoring sendee, the method comprising: receiving an escalation message from one of the monitoring processes; determining from the escalation message whether action is required at one or more senice processes in one or more computing nodes; and if action is required, sending an action message to the monitoring process for the affected senice processes. The monitoring process can then update its senice process if required.

These senice processes may comprise a first senice process for performing a first senice and a second senice process for performing a second senice, with the first service and the second service are complementary to each other. The first senice process may comprise generation of a credential and the second senice process may comprise verification of a credential. Here, the action message may indicate to a plurality of second senice monitoring processes that a credential has already been used. The action message may be used to update a plurality of senice processes, via their monitoring processes, that an identified user of the distributed computing system is no longer allowed to use one or more of the sendees.

In a third aspect, the disclosure provides a computing node adapted to perform at least one service, wherein the computing node is one of a plurality of computing nodes in a distributed computing system each adapted to perform at least one senice for clients, wherein a monitoring process is adapted to monitor a senice process performing the process, the computing node comprising: a senice process adapted to perform the senice in response to a client request; and a monitoring process adapted to monitor the senice process on expected operation of the senice and to provide monitoring information to a monitoring process for another senice process.

The monitoring process may be adapted to provide the monitoring information directly after the service process is completed. The monitoring process may alternatively be adapted to provide monitoring information after monitoring information is received from another service process.

This monitoring information may be provided to a monitoring process in another computing node. In some cases, the computing node may comprise a plurality of service processes, and further comprises a monitoring process for each service process. Such a monitoring process may be adapted to provide monitoring information to a monitoring process in the computing node. The monitoring information may be provided to a plurality of monitoring processes.

The computing node may further comprise a monitoring process database associated with the monitoring process, wherein the monitoring process is adapted to update the monitoring process database on monitoring the service process.

In embodiments, service processes may comprise a first service process for performing a first service and a second service process for performing a second service, wherein the first service process and the second service process are complementary to each other. A computing node may contain a plurality' of service processes, and these may comprise first service processes, second service processes, or both first services and second service processes. The first service process may comprise generation of a credential and the second service process comprises verification of a credential.

Where the service process is a second service process, the monitoring process may be adapted to provide monitoring information to a monitoring process of a first sendee process that generated the credential. Such a monitoring process may also be adapted to receive a monitoring information response from the monitoring process from the first service process that generated the credential.

Where the service process is a first sendee process, the monitoring process may provide monitoring information to a monitoring process for a second sendee process that verified the credential. Such a monitoring process may also be adapted to provide a monitoring information response in response to verification monitoring information received from the monitoring process for the second sendee process that verified the credential.

The monitoring process may also be adapted to provide an update message to update the service process that it monitors. Such a monitoring process may be adapted to provide the update message after providing the monitoring information. The computing node comprises a sendee process database associated with the sendee process, wherein the service process is adapted to update the service process database on receiving an update message from the monitoring process.

The monitoring process may also be adapted to provide an escalation message to, or receive an action message from, a coordinated monitoring process associated with multiple service processes. Such a monitoring process may be adapted to provide the escalation message after providing the monitoring information. After providing the escalation message, the monitoring process may also be adapted to receive an action message from the coordinated monitoring process to make an update. On receiving the action message, the monitoring process may also be adapted to update the sendee process.

In a fourth aspect, the disclosure provides a distributed computing system for providing sendees to clients, the system comprising a plurality of computing nodes as identified in the third aspect of the disclosure, wherein each computing node is adapted to perform at least one service for clients.

DESCRIPTION OF SPECIFIC EMBODIMENTS

Specific embodiments of the disclosure are now described, by way of example, with reference to the accompanying drawings, of which:

Figure 1 shows multiple clients interacting with a central sender;

Figure 2 shows multiple clients interacting with a distributed computing architecture providing the same sendees as the central server of Figure 1;

Figure 3 shows operation of a distributed system such as that shown in Figure 2 where distributed nodes create and verify proofs;

Figure 4 shows an approach to monitoring in the arrangement of Figure 3 according to embodiments of the disclosure

Figure 5 shows schematically a distributed transaction architecture using a four-party model;

Figure 6 illustrates elements of a complex distributed system adapted to implement the transaction architecture of Figure 5;

Figure 7 shows schematically an exemplary system for enabling digital transactions in the transaction architecture of Figures 5 and 6;

Figure 8 illustrates schematically an arrangement for a distributed system for digital enablement of transactions;

Figure 9 illustrates a computing node of the arrangement of Figure 8 in more detail;

Figure 10 illustrates elements within the computing node of Figure 9;

Figure 11 indicates transaction flow in relation to operations performed by the node of Figure 9;

Figure 12 indicates use of tokenisation in an embodiment of the arrangement of Figures 9 to 11;

Figure 13 indicates an approach to key management used in embodiments of the disclosure;

Figure 14 illustrates an exemplary approach to transaction identification;

Figure 15 illustrates an exemplary set of cryptographic mechanisms for use for digitised transactions in embodiments of the disclosure;

Figure 16 illustrates a global model of key management w ith individual modes managed as shown in Figure 13;

Figure 17 illustrates a global model of monitoring associated with the key management model of Figures 13 and 16;

Figure 18 shows elements of a monitoring system according to an embodiment of the disclosure for use with a distributed system such as that shown in Figure 8;

Figure 19 shows the monitoring system of Figure 18 shown as a multi-layer model;

Figure 20a is a block flow' diagram indicating monitoring-related communication involving two nodes in the arrangement of Figure 18, and Figure 20b illustrates the various action types shown in Figure 20a;

Figure 21a shows an interaction flow for the generation service G in the arrangement of Figure 20a and Figure 21b show's an interaction flow' for the validation service V in the arrangement of Figure 20a, whereas Figure 21c shows an interaction flow in response to a distributed action from the coordinated monitoring service M;

Figure 22 illustrates transaction and monitoring flows for the generation service G;

Figure 23 illustrates transaction and monitoring flows for the validation service V;

Figure 24 shows a monitoring flow detecting a replay attack;

Figure 25 shows a monitoring flow preventing a replay attack involving multiple nodes;

Figure 26 shows a reaction flow to indicate that a double-spend fraud has been attempted;

Figure 27 indicates the use of the monitoring system to detect and communicate replay fraud;

Figures 28 to 30 relate to the use of the monitoring system to detect and signal different types of guessing attacks; with Figure 28 relating to a guessing error; Figure 29 relating to a guessing attempt made by a single Merchant (or PSP); and Figure 30 relating to a guessing attempt made by a coalition of dishonest Merchants (or PSPs); and

Figure 31 shows a further monitoring process to be carried out at the end of a period.

In general terms, the problem addressed by the disclosure is illustrated in Figures 1 to 3. Figure 1 shows a central system perfomiing functions in response to requests from a very large number of geographically distributed entities. This places intense demand on the central system in relation to processing capability, storage and messaging, and will typically lead to significant load on the system overall because of bottlenecks and messaging requirements. This is in addition to the problem of network latency resulting from travel time when a request is coming from a geographically distant requester communicating with a centralized system.

Figure 2 shows an alternative arrangement in which the role of the central system is replicated so that the same functions are performed by a distributed set of nodes, each with the capability to perform some or all of the functions provided by the central system. Individual nodes should see a significantly lower demand than the central system, and as entities should be able to interact with a more local node than the central system, there is potential to reduce network latency. However, as discussed above in general terms, and below with specific relevance to a transaction processing system, there are significant technical challenges in achieving this benefit - in particular, there would for straightforward replication be a need to distribute all the same information to all the nodes replicating the centralized system, generally making the overall position worse rather than better.

There are particular difficulties where it is necessary for a second user of the system to be satisfied that an action taken by a first user of the system was legitimate. In the Figure 1 case, this is relatively straightforward - as the service is performed centrally and the central system has all information, then if users trust the central system this is typically not problematic. In the Figure 2 case, the first user may have been interacting with one node and the second user may be interacting with another node, in which case the same level of confidence cannot be achieved unless all necessary information is held in common between all the nodes, suitably synchronized, which would defeat the point of disaggregation when replicating a centralized system. If the product of the first service performed by the first user is valuable information - such as the proof of a payment made by the first user to be used by a second user in completing a transaction - then risks of system failure or compromise by, for example, use of a proof at multiple nodes by multiple second users to complete a relevant transaction, need to be addressed.

Generally, this situation is shown in Figure 3. A first user 1 requests execution of a first sendee 3 - in this case, the creation of a proof of an event such as a payment from a particular account - and a second user 2 requests verification of the proof of this event, for example to determine that a payment is validly made, from a second sendee 4. The first user 1 has invoked the first senice 3 at a first node 5. The second user will typically not have a choice of where to invoke the second senice 4 -this may be a matter of geography or other administrative factors - and in particular may not be able to invoke the second senice 4 at the first node 5 (though this may be a possibility). In practice, the second service 4 will be invoked at a further node 6a, fib, 6c that has sufficient information to achieve the verification process. Typically, this will involve access to a common set of cryptographic keys together wdth the minimal set of information required to regenerate the proof or otherwise determine that the proof is correct - as discussed below, in embodiments a limited set of keys may be used. Situations in which such a proof, or an object claiming to be such a proof, is presented to one or more second services at one or more nodes need to be addressed for such a system to function reliably and securely.

The present disclosure teaches how these situations can be addressed by an appropriate system of monitoring. A system of monitoring according to embodiments of the disclosure is shown in Figure 4, which extends the arrangement of Figure 3 by inclusion of a monitoring system. In this system, each service in a node, such as first sendee 3 and second service 4, has an associated monitoring sendee (such as first sendee monitoring sendee 31 and second service monitoring senice 41) that interacts directly with its associated sendee using suitable messaging, performing monitoring at the time that the sendee is performed and providing information, including information received from elsewhere in the distributed system, that is needed by the associated service for correct current or future senice delivery.

Each monitoring service has at least two further communication paths. One is a peer to peer (horizontal) communication path 7 for communicating with monitoring sendees in other nodes using inter-node messages so that information immediately identifiable as relevant to other sendees are transmitted to the monitoring sendees for those sendees. It should be noted that while this peer to peer (horizontal) communication path is shown as an inter-node path, it can effectively also operate within a single node if multiple sendees are provided within that node (i.e., if processes 4 and 41 would run in node 5 next to the processes 3 and 31) - in this case the peer to peer (horizontal) communication path between 41 and 31 is provided as an intra-node message or path. The terms intra-node and in-node may be used interchangeably here to refer to a message sent within the same physical or logical node, though the term in-node will be used generally below. This pathway is particularly effective for direct communication between monitoring services for a second service verifying a proof and a first sendee that has created the proof.

The second communication path is a path 8 between each local monitoring service 31, 41 and a coordinated monitoring sendee - which may be provided as a central monitoring service 9, for example. This is useful to support an escalation process for evaluating potential errors or threats that are not determinable directly by a local monitoring sendee, and for communicating actions to affected nodes, or sendees in nodes, when such issues have been detected when a distributed reaction is required in order to address the threat and mitigate the associated residual security risk.

The arrangement shown here has a third communication path used for vertical communication between the services 3, 4 and their monitoring processes 31 , 41. This is here used for messaging between the service 3, 4 and its monitoring process 31, 41 for monitoring of service expected operation. In the arrangements described here, messaging is used for this purpose, though in other architectures it is conceivable that monitoring may be achieved by measurement without an explicit messaging step. However, this third communication path is also valuable for provision of information back to the sendee 3, 4 from the monitoring process 31, 41

This architecture is effective to allows both the first service and the second service to take place without delay while allowing effective monitoring using peer-to-peer interaction between monitoring processes to exchange a first type of information and a remote coordinated monitoring system to receive a second type of information. The first type of information can be used to provide rapid updates that can address, for example, coordinated attacks, whereas the second type of information can be used to ensure sufficient knowledge of events across the system to prevent other types of attack developing. This approach supports effective monitoring across the distributed system, but with information exchanges limited to those necessary to maintain an effective and secure system.

The timing of messaging within the extended system is highly significant. There are three timing types used for messaging: real time; near real time: and post-service. Real time messaging is immediate. Near real time messaging may not be immediate - real time messaging is prioritised over it - but it is rapid and may complete during a related extended system event, and such that monitoring information may be received during use of multiple second sendees in parallel. Post-transaction messaging is less urgent and is used for reconciliation and system changes to remove identified vulnerabilities.

Here, messaging and processing involved in provision of services to users takes place in real time, enabling such services to be full real time processes. Local monitoring and associated communication such as messaging peer to peer between monitoring services take place typically in near real time, so the speed of service provision is not affected but so that response is sufficiently rapid to address threats on a sufficiently short timescale. Typically, such near real time communication is sufficiently rapid that it will take place in the same time frame as the associated broader process in which the second service is used, and often before the completion of such a process, rendering this approach effective against attacks or problems occurring at multiple points in the system. Coordinated monitoring and other communications involving the coordinated monitoring service typically do not need to be immediate and can be carried out after the completion of the associated service. This approach therefore allows for effective response to threats in a distributed system of service provision without compromising the operation of service provision itself.

This issue is particularly relevant to transaction processing systems, and in particular to systems for handling digital transactions. The number of digital transactions is increasing extremely rapidly, and it is necessary for them to execute reliably and rapidly. Support of these transactions can use transaction processing systems developed for device-based payments using payment cards and use the protocols of such payment systems, but in practice such transactions have a different character from device-based transactions. This is discussed below, first by reference to the general elements of a transaction processing system, and then by a more detailed discussion of the infrastructure used to support digital transactions.

Figure 5 is a block diagram of a typical four-party model or four-party payment transaction scheme. The diagram illustrates the entities present in the model and the interactions occurring between entities operating in a card scheme.

Normally, card schemes - payment networks linked to payment cards - are based on one of two models: a three-party model or a four-party model (adopted by the present applicant). For the purposes of this document, the four-party model is described in further detail below.

The four-party model may be used as a basis for the transaction network. For each transaction, the model comprises four entity types: cardholder 110, merchant 120, issuer 130 and acquirer 140. In this model, the cardholder 110 purchases goods or services from the merchant 120. The issuer 130 is the bank or any other financial institution that issued the card to the cardholder 110. The acquirer 140 provides services for card processing to the merchant 120.

The model also comprises a central switch 150 - interactions between the issuer 130 and the acquirer 140 are routed via the switch 150. The switch 150 enables a merchant 120 associated with one particular bank acquirer 140 to accept payment transactions from a cardholder 110 associated with a different bank issuer 130.

A typical transaction between the entities in the four-party model can be divided into two main stages: authorisation and settlement. The cardholder 110 initiates a purchase of a good or sendee from the merchant 120 using their card. Details of the card and the transaction are sent to the issuer 130 via the acquirer 140 and the switch 150 to authorise the transaction. The cardholder 110 may have provided verification information in the transaction, and in some circumstances may be required to undergo an additional verification process to verify their identity (such as 3-D Secure in the case of an online transaction). Once the additional verification process is complete the transaction is authorised.

On completion of the transaction between the cardholder 110 and the merchant 120, the transaction details are submitted by the merchant 120 to the acquirer 140 for settlement.

The transaction details are then routed to the relevant issuer 130 by the acquirer 140 via the switch 150. Upon receipt of these transaction details, the issuer 130 provides the settlement funds to the switch 150, which in turn forwards these funds to the merchant 120 via the acquirer 140.

Separately, the issuer 130 and the cardholder 110 settle the payment amount between them. In return, a service fee is paid to the acquirer 140 by the merchant 120 for each transaction, and an interchange fee is paid to the issuer 130 by the acquirer 140 in return for the settlement of funds.

In practical implementations of a four-party system model, the roles of a specific party may involve multiple elements acting together. This is typically the case in implementations that have developed beyond a contact-based interaction between a customer card and a merchant terminal to digital implementations using proxy or virtual cards on user computing devices such as a smart phone.

Figure 6 show's an architecture according to an embodiment of the disclosure appropriate for interaction between a cardholder and a merchant. This Figure shows a general-purpose architecture for reference but shows in particular

elements of an architecture used when a cardholder carries out an online transaction with a merchant server.

For a conventional transaction, a cardholder will use their payment card 6 - or a mobile computing device such as smartphone 11 adapted for use as a contactless payment device - to transact with a POS terminal 7 of a merchant 2.

However, in embodiments relevant to the present disclosure, the cardholder will use his or her computing device - which may be any or all of a cellular telephone handset, a tablet, a laptop, a static personal computer or any other suitable computing device (here cellular telephone handset or smartphone 11 is shown) - and other computing devices such as a smart w'atch or other wearable device may also be used) - to act either as a proxy for a physical payment card 6 or as a virtual payment card operating only in a digital domain. The smartphone 11 may achieve this with a mobile payment application and a digital wallet, as described below. The smart phone 11 can use this to transact with a merchant POS terminal 7 using NFC or another contactless technology, or to make a payment in association with its wallet service as discussed below. However, online transactions with a merchant are of particular interest in connection with embodiments of the disclosure, rather than contact or contactless transactions with a merchant POS terminal 7. To make an online transaction, the smartphone 11 may also be able to interact with a merchant serv er 12 representing the merchant 2 over any appropriate netwOrk connection, such as the public internet - the connection to the merchant may be provided by an app or application on the computing device.

The transaction scheme infrastructure (transaction infrastructure) 5 here provides not only the computing infrastructure necessary to operate the card scheme and provide routing of transactions and other messaging to parties such as the acquirer 3 and the issuer 4, but also a wallet service 17 to support a digital wrallet on the cardholder computing device, and an internet gateway 18 to accept internet based transactions for processing by the transaction infrastructure. In other embodiments, the wallet service 17 may be provided similarly by a third party with an appropriate trust relationship with the transaction scheme provider. To support tokenisation, a token sendee provider 19 is present (again, this is shown as part of transaction infrastructure 5 but may be provided by a third party with appropriate trust relationships), and the transaction scheme infrastructure provides a digital enablement service 16 to support the performance of tokenised digital transactions, and to interact with other elements of the system to allow transactions to be performed correctly -this digital enablement service may include other elements, such as token service provision.

For a tokenised transaction, the transaction is validated in the transaction scheme by mapping the cardholder token to their card PAN, checking the status of the token (to ensure that it is in date and otherwise valid) and any customer verification approach used. This allows the issuer to authorise the transaction in the normal manner.

Figure 7 shows elements of a transaction infrastructure to support digitised payments from a mobile device in more detail. This Figure shows as a specific example the applicant’s Mastercard CloudBased Payment (MCBP) architecture - this is exemplary rather than specific to the disclosure, and illustrates how the architecture is used to support a mobile payment application 215 on a mobile device (such as smartphone 11) - here the mobile payment application 215 is shown as contained within a wallet application or digital wallet 41. Such a digital wallet 41 may communicate with a wallet server 17 to allow management of the mobile payment application, and it also can be used to request digitization of a payment card 6 to be used by the mobile device 11.

The Mastercard Digital Enablement Service (MDES) 42 performs a variety of functions to support mobile payments and digitized transactions. As indicated above, the MDES 42 is exemplary only - other embodiments may use digitisation, tokenisation and provisioning services associated with other transaction processing infrastructures, for example. The wallet server 17 is not a part of the MDES 42 - and need not be present, for example if the mobile payment application 215 is not embedded within a digital wallet 41 - but acts as an interface between the mobile device 11 and the MDES 42. The MDES 42 also mediates tokenised transactions so that they can be processed through the transaction scheme as for conventional card transactions. The following functional elements shown within the MDES 42: the Account Enablement System (AES) 43, the Credentials Management System (CMS) 44, the Token Vault 45, and the Transaction Management System (TMS) 46. These will be described briefly below.

The Account Enablement System (AES) 43 is used in card digitisation and user establishment. It will interact with the mobile payment application (here through the wallet server 17) for card digitisation requests, and it will populate the Token Vault 45 on tokenisation and will interact with the CMS 44 to establish a card profile with associated keys for digital use of the card.

The Credentials Management System (CMS) 44 supports management of cardholder credentials and is a key system within the MDES 42. The core system 441 manages synchronisation with the transaction system as a whole through interaction with the TMS 46 and manages the channel to the AES 43. The dedicated system 442 provides delivery of necessary elements to the mobile payment application such as the digitized card and credentials and keys in the form needed for use. This system may also interact with the wallet server 17 for management of the mobile payment application.

CLAIMS

1. A method of monitoring a service performed at a computing node, wherein the computing node is one of a plurality of computing nodes in a distributed computing system each adapted to perform at least one service for clients, wherein a monitoring process is adapted to monitor a service process performing the process, the method comprising the monitoring process:

monitoring the service process for expected use of the service: and

providing monitoring information to a monitoring process for another service process.

2. The method of claim 1, wherein the monitoring process provides the monitoring information directly after the service process is completed.

3. The method of claim 1, wherein the monitoring process provides monitoring information after monitoring information is received from another service process.

4. The method of any preceding claim, wherein the monitoring process has a monitoring process database, wherein the monitoring process updates the monitoring process database on monitoring the service process.

5. The method of any preceding claim, wherein service processes comprise a first service process for performing a first service and a second service process for performing a second service, wherein the first sendee process and the second service process are complementary to each other.

6. The method of claim 5, wherein the first service process comprises generation of a credential and the second service process comprises verification of a credential.

7. The method of claim 6, wherein the service process is a second service process, and the method comprises providing monitoring information to a monitoring process of a first service process that generated the credential.

8. The method of claim 7, wherein the monitoring process also receives a monitoring information response from the monitoring process from the first service process that generated the credential.

9. The method of claim 8, wherein after receiving the monitoring information response, the monitoring process updates the service process.

10. The method of claim 8 or claim 9, wherein the monitoring information response indicates that the credential was not valid or that the credential was never generated, and that the credential is not available for legitimate use.

11. The method of claim 6, wherein the service process is a first service process, and the method comprises providing monitoring information to a monitoring process for a second service process that verified the credential.

12. The method of claim 11 , wherein monitoring information is provided as a monitoring information response in response to verification monitoring information received from the monitoring process for the second service process that verified the credential.

13. The method of claim 12, wherein on receiving the verification monitoring information, the monitoring process either determines whether the credential has already been used, and if so, indicates this in the monitoring information, or determines whether the credential is available for legitimate use, and if not, indicates this in the monitoring information.

14. Tire method of any preceding claim, wherein the monitoring process is also adapted to provide an update message to update the service process that it monitors.

15. The method of claim 14, wherein the service process has an associated service process database, wherein on receiving an update message from the monitoring process the service process updates the service process database.

16. The method of any preceding claim, wherein the monitoring process is also adapted to provide an escalation message to, or receive an action message from, a coordinated monitoring process associated with multiple service processes.

17. The method of claim 16, wherein after an escalation message is provided, the monitoring process receives an action message from the coordinated monitoring process to make an update and on receiving the action message, the monitoring process updates the service process.

18. A method of monitoring services performed in a distributed computing system, wherein the distributed computing system comprises a plurality of computing nodes each adapted to perform at least one service for clients, wherein the service is performed by a service process having an associated monitoring process, wherein the method is performed by a coordinated monitoring service, the method comprising:

receiving an escalation message from one of the monitoring processes;

determining from the escalation message whether action is required at one or more service processes in one or more computing nodes; and if action is required, sending an action message to the monitoring process for the affected service processes.

19. The method of claim 18, wherein service processes comprise a first service process for perfonning a first service and a second service process for performing a second service, wherein the first service and the second service are complementary to each other, wherein the first service process comprises generation of a credential and the second service process comprises verification of a credential. and wherein the action message indicates to a plurality of second service monitoring processes that a credential has already been used.

20. The method of claim 18 or claim 19, wherein the action message indicates to a plurality of service processes that an identified user of the distributed computing system is no longer allowed to use one or more of the services.