Title

Identity and Risk Management System and Method

Field

The invention relates to an identity and risk management system and method. In particular, the invention relates to identity and risk management of endpoint devices in a communications network. Background

Demand for applications for smart phones and other devices has led to voluminous increase in the amount of applications which can be downloaded to such devices, but also to growth and continuous evolvement in associated risks and security threats. Mobile commerce (or m-commerce) is also experiencing stellar growth with some predictions indicating that accelerated migration from traditional fixed Internet Electronic Commerce (or e-commerce) to m- commerce is increasingly likely.

Mobile service providers such as mobile banking service providers are increasingly providing services accessible via the mobile channel. However the risks and security threats associated with mobile endpoint devices are hampering the rollout of mobile services including banking services and can result sometimes in security solutions which can be unwieldy and which are open to being compromised.

There is a need for secure identity establishment and risk management of endpoint devices in a communications network. In the context of mobile devices and services, authentication methods such as 2-factor authentication and 3D Secure functionality have very significant shortcomings and cannot in their known forms be applied to mobile devices and services to achieve a secure solution.

It is an object of the invention to provide one or more solutions to overcome at least one of the above mentioned problems.

Summary

According to one embodiment of the invention there is provided, as set out in the appended claims, a system and method for identity and risk management for use in a communications network said network comprising at least one device, for example a mobile phone operable to communicate with an application device or terminal, for example an Application Service Provider, to effect a transaction, said system comprising:

a security module configured to receive an authentication message from the network, said authentication message originating from the at least one device to determine the identity of the device based on the content of said authentication message and sending a message to the application device or terminal confirming the identity of the at least one device.

In one embodiment there is provided a system and method for identity and risk management for use in a communications network said network comprising at least one device operable to communicate with an application device or terminal to effect a transaction, said system comprising a security module configured to initiate an authentication communication with the at least one device to determine the identity of the device and sending a message to the application device or terminal confirming the identity of the at least one device. In one embodiment the message confirming the identity is in the form of providing a risk score rating indicating whether a device is fraudulent or not. In another embodiment there is provided a security module configured to receive an authentication message from a telecommunication network, said authentication message originating from at least one mobile device to determine the identity of the device based on the content of said authentication message and sending a message to an application device or terminal confirming the identity of the at least one device.

In one embodiment the at least one device is a mobile device and comprising means for providing a secure identity for the mobile device by querying the mobile network for the mobile device's identity by sending a SMS, or other message, from the mobile device to the security module, wherein the SMS, or other message, is routed securely to the security module wherein the SMS or other message comprises the secure identity. In other words the mobile application can send an SMS message from the user mobile phone unknown to the user and the mobile network inserts the correct mobile number from the sending phone and forwards this to the security module where it can be used for secure authentication of a service or accessing a service.

In one embodiment the invention provides secure identity establishment and risk management of end point devices in a communication network, including risk management associated with the identity of end point devices. In one embodiment the invention enables identity establishment of a user of an application running on an endpoint device to ensure that the user is the legitimate user of the particular service provided by the application.

In one embodiment the invention provides secure multi-factor authentication for mobile devices and services. The invention uses the mobile network to confirm the identity and the location of the mobile device and therefore the user of the service.

In one embodiment he invention provides 3D Secure functionality for mobile devices and services including means for 3D Secure for secure telephone (including mobile phone) payments (i.e. Card-Not- Present transactions).

In one embodiment the invention provides security for mobile applications communicating with Application Service Providers (ASPs) that requires enhanced security and threat mitigation. In one embodiment the invention provides secure services from mobile devices.

In one embodiment the invention provides means of providing endpoint devices (i.e. mobile phone) a secure and trusted identity when the endpoint device is used to access a service provided by an application service provider.

In one embodiment the invention provides device isolation from all communications networks except a private communications network with an ASP. The invention provides intelligent traffic management by only permitting traffic from an end point device on a dedicated network or connection. In one embodiment the invention also has means of preventing the user of an application running on an endpoint device from executing any other activities or accessing any other applications on the same endpoint device.

In one embodiment the invention provides means for prevention of Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks by routing the data connection from an application on an endpoint device over a private connection to the applications network or a private data network using a private IP. In one embodiment the invention comprises means for routing a data connection from an application running on an endpoint device to an application server either over a private data network using a private IP or a public data network using a public IP depending on the identity and/or the communications network the endpoint is connected to of the end point device.

In one embodiment the invention provides means for secure authentication for a user of an application running on an endpoint device (such as a mobile phone) by utilising Unstructured Supplementary Service Data (USSD) as a separate communication channel to achieve device separation in a multi-factor authentication scenario.

In one embodiment the invention provides user authentication for applications running on endpoint devices by using the utilising the location of the mobile device and comparing this against a stored location where the user or application service provider has authorised access from.

In one embodiment the invention provides means of verifying the location of an endpoint device by comparing the location received from the endpoint device itself against the location of the endpoint device obtained from the communications network. This information can then be used by the invention to either authorise a transaction (or similar) or prevent a transaction from occurring or the information can be used to calculate a risks score that can be used by the invention or passed on to a third party for further processing.

In one embodiment the invention provides secure identity and secure services for users of applications running on mobile devices by utilising the telephony communications network (i.e. a mobile network) to obtain information about the mobile device to provide a trusted identity that cannot be compromised through malware running on the mobile device.

In one embodiment the invention provides means to communicate and pass on the identity of a mobile device to application service providers when using a service provided by the application service provider from an application running on the mobile device.

In one embodiment the invention provides means of utilising the trusted identity of the mobile device obtained from the mobile network as one authentication factor when a user is accessing an application running on a mobile device.

In one embodiment the invention provides means to route data to a local or private network by either using or assigning different APN (Access Point Nodes) used to access a service based on; The target IP address, communication channel used by the user to access the service (e.g. mobile network, WIFI connection, etc.), device used by the user to access the service, APN sent down by the application, APN dynamically allocated from pool of APNs, APN stored within the invention part of the application.

In one embodiment the invention provides a secure identity for the mobile device by querying the mobile network for the mobile device's identity by sending a SMS, or other message, from the mobile device to the security component of the invention unknowns to the user. The SMS, or other message, is routed securely to the invention security manager by sending the SMS to a short code that is configured for the invention.

In one embodiment the invention provides multi-factor authentication by using the mobile device as one authentication factor (something only the user has), and the location of the mobile device (something only the user knows) as another authentication factor. In another embodiment there is provided a method for identity and risk management for use in a communications network said network comprising at least one device, for example a mobile phone, operable to communicate with an application device or terminal, for example an Application Service Provider, to effect a transaction, said system comprising:

receiving an authentication message from the network, said authentication message originating from the at least one device to determine the identity of the device based on the content of said authentication message and sending a message to the application device or terminal confirming the identity of the at least one device. There is also provided a computer program comprising program instructions for causing a computer program to carry out the above method which may be embodied on a record medium, carrier signal or read-only memory.

Routing over Private Data Network (DoS/DDoS Prevention) Embodiment

In another embodiment there is provided means for preventing DoS/DDoS attacks for mobile applications by routing traffic over private data network.

In one embodiment there is provided a system for routing mobile data traffic to private data network using a different APN to access the private data network. The APN can be assigned to the mobile user in multiple ways; (1) Within the application, (2) Obtained from network, or (3) Obtained from invention security manager, (4) Sent to the mobile device application from the application service provider as part of the access request, (5) DNS Lookup of target IP address, (6) Dynamic allocation of APN, (7) Based on device identity (device registered to access private data network).

In one embodiment usage of Private IP addresses and a private data network for communication for mobile services when accessing the service over a mobile network can be provided.

In one embodiment there is provided means to query the mobile network to obtain information about mobile device connecting.

In one embodiment there is provided means to assign different short codes to route to security manager depending on mobile network the user is located in. In one embodiment there is provided means for assigning a different APN to route to private data network based on information obtained from the mobile network.

In one embodiment there is provided means for assigning different APN to route to private data network based on information obtained from the mobile device.

In one embodiment there is provided means for assigning private APN based on adding target IP address in restricted IP list of the invention. When traffic is sent to restricted IP address, the invention will trigger and assign relevant APN to route to private data network. In one embodiment there is provided means for assigning APN for Private Data Network by verifying the Mobile Identity (i.e. MSDISN), IP address assigned by mobile network.

In one embodiment there is provided means for assigning APN or connection network by using the destination IP address to query a RADIUS server for authentication.

In one embodiment the invention provides means for routing traffic to public data network (i.e. Internet) if MSISDN is not provisioned for APN. In one embodiment the invention enables short codes to communicate between application and invention. Invention will receive all SMS messages destined for assigned short codes. In one embodiment short codes are more secure and mobile device needs to be on the mobile network provider's network to be routed when using short codes.

In one embodiment authentication message or short Code used by invention can be retrieved from; (1) ASP and sent back in original access request in application, (2) short codes can be requested from the invention itself (either over HTTP/HTTPS or using SMS to SMS long number), (3) obtain short codes from app on mobile device by querying mobile device to get MCC and MNC, (4) invention can use time- based short codes and rotate short codes based on time, (5) invention can use dynamic short code allocation from a pool of short codes. In one embodiment the short codes that will be assigned can be rotated for added security.

In one embodiment the system can query mobile network based identifier (Originating Address) received in the SMS using MAP SRI to obtain trusted identifiers from mobile network, e.g. MCC, MNC, MSISDN, IMEI, etc.

Risk scoring can be based in location (geographical), SIM Swap, etc.

In one embodiment the invention can use or send metadata to ASP to allow or reject access request to service.

The invention is malware agnostic, there is nothing that the malware on the device can do to manipulate the identity.

The invention can be used in conjunction with other authentication mechanisms, e.g. PIN Code, password, etc.

In one embodiment the Private IP can be located in DMZ or in Application Service Provider network.

In one embodiment the invention comprises means for performing intelligent traffic management only permitting traffic from the device on a particular network and/or connection, for example a private network and/or private connection between the device and the ASP.

Device Isolation Embodiment It will be appreciated that the invention can prevent mobile user from accessing other applications when using secure application setting.

In one embodiment the invention can prevent a user to connect to Internet through Bluetooth, WIFI, and any other communication method available when using secure application setting.

The invention can prevent malware from communication with Control & Command centre.

In one embodiment the invention only allows traffic to private data network using private IP addresses when mobile device is isolated from the mobile network and from the use of other applications running on the mobile device. In one embodiment the invention can force all traffic onto mobile network to ensure that traffic is on a secure and trusted network and to ensure that invention has visibility of all traffic.

In one embodiment device isolation can be triggered on the destination IP address, APN used to access mobile Internet, etc.

User Identity (UID) Generation Embodiment

In another embodiment of the invention there is provided a user identity generation module comprising one or more of the following features:

Anonymizing the mobile network User ID (e.g. MSISDN, IMEI, etc.)

Preventing Application Service Provider information from being stored within invention

Generating User Identity based on device profile and mapping to MSISDN

Provides data protection

- Mapping between invention UID and Application Service Provider User ID is done within ASP

Risk Scoring and Behavioural Analysis Embodiment

In another embodiment of the invention there is provided a risk scoring and behavioural analysis module comprising one or more of the following features:

Location check based on latest serving MSC

Location check based on querying mobile device (GPS or A-GPS)

Location check based on querying the mobile network

Risk score based on comparing location obtained from mobile device and location obtained from mobile network for same device

Risk score based on change of SIM card (SIM Swap) for mobile device

Risk score based on the identity of the mobile device

Risk score based on historical patterns of the mobile identity

Risk score based on combination of biometric information, e.g. voice recognition, finger print recognition, facial recognition, iris scan, etc. in conjunction with information obtained from the mobile network.

Risk score can be used in addition to other risk management systems and can feed metadata into these risk management systems

Invention allows for building up a risk profile for each mobile device (identity, location, behaviour, access points and access methods, connection methods (direct or tethered, etc.)

Historical non repudiation transactional information Embodiment

In another embodiment of the invention there is provided a Historical non repudiation transactional information module comprising one or more of the following features:

Covers fraud from legitimate users claiming that for example mobile device was stolen at the time of transaction

Invention provides means to validate historical transaction data for mobile communication (in short, invention can check if a transaction that was performed from a particular mobile device was legitimate or not.

Prevent person pretending that phone was stolen when performing a transaction that resulted in a loss to the user, e.g. gambling, money transfers.

Invention checks; device location, device identity (IMSI, MSISDN, etc.), date of transaction, amount of transaction, date of last transaction, date of last payment, session ID, ASP ID, SIM

Swap check, multi-party call status, call-divert unconditional status, etc. and uses this to detect fraud Can use Mobile network information from mobile transactions to build up historical picture of activities for mobile device users to perform forensic analysis.

Location Embodiment

In another embodiment of the invention there is provided a location information module comprising one or more of the following features:

Invention obtains location information from the mobile network (HLR/HSS/MSC/GMLC/MPS). - Determine the location of a mobile device based on information received from the mobile network using the following operations on the mobile identifier received in the incoming SMS to the invention;

o MAP SRI (Send Routing Information)

o MAP SRI for SM (Send Routing Information for Short Message)

o MAP ATI (Any Time Interrogation)

Invention can also use GPS or Assisted-GPS to get the location from the mobile device itself. The invention bases the risk scoring or authorisation of a service request based on any of the above methods or any combination of the above methods.

Detection of a mobile device being on-net or off-net (connected to a mobile network) when accessing a service from the mobile device (the user can still be connected through WIFI) and use this to calculate a risk score or determine if a mobile device should gain access to a service or not.

Invention using a registered location of a user's mobile device as one authentication factor. Mobile device must be in proximity of the registered location to allow the location to be used as an authentication factor. If the mobile device is not in a configured proximate location of the registered location, the invention will either reject the service request, calculate a risk score that can be passed on to an application service provider or prompt the user for additional authentication factors to be presented. Identity & Risk Management (Voice) Embodiment

In another embodiment there is provided a system and method for identity and risk management for use in a communications network said network comprising at least one device operable to communicate with an application device or terminal to effect a transaction via a voice channel or call, said system comprising a security module configured to initiate an authentication communication with the at least one device to determine the identity of the device and sending a message to the application device or terminal confirming the identity of the at least one device.

In one embodiment of the invention there is provided an Identity & Risk Management (Voice) module comprises one or more of the following features:

The invention applies to inbound, outbound and multi-party calls between a user and an application service provider / call centre / service provider.

Secure payments over the telephone - 3D Secure functionality for mobile devices and services for CNP transactions.

Means to check ongoing calls if user is calling from a legit number by querying the mobile network.

Outbound calls from an ASP or incoming calls to an ASP are routed via, or providing metadata from the call to, the invention by setting up a three-way call between ASP, user and invention - Calculate risk score based on analysis performed on the destination number, e.g. SIM Swap, location, call divert unconditional status (HLR), check for active multi-party calls (fraudster eaves -dropping to obtain knowledge factor), etc. Ability to play announcement to caller (ASP) depending on result of risk calculation to indicate to call if the destination number can be trusted or not.

Treating the mobile device as a trusted device for the user

Metadata can be used by invention or provided to 3 ^rd party system for further processing.

- Applies to voice calls for all types of telecommunications networks and voice-over-IP networks.

Provides device identity (and indirectly user identity) for voice calls

The invention can perform the call logic itself, or it can be hosted by the telecommunications network (e.g. utilising a IN service, CAMEL, but not limited to)

The invention can determine if further authentication is required to be presented by the user. - The invention enables detection of three-way/multi-party calls to detect potential fraud and of call being compromised or hijacked by another party.

Information about identity and authentication of user can be provided to ASP via voice message only played to ASP, from a Telephone User Interface (TUI) or a Graphical User Interface (GUI). Invention provides means of identity and authentication to comply with data protection legislation.

Identity & Risk Management (Data) Embodiment

In another embodiment of the invention there is provided an Identity & Risk Management (Data) module comprising one or more of the following features:

Using mobile network to confirm identity of mobile device and thereby the user

Using the location as a knowledge factor (something that only the user knows) for authentication or gaining access to a service

Location is used as knowledge factor and stored as "Safe Place"

- The registration of a "Safe Place" location is done securely by the user or by the application service provider.

Using a combination of the device factor (mobile device identity) and knowledge factor (location of mobile device) to authenticate a user

Covers both direct mobile Internet, Mobile connected over WIFI router, tethered connections (using the mobile device as a hotspot)

Invention enables application service providers to use mobile devices certificate keys by using the mobile network operators as Public Key Infrastructure (PKI) issuers.

Mobile Device Profiling Embodiment

In one embodiment the invention builds up a profile of each user's mobile device - provides a mobile device "finger print".

In one embodiment a service profile can be based on attributes like; IMEI, IMSI, MSISDN, Language Settings in device, SW version running on mobile device, Serial Number of mobile device, CPU in mobile device, SIM Card Serial Number (ICCID), Browser version(s) in mobile device, model of mobile device, firmware running in mobile device, etc.

Store the above information in persistent storage for each user.

Query stored device information and compare against current information obtained as part of ongoing authentication request.

Calculates risk score or authenticates user based on device profile information.

3D Secure for mobile applications Embodiment In another embodiment of the invention there is provided a 3D secure authentication module comprising one or more of the following features:

Invention provides 3D secure for Card-Not-Present transactions (e.g. online purchases or payments over the phone)

Invention performs risk score and/or authentication of transaction (real-time or offline).

Uses mobile network to identify Card Holder's mobile device (when calling from mobile device to make a purchase)

Checks time and date of last call of cardholder's registered mobile number to ensure mobile device was the device used to make the purchase over the phone.

Checks if multi-party calls were ongoing during CNP purchase to prevent call from being compromised by third person

Using the mobile device as a trusted device during CNP transactions

Invention allows service provider to obtain caller's mobile number from the mobile network, mobile number is then sent to card Issuer as part of transaction security check. Invention verifies mobile device identity from mobile network and performs risk management based on the identity of the mobile device (e.g. IMSI, MSISDN, etc.), location of the mobile device, mobile device history and mobile device settings (SIM Swap, Call forwarding, etc.)

Invention calculates risk score an presents to service provider or Issuing Bank indicating if transaction is legit or potential fraud.

The invention allows for performing security check and risk management either prior to sending transaction to Issuing Bank or after sending it to Issuing Bank.

Additional Embodiments

The invention provides secure identity establishment and risk management of endpoint devices in a communications network, including risk management associated with identity of endpoint devices.

The invention provides secure multi-factor authentication for mobile devices and services. The invention uses the mobile network to confirm the identity and the location of the mobile device and therefore the user of the service.

The scope of the invention also includes secure telephone payments. The invention provides 3D Secure functionality for mobile devices and services including means for 3D Secure for secure telephone (including mobile phone) payments (i.e. card not present transactions).

The invention includes a network security service which operates and communicates with one or more devices and one or more Application Service Providers (ASPs), and one or more network elements. The invention includes a security agent installed on at least one device (which can be standalone or an adjunct security module bundled with another application), and communicates with the network security service.

The security agent of the invention in conjunction with the network security service of the invention provides enhanced security and threat mitigation for mobile device applications, such as for example fraud prevention for mobile device applications. Thus for example core aspects of the invention relate to security of mobile applications (for example mobile banking applications) communicating with Application Service Providers (for example a mobile web service such as a banking service). The security agent of the invention has means to isolate the device from all communications networks (for example Internet) except for example a private communications network with an ASP, while a user on a device is using an application or aspects of an application which require enhanced security and threat mitigation. Thus the invention has means for performing intelligent traffic management only permitting traffic from the device on a particular network and/or connection, for example a private network and/or private connection between the device and the ASP (as well as permitting any interactions required with the network security service). Thus advantageously if there is any malware on the device, the malware won't for example be able to communicate to a command and control (C&C) centre while the application is in use.

The invention provides means for Prevention of Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks. In one embodiment a network security manager according to the invention may operate and communicate with one or more devices and an Application Service Provider and communicate or reside on one or more network elements, and has means to route a data connection from an application on an endpoint device over a private connection to the application's network or Private Data Network and connects to a private IP for the ASP, or in an alternative embodiment has means to route the data connection from an application on an endpoint device to the Public Data Network (PDN), for example the Internet and connect to the public IP for the ASP.

The security agent of the invention also has means to prevent a user from carrying out other activities on the mobile phone whilst using an application which requires enhanced security and threat mitigation. The scope of the invention is not limited to but includes verifying and providing secure identity and risk management including risk management associated with identity, for many heterogeneous services and communications including inbound and outbound messaging (such as SMS and USSD), inbound and outbound data (such as mobile data), and inbound and outbound voice services (such as voice calls, including multi-party calls) such as for example to/from a service provider, and also includes, scenarios where the user is using their phone as a mobile WiFi hotspot.

The invention provides means for communicating, delivering and obtaining information from a user of a mobile application by using Unstructured Supplementary Service Data (USSD) as the bearer and communication channel in relation to mobile device applications that requires the user to enter authentication credentials that is sent to an Application Service Provider to be allowed perform a service through the same mobile device. The usage of USSD as the delivery and collection mechanism for sensitive data for a user of a mobile application is more secure as there is currently limited capability in mobile devices to listen to and obtain the information by using malware running on the mobile device. In addition, USSD traffic is sent over the mobile network signalling network as opposed to the Internet and is therefore more secure.

The invention provides means for secure services such as for example secure banking, secure payments, etc. from one or more devices. The invention provides location awareness of a mobile device using a service, including restriction of service based on a mobile device's location, such as for example restriction of a service such as mobile payments to reduce fraudulent behaviour. The mobile device location is obtained from the mobile network and/or from the GPS device in the mobile device. As added security the invention compares the location from the GPS device in the mobile device with the location obtained from the mobile network to determine if the user's mobile device is at the same location it claims to be. This is to combat any fraudulent scenarios where the location of the mobile device is faked or spoofed. Obtaining the location of a mobile device from the mobile network adds security and is more difficult to compromise or spoof for a potential fraudster. The invention provides users of mobile applications and/or ASPs the possibility to define one or more "Safe Places" (physical geographical locations) that can be used as one factor required for authentication as part of a multi-factor authentication. The "Safe Place" location would be part of the knowledge factor ("something the user knows") when authentication is required by a user to access an application running on a mobile device. In addition to this, the invention verifies the mobile device by ensuring that the mobile device is the expected user's mobile device by using the mobile network to obtain the required information.

The invention by providing secure identity establishment and risk management of endpoint devices in a communications network, including risk management associated with identity of endpoint devices, enables such features as Anti Money Laundering (AML) by enabling identity establishment of the customer, ensuring for example that the legitimate account holder or cardholder is using a particular service.

The invention by providing identity authentication, and enabling multi-factor authentication enables for example an Application Service Provider (ASP), for example a banking service contact centre, to know when they are communicating with a party, the degree of likelihood that they are communicating with the actual trusted party (e.g. the party's trusted device) and enables for example the ASP to be compliant with data protection legislation obligations.

Note the terms service provider and application service provider (ASP) are used inter changeably in this specification and are to be afforded the broadest possible interpretation.

Two-factor authentication

Two-factor authentication (also referred to as multi-factor authentication (MFA) or two-step verification, etc.) is an approach to authentication or the process of verifying someone's identity which requires the presentation of at least two of the three authentication factors: a knowledge factor ("something only the user knows"), a possession factor ("something only the user has"), and an inherence factor ("something only the user is"). After presentation, each factor must be validated by the other party for authentication or identity verification to occur. For clarity, the term 2 factor authentication is used to demonstrate example of multi-factor authentication, i.e. 2 or more factors. Embodiments of the invention are not limited to 2 factor authentication and may include for example, but not limited to, include voice biometric systems as an additional authentication factor.

Traditionally two factor authentication has device separation for enhanced security, thus typically a subscriber or user does not access the service from the same device to which it receives a verification or authentication code. Thus a user might want to access an application or service, for example Internet banking services on a fixed line device such as a laptop. In addition to the normal knowledge factor required (for example, username, password or other identification codes), the user typically receives a second Personal Identification Number (PIN) or authorisation code via for example an SMS being sent to a different device such as a mobile device, and the user enters this code in addition to the normal knowledge factors required, in order to access the service. Thus with the separation of the device that are accessing the service on and the trusted device (for example mobile phone), this makes it more challenging for a fraudster to compromise a service as it is less likely for example that both devices are compromised by malware, and compromising one device with malware may not compromise the service. The Two factor authentication solution in this example may have enhanced security, however the solution does entail two communication channels, Internet in the case of the fixed line device and SMS in the case of the mobile device, and also involves two devices.

With the advent of mobile services such as for example mobile banking services, which require two factor authentication, the security of the two factor authentication approach is reduced as there is no longer device separation, as the user is accessing the application or service, for example a mobile web based banking service on the same device (for example mobile phone) as the verification or authentication code is being sent to (for example in an SMS sent to the mobile device). Thus for example a fraudster now has one device to target with malware or other means, and the user accessing for example a website requiring two factor authentication are at a higher risk of their identity and security being compromised.

This weakening of the security associated with the two factor authentication approach in the mobile services domain is further compounded by the fact that the actual mobile device identity can be compromised by a fraudster. Thus there are particular vulnerabilities that the trusted mobile device can exhibit. One of these includes for example a SIM swap attack or SIM takeover, where a fraudster by impersonating a user succeeds in obtaining and activating a new mobile SIM from the mobile network operator under the subscriber's credentials, with the original SIM being cancelled and the legitimate user having no mobile services. This means that for services requiring 2-factor authentication, the 2-factor authentication code is then sent to the fraudster's phone with the new SIM, potentially allowing the fraudster access to the user's associated online service (for example mobile banking services).

Further, mobile device identity is generally not passed to for example the service provider or application service provider (ASP) which is providing the mobile service (for example a mobile web based service such as a banking service) and thus cannot be used as part of secure authentication mechanisms such as 2- factor authentication.

The invention addresses such issues. A solution providing secure 2-factor authentication for mobile devices and services is required and the invention provides this. In this invention focus will be on achieving two-factor authentication using knowledge factor (something the user knows for example, but not limited to, the location from where the user access the service from a mobile device) and possession factor (with the something the user has being for example, but not limited to, a mobile device).

Unstructured Supplementary Service Data (USSD)

Unstructured Supplementary Service Data (USSD) is a protocol that can be used by, but is not limited to, GSM mobile devices to communicate with servers/computers sitting in an Application Service Provider's (ASP) network. USSD is typically used for various mobile phone services like WAP browsing, call-back services, information services, etc.

An USSD message can be up to 182 alphanumeric characters in length. USSD messages creates a realtime connection that remains open during the USSD session. The USSD session will remain open until the session is closed down. A USSD connection makes it possible to have a two-way communication of data. USSD is generally faster and more response than using SMS. Most GSM mobile devices have USSD capability. USSD traffic would typically be carried between the mobile device and a USSD Gateway via the MSC. USSD contains a set of operations; USSD Request, USSD Response, USSD Notify and USSD Release. A USSD Request can be used to establish a new connection or it can also be sent within a USSD session that is already established. The USSD Response is a response message to a USSD Request. A USSD Notify can be used to send a notification to a mobile device. USSD Release will end the USSD session. An USSD Gateway is used by the Mobile Network Operators to enable communication between the GSM network and applications. USSD use the signalling channel of the mobile network as the bearer. USSD is real-time and is a session oriented protocol. Once a USSD session is opened, it will stay open until it is released either by the application server, the mobile device user or if it times out. Another added advantage with USSD is that there is no impact when roaming. There will be no charges for sending USSD messages when roaming. The same USSD services that are available in the mobile subscribers' home network will be available in the roaming network. With USSD it is possible to use interactive menus as well as just sending notifications to a mobile device. This allows ASPs by using the invention to efficiently use USSD to obtain required information by for example using, but not limited to, the USSD menu options on the mobile device. Another advantage using USSD is that USSD messaging is not depending on the software level installed on the mobile device. USSD is also not directly linked with the SIM card in the mobile device. For USSD to work, the mobile device must be connected to a mobile network. USSD was originally developed for GSM mobile networks, but there are support for USSD on WCDMA/3G and LTE as well. Only one USSD session can be active at one time towards a mobile device. If a mobile device has an active USSD session and receives a new USSD operation with a new USSD session ID, the mobile device will reject the new request. This additionally adds to the security of using USSD as the communication channel to send a mobile device user's PIN code to an ASP Application server. The main disadvantage using USSD as the bearer for end user communication is that there are no delivery reports, so there is no way of checking that an USSD message was actually delivered or not.

The invention uses USSD as a communication channel (bearer) to interact with the user to obtain the user's access or authorisation credentials. The invention will trigger an USSD Request to the user's mobile device via a USSD Gateway. The user's mobile will receive the request and the request will be displayed on the user mobile device. The invention would typically, but is not limited to, display a message requesting the user to enter a PIN Code or a Password ("Something that only the user knows"). The USSD message would be displayed in the forefront of the user's mobile device.

The user is for example asked to enter, but not limited to, the authentication credentials, e.g. a PIN Code or a Password (knowledge factor) and then click's "send" to reply to the USSD Request. Once the user has entered the PIN Code and clicked "Send" an USSD Response is sent back to the USSD Gateway from the Mobile Handset. The password is transferred securely and efficiently over SS7 back to the invention Security Manager.

Using USSD instead of for example SMS as the bearer for any request for the user to present additional authentication credentials is a more secure solution as there are currently no SW support for listening on USSD traffic in Android or iPhone mobile devices. Due to the lack of USSD listening capability it makes it more difficult for a potential fraudsters to compromise and listen to the traffic sent over USSD by for example using malware that has been installed on a user's mobile device. Additionally by using USSD as the bearer for the user to present additional authentication credentials the traffic is sent over SS7 within the Mobile Network, and it is generally more difficult to compromise the data between ASP application server and the mobile device.

Invention application areas within the Mobile Network For the clarity of the invention, when the patent application refers to specific mobile network elements like for example the Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN), the patent and invention applies to network elements providing the equivalent functionality in newer and later versions and releases of the mobile network like for example, but not limited to, 3G/W CDMA/LTE/EPC/4G/5G, etc. For example when the invention refers to SGSN, the invention also applies to the Mobility Management Entity (MME) in the Evolved Packet Core (EPC) network that provides the same functionality. In the same manner, where invention refers to GGSN, the invention also applies to the Packet Data Network Gateway (PGW and also referred to sometimes as PDN-GW) in the EPC network. Brief Description of the Drawings

The invention will be more clearly understood from the following description of an embodiment thereof, given by way of example only, with reference to the accompanying drawings, in which:- Figure 1 illustrates a network environment in which a network security service according to the invention may operate and communicates with one or more devices and an Application Service Provider and one or more network elements. Each device communicates with the ASP via an app which has an adjunct security software module (which can be bundled or standalone).

Figure 2 illustrates a network environment in which a network security manager according to the invention may operate and communicates with one or more devices and an Application Service Provider and communicates or resides on one or more network elements, and which routes a data connection from an application on an endpoint device over a private connection to the application's network or Private Data Network (PDN) and connects to a private IP for the ASP, or alternatively routes the data connection from an application on an endpoint device to the

Public Data Network, for example the Internet and connects to the public IP used by the ASP. Figure 3 illustrates a Risk Management for Mobile (RMM) module according to one embodiment of the invention communicating with an ASP such as for example a banking service provider. In this specification the network security service according to the invention, in one embodiment a mobile risk management system of the invention is interchangeably referred to as a Risk Management for Mobile (RMM) module.

Figure 4 illustrates a network environment in which a network security service according to the invention may operate and communicates with one or more devices and an Application Service Provider and one or more network elements and provides risk management for mobile broadband communications. In this embodiment a device tethered to another device acting as a mobile WiFi hotspot is illustrated.

Figure 5 illustrates a network environment in which a network security service according to the invention may operate and communicates with one or more devices and an Application Service Provider and one or more network elements and provides risk management. In this embodiment a mobile device tethered to another mobile device acting as a mobile WiFi hotspot is illustrated.

Figure 6 illustrates how a network security service according to the invention, can be applied to outbound calls from an ASP such as for example a banking service contact centre to a customer (for example to a customer's mobile phone).

Figure 7 illustrates an alternative embodiment of how a network security service according to the invention, can be applied to outbound calls from an ASP such as for example a banking service contact centre to a customer (for example to a customer's mobile phone).

Figure 7a illustrates a further alternative embodiment of how a network security service according to the invention, can be applied to outbound calls from an ASP such as for example a banking service contact centre to a customer (for example on their mobile phone), in this embodiment in an IMS context.

Figure 8 illustrates a further alternative embodiment of how a network security service according to the invention, can be applied to outbound calls from an ASP such as for example a banking service contact centre to a customer (for example on their mobile phone), where the network security service according to the invention is part of or integrated with an intelligent telephony service within a telecommunications network.

Figure 9 illustrates how a network security service according to the invention, can be applied to inbound calls to an ASP (such as for example a banking service contact centre) from a customer (for example from their mobile phone) or from a party masquerading as a customer, such as a fraudster.

Figure 10 illustrates an alternative embodiment of how a network security service according to the invention, can be applied to inbound calls to an ASP (such as for example a banking service contact centre) from a customer (for example from their mobile phone) or a party masquerading as a customer, such as a fraudster.

Figure 10a illustrates a further alternative embodiment of how a network security service according to the invention, can be applied to inbound calls from an ASP such as for example a banking service contact centre to a customer (for example on their mobile phone), in this embodiment in an IMS context. Figure 11 illustrates a further alternative embodiment of how a network security service according to the invention, can be applied to inbound calls from an ASP such as for example a banking service contact centre to a customer (for example on their mobile phone), where the network security service according to the invention is part of or integrated with an intelligent telephony service within a telecommunications network.

Figure 12 illustrates how a network security service according to the invention, can be applied to inbound calls to an ASP (such as for example a banking service contact centre) from a party masquerading as a customer, such as a fraudster (for example from their mobile phone) in the context of a multi-party call.

Figure 13 illustrates an alternative embodiment of how a network security service according to the invention, can be applied to inbound calls to an ASP (such as for example a banking service contact centre) from a party masquerading as a customer, such as a fraudster (for example from their mobile phone) in the context of a multi-party call.

Figure 14 illustrates how a network security service according to the invention, can be applied to 3D Secure functionality for mobile devices including means for 3D Secure for mobile phone payments (i.e. card not present transactions).

Figure 15 illustrates an alternative embodiment of how a network security service according to the invention, can be applied to 3D Secure functionality for mobile devices including means for 3D Secure for mobile phone payments (i.e. card not present transactions).

Figure 16 illustrates an alternative embodiment on how a network security service according to the invention can be applied to verify a Card-Not-Present payment over the phone to a service provider where the Service Provider have to manually enter the credit card details in to for example, but not limited to, a Point of Sale (POS). The invention allows the service provider to trigger a security check on cardholder's mobile device number during the ongoing call between the service provider and the card holder or potential fraudster. The cardholder's or fraudster's mobile number (MSISDN) is obtained from the network and is forwarded as part of the credit card check to the issuing bank via the acquiring bank. The invention's network security services receives a request by the issuing bank to check if the card holder's mobile number (MSINSDN) is legitimate or not, and produces a Risk Score and Reason Code based on this information together with for example, but not limited to, a check to see if there was a multi-party call active for this mobile number (MSISDN) at the time the card was used. Based on the invention's risks score that is returned to the issuing bank, the issuing bank can decide if the card transaction should be accepted or rejected.

Figure 17 and Figure 18 illustrates multiple alternative embodiments of the invention where the invention is used to authenticate a mobile device application user requiring one or more authentication factors to for example, but not limited to, gain access to an online banking service from a mobile device when connected to the internet through WIFI (figure 17) or when connected through the mobile internet (figure 18). Authentication is achieved by utilising the mobile network to authenticate the user by either using the mobile device identifier (something the user has) such as, but not limited to the MSISDN, IMSI, etc., or using the location of the mobile device (knowledge factor) or by providing or collecting an additional authentication factor through USSD. The invention allows for each authentication factor to be used as a standalone authentication or in any combination of the various methods or in conjunction with other existing authentication methods.

Figure 19 illustrates another embodiment of the invention relates to a scenario where a transaction request requires authentication and authorisation from multiple parties.

Detailed Description of the Drawings

The invention will be more clearly understood from the following description of an embodiment thereof, given by way of example only. Figure 1 illustrates a network environment in which a network security service according to the invention may operate and communicates with one or more devices and an Application Service Provider (ASP) and one or more network elements. Each device communicates with the ASP via an app which has an adjunct security software module, indicated generally by the reference numeral 10 (which can be bundled or standalone). The network security service according to the invention can be a cloud based service but need not be.

Aspects of the invention may be better understood from the following description.

• An application (e.g. a banking application) is started up on an end point device, for example a mobile phone.

• The banking application has an adjunct security software module (which can be bundled or standalone) for example a Java application contained within a Java ARchive (JAR) or an application running for example on a SIM card or on a UICC (Universal Integrated Circuit Card) or any equivalent on technologies such as for example 2G, 2.5G, 3G, 4G (including for example LTE, LTE-A, etc.) 5G and later incarnations and is not limited to these technologies. The app could for example be created within the context of a SIM application toolkit or a USIM Application Toolkit (USAT) or equivalent or on later technologies etc.

• The app sends a request (1) to the Application Service Provider (for example a mobile web service such as a banking service) to obtain the login screen (in one embodiment over WiFi). As part of the request the session ID associated with the session between the app and the

Application Service Provider (for example a back end server) is returned. The app or the Application Service Provider (ASP) can generate the session ID. The security service short code could also be returned from the ASP and passed in one embodiment into a JAR file which results in the short code being populated in the destination address of the SMS. Alternatively the system can use APNs to route the traffic to a Private IP. An ASP ID is issued to the Application Service

Provider (ASP) by the network security service (which may or may not be a security service) to uniquely identify that individual Application Service Provider (ASP) and in order to route information to the ASP.

• The invention encompasses means for routing communications between application(s) on an end-point device (such as for example a mobile device) and an ASP, through any mobile network to a Private Data Network (PDN) (such as for example a banking application network), connecting for example over a fixed connection using a private network address (such as a private IP address).

• Advantageously, any transactions made over this private network and using the private IP address to access the Application Service provider' s (for example a banking application or a bank's application back-end infrastructure hosting for example a banking application/service) system will not be exposed to security threats or attacks such as for example DoS/DDoS attacks. Thus the preferred route for an application on a mobile device (for example a banking application) to connect to the ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service) is via a private connection to the application's network or Private Data Network (PDN), connecting to the private IP for the ASP.

• In one embodiment a network based security manager of the invention (which in one embodiment can be on an SGSN and in another embodiment can be the MME node in the Evolved Packet Core (EPC) network) has means to recognize that a request from an application for a data connection to a particular service/domain or IP address to connect for example to an ASP, which may for example be using the default APN, for example an Internet Service Provider (ISP) APN should be using a different APN which is provisioned for the service.

• The network based security manager of the invention on ascertaining the IP address or for example resolving the target service/domain that the application is trying to connect to (for example via DNS lookup including for example can have access to a local DNS entry configured in the mobile operator), thus ascertains the IP address that must be used in order for the application to reach the requested domain name/service, and determines that the application should preferentially access that over for example a local IP address, which is a private IP address. In one embodiment the security manager (on or integrated with the SGSN) maintains or has access to a list of restricted IP addresses (for example a network service access address control list) and the private IP address in this embodiment is in that list. In order for the application to access the requested service (for example ASP) over the private IP address the security manager (together with the SGSN) determines the appropriate APN that must be used instead of for example the default APN (for example ISP APN which can be provided in the request from the connecting user). The security manager (in this embodiment on an SGSN) before assigning the APN (for example associated with an access means via a private connection to the application's network or a private data network and private IP to the ASP), in one embodiment queries the network (for example a network node such as a HLR) to ascertain if the subscriber (for example the subscriber's IMSI or MSISDN) is provisioned to access that particular ASP's APN.

If the subscriber is provisioned for the APN, this APN and corresponding private IP address can be used and in this embodiment the security manager via for example the SGSN identifies the relevant GGSN node as being a dedicated GGSN (in the mobile network), which routes the data connection over the private connection to the application's network or Private Data Network and connects to the private IP address for the ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service).

Advantageously, any transactions made over this private network and using the private IP address to access the ASP or ASP's system (for example a banking application or a bank's application back-end infrastructure hosting for example a banking application/service) will not be exposed to service disruption or compromise due to for example security threats or attacks such as for example DoS/DDoS attacks.

If the user (for example user's IMSI or MSISDN) has not been provisioned (for example in the HLR) to access an ASP's APN (which corresponds to an access means via a private connection to the application's network or a Private Data Network and private IP to the ASP) selected and/or deemed appropriate by the security manager for the Mobile Station (MS) or Mobile Device to access the service (for example ASP), then the network based security manager of the invention has means to assign a different APN which corresponds to an access means via a public data network and public IP to the ASP, and the security manager in this embodiment via an SGSN node identifies the relevant GGSN node as being a GGSN (in the mobile network) which connects to the Public Data Network, for example the Internet and which routes the data connection to the Internet and connects to the public IP for the ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service), which can be subject to compromise such as security threats or attacks such as for example DoS/DDoS attacks. Further detail on this aspect of the invention is provided later in the specification, refer to section on "Prevention of DoS/DDoS attacks - Routing via Private Network".

The app calls the bundled JAR file (the JAR file can provide means for contributing to security and end point device identification as described later). The JAR file provides a standard interface for all application developers to use, abstracting out any details of the implementation, easing integration. Thus application developers at an ASP (for example a mobile web service such as a banking service) can use and invoke it much like any standard SDK (Software Development Kit). It will be appreciated that the JAR file can be any software instructions code, SDK or applet configure to operate on the end point device. Thus for example there could be, but not limited to, a Java method:

Int doAuthLogin (session ID, ASP ID, short code); with three parameters passed in, session ID, application Service Provider ID and the security service short code, and Int provides means to communicate back to the app that the operation is successful or there is some problem with the operation. This approach of making a JAR file/SDK available which could for example be made available via a website, means an ASP(s) when for example are building their app can sign up, download and bundle the JAR file with their app, which means it is very easy to distribute, easing rollout and deployment, and facilitates ease of scaling of the number of apps deployed on devices.

As already mentioned the app can request the security service short code from the Application Service Provider. Alternatively the app can request the short code (2) from the network security service (in one embodiment a Risk Management module) of the invention.

For example if the doAuthLogin method just has sessionID and ASP ID and does not have the short code, the JAR file can request a short code from the network security service. The network security service can return a short code from a short code pool even if the request is not via a trusted mechanism (i.e. the query can be untrusted), as the network security service performs authentication in any event when the message is submitted with the short code. Thus for example the request could be a HTTP or HTTPS or other request over a data connection. Further advantageously the SMS centre can be configured to only accept on-net traffic for a short code, thus if for example a party on the Internet had access to the short code it would not be routed to the network security service unless the party was on-net on the mobile network provider's network.

If the request from the app to the network security service via for example a HTTP request over a data connection, was unsuccessful, the app could send a text message to a standard long number at which the network security service is reachable. On receiving the message the network security service obtains the originating address (OA) from the SMS and validates the address by sending to a HLR a MAP SRI (Send Routing Information) query on the originating address for example a MSISDN (required because the Mobile Network Code (MNC) if present in the OA address (for example MSISDN) may not be the actual associated network because of number portability), obtaining the Mobile Country Code (MCC) and MNC (Mobile Network Code). Based on the MCC and MNC the network security service returns an appropriate short code for the particular network, one that is provisioned on the SMSC, and then the network security service texts that back to the mobile device, with the short code in the body of the message. In one embodiment the app on the mobile device is monitoring for the inbound message, and when it receives the inbound message, it reads the short code, and then it sends a further SMS this time to the short code, which is routed to the network security service.

In an alternative embodiment the network identifier for the mobile network operator can be provided by the bundled JAR file. The JAR file could query the devices OS and obtain the MCC and MNC. Once the MCC and MNC are identified and provided in the body of the text message sent to the network security service an appropriate short code can be assigned and returned by the network security service in a text message as already described or the JAR file could be preprogrammed with appropriate short codes for various network providers, or a list of appropriate short codes could be pulled down by the security agent from a configured location.

The short code can change, e.g. rotate, based on time etc. The network security service of the invention can communicate with multiple operators. The short code(s) are unique per mobile operator. In an alternative embodiment where operators standardise the requisite short codes, such short codes can be shared.

Dynamic short code allocation can be used for load sharing. As already described the initial request sent by the app to the ASP can return a security service short code, in this instance the ASP could for example achieve dynamic short code allocation by maintaining a pool of short codes and allocating the most appropriate depending on for example load share factors etc. In an alternative embodiment the ASP or the app (via for example the JAR file) requests a short code and the network security service returns a short code from a pool of short codes. In a further alternative embodiment, the ASP could request a short code from the network security service, specifying the number of network users that are associated with that service and the network security service provides an appropriate short code from a pool of short codes. In yet another alternative embodiment, the network security service maintains a token list of how many requests there are associated with a particular short code and returns an appropriate short code from a pool of short codes to the ASP or the app.

Importantly the short code is in itself not an end to end routable number and requires additional provisioning on network service elements, for example in order to route an SMS to a short code, the short code has to be provisioned on the SMSC. Significantly a short code is not suitable for a "man in the middle" security threat to route on. Thus for example if a device had a rogue app or compromised app installed then if such a "man in the middle" security threat attempted to route an SMS via a Rogue SMSC it would not be possible to do so as the requisite provisioning and configuration would not be in place, with the "man in the middle" security threat requiring a long code to route. In a particular geographic territory the network security service will have connections into all local operators which are providing the secure service and will only accept messages from customers of those local operators on those connections (in one embodiment SMPP binds).

The app (via the bundled JAR File) sends an SMS (3) embedding the session ID, and the ASP ID, to the network security service (in one embodiment a Risk Management for Mobile module) of the invention via the short code. The SMS is sent to the originator's home Mobile Network Operator (MNO) SMSC.

The network security service of the invention binds via an ESME channel (for example using an SMPP bind) to the Mobile Network Operators (MNO) SMSC. Normally such an ESME channel would be a permanent or very long running session (for example SMPP session). In one embodiment the SMSC is configured to send messages with particular destination addresses or messages whose destination addresses fall into a configured address range which includes the requisite short code, to the network security service. Thus the network security service receives all messages destined for the requisite short code. Importantly this is the case regardless of whether the message originator is roaming or not. In an alternative embodiment the ESME (the network security service in this instance) can specify for example an address range of short messages which it wishes to be routed to it, although in practice what the MNO has configured on the SMSC is likely to take precedence.

The network security service when it receives a message on an ESME channel obtains the originating address (OA) from the SMS and validates the address by sending to a HLR a MAP SRI (Send Routing Information) query on the originating address for example a MSISDN (required because the MNC if present in OA (for example MSISDN) may not be the actual associated network because of number portability), obtaining the MCC (Mobile Country Code) and MNC (Mobile Network Code), and other identification information for the subscriber. The network security service then validates if the subscriber is on the expected network, for which the short code(s) are associated and provisioned for the ESME channel on which the message is received. If this is not the case in one embodiment the message can be discarded by the RMM. The risk score for the subscriber device associated with the originating address is updated to reflect the outcome of this check.

Thus the network security service has reliable device identity of the SMS originator from the MSC (which can insert the originating MSISDN into the SMS signal).

Significantly the network security service can have a high level of trust as to originator(s) of messages it receives as the message is being received via a home SMSC configured with the short code, and is being routed via an MSC which can insert the originating MSISDN into the SMS signal. Thus there are trusted core network elements involved in routing and identity of the SMS to the network security service. This trust is further augmented by the fact that the session ID and ASP ID are present in the message. The network security service anonymizes the device identity and translates the identity to a UID which remains consistent (In one embodiment this can be the MSISDN which is translated to a UID).

The network security service (in one embodiment a Risk Management module) performs risk management procedures. This can include, but is not limited to, such procedures as location analysis by the RMM (via a location based check such as querying a HLR for the latest serving MSC for a mobile device) which might indicate, but is not limited to, that the user is in a geographical location that is more associated with fraud than other locations, or in a less secure environment for example for a banking application that the user is outside the EU, in a non-chip and PIN area/environment. The outcome of such location analysis can be reflected by the RMM in the risk score and reason code(s).

Other risk management procedures and analysis that the network security service can perform include SIM takeover analysis. The Subscriber Identification Module (SIM) card inserted into the mobile phone is uniquely associated with the IMSI. In this instance the network security service can query the HLR for the latest IMSI. The RMM can then perform SIM takeover/SIM swap attack analysis, and if such analysis indicates a high probability of SIM swap /takeover having occurred this can be reflected in the risk score and a reason code.

In one embodiment the reason code encodes the characteristic that influences the risk score most, allowing the RMM to indicate that this is the dominant cause of the risk score associated for example with the subscriber. Where a reason code encodes a single characteristic there can be one reason code, or alternatively multiple reason codes, for example where each reason code encodes a different characteristic that is contributing to the risk score.

In an alternative embodiment a reason code can encode multiple characteristics, reflecting the one or more characteristics that influence the risk score most, allowing the RMM to indicate the one or more characteristics which are the dominant cause(s) of the risk score associated for example with the subscriber. Thus the reason code can be an aggregate code to indicate a combination of factors including dominant factors that have contributed to the risk score. Also in such an alternative embodiment there can be multiple reason codes each encoding multiple characteristics.

Other useful identifiers for a mobile subscriber device that can be returned from a HLR include the International Mobile Station Equipment Identity (IMEI).

On completion of the risk management procedures the Risk Management module outputs metadata (4) to the requisite Application Service Provider, which can include such metadata as UID, risk score, reason code etc.

The Application Service Provider can take action based on the received metadata.

The ASP in this embodiment is a Mobile service provider such as a mobile banking service provider. Advantageously the level of access to the application or service provided by the ASP (in this example a mobile web service such as a banking service) given to the user, on successful login, by the ASP can be based on the result of the risk analysis by the mobile risk management of the invention (in one embodiment an RMM) as reflected in the metadata presented to the ASP (a mobile banking service in this embodiment). Mobile banking service providers do allow for example basic banking tasks to be performed which include such operations as money transfer to existing beneficiaries, without requiring the highest level of security, However for more sensitive tasks such as adding new beneficiaries, change of address, registering for e-statements etc., they do need to be as sure as possible that such tasks are not being carried out by a fraudster. Such differentiation of level of service to the user can be based on the result of the risk analysis of the trusted device by the RMM as reflected in the metadata presented to the banking service in this example. As already mentioned with the advent of mobile services such as for example mobile banking services, which require two factor authentication, the security of the two factor authentication approach is reduced as there is no longer device separation, as the user is accessing the application or service, for example a mobile web based banking service on the same device (for example mobile phone) as the verification code or authentication code is being sent to (for example in an SMS sent to the mobile device). ASPs such as (a mobile web service provider such as a mobile banking service provider) demand a level of security that separation of access traditionally gave, i.e. the user not accessing the service from the trusted device. Although in this embodiment of the invention the user is accessing the service from the end device (traditionally the trusted device), the invention is not however depending on the end device to provide the identity, instead the identity is coming from the mobile core network (from the MSC which can insert the originating MSISDN into the SMS signal which is routed to the network security service, with the MSC effectively being the secure element (as opposed to the device)). Thus there are trusted core network elements involved in routing (SMSC via provisioned short code) and identity (via MSC inserting the originating MSISDN into the SMS signal of the SMS) which is routed to the network security service. This trust is further augmented by the fact that the session ID and ASP ID are present in the message.

Advantageously an MSC (or HLR/HSS) are exceedingly difficult to compromise, being deep in the MNO core network. Also the software and configuration are very specialized. Even if it were possible to tamper with identities such as for example MSISDNs and IMSIs, it is more likely that would result in a subscriber being off the network and no traffic going to and from the subscriber, than for example an opportune fraud window for a fraudster.

Thus in this embodiment the invention is achieving the separation that on a business and technical level the ASP (e.g. banking service provider, i.e. Bank) requires. Because of that the invention is malware agnostic, i.e. there is nothing that the malware on the device can do to manipulate the identity. Even if malware could manipulate the session ID or ASP ID the result is that either the network security service cannot pass the risk information to the bank (i.e. if ASP ID manipulated) or if the network security service does pass it to the bank and the session ID is incorrect the bank will be unable to correlate to the real customer's active service session. Either of these situations will result in the ASP (in this example the banks backend server) assuming a high risk and minimizing the customer end user device access rights within the service.

Thus the possession factor element ("something only the user has") in this instance the trusted device, of the two-factor authentication has been fulfilled by the risk analysis performed by the mobile risk management of the invention (in one embodiment refer to RMM in Figure 3) on the trusted identifier or identity of the end user device. The invention is not however depending on the end device to provide the identity, instead the trusted identifier or identity has been provided by a trusted core network element in the mobile network, namely the MSC (inserting the originating MSISDN into the SMS signal of the SMS which is routed to the network security service), which can effectively be viewed as a "trusted device" in this invention. As already described this is augmented by another trusted core network element involved in routing the SMS, namely the SMSC via a provisioned short code. This trust is further augmented by the fact that the session ID and ASP ID are present in the message.

The knowledge factor ("something only the user knows") element of the two-factor authentication is fulfilled by the user providing login credentials such as user name and password (as well as any authorization code or PIN from the ASP) on attempting to login to the mobile banking service. Thus the invention has achieved secure two-factor authentication and overcome the limitations associated with using an application (such as a banking application) on a single trusted device for two-factor authentication.

The solution is ubiquitous, operating equally well on modern devices such as for example a modern smart phone or an older Symbian device or legacy device capable of running applications. ASPs such as (a mobile web service provider such as a mobile banking service provider) demand a level of security that separation of access traditionally gave, i.e. the user not accessing the service from the trusted device. Because this has not been traditionally addressed and thus because of the attendant security risks including fraud risks associated with mobile banking, although service providers do allow money transfer operations between existing beneficiaries, they impose stringent limits on the amounts that can be transferred typically limiting the amounts to around€100. Thus for example banks are providing mobile banking services where a customer can download and install a banking app on their mobile device. A customer can for example select a beneficiary and their mobile number in the app, and select a monetary amount for transfer (up to a stringent limit such as for example€100). In one embodiment the app can check the availability of those funds in the customer's account, check if the beneficiary is registered, obtain the details of the beneficiary's account that are registered against the mobile number, and do a bank transfer. The customer affecting the transfer need only concern themselves with the mobile number of the beneficiary, i.e. at a high level it seems to the customer that they are transferring money to the mobile number of the beneficiary. The mobile banking service providers (for example banks) want to be able to satisfy their customer's demands to increase the amounts transferable very significantly, but as mentioned the current security risks including fraud risks associated with mobile banking mitigate against that. As just described the invention by achieving secure two-factor authentication and overcoming the limitations associated with using an application (such as a banking application) on a single trusted device for two-factor authentication, addresses the risks associated with such applications and provides secure identity establishment and risk management of endpoint devices in a communications network, including risk management associated with identity of endpoint devices. Thus by incorporating the invention banks can increase the amounts transferable very significantly between parties where transactions are requested from a mobile device. Thus the invention is not only providing benefits such as much stronger and secure identification and addressing security risks such as preventing fraud, but also enabling business. As described later the invention can also advantageously perform forensic analysis to detect and report on fraudulent activity which could for example indicate a potentially compromised device, or for example potential Anti Money Laundering (AML) activity, or other suspicious activity. A key aspect of the invention as regards AML is risk management associated with identity of endpoint devices, as a key AML challenge is to be able to identify the customer.

Some ASPs have requirements for multiple security levels with more sensitive capabilities being reserved for parties which have higher levels of security. Thus an ASP for example such as mobile banking service providers do allow for example basic banking tasks to be performed which include such operations as money transfer to existing beneficiaries, without requiring the highest level of security. However for more sensitive tasks such as removing or adding new beneficiaries, change of address, registering for e- statements etc., they do need to be as sure as possible that such tasks are not being carried out by a fraudster. Such differentiation of level of service can be based on the result of the risk analysis of the trusted device by the RMM as reflected in the metadata presented to the banking service in this example. As just described the invention by achieving secure two-factor authentication can permit only users who satisfy two-factor authentication to perform more sensitive tasks.

Device Isolation Advantageously, in one embodiment a mobile phone application (has an adjunct security software module or security agent of the invention (which can be bundled or standalone) for example a Java application contained within a Java ARchive (JAR)), for example a banking application allows the application user to choose between a "Normal Security" or a "Maximum Security" option. The "Normal Security" option allows the application user to perform some tasks, but not any sensitive tasks that require 2-factor authentication as described above. The "Maximum Security" option allows the application user to perform sensitive tasks that require 2-factor authentication as described above. Whilst the user is performing sensitive tasks the application isolates the device from the Internet, for example shutting down Wi-Fi, Bluetooth, and any other active connections on the phone, preventing the user from connecting through the Internet while the application is in use (for example access to services such as Facebook, email etc. is disabled). This allows the application to isolate the phone from any other network with the exception of the mobile network and the network that is assigned to the application either through the security manager of the invention, or configured on the end-user device such as a mobile device, in both cases in conjunction with being configured on the network (for example the HLR). For detail on the various scenarios possible refer to the scenarios described under the heading "Prevention of DoS/DDoS attacks - Routing via Private Network". Thus the invention has means for performing intelligent traffic management only permitting traffic from the device on a particular network and/or connection. For example if the user is assigned an APN associated with a private IP (either by the invention or configured on the end-user device such as a mobile device), and the user (for example user's IMSI or MSISDN) has been provisioned for that APN (of the ASP) within the Mobile Network (for example HLR), then the connection will use the private IP to connect to the ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service), and in one embodiment the traffic will be routed to a dedicated node within the network that will have a private connection set up to the ASP (for example banking service provider/banking application). Thus the application can isolate the device from all other networks not required for access to the private network to the ASP, the banking application in this instance, for the period required for access to the banking application.

The purpose of isolating the device from all other networks such as WiFi, Bluetooth, etc., is that are thereby forcing the device traffic into the mobile network where the security manager of the invention has visibility of the traffic. Thus (for example depending on operator policy) the security manager which in this embodiment can be on the GGSN or on both the SGSN and GGSN, or in other embodiments reside on the SGSN, or reside on a separate node and be in communication with an GGSN and/or SGSN or other suitable node, or reside on any suitable network element or combination of elements. The security manager can perform many and varied functions.

In one embodiment the aspects/modules of the security manager on the SGSN can perform functions such as but not limited to deciding and implementing how traffic is routed to the ASP as described in the scenarios under the heading "Prevention of DoS/DDoS attacks - Routing via Private Network", whilst those aspects of the security manager on the GGSN can implement policy decisions such as whether other traffic besides traffic that is related to the application is allowed to be routed. Thus for example the security manager on the GGSN could implement a policy where all traffic that is not related to a specific application (for example a banking application), such as for example Facebook, Google, YouTube, command and control traffic is blocked. Alternatively such traffic could be allowed in parallel to the application specific traffic.

Triggering device (in one embodiment a mobile phone) isolation is based on the destination IP address. The invention (in one embodiment the security manager of the invention which as already described, in one embodiment can be on the GGSN or on both the SGSN and GGSN, or in other embodiments reside on the SGSN, or reside on a separate node and be in communication with an GGSN and/or SGSN or other suitable node, or reside on any suitable network element or combination of elements) identifies the traffic for a particular ASP, for example a banking ASP, by the destination IP address.

Thus when a user starts up their phone, when the user opens up the application (for example a banking application or a payment application), as already described the application allows the application user to choose between a "Normal Security", or a "Maximum Security" option. Thus for example if the user chooses normal security the traffic is sent to a particular IP address, (for example, but not limited to, via HTTP Post or other suitable mechanism). If a user however chooses maximum security, traffic is sent to a different IP address. In one embodiment both of those IP addresses could be on the same physical server, so for example in a bank' s network it might be the same machine, physically handling the receipt of the traffic destined for both IP addresses, but the difference is that when the user chooses the "Maximum Security" option traffic is routed to a particular IP address, whilst when the user chooses the normal security option traffic is routed to a different IP address. Significantly in one embodiment the security manager of the invention in the mobile network is monitoring for traffic destined for the IP address associated with the maximum security option, and when it detects traffic destined for that IP address, this triggers the security manager to isolate the device from the Internet and all other services (blocking all traffic to those), and only allowing traffic destined for the IP address associated with the "Maximum Security" option.

Thus the invention is performing intelligent traffic management, only permitting traffic from the device on the private network or private connection between the device and the ASP (as well as permitting any interactions required with the network security service).

Thus advantageously if there is any malware on the device, the malware won't for example be able to communicate to a command and control (C&C) centre while the application is in use.

The application user is also prevented from carrying out other activities on the mobile phone while using this application, with for example in one embodiment the mobile application taking control of the screen on the mobile device to prevent the application user from performing other activities on the mobile phone while using this application.

Once the application is shut down, normal service is resumed, with normal Internet access restored, and any other restrictions as regards the user carrying out activities on the phone are lifted etc. Prevention of DoS DDoS attacks - Routing via Private Network

Currently many mobile applications use the Internet as a transport network to connect from subscriber devices to Application Service Provider resources. Thus for example currently many mobile applications such as mobile banking applications use the Internet as a transport network to connect account holders to ASP resources for example server resources at the account holder's bank. Account holders may roam from location to location with the mobile device on which they have installed the mobile banking application. As a result, the account holder's device may obtain temporary and unpredictable network address allocations. This makes it difficult for the ASP, i.e. in this embodiment the account holder's bank to defend against malicious traffic from specific locations because the account holder may legitimately originate a mobile banking session from a suspicious location.

The account holder's bank may opt to deploy a bandwidth choke at the receiving end of the session (i.e. where the bank servers are located). While this can provide some defence against an excess of traffic from each individual source address, it does little to defend against security threats or attacks such as for example distributed denial of service (DDoS) attacks.

A DoS (Denial of Service) attack and/or a DDoS attack is an attempt to make a system, machine or network resource unavailable to its intended users by flooding the application with illegitimate requests. A common method of attack involves saturating the target machine or system with external communications requests, so much so that it cannot respond to legitimate traffic or responds so slowly as to be rendered essentially unavailable. Such attacks usually lead to server overload and thereby denial of service for the legitimate users. In the case of DDoS the external communications requests to the target for example an ASP originate from many sources. To complicate matters, attackers may vary the source addresses used in a DDoS attack so that the victim for example an ASP (such as for example, but not limited to, a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service) is unable to adequately and dynamically adapt its defences at the destination/target (i.e. at the side of the session where the victim ASP hosts infrastructure/servers/applications).

Perpetrators of DoS/DDoS attacks, typically target for example internet sites or services hosted on high- profile web servers, and in the case of financial services can target for example banking service ASPs, credit card payment gateways, or potentially naming servers, etc. DoS/DDoS attacks can also be carried out as a form of resistance or protest.

Anti-DDoS service providers attempt to solve the problem of DDoS by shifting the choke point further towards the client side of the attack. In this case, the ASP's servers may be protected but there is still a window of opportunity for attackers to create a DDoS within the clients Internet Service Provider network.

The invention addresses the DDoS problem for both the ASP (for example banking service provider with whom the application user's account holder is with) and for the application user/account holder by providing a dedicated data transmission path over the mobile network directly to the ASP (for example banking service provider/banking application). This private transmission path does not facilitate unsolicited traffic, including excess traffic during a DDoS attack. In the event that a legitimate application user such as an account holder attempts to execute a DoS attack on an ASP (for example a bank's application back-end infrastructure (for example servers) hosting for example a banking application/service), this activity can be identified and choked at source so that the only impact is to that application user/account holder. The invention encompasses means for routing communications between application(s) on an end-point device (such as for example a mobile device) and an ASP, through any mobile network to a Private Data Network (such as for example a banking application network), connecting for example over a fixed connection using a private network address (such as a private IP address). The invention covers any use of mobile applications connecting through a mobile network, to an IP network running and hosting the back-end infrastructure for an ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service), where the mobile network can encompass technologies such as but not limited to: GSM, UMTS and LTE/4G, 5G, future incarnations etc.

As already described mobile devices are being used for services which require a high level of security such as for example, but not limited to, online banking (including updating banking details making transfers, making payments, adding beneficiaries, and similar activities on line), payment solutions, and mobile money solutions where the mobile itself can be used as a purse, etc. The demand and growth for such mobile services means that application users are accessing such services from their end-user device via a mobile network and generally thence over the internet as a transport network to access the ASPs.

Although accessing these services via an end-point device such as mobile device, makes it convenient and easy for the end user to perform such services, services such as mobile banking services require added security measures to prevent fraudulent behaviour and to protect the actors involved (including but not limited to), financial institutions such as a bank, and the bank's customers against fraud.

Most mobile and online banking services expose a public IP that the end user can connect to over the Internet. Thus application users such as mobile banking customers on end-point devices such as a mobile device, initiating a connection request or IP traffic to for example mobile banking applications over the mobile network are generally routed from the mobile device through the Mobile Network and then over the Internet to the ASP (for example Banking applications residing within the Bank's network). Hence because the traffic is usually routed out through the Internet, this means that a request to connect to a mobile service such as a banking service initiated from for example a mobile banking application by a mobile banking customer on a mobile device over a mobile network is often to a public IP address. This connection method, connecting using a public IP, exposes services such as banking applications to security threats or attacks such as for example Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks. The invention addresses such security issues.

The invention has means to effectively change the flow of the data traffic from a mobile device to an ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service). Instead of routing the traffic from the mobile network and out through the Internet and thereby connecting to the ASP (for example, but not limited to, a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service) using a public IP, the invention has means to preferentially route the traffic through the Mobile Network and connect to the ASP's network over a fixed IP connection using a private IP (provided the application user is provisioned on the network for the appropriate Access Point Name (APN) as described later). By using a private IP instead of a public IP to connect to the ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service) the risk of DoS attack and DDoS attack is effectively eliminated.

Any mobile device making a data connection over a mobile network must be configured with an Access Point Name (APN) to present to the mobile carrier / mobile network. Thus for example the APN can be the name of a gateway such as between a, but not limited to, GPRS/3G/LTE mobile network and any other communications network. When a mobile user connects to an application from a mobile device over the mobile Internet, the APN is used to identify how the customer's mobile handset will connect to the external world, e.g. the Internet.

The security manager of the invention (which in one embodiment can be on an SGSN) may have access to and/or maintain several configured APNs. The security manager can determine that an app on a device should preferentially access an ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service), over a private IP address which is for example in a list of restricted IP addresses (for example a network service access address control list, which the security manager maintains or has access to) and determines the appropriate APN that must be used (instead of for example the default APN for example ISP APN which can be provided in the request from the connecting user) which is for example associated with an access means via a private connection to the application's network or a private data network and private IP to the ASP.

Before assigning the APN the security manager, in one embodiment queries the network (for example a network node such as a HLR) to ascertain if the subscriber (for example the subscriber's IMSI or MSISDN) is provisioned to access that particular ASP's APN, and if the subscriber is provisioned for this APN the associated access means (via a private connection to the application's network or a private data network and private IP to the ASP) is used, and in one embodiment the traffic will be routed to a dedicated node within the network that will have a private connection set up to the ASP, protecting the ASP (for example mobile application server) from exposure to service disruption and/or compromise due to for example security threats or attacks such as for example DoS/DDoS attacks.

In an alternative embodiment if the user (for example user's IMSI or MSISDN) has not been provisioned (for example in the HLR) to access the appropriate APN (which corresponds to an access means via a private connection to the application's network or a private data network and private IP to the ASP) selected and/or deemed appropriate by the security manager for the MS to access the requested service (for example ASP), then the network based security manager of the invention has means to assign a different APN (which in one embodiment can be the default Internet APN or default ASP APN for example requested by the mobile device or any APN configured for this purpose) which corresponds to an access means via a public data network and public IP to the ASP, which exposes the ASP to service disruption and/or compromise such as security threats or attacks such as for example DoS/DDoS attacks. Referring to Figure 2 (ASP private IP), a technical issue that the invention addresses is that the APN associated with the ASP (for example banking service provider/banking application) may not be provisioned on the device.

The network based security manager of the invention (in one embodiment on an SGSN) adds a check to the connecting user's APN received in the incoming request to examine how the connection to the ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service) should be set up.

Further detail is described in the following embodiments.

Security manager of the invention determines that preferential access for ASP is via a private IP address, and subscriber provisioned (for example on the HLR) for the associated APN, APN associated with preferential access not configured on the device. In one embodiment an APN for preferential access means for the ASP (for example banking service provider banking application) is not configured on the device.

The application user starts the application on the mobile device and provides the required access details to enter the mobile application (for example a mobile banking application). The mobile application connects to the mobile network and sends the relevant IP address or domain name and APN to request and initiate a data connection to the application' s back-end server.

Referring to Figure 2 (ASP private IP), the app on the mobile device can make use of an APN that is provisioned on the device. If the required APN for the service (for example banking service provider banking application) is not provisioned on the terminal, then the app on the device may try and connect to the service using the ISP APN or other default APN. The invention advantageously addresses this by a network based security manager (depicted in Figure 2) of the invention (which in one embodiment can be on an SGSN) which has means to recognize that a request from an application for a data connection to a particular service/domain or IP address to connect for example to an ASP, which may for example be using the default APN, for example an ISP APN should be using a different APN which is provisioned for the service.

In one embodiment the network based security manager of the invention (which in one embodiment can be on an SGSN, or integrated with an SGSN and capable of leveraging functionality and means available to the SGSN) on ascertaining the IP address or for example resolving the target service/domain that the application is trying to connect to (for example via DNS lookup including having access for example to a local DNS entry configured in the mobile operator), thus ascertains the IP address that must be used in order for the application to reach the requested domain name/service, and determines that the application should preferentially access that over for example a local IP address, which is a private IP address. In one embodiment the security manager (on or integrated with the SGSN) maintains or has access to for example a list of restricted IP addresses (for example a network service access address control list) and the private IP address in this embodiment is in that list. In order for the application to access the requested service (for example ASP) over the private IP address the security manager (together with the SGSN) determines the appropriate APN that must be used instead of for example the default APN (for example ISP APN which can be provided in the request from the connecting user). But in order to connect to that private IP, the security manager (on the SGSN) must first establish if the subscriber is configured on the network (for example on a HLR) for the particular associated APN. Thus the security manager (in this embodiment on an SGSN) before assigning the APN (for example associated with an access means via a private connection to the application's network or a private data network and private IP to the ASP), in one embodiment queries the network (for example a network node such as a HLR) to ascertain if the subscriber (for example the subscriber's IMSI or MSISDN) is provisioned to access that particular ASP's APN.

If the subscriber is provisioned for the APN, this APN and corresponding private IP address can be used (rather than for example any APN provided by the Mobile Station (MS) such as the default APN (for example ISP APN)), and in this embodiment the security manager via the SGSN identifies the relevant GGSN node as being a dedicated GGSN (in the mobile network), which routes the data connection over the private connection to the application's network or Private Data Network and connects to the private IP address for the ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service). The private IP address may or may not be in a De- Militarised Zone (DMZ), but using a private data connection and a private IP address will protect the ASP (for example mobile application server) from security threats or attacks such as for example DoS/DDoS attacks, as the ASP's private IP address is never known or visible outside the mobile network. Thus advantageously any transactions made over this Private network and using the private IP address to access the ASP or ASP's system (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service) will not be exposed to service disruption or compromise due to for example security threats or attacks such as for example DoS/DDoS attacks.

Security manager of the invention determines that preferential access for ASP is via a private IP address, and subscriber is not provisioned (for example on the HLR) for the associated APN, APN associated with preferential access not configured on the device.

In an alternative embodiment if the user (for example user's IMSI or MSISDN) has not been provisioned (for example, but not limited to, in the HLR) to access the appropriate APN (which corresponds to an access means via a private connection to the application's network or a private data network and private IP to the ASP) selected and/or deemed appropriate by the security manager for the MS to access the requested service (for example ASP), then the network based security manager of the invention has means to assign a different APN (which in one embodiment can be the default Internet APN or default ASP APN for example requested by the mobile device or any APN configured for this purpose) which corresponds to an access means via a public data network and public IP to the ASP.

In this embodiment the security manager (residing for example on an SGSN node) identifies via the SGSN node the relevant GGSN node as being a GGSN (in the mobile network) which connects to the Public Data Network, for example the Internet and which routes the data connection to the Internet and connects to the public IP address for the ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service). The public IP address may or may not be in a De-Militarised Zone (DMZ), but using the Public Data Network and a public IP address exposes the ASP to compromise such as security threats or attacks such as for example DoS/DDoS attacks. As already described the security manager of the invention (in this embodiment on the SGSN) may have access to several configured APNs. Thus as already described for example the security manager can determine that an app on a device should preferentially access an ASP over a private IP address which is for example in a list of restricted IP addresses (for example a network service access address control list which the security manager maintains or has access to) and determines the appropriate APN that must be used (instead of for example the default APN for example ISP APN which can be provided in the request from the connecting user), subject to the outcome of the check the security manager performs to establish if the subscriber is provisioned for the APN on the network, which APN is for example associated with an access means via a private connection to the application's network or a private data network and private IP to the ASP. In an alternative embodiment as already described the security manager can determine that an app on a device should preferentially access an ASP via a public data network and public IP to the ASP, and assigns the appropriate APN accordingly. In yet another alternative embodiment, the security manager of the invention may determine that an app on a device should preferentially access an ASP via a public data network and public IP to for example a honeypot (a honeypot refers to a computer system that is set up as a trap to detect and deflect attempts of unauthorised use of a system resource) that is isolated where the device cannot compromise either the preferred private IP address or private data network or even the preferred public IP address and cannot compromise services for users accessible via those IP addresses, and assigns the appropriate APN accordingly. Other non-limiting alternative embodiments are described below.

Security manager of the invention determines that preferential access for ASP is via a private IP address, and subscriber provisioned (for example on the HLR) for the associated APN, APN associated with preferential access configured on the device.

As already described a device can communicate with an ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service) via an app which has an adjunct security software module (which can be bundled or standalone).

In one embodiment a new ASP user wishing to use the service, downloads and installs the app on the mobile device, and the app directs the mobile user to a secure registration method of the invention. As part of secure registration the security manager of the invention (refer to Figure 2) can verify the identity of the mobile device user, by communicating with and leveraging risk management procedures and analysis that the network security service can perform that are detailed elsewhere in the document. The security manager of the invention can be embodied in the network security service of the invention, or the network security service can be embodied in the security manager, or both entities can be separate and exist independently. Both the security manager and the network security service can inter communicate and leverage functionality and means from each other.

As part of the registration process, and upon successful validation of the identity of the mobile device user, the ASP's APN is sent to the Mobile Handset. Thus in this embodiment an APN for the ASP (for example banking service provider/banking application) is configured on the device. The mobile device (for example, but not limited to, MSISDN) is then registered within the invention (or within the mobile network) as a valid for example MSISDN to which a Private Network access method (which corresponds to an access means via a private connection to the application's network or a private data network and private IP address to the ASP) can be used. The application user starts the application on the mobile device and provides the required access details to enter the mobile application (for example a mobile banking application). The mobile application connects to the mobile network and sends the relevant IP address or domain name and APN (in this embodiment associated with an ASP), to request and initiate a data connection to a particular service/domain or IP address to connect for example to an ASP, and the security manager of the invention (in this embodiment on the SGSN) has means to determine and enforce that preferentially this corresponds to an access means via a private connection to the application's network or a private data network and private IP address to the ASP, and that the APN provided in the request from the user is appropriate for the particular service.

Thus in one embodiment the network based security manager of the invention (which in one embodiment can be on an SGSN, or integrated with an SGSN and capable of leveraging functionality and means available to the SGSN) on ascertaining the IP address or for example resolving the target service/domain that the application is trying to connect to (for example via DNS lookup including having access for example to a local DNS entry configured in the mobile operator), thus ascertains the IP address that must be used in order for the application to reach the requested domain name/service, and determines that the application should preferentially access that over for example a local IP address, which is a private IP address. In one embodiment the security manager (on or integrated with the SGSN) maintains or has access to for example a list of restricted IP addresses (for example a network service access address control list) and the private IP address in this embodiment is in that list. In order for the application to access the requested service (for example ASP) over the private IP address the security manager (together with the SGSN) determines the appropriate APN that must be used, and in this embodiment determines that the APN provided in the request from the user is appropriate for the particular service.

However in order for the application to access the requested service (for example ASP) over the private IP address the security manager (on the SGSN) must first establish if the subscriber is configured on the network (for example on a HLR) for the requisite APN and queries the network (for example a network node such as a HLR) to ascertain if the subscriber (for example the subscriber's IMSI or MSISDN) is provisioned to access that particular ASP's APN.

If the subscriber is provisioned for the APN, this APN and corresponding private IP address can be used, and in this embodiment the security manager via the SGSN identifies the relevant GGSN node as being a dedicated GGSN in the mobile network (in alternative embodiments the node can be for example an MME/SGW/PGW for LTE/EPC mobile networks or any suitable node or gateway node), which routes the data connection over the private connection (which can for example be a fixed connection) to the application's network or Private Data Network and connects to the private IP address for the ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service).

The private IP address may or may not be in a De-Militarised Zone (DMZ), but using a private data connection and a private IP address will protect the ASP (for example mobile application server) from security threats or attacks such as for example DoS/DDoS attacks, as the ASP's private IP address is never known or visible outside the mobile network. Thus advantageously any transactions made over this Private network and using the private IP address to access the ASP or ASP's system (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service) will not be exposed to service disruption or compromise due to for example security threats or attacks such as for example DoS/DDoS attacks. Security manager of the invention determines that preferential access for ASP is via a private IP address, and subscriber not provisioned (for example on the HLR) for the associated APN, APN associated with preferential access configured on the device

In an alternative embodiment if the user (for example user's IMSI or MSISDN) has not been provisioned (for example in the HLR) to access the appropriate ASP's APN (which corresponds to an access means via a private connection to the application's network or a private data network and private IP to the ASP), then the network based security manager of the invention has means to assign a different APN (which in one embodiment can be the default Internet APN or default ASP APN or any APN configured for this purpose) which corresponds to an access means via a public data network and public IP to the ASP (for example, but not limited to, a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service).

In this embodiment the security manager (residing for example on, but not limited to, an SGSN node) identifies via the SGSN node the relevant GGSN node (or for example SGW/PGW for LTE/EPC mobile network) as being a GGSN (in the mobile network) which connects to the Public Data Network, for example the Internet and which routes the data connection to the Internet and connects to the public IP address for the ASP (for example a banking application or a Bank's application back-end infrastructure hosting for example a banking application/service). The public IP address may or may not be in a De- Militarised Zone (DMZ), but using the Public Data Network and a public IP address exposes the ASP to compromise such as security threats or attacks such as for example DoS/DDoS attacks. Thus the network based security manager of the invention (in this embodiment on an SGSN) has means to recognize that a request from an application to a particular service (e.g. domain name) or IP address for a data connection is using an appropriate APN, and has means to dynamically modify the APN and means to assign and modify the access means for the service as appropriate. In an alternative embodiment advantageously a subscriber (who is registered via the invention for one particular device, and can access the ASP via a Private Network access method, which corresponds to an access means via a private connection to the application's network or a private data network and private IP address to the ASP) when attempting to access the ASP from a different mobile device which is not registered with the invention, is presented with access means via a public data network and public IP to the ASP.

In an alternative embodiment the invention may optionally use a bandwidth choke to control the maximum levels of traffic that will be accepted from each legitimate mobile device that has connected to the ASP's APN (which corresponds to an access means via a private connection to the application's network or a private data network and private IP to the ASP).

Although the security manager is described in some of the invention's embodiments as being on an SGSN, it can equally reside on a GGSN or on both the SGSN and GGSN, or reside on a separate node and be in communication with an SGSN or other suitable node, or reside on any suitable network element or combination of elements. The security manager can perform many and varied functions.

Although the embodiments are described with reference to network nodes being involved such as SGSNs and Gateway GPRS Support Nodes (GGSN), the invention works equally with alternative nodes such as a PDN Gateway (PGW) depending on the mobile network technology used.

The radio access elements are not depicted in detail in Figure 2. Depending on the mobile network technology the radio access elements could be BTS (GPRS) and BSC (GPRS), NodeB (UMTS), or enodeB (LTE) or any other appropriate radio access elements. Only some mobile network elements are depicted in Figure 2, and although the embodiments are described with reference to network nodes being involved such as SGSNs and Gateway GPRS Support Nodes (GGSN), the invention works equally with alternative nodes such as a PDN Gateway (PGW) depending on the mobile network technology used, with other core mobile network elements being applicable for example MME (LTE), SGW (LTE), PGW (LTE) or any other appropriate elements.

In the case of a private connection, private data network and private IP address, the invention is not limited in terms of the placement and routing within the Private network, so for example the ASP can be located in a DMZ or directly within the ASP's (for example Banking service provider's) network. In an alternative embodiment the network based security manager of the invention can be based on risk score associated with a particular device,

or traffic profile for a particular app associated with a particular device, for example an application session such as a banking application session is likely to have certain interactions being performed on the session, if there are marked deviations from those such as for example abnormal traffic such as a picture being uploaded to a banking app, or if data volume is markedly higher than expected leading to suspicion for example of malware presence on the device such as for example the device being part of a botnet based DDOS attack on an ASP, or be based on other characteristics,

assign the device an APN which may be associated with (via for example DNS) an access means via a public data network and public IP to for example a honeypot system that is isolated where the device cannot compromise either the preferred private IP address or private data network or even the preferred public IP address and cannot compromise services for users accessible via those IP addresses. The device may be able to access ASPs via this means but the quality of service is by no means guaranteed.

The invention is not limited to but is applicable to and can be integrated with many and various network technologies including (without limitation) 2G, 3G, 4G/LTE network, 5G and future network incarnations. For example the APN received from the mobile application can be used within the mobile network to route the data connection over for example a fixed connection from for example a dedicated GGSN node or a PDN Gateway (PGW) node within the mobile network to a Private Data Network for example hosting a website or service.

It is noteworthy that the invention is performing intelligent traffic management only permitting traffic from the device on a particular network or connection between the device and the ASP (as well as permitting any interactions required with the network security service). Thus as already described in one embodiment a network security manager according to the invention may operate and communicate with one or more devices and an Application Service Provider and communicate or reside on one or more network elements, and has means to route a data connection from an application on an endpoint device over a private connection to the application's network or Private Data Network and connects to a private IP for the ASP, or in an alternative embodiment has means to route the data connection from an application on an endpoint device to the Public Data Network, for example the Internet and connect to the public IP for the ASP. And in yet another alternative embodiment, the network security manager of the invention may have means to route a data connection from an application on an endpoint device via a public data network and public IP to for example a honey pot that is isolated where the device cannot compromise either the preferred private IP address or private data network or even the preferred public IP address of an ASP and cannot compromise services for users accessible via those IP addresses

Figure 3 illustrates a Risk Management for Mobile (RMM) module 10 including some components, according to one embodiment of the invention. The components include a UID generation component 11, a risk scoring and behavioural analysis component 12, a historical non repudiation transactional analysis component 13, and a forensic analysis component 14. The components have access to data stored in persistent stores.

User ID (UID) generation

User ID (UID) generation is performed based on an Identifier such as, but not limited to, a MSISDN if this is the first time the network security service of the invention (in one embodiment as illustrated an RMM) has been presented with the Identifier (for example MSISDN), and the UID is persisted in the UID persistent store. Alternatively if the MSISDN has been presented to the RMM previously the associated UID can be retrieved from the UID persistent store. The primary purpose of anonymizing the MSISDN and translating it into a UID is for data protection. Thus in the case where the network security service of the invention (the RMM in this embodiment) is not permitted to share the identifier (for example MSISDN), or the ASP is not permitted to have access to the identifier (for example MSISDN) a consistent UID (which represents the identifier) can be presented to the ASP, which can be used for example for the ASP's correlation purposes. Risk Scoring and Behavioural Analysis As already described the network security service (in one embodiment a Risk Management module) performs risk management procedures. This can include such procedures as location analysis by the RMM (via a location based check such as querying a HLR for the latest serving MSC for a mobile device) which might indicate that the user device is in a geographical location that is more associated with fraud than other locations, or in a less secure environment for example for a banking application that the user is outside the EU, in a non-chip and PIN area/environment. The outcome of such location analysis can be reflected by the RMM in the risk score and reason code(s).

Other risk management procedures and analysis that the network security service can perform include SIM takeover analysis. The Subscriber Identification Module (SIM) card inserted into the mobile phone is uniquely associated with the IMSI. In this instance the network security service can query the HLR for the latest IMSI. The RMM can then perform SIM takeover/SIM swap attack analysis, and if such analysis indicates a high probability of SIM swap/takeover having occurred this can be reflected in the risk score and a reason code.

Other risk management procedures and analysis that the network security service can perform include for example checking multi-party call status and call divert unconditional status.

In one embodiment the reason code encodes the characteristic that influences the risk score most, allowing the RMM to indicate that this is the dominant cause of the risk score associated for example with the subscriber. Where a reason code encodes a single characteristic there can be one reason code, or alternatively multiple reason codes, for example where each reason code encodes a different characteristic that is contributing to the risk score. In an alternative embodiment a reason code can encode multiple characteristics, reflecting the one or more characteristics that influence the risk score most, allowing the RMM to indicate the one or more characteristics which are the dominant cause(s) of the risk score associated for example with the subscriber. Thus the reason code can be an aggregate code to indicate a combination of factors including dominant factors that have contributed to the risk score. Also in this embodiment there can be multiple reason codes each encoding multiple characteristics. Other useful identifiers for a mobile subscriber device that can be returned from a HLR include the IMEI. On completion of the risk management procedures the Risk Management module outputs metadata to the requisite Application Service Provider, which can include such metadata as UID, risk score, reason code etc. The information used for the risk management procedures such as location information (e.g. serving MSC for a mobile device), identity information such as IMSI, IMEI, MSISDN, multi-party call status, call divert unconditional status, etc. can all be persisted in the Risk Scoring and Behavioural Analysis persistent store. In addition all outputs from the risk management procedures can also be persisted in the Risk Scoring and Behavioural Analysis persistent store, e.g. SIM swap status, UID, risk score, reason code etc. for each device that is analysed, and can be used for behavioural analysis.

As a user device accesses services, which lead to the network security service performing risk management of the endpoint device including risk management associated with the identity of the endpoint device, information including profile information on the device is built up, stored and archived in the Risk Scoring and Behavioural Analysis persistent store and/or other stores of the invention as appropriate, and can be used for behavioural analysis. The network security service can perform behavioural analytics on such previous behavioural information as well as current behavioural information for the user device such as service access requests and usage. If behavioural information is detected deviating strongly from historical behavioural patterns then this can influence the risk profile and the risk score for the user device which the network security service generates. In the case of an embodiment where a user on a device such as for example a mobile device wishes to access a mobile banking service by being tethered to another mobile device which is acting as a mobile WiFi hotspot, after successfully connecting to the mobile WiFi hotspot device, the mobile device user then attempts to access an ASP such as a mobile banking service provider. In this instance the mobile risk management system of the invention (in one embodiment an RMM) receives an identifier such as a MSISDN for each of the trusted mobile devices and can perform risk management on both of those devices, resulting in a superior augmented risk analysis. Further a combined risk analysis can be performed on the two devices in tandem, enhancing the behavioural and other analyses performed. The results of the combined risk analysis for both devices in tandem and/or the individual risk analysis for each device, can be presented to the ASP (in this embodiment a mobile banking service). The ASP has thus enhanced risk analysis information on which it can make an informed decision as to for example what level of service access to allow the user. Further the results of the combined risk analysis for both devices in tandem and/or the individual risk analysis for each device, can be persisted (and complement historical behavioural information, including historical behavioural access information) in the Risk Scoring and Behavioural Analysis persistent store and/or other stores of the invention as appropriate, and can be used to build a risk profile for the individual devices or the devices in tandem, all of which can form identity and location, or for example behavioural information, so if a user normally accesses the service from their device tethered to another mobile device then that is part of the risk profile, and historical behaviour, and if that behaviour changes it can be reflected in the risk profile and risk score.

Historical non repudiation transactional information

Historical non repudiation transactional information concerns information that reinforces that a particular party has carried out a particular transaction. For example a user has a gambling app on their device (for example mobile phone), for example a PaddyPower gambling app. The user has a bad run of luck and runs up a large debt, and rather than pay their debt, decide to pretend to the ASP (in this instance the gambling service provider) that their device was stolen and that it was not they who gambled and ran up the debt. The historical non repudiation transactional persistent store (for example database) can maintain all records as regards transactions from the app, for example gambling app, including for example the device location, the device and subscriber identifiers (IMSI, MSISDN etc.) for each transaction, the date of the transaction, the amount of the transaction, the date of last transaction, the date of last payment, session ID (between app and ASP), ASP ID identifying the application service provider, risk settings to indicate if device was compromised during the gambling period, such as SIM swap status, multi-party call status, call divert unconditional status, etc. Such information can act as independent third party information (with the independent third party being the mobile network operator(s) which has the invention integrated), and can be used and required for non-repudiation of transactions for example for dispute resolution, court proceedings etc. Thus for example the ASP could prove that the customer is still using the same SIM card that they were using when they were gambling and refute an assertion that they have changed their SIM card as a result of their device being stolen, they could provide the locations a person was at when they were gambling with their gambling app, the date they were still gambling, phone number (e.g. MSISDN), metrics to indicate the device was not compromised etc.

Non repudiation of transactions is important for contracting with a key part of contracting being identity and non-refutation of identity. The historical non repudiation transactional information persistent store of the invention as described maintains trusted records of the parties involved in the transactions and provides risk management associated with identity of the parties including particularly endpoint devices. This is important for money transfer, the party who is transferring the money and the party to whom the money is being transferred effectively form a contract. For a contract both sides have to accept but also identity is a key cornerstone of a contract, with both sides having to trust that the other party is whom they purport to be, and are authorized to be a party to the contract. The invention can perform identity risk management, validating the parties before a transaction happens and persist the associated metrics as trusted records advantageously for both parties. Thus Historical non repudiation transactional information can play an important role in financial services such as payments, money transfer transactions, gambling services, etc. with the operator acting as a trusted custodian able to persist the associated metrics and produce those on request by authorized parties.

Forensic Analysis

A key aspect of forensic analysis is that it can be analytics based, discerning patterns in large data sets. Thus forensic analysis could for example perform analytics on all available transactions for all customers in for example a particular network, or all networks in a nation or federal state, or region (for example EU) etc.

Forensic analysis could for example discern suspicious behavioural patterns associated with one or more fraudsters either working alone or co-ordinated. This can be a key difference in some embodiments vis-a- vis historical non repudiation transactional information analysis which tends to focus on historical transactions for particular parties on for example particular accounts, or particular interactions between parties and ASPs. Although certainly historical non repudiation transactional information can be part of forensic analysis and they can complement each other, and in some embodiments may be co-located and indistinguishable.

Risk scoring and behavioural analysis can also be different in some embodiments from forensic analysis in that it is in the main computing risk score based on factors for a particular context or transaction as described, although it can of course employ historical analysis as input to computing a risk score. Forensic analysis and historical non repudiation transactional information analysis can also complement and make use of risk scoring and behavioural analysis including results such as for example risk scores therefrom.

Thus forensic analysis could for example be considering all customers in the network for which it has data and could discern a pattern such as a particular mobile number has been used in particular suspicious scenarios, for example in several payments. Forensic analysis could discern an IMEI associated with those payments, associated with a particular mobile number (MSISDN) which could be a fraudster's device or a compromised device. The same IMEI might appear in the context of other transactions associated with a different mobile number (MSISDN) which can be used to build up the forensic profile of the end-point device.

In the context of money transfer forensic analysis can be monitoring suspicious activity on a particular subscriber's account. For example an amount of€5000 euro is transferred out of several bank accounts belonging to a subscriber and sent to various different accounts for example to an account in a bank in London, to another account in a different bank in New York, to an account in a different bank in Hong Kong and the transfer requests came from the subscriber's purported device. Forensic analysis can detect and provide forensic reports on such activity which could for example indicate a potentially compromised device, or for example potential Anti Money Laundering (AML) activity, or other suspicious activity.

Thus in response to a request from law enforcement for forensic data on a particular party, an operator (who has integrated the invention) has in one embodiment one or more forensic nodes that can be queried for forensic analysis, for prosecution of a party for fraud or other potential transgression, etc.

In one embodiment the forensic analysis persistent store and the historical non repudiation transactional information persistent store can be combined and co-located in the same persistent store (for example database). In an alternative embodiment the forensic analysis persistent store, the historical non repudiation transactional information persistent store, and the risk scoring and behavioural analysis store can be combined and co-located in the same persistent store (for example database). Where not combined there can be much intercommunication, sharing of information and overlap between these components.

In some embodiments all the modules of the network security service may be co-located and/or indistinguishable

Location information As regards location information the network security service according to the invention can communicate with network elements to obtain location information such as a HLR or HSS, MSC, or a Gateway Mobile Location Centre (GMLC), or a Mobile Positioning Server (MPS). For many use cases of the invention the Cell-ID of the Base Transceiver Station (BTS) with which the device communicated is an appropriate location identifier, and this can be persisted per transaction, or in a lookup table etc. For example Cell-ID can be appropriate for forensic analysis. The location information can be persisted in any or all of the persistent stores including forensic analysis persistent store, the historical non repudiation transactional information persistent store, and the risk scoring and behavioural analysis store, or stored elsewhere.

Further as regards location of a device the invention can ascertain and detect if a subscriber device is on- net or off-net and apply separate risk analysis and scores to on-net or off-net subscriber devices and can indicate in the risk score whether a subscriber device is on-net or off-net and how that has influenced the score, with for example an off -net subscriber potentially having a higher associated risk reflecting that the home operator has less control and visibility of the off-net subscriber. Thus for example an inbound on- net phone call on a Vodafone network from a Vodafone customer can be treated differently than when the customer originates an off-net call from another network. Thus an ASP can make a decision on what level of service to offer off-net subscribers versus on-net subscribers, or if they need to apply more knowledge factor etc.

Integrating the system of the invention with existing ASP systems

As illustrated in Fig. 3 advantageously the system of the invention can be integrated with and provide input into an existing system of an application service provider such as a banking service provider (e.g. bank). In one embodiment an existing banking service provider's back end system has a risk management system for credit card transactions. The risk management system produces an output, but is not limited to, a risk score, between 0-1000 for a particular credit card number, which is passed onto another system which performs further analysis and then output can be provided to the ASP Customer Care team, in this embodiment a banking service provider Customer Care team. Banks have invested heavily in credit card systems in this context. However for money transfers between parties, traditionally banking service providers have been relying on having quite an amount of time, for example up to three working days to do the transfer between one account and another, in which they can perform their checking procedures and even that poses problems and risks such as financial fraud exposure to the banks. These issues are now being further exasperated by the advent of the Single Euro Payments Area (SEP A) payment integration initiative, where banks are being mandated to support Europe wide faster and more efficient fund transfers between parties in SEPA member states. Thus there are urgent requirements for a technically efficient and expeditious risk management solution for banking fund transfers (including cross border transfers) including for combating Anti Money Laundering (AML), and as already described the system of the invention provides the technical solution to such issues, by including such features as secure two-factor authentication or multi-factor authentication for secure identity and secure risk management of identity, including identity of endpoint devices in a communications network. As already mentioned advantageously in one embodiment the output of the system of the invention can be integrated with and provide input into an existing system of an application service provider such as a banking service provider (e.g. bank). Thus the application service provider, the banking service provider in this instance, can continue to make use of their current infrastructure, can continue to use their own platform (which the invention can integrate with, and provide information to, in the standard format the banking platform requires), and continue with their tried and trusted processes, and continue using customer care staff, etc., but the system is greatly enriched with output information from the network security service of the invention, pertaining to one or more mobile networks, for example such as risk scores for mobile end-point devices.

Prepaid credit cards whose identity can be compromised, present serious security risks including fraud risk issues for current banking systems as they are a money instrument which can carry significant funds and can be readily transferred across borders (versus bank transfers which spend relatively long periods being transferred in the banking eco system and transgressions may be caught there). Mobile money transfers present many of the same threats traditionally associated with prepaid credit cards, to the banking ecosystem. The invention by providing strong secure risk management including identity risk management, addresses the identity issues associated with mobile money transfers. Figure 4 illustrates a network environment in which a network security service according to the invention may operate and communicates with one or more devices and an Application Service Provider and one or more network elements and provides risk management for mobile broadband communications. In this embodiment a device tethered to another device acting as a mobile WiFi hotspot is illustrated. In an alternative embodiment the device could be connected to another device via a fixed connection or by other means.

In one embodiment as illustrated in Figure 4, a user activates his mobile phone as a mobile WiFi access point (by for example turning on his WiFi hotspot on the phone). In one embodiment the user connects his laptop to the mobile phone WiFi hotspot for mobile Internet access via the MNO's network.

In one embodiment the user is an employee attempting externally to access an ASP which hosts or allows access to the employee's corporate intranet.

The user opens his browser and attempts to browse to the pertinent website (which hosts or allows access to the corporate intranet), and the associated HTTP request is routed out over the particular mobile network operators mobile broadband network and is routed as illustrated in Figure 4, to a HTTP Proxy.

The radio access elements are not depicted in detail in Figure 4. Depending on the mobile network technology the radio access elements could be BTS (GPRS) and BSC (GPRS), NodeB (UMTS), or enodeB (LTE) or any other appropriate radio access elements. Only some mobile network elements are depicted in Figure 4, namely the SGSN and GGSN. Depending on the mobile network technology other core mobile network elements are applicable for example MME (LTE/EPC), SGW (LTE/EPC), PGW (LTE/EPC) or any other appropriate elements. The HTTP proxy is configured to route the HTTP request to the network security service of the invention, but before routing, the HTTP proxy initiates a Radius request for the originating IP address of the HTTP request to a Radius Server, to obtain the user's mobile number, and the associated MSISDN if available is returned. The HTTP header of the initial HTTP request (which is unencrypted) is populated with the MSISDN and the HTTP proxy routes the HTTP request to the network security service of the invention. The network security service of the invention, in this embodiment a risk management for mobile (RMM) module performs UID (User ID) generation based on the device identifier, for example MSISDN, if this is the first time the RMM module has been presented with the MSISDN and the UID is persisted in the UID persistent store (refer to Figure 3). Alternatively if the device identifier, for example MSISDN has been presented to the RMM previously the associated UID is retrieved from the UID persistent store. The primary purpose of anonymizing the MSISDN and translating it into a UID is for data protection. Thus in the case where the network security service of the invention (the RMM in this embodiment) is not permitted to share the identifier (for example MSISDN), or the ASP is not permitted to have access to the identifier (for example MSISDN) a consistent UID (which represents the identifier) can be presented to the ASP, which can be used for example for the ASP's correlation purposes. The network security service in this embodiment an RMM performs risk analysis and on completion outputs metadata which can include for example such metadata as a reason code, along with a risk score and a UID.

In one embodiment the reason code encodes the characteristic that influences the risk score most, allowing the RMM to indicate that this is the dominant cause of the risk score associated for example with the subscriber. Where a reason code encodes a single characteristic there can be one reason code, or alternatively multiple reason codes, for example where each reason code encodes a different characteristic that is contributing to the risk score. In an alternative embodiment a reason code can encode multiple characteristics, reflecting the one or more characteristics that influence the risk score most, allowing the RMM to indicate the one or more characteristics which are the dominant cause(s) of the risk score associated for example with the subscriber. Thus the reason code can be an aggregate code to indicate a combination of factors including dominant factors that have contributed to the risk score. Also, in this embodiment there can be multiple reason codes each encoding multiple characteristics. In an alternative embodiment the reason code could be an aggregate code to indicate a combination of dominant factors that have contributed to the risk score.

Examples of reason codes could be suspicious location because for example location analysis by the RMM revealed that the user is in a geographical location that is more associated with fraud than other locations. A variation on suspicious location could be a reason code appropriate for a banking application reserved for indicating that the user is outside the EU, in a non-chip and PIN area/environment. Another reason code could indicate that SIM takeover analysis by the RMM, has indicated a high probability of SIM swap/takeover having occurred. Other risk analysis by the RMM could indicate that such features as call divert unconditional is active on a call and/or if a multi-party call is active at the time of a phone call, which can be reflected in reason codes.

Reason codes can be configured to be appropriate for the analysis performed.

An RMM or its equivalent need not be provided by the invention but could be from another party.

The metadata in one embodiment is returned to the HTTP Proxy populated in the HTTP header of the HTTP Request, for onward routing to the Application Service Provider. In an alternative embodiment the metadata is sent directly to the ASP from the RMM to for example a separate security IP address. The direct connection between the ASP and the RMM could for example be over HTTPS or a VPN connection, or a dedicated link such as a point to point link, or by other means. In the case where the metadata is being sent via the HTTP Proxy to the ASP, that connection could be over HTTPS or a VPN connection, or a dedicated link such as a point to point link, or by other means. In the case where the connection to the ASP is point to point this would advantageously provide protection from security threats or attacks such as for example DDOS protection as the IP address would be private and only ASP specific traffic would be allowed on the point to point connection. Thus by employing direct, and/or secure and/or encrypted connections, the invention enables prevention of security threats such as man in the middle attacks. As well as the factors already described which contribute to risk score, it is worth stating that additional factors which have also already been described, also can be employed by the RMM to contribute to risk score. Thus for example the RMM can ascertain if DDOS protection is active and use that to influence risk score, The RMM can also check if device isolation is active during a particular session, for example if a user is connecting from their phone to an ASP such as a banking service provider (e.g. bank) choosing "maximum security" which results in device isolation being active during the session then that can be used by the RMM to contribute to the risk scoring.

Other factors that the RMM of the invention can employ to contribute to risk score and in building up a profile of the user over time, include biometric features.

Thus for example voice biometrics (i.e. voice recognition/authentication) could be employed either directly integrated with the invention, or the result of voice recognition analysis in the network (for example biometric IVR such as IVR voice authentication in the network) can be provided as an input to the RMM which can then be used to influence the risk score as a contributor in combination with all the other risk factors that the RMM has available. Any suitable bio-metric factors can be employed including for example fingerprinting (if the device had a fingerprint reader), or facial recognition (for example the security agent on the device could take a photograph of the user), or iris scan, with such features, or the results of analysis of such features being provided as input to the security agent of the invention on the device, and/or to network elements (which can perform biometric analysis), and/or to the RMM which can then be used to influence the risk score.

Advantageously the RMM is not relying solely on a relatively new technology such as biometrics in order to compute the risk score, but rather biometric features can be used in conjunction with other factors available to the RMM of the invention, including those centring around identity such as those already described, including those that associate a user with a particular device (e.g. mobile phone in a mobile network), for example features that establish with high likelihood that a particular user is making a call from a particular device. Advantageously the level of access to the application or service (in this example access to a website which hosts or allows access to the corporate intranet) given to the user, on successful login, by the ASP can be based on the result of the risk analysis by the mobile risk management of the invention (in one embodiment an RMM) as reflected in the metadata presented to the ASP (the corporate intranet in this embodiment), with for example no access at all, or partial access, or full access to the corporate intranet being granted to the employee.

Thus the possession factor element ("something only the user has") in this instance the trusted device, of the two-factor authentication has been fulfilled by the risk analysis performed by the mobile risk management of the invention (in one embodiment refer to Risk Management for Mobile (RMM) in Figure 4) on the trusted device. The knowledge factor ("something only the user knows") element of the two- factor authentication is fulfilled by the user providing login credentials such as user name and password on attempting to login to the corporate intranet. Thus the invention has achieved secure two-factor authentication and overcome the limitations associated with using a single trusted device for both two- factor authentication and accessing the service.

An ASP could also for example be a Mobile service provider such as mobile banking service provider. Mobile banking service providers do allow for example basic banking tasks to be performed which include such operations as money transfer to existing beneficiaries, without requiring the highest level of security. However for more sensitive tasks such as adding new beneficiaries, change of address, registering for e-statements etc., they do need to be as sure as possible that such tasks are not being carried out by a fraudster. Such differentiation of level of service can be based on the result of the risk analysis of the trusted device by the RMM as reflected in the metadata presented to the banking service in this example.

In an alternative embodiment the ASP could provide feedback (not shown in diagrams) to the mobile risk management system of the invention (in one embodiment an RMM) as regards handling of particular subscribers by the ASP and such feedback could be persisted in a persistent store such as a historical behavioural database or in an alternative store, and form part of future analysis, including for example behavioural analysis. Such feedback could be in real or near real-time, be asynchronous or be based on batch mode (for a batch of subscribers) or consist of alternative means. The feedback could consist of metrics and/or other information.

In an alternative embodiment (depicted in Figure 5) a mobile device tethered to another mobile device which is acting as a mobile WiFi hotspot is considered. Thus for example an employee has a large mobile broadband allowance associated with his corporate phone and allows other family members to connect to the Internet via his phone acting as a mobile phone WiFi hotspot. The user activates his mobile phone as a mobile WiFi access point (by for example turning on his WiFi hotspot on the phone). A family member then connects to the mobile WiFi hotspot and then attempts to access a mobile banking service. In this instance the mobile risk management system of the invention (in one embodiment a RMM) receives a MSISDN for each of the trusted mobile devices and can perform risk management on both of those devices, resulting in a superior augmented risk analysis. The embodiment presented here from the identity perspective can be considered to be a combination of the embodiments presented in Figure 1 and Figure 4. Refer to the description for Figure 1 for further detail on how the user device identifier (in this embodiment the MSISDN) is made available through a short code routed SMS to the network security service of the invention. Refer to the description for Figure 4 for further detail on how the user device identifier (in this embodiment the MSISDN) is made available and provided through the HTTP Proxy.

Further a combined risk analysis can be performed on the two devices in tandem, enhancing the behavioural and other analyses performed. The results of the combined risk analysis for both devices in tandem and/or the individual risk analysis for each device, can be presented to the ASP (in this embodiment a mobile banking service). The ASP has thus enhanced risk analysis information on which it can make an informed decision as to what level of service access to allow the user (in this case the family member).

The radio access elements are not depicted in detail in Figure 5. Depending on the mobile network technology the radio access elements could be NodeB (UMTS), or enodeB (LTE) or any other appropriate radio access elements. Only some mobile network elements are depicted in Figure 5, namely the SGSN and GGSN, and the MSC and SMSC. Depending on the mobile network technology other core mobile network elements are applicable for example MME (LTE/EPC), SGW (LTE/EPC), PGW (LTE/EPC) or any other appropriate elements.

As already mentioned the scope of the invention also includes verifying and providing secure identity and risk management including risk management associated with identity, for inbound and outbound calls (including multi-party calls) to/from a service provider. The following embodiments illustrated in Figures 6-13 describe those aspects of the invention in more detail.

Figure 6 illustrates how a network security service according to the invention, in one embodiment a mobile risk management system of the invention (which in this specification is interchangeably referred to as a Risk Management for Mobile (RMM) module), can be applied to outbound calls from an ASP such as for example a banking service contact centre to a customer (for example on their mobile phone).

In one embodiment as illustrated in Figure 6, when a member of a Customer Care team in an Application Service Provider (ASP) such as a banking service contact centre initiates a call to a customer, all such outbound calls are automatically routed via (or metadata from such calls is provided to) a network security service. In an alternative embodiment a member of a customer care team, in order to initiate a secure call, first dials a code or a prefix such as for example 123, which would then result in this particular outbound call being routed via (or metadata from such calls being provided to) a network security service.

Effectively a three way call is established by a network system in the telecommunications network, with the ASP being the A party, the customer being the B party and the network security service according to the invention being the C party.

In one embodiment the network system could be an IN (Intelligent Network) service within the telecommunications network, which can detect a call from a particular A party (for example ASP) to a B party (for example customer) and on such detection set up a call (effectively an IN call) to a C party (for example network security service of the invention). The IN service in one embodiment could be a Camel (Customised Applications for Mobile networks Enhanced Logic) based service.

The network security service according to the invention, in one embodiment a mobile risk management system of the invention (which need not be but can be termed a Risk Management for Mobile (RMM) module) performs risk analysis on the number to whom the call is destined, the B party, as the banking service contact centre customer care want to be as sure as is possible that the party they are calling are whom their records purport them to be.

The risk analysis performed by the mobile risk management system of the invention can take many forms including for example, SIM takeover protection where analysis is performed to ascertain if the B party SIM has changed in the previous configurable time period, for example in the last 24-48 hours. Such configurable time periods can be agreed with the ASP.

Additionally the network security service can check if call divert unconditional is active on the call. In that situation a fraudster has succeeded in diverting calls for a subscriber or user' s device such as a mobile phone, to the fraudster's device. Thus any outbound calls destined for the user's device are diverted to the fraudster's device. The call divert unconditional feature can be configured for example in a network element such as a HLR.

The network security service of the invention can perform a further check such as ascertaining for example if multi-party phone call is active on this connection. One or several fraudsters in tandem can use this feature very effectively. For example the fraudster performs some action to trigger an ASP such as a call centre to ring a customer and the fraudster is joined into the call which is then a multi-party call. The fraudster could for example eavesdrop on the authentication of the identity information, that is the knowledge factor and then cause the customer to be dropped off the call once the knowledge factor is complete, and take over the call for example for fraudulent purposes, or use the identity information garnered at a future stage etc. Further description on multi-party call is provided later in the specification, refer to Figure 12 and related description. So by checking if multi -party call is active the network security service can prevent issues such as security risks and fraud associated with multi-party call active, and ensure that it is much more likely the phone call is made to the correct intended party.

A further check is to ascertain the location of the device which also influences the risk score. All of these are examples of some of the actions or features or facets that can be used by fraudsters to compromise a phone call, and the network security service of the invention by detecting these and other features mitigates against the risk of call compromise. As part of the risk analysis the network security service can use some or all of the features outlined and other features to determine a risk score. In one embodiment if the risk score for the device identifier is over a certain configurable threshold (which can be agreed with the ASP) then the network security service can cause a message to be played out to the contact centre agent, which only the contact centre agent can hear indicating for example something along the lines of "warning further authentication needed".

If alternatively the risk score for the device identifier is less than a certain configurable threshold then in that case the network security service can cause a message to be played out to the contact centre agent indicating for example something along the lines of "call secured" or "customer identified". Such outputs make the security service very accessible for a contact centre agent, alerting them in an easy to understand format the risk status of calls with particular parties. The contact centre agent can then perform the appropriate action based on the message, for example requesting very detailed or less detailed knowledge factor from the customer as appropriate, or even terminating the call. The benefit of less detailed knowledge factor being required is that the contact centre agent spends less time on the call (i.e. they don't have to spend as much time on the questions and answers with the customer), and thus can handle more calls, with attendant significant cost savings, with security being actually enhanced by the invention, and the agent having more confidence that they are talking to the correct person. Advantageously this benefit applies to both inbound and outbound calls.

Thus the invention augments the current knowledge factor that an ASP such as a call centre uses with customers when performing outbound calls to them (for example going through questions that only the B- Party should know the answers to) by including a possession factor ("something only the user has"), in this instance the trusted device or more particularly a risk score or verification profile that the invention calculates for the trusted device. Thus the invention provides identity authentication and is enabling the ASP (which in this embodiment is a banking service contact centre) to know when they make an outbound call the degree of likelihood that they are communicating with the actual trusted device (for example the phone that is registered against the customer account). Thus the invention enables two-factor authentication for outbound calls for an ASP.

In an alternative embodiment as illustrated in Figure 7, the network security service receives metadata from the network on the A and B parties (in one embodiment for example the A party (ASP) number and the B party (customer) number (for example MSISDN)). In one embodiment the network system in the telecommunications network could be, but not limited to, an IN (Intelligent Network) service within the telecommunications network, which in one embodiment could be a Camel based service. The meta information could be generated from the IN service, for example the Camel service or from a network element such as a switch or by an intelligent platform or service deployed to provide such meta information to the network security service or by other means, on detection of any outbound call from a particular A party (for example an ASP) or on detection of an outbound call from a particular A party (for example ASP) to a B party (for example customer).

On completion of the risk analysis the network security service can output metadata which includes a message indicator which indicates to a network system in the telecommunications network which message to play to the ASP, for example message X or message Y. The network system in the telecommunications network, then depending on the message indicator received is triggered to play out the appropriate message to the ASP (which in this embodiment is a banking service contact centre), for example if indicator X is received (as illustrated in Figure 7), it plays out the message configured for indicator X, for example a message such as "customer identified" or if message indicator Y is received it plays out the message configured for indicator Y for example a message such as "warning further authentication needed". Normally this X or Y message indicator is sufficient but optionally further metadata such as for example the B party number (for example MSISDN or UID) and the A party number (ASP number) or whatever other available meta information could also be included as part of the response from the network security service to the network system if required.

The alternative embodiment achieves the same end result, namely enabling the ASP to know when they make an outbound call the degree of likelihood that they are communicating with the actual trusted device (for example the phone that is registered against the customer account). In an alternative embodiment as illustrated in Figure 7a, the network security service receives metadata from an IMS network on the A and B parties (in one embodiment for example the A party (ASP) number or ASP ID, and the B party (customer) number (for example MSISDN or UID)). In one embodiment the network system in the telecommunications network could be an IN (Intelligent Network) service within the telecommunications network, which in one embodiment could be a Camel based service. The meta information could be generated in the IMS network by a Session Initiation Protocol (SIP) enabled network element or service deployed to provide such meta information to the IMS/SIP enabled network security service of the invention, as SIP headers in a SIP Request over SIP signalling or by other means, on detection for example of any outbound call from an A party (for example a particular ASP) or on detection of a call for example from a particular A party (for example a particular ASP) to a B party (for example customer).

The network security service (in this embodiment an IP Multimedia Subsystem (IMS)/SIP enabled service) according to the invention, in one embodiment a mobile risk management system of the invention (which need not be but can be termed a Risk Management for Mobile (RMM) module) performs risk analysis on the number to whom the call is destined, the B party (for example a user on a device such as for example a customer), as the ASP (for example banking service contact centre customer care) want to be as sure as is possible that the party they are calling are whom their records purport them to be.

On completion of the risk analysis the network security service outputs metadata which can include information such as B-Party UID or MSISDN, A-Party ASP ID or number, Risk Score, Reason code(s), etc., via SIP signalling in SIP response headers, which are passed through via the IMS network to an ASP.

Thus advantageously, in the context of the network security service of the invention (for example as in this embodiment an IMS/SIP enabled service) communicating with an ASP via an IMS network, identifiers such as A party identifiers (such as in the case for example of an ASP, an ASP ID or number) and B party identifiers (such as in the case for example of a customer, a UID or MSISDN) as well as other pertinent metadata can be passed in SIP responses and/or SIP requests according as the information is available, for example passed in SIP headers (such as for example in SIP response headers and/or in SIP request headers as available). The level of service to the user can be based on the result of the risk analysis of the trusted device by the RMM as reflected in the metadata presented to the ASP (for example banking service).

The IP-PBX can as illustrated in Figure 7a be located and/or integrated with the ASP, or in an alternative embodiment located in the IMS network.

The alternative embodiment achieves the same end result, namely enabling the ASP to know when they originate an outbound call the degree of likelihood that they are communicating with the actual trusted device (for example the phone that is registered against the customer account). In an alternative embodiment as illustrated in Figure 8, the network security service is part of or integrated with an intelligent telephony service within a telecommunications network. In this embodiment all outbound calls are routed through the intelligent telephony service, and thus the call flow is available to the network security service of the invention. Thus any outbound phone calls from the ASP, are automatically routed to the network security service, in one embodiment a mobile risk management system of the invention (which in this specification is interchangeably referred to as a Risk Management for Mobile (RMM) module). Thus in one embodiment the network security service of the invention can handle the rest of the call setup to the B party. In an alternative embodiment the network security service could be integrated with another module which performs call handling and call setup to the B party as described below.

The network security service performs risk analysis on the number to whom the call is destined, the B party, as the banking service contact centre customer care want to be as sure as is possible that the party they are calling are whom their records purport them to be.

In one embodiment if the risk score for the device identifier is over a certain configurable threshold (which can be agreed with the ASP) then the network security service can cause a message to be played out to the contact centre agent, which only the contact centre agent can hear indicating for example something along the lines of "warning further authentication needed".

If alternatively the risk score for the device identifier is less than a certain configurable threshold then in that case the network security service can cause a message to be played out to the contact centre agent indicating for example something along the lines of "call secured" or "customer identified".

In one embodiment the Intelligent Telephony service could include an IVR system with which the network security service integrates as part of the Intelligent Telephony service, and performs its intelligence including mobile risk management. The IVR system could be an existing system in the telecommunications operator' s network with which the network security service can integrate, or an IVR platform included in and deployed as part of the Intelligent Telephony service along with the network security service. Advantageously the Intelligent Telephony service provides a complete solution for a mobile risk management value add service for inbound and outbound calls for ASPs (refer also for example to Figure 11). The Intelligent Telephony service can have for example a web based GUI or TUI for configuration.

In an alternative embodiment the intelligent telephony service could be hosted on an ASP platform. The network security service can be integrated as part of the Intelligent Telephony Service, or the network security service can be stand alone, for example a cloud based service communicating with the Intelligent Telephony Service.

Figure 9 illustrates how a network security service according to the invention, in one embodiment a mobile risk management system of the invention (which in this specification is interchangeably referred to as a Risk Management for Mobile (RMM) module), can be applied to inbound calls to an ASP such as for example a banking service contact centre from a customer (for example on their mobile phone) or a party masquerading as a customer, such as a fraudster.

In one embodiment as illustrated in Figure 9, a member of a Customer Care team in an Application Service Provider (ASP) such as a banking service contact centre receives a call from a party purporting to be a customer. Effectively a three way call is established by a network system in the telecommunications network, with the ASP being the B party, the customer being the A party and the network security service according to the invention being the C party.

In one embodiment the network system could be, but not limited to, an IN (Intelligent Network) service within the telecommunications network, which can detect a call from a particular A party (for example customer) to a B party (for example ASP) and on such detection set up a call (effectively an IN call) to a C party (for example network security service of the invention). The IN service in one embodiment could be a Camel (Customised Applications for Mobile networks Enhanced Logic) based service. The network security service according to the invention, in one embodiment a mobile risk management system of the invention (which need not be but can be termed a Risk Management for Mobile (RMM) module) performs risk analysis on the number from which the call originates, the A party, as the banking service contact centre customer care want to be as sure as is possible that the calling party are whom their records purport them to be.

The risk analysis performed by the mobile risk management system of the invention can take many forms including for example, SIM takeover protection where analysis is performed to ascertain if the A party SIM has changed in the previous configurable time period, for example in the last 24-48 hours. Such configurable time periods can be agreed with the ASP.

Since this is an inbound call, it is not necessary for the network security service to check if call divert unconditional is active on the call. The network security service of the invention can perform a further check such as ascertaining for example if multi -party phone call is active on this connection. One or several fraudsters in tandem can use this feature very effectively. For example the fraudster does something to trigger a customer to ring the call centre and the fraudster is joined into the call which is then a multi-party call. The fraudster could for example eavesdrop on the authentication of the identity information, i.e. the knowledge factor and then cause the customer to be dropped off the call once the knowledge factor is complete, and take over the call for example for fraudulent purposes, or use the identity information garnered at a future stage etc. Further description on multi-party call is provided later in the specification, refer to Figure 12 and related description. So by checking if multi -party call is active the network security service can prevent issues such as security risks and fraud associated with multiparty call active and ensure that it is much more likely the phone call is originating from the correct party, and that they are not subject to compromise that can be associated with multi-party call active on a call.

A further check is to ascertain the location of the device which also influences the risk score. All of these are examples of some of the actions or features or facets that can be used by fraudsters to compromise a phone call, and the network security service of the invention by detecting these and other features mitigates against the risk of call compromise.

As part of the risk analysis the network security service can use some or all of the features outlined and other features to determine a risk score. In one embodiment if the risk score for the device identifier is over a certain configurable threshold (which can be agreed with the ASP) then the network security service can cause a message to be played out to the contact centre agent, which only the contact centre agent can hear indicating for example something along the lines of "warning further authentication needed". If alternatively the risk score for the device identifier is less than a certain configurable threshold then in that case the network security service can cause a message to be played out to the contact centre agent indicating for example something along the lines of "call secured" or "customer identified".

Such outputs make the security service very accessible for a contact centre agent, alerting them in an easy to understand format the risk status of calls with particular parties. The contact centre agent can then perform the appropriate action based on the message, for example requesting very detailed or less detailed knowledge factor from the customer as appropriate, or even terminating the call.

Thus the invention augments the current knowledge factor that an ASP such as a call centre uses with customers when receiving inbound calls from them (for example going through questions that only the calling party should know the answers to) by including a possession factor ("something only the user has"), in this instance the trusted device or more particularly a risk score or verification profile that the invention calculates for the trusted device. Thus the invention provides identity authentication and is enabling the ASP (which in this embodiment is a banking service contact centre) to know when they receive an inbound call the degree of likelihood that they are communicating with the actual trusted device (for example the phone that is registered against the customer account). Thus the invention enables two-factor authentication for inbound calls for an ASP.

In an alternative embodiment a customer contacts for example a customer care number for a banking service contact centre such as a credit card customer care number. The network security service, for example the network security service of the invention can for example be deployed in each network operator, or can be deployed centrally in one operator. In the latter case when a network operator detects that a call is bound for the credit card customer care number, if it is not itself hosting the invention security service it routes the call to a network which is hosting the security service. The inbound call (refer to Figure 9) is thus routed via (or metadata from the call is provided to) a network security service such as the security service, and routed straight onto the destination, (for example credit card customer care number). On detection of the call (or receiving pertinent metadata for the call) the network security service automatically carries out its risk analysis, based on the A party number, (the network security service can also perform risk analysis on the destination number, e.g. the pilot number of the destination number, the B party, and the associated risk scoring profile for the destination number can also play a role in the final risk score). The risk score is cached in the RMM database. The user may still be navigating through the ASP IVR. Importantly the security service needs to be informed when it should perform message playout. When the IVR portion of the phone call is complete and the customer is exiting the IVR menu and has chosen and is about to speak to a customer care agent, but just before the agent actually physically takes the call (for example the customer is still on hold, but the call has been assigned to the agent) the IVR platform creates a specific voice prompt, for example a tone which could for example be a DTMF tone of some sort, or could for example be very high pitched tone and outside of normal hearing, which triggers the network security service to play a message out to the contact centre agent, which as already described if the risk score for the device identifier is over a certain configurable threshold (which can be agreed with the ASP) can indicate for example something along the lines of "warning further authentication needed". If alternatively the risk score for the device identifier is less than a certain configurable threshold then in that case the network security service can cause a message to be played out to the contact centre agent indicating for example something along the lines of "call secured" or "customer identified". The playout message could for example be several beeps to indicate "warning further authentication needed" and a different beep or set of beeps to indicate "call secured" etc. Advantageously this feature applies to all outbound and inbound call scenarios, where the network security service is being triggered.

In an alternative embodiment rather than causing a message to be played out, on completion of the risk analysis, the network security service outputs metadata (pertaining to risk information) which in the case of an inbound call includes information such as A-Party UID or MSISDN, Risk Score, Reason code(s), etc., via for example a HTTP post or other suitable mechanism (not shown in Figure 9), to for example a backend service such as an ASP (for example a banking service). In the case of an outbound call the network security service outputs metadata (pertaining to risk information) which includes information such as B-Party UID or MSISDN, Risk Score, Reason code(s), etc. Advantageously this feature applies to all outbound and inbound scenarios, where the network security service is being triggered.

In a further alternative embodiment the network security service can cause both a message to be played out (to for example a customer care agent) and output metadata (pertaining to risk information) to for example a backend service such as an ASP (for example a banking service). Advantageously such combinations of the feature apply to all outbound and inbound scenarios, where the network security service is being triggered. In a further alternative embodiment on completion of the risk analysis, the network security service can cause any appropriate communication or action to an ASP agent (for example a customer care agent) or to a backend service such as an ASP (for example a banking service) or to any suitable communication end point or any combination of such.

In an alternative embodiment as illustrated in Figure 10, the network security service receives metadata from the network on the A and B parties (in one embodiment for example the A party (customer) number (for example MSISDN) and the B party (ASP) number). In one embodiment the network system in the telecommunications network could be an IN (Intelligent Network) service within the telecommunications network, which in one embodiment could be a Camel based service. The meta information could be generated from the IN service, for example the Camel service or from a network element such as a switch or by an intelligent platform or service deployed to provide such meta information to the network security service or by other means, on detection for example of any inbound call to a B party (for example a particular ASP) or on detection of a call for example from a particular A party (for example customer) to a B party (for example ASP).

On completion of the risk analysis the network security service can output metadata which includes a message indicator which indicates to a network system in the telecommunications network which message to play to the ASP, for example message X or message Y. The network system in the telecommunications network, then depending on the message indicator received is triggered to play out the appropriate message to the ASP (which in this embodiment is a banking service contact centre), for example if indicator X is received (as illustrated in Figure 10), it plays out the message configured for indicator X, for example a message such as "customer identified" or if message indicator Y is received it plays out the message configured for indicator Y for example a message such as "warning further authentication needed".

Normally this X or Y message indicator is sufficient but optionally further metadata such as for example the A party number (for example MSISDN or UID) and the B party number (ASP number) or whatever other available meta information could also be included as part of the response from the network security service to the network system if required.

The alternative embodiment achieves the same end result, namely enabling the ASP to know when they receive an inbound call the degree of likelihood that they are communicating with the actual trusted device (for example the phone that is registered against the customer account).

In an alternative embodiment as illustrated in Figure 10a, the network security service receives metadata from an IMS network on the A and B parties (in one embodiment for example the A party (customer) number (for example MSISDN or UID) and the B party (ASP) number or ASP ID). In one embodiment the network system in the telecommunications network could be an IN (Intelligent Network) service within the telecommunications network, which in one embodiment could be a Camel based service. The meta information could be generated in the IMS network by a SIP enabled network element or service deployed to provide such meta information to the IMS/SIP enabled network security service of the invention, as SIP headers in a SIP Request over SIP signalling or by other means, on detection for example of any inbound call to a B party (for example a particular ASP) or on detection of a call for example from a particular A party (for example customer) to a B party (for example ASP).

The network security service (in this embodiment an IMS/SIP enabled service) according to the invention, in one embodiment a mobile risk management system of the invention (which need not be but can be termed a Risk Management for Mobile (RMM) module) performs risk analysis on the number from which the call originates, the A party (for example a user on a device such as for example a customer), as the ASP (for example banking service contact centre customer care) want to be as sure as is possible that the party they are calling are whom their records purport them to be. On completion of the risk analysis the network security service outputs metadata which can include information such as A-Party UID or MSISDN, B -Party ASP ID or number, Risk Score, Reason code(s), etc., via SIP signalling in SIP response headers, which are passed through via the IMS network to an ASP.

Thus advantageously, in the context of the network security service of the invention (for example as in this embodiment an IMS/SIP enabled service) communicating with an ASP via an IMS network, identifiers such as A party identifiers (such as in the case for example of a customer, a MSISDN or UID) and B party identifiers (such as in the case for example of an ASP, an ASP ID or number) as well as other pertinent metadata can be passed in SIP responses and/or SIP requests according as the information is available, for example passed in SIP headers (such as for example in SIP response headers and/or in SIP request headers as available).

The level of service to the user can be based on the result of the risk analysis of the trusted device by the RMM as reflected in the metadata presented to the ASP (for example banking service).

The IP-PBX can as illustrated in Figure 10a be located and/or integrated with the ASP, or in an alternative embodiment located in the IMS network. The alternative embodiment achieves the same end result, namely enabling the ASP to know when they receive an inbound call the degree of likelihood that they are communicating with the actual trusted device (for example the phone that is registered against the customer account).

In an alternative embodiment as illustrated in Figure 11, the network security service is part of or integrated with an intelligent telephony service within a telecommunications network. In this embodiment all inbound calls are routed through the intelligent telephony service, and thus the call flow is available to the network security service of the invention. Thus any inbound phone calls from the ASP, are automatically routed to the network security service, in one embodiment a mobile risk management system of the invention (which in this specification is interchangeably referred to as a Risk Management for Mobile (RMM) module). Thus in one embodiment the network security service of the invention can handle the rest of the call setup to the B party. In an alternative embodiment the network security service could be integrated with another module which performs call handling and call setup to the B party as described below. The network security service performs risk analysis on the number from whom the call originates, the A party, as the banking service contact centre customer care want to be as sure as is possible that the party they are calling are whom their records purport them to be.

In one embodiment if the risk score for the device identifier is over a certain configurable threshold (which can be agreed with the ASP) then the network security service can cause a message to be played out to the contact centre agent, which only the contact centre agent can hear indicating for example something along the lines of "warning further authentication needed".

If alternatively the risk score for the device identifier is less than a certain configurable threshold then in that case the network security service can cause a message to be played out to the contact centre agent indicating for example something along the lines of "call secured" or "customer identified".

In one embodiment the Intelligent Telephony service could include an IVR system with which the network security service integrates as part of the Intelligent Telephony service, and performs its intelligence including mobile risk management. The IVR system could be an existing system in the telecommunications operator' s network with which the network security service can integrate, or an IVR platform included in and deployed as part of the Intelligent Telephony service along with the network security service. Advantageously the Intelligent Telephony service provides a complete solution for a mobile risk management value add service for inbound and outbound calls for ASPs (refer also for example to Figure 8). The Intelligent Telephony service can have for example a web based Graphical User Interface (GUI) or Telephone User Interface (TUI) for configuration.

In an alternative embodiment the intelligent telephony service could be hosted on an ASP platform.

The network security service can be integrated as part of the Intelligent Telephony Service, or the network security service can be stand alone, for example a cloud based service communicating with the Intelligent Telephony Service.

Figure 12 illustrates how a network security service according to the invention, can be applied to inbound calls to an ASP such as for example a banking service contact centre from a customer (for example on their mobile phone) or a party masquerading as a customer, such as a fraudster in the context of a multi- party call.

Referring to Figure 12, in one embodiment Fraudster 1 initiates a phone call with a customer, whilst Fraudster 2 initiates a phone call with an ASP such as for example a banking service contact centre for the customer's bank. Fraudster 1 is in a multi -party call with the customer and Fraudster 2. Fraudster 1 proceeds to go through the ASP's knowledge factor with the customer, presenting the questions that the ASP is presenting to Fraudster 2, questions that only the real customer should know the answers to. With good timing the correct answers from the customer can be relayed back through Fraudster 2 to the ASP. Once the knowledge factor is successfully completed and the caller (in this case Fraudster 2) is authenticated with the ASP. Fraudster 1 can drop the call with Fraudster 2. Fraudster 2 can proceed with the intended action of the call, for example surreptitiously setting up a new beneficiary, transferring funds etc.

The above serves as an example with many different methods and variations being possible, particularly if a fraudster(s) is technically proficient. For example a fraudster may have sufficient technical proficiency to intercept an active call between a customer and the ASP, and once the knowledge factor is successfully completed the fraudster may be capable of hijacking the call (with or without involving another fraudster), taking over the call whilst causing the customer to be dropped off the call to complete for example surreptitious fraudulent or other actions causing security threats or risks, or use the identity information garnered at a future stage. In such an example bio-metrics would also fail as the real customer would have been authenticated, for example their voice could already have been authenticated at the start of the call.

Advantageously the network security service of the invention by checking if multi-party call is active, can prevent issues such as security threats and risks and fraud associated with multi-party call active, and ensure that it is much more likely the phone call is originating from the correct party. Thus even though the knowledge factor ("something only the user knows") element of the two-factor authentication has been compromised, the invention ensures that the possession factor element ("something only the user has") in this instance the trusted device, does undergo a risk analysis and proper authentication. In this example the network security service checks if Fraudster 2 has multi-party call active on his phone, as it is Fraudster 2 that is doing an inbound phone call into the bank.

As part of the risk analysis the network security service can use features such as multi-party call active setting and other features to determine a risk score. In one multi -party embodiment (refer to Figure 12) if the risk score for the device identifier is over a certain configurable threshold (which can be agreed with the ASP) then the network security service can cause a message to be played out to the contact centre agent, which only the contact centre agent can hear indicating for example something along the lines of "warning further authentication needed". If alternatively the risk score for the device identifier is less than a certain configurable threshold then in that case the network security service can cause a message to be played out to the contact centre agent indicating for example something along the lines of "call secured" or "customer identified".

As already described such outputs make the security service very accessible for a contact centre agent, alerting them in an easy to understand format the risk status of calls with particular parties. The contact centre agent can then perform the appropriate action based on the message, for example requesting very detailed or less detailed knowledge factor from the customer as appropriate, or even terminating the call.

In an alternative embodiment as illustrated in Figure 13, the network security service receives metadata from the network on the A and B parties (in one embodiment for example the A party (Fraudster 2 in Figure 13) number (for example MSISDN) and the B party (ASP) number). In one embodiment the network system in the telecommunications network could be, but not limited to, an IN (Intelligent Network) service within the telecommunications network, which in one embodiment could be a Camel based service. The meta information could be generated from the IN service, for example the Camel service or from a network element such as a switch or by an intelligent platform or service deployed to provide such meta information to the network security service or by other means, on detection of for example any inbound call to a B party (for example a particular ASP) or for example from a particular A party (for example Fraudster 2) to a B party (for example ASP).

On completion of the risk analysis the network security service can output metadata which includes a message indicator which indicates to a network system in the telecommunications network which message to play to the ASP, for example message X or message Y. The network system in the telecommunications network, then depending on the message indicator received is triggered to play out the appropriate message to the ASP (which in this embodiment is a banking service contact centre), for example if indicator X is received (as illustrated in Figure 10), it plays out the message configured for indicator X, for example a message such as "customer identified" or if message indicator Y is received it plays out the message configured for indicator Y for example a message such as "warning further authentication needed".

Normally this X or Y message indicator is sufficient but optionally further metadata such as for example the A party number (for example MSISDN or UID) and the B party number (ASP number) or whatever other available meta information could also be included as part of the response from the network security service to the network system if required.

The alternative embodiment achieves the same end result, namely enabling the ASP to know when they receive an inbound call the degree of likelihood that they are communicating with the actual trusted device (for example the phone that is registered against the customer account).

In an alternative embodiment the invention has means to provide an IMS based solution as described with reference to Figure 7a and Figure 10a which is applicable to a multi -party call.

Data Protection

Advantageously the network security service of the invention can also be applied to data protection. Some jurisdictions are mature in terms of legislation for data protection, others not, for example just enacting data protection legislation, regardless the invention can help parties meet compliance with data protection legislation. If an Application Service Provider (for example a financial service provider, utility provider, etc.) is in contact with customers, in order to be compliant with data protection legislation they need to be as sure as possible that they are in communication with the correct intended party, for example customer. An ASP such as a call centre can currently use knowledge factor with customers when performing outbound calls to them or receiving inbound calls from them (for example going through questions that only the customer should know the answers to), in order to try and establish if the customer is whom the customer purports to be or whom the ASP believes them to be for example to be compliant with data protection legislation obligations.

As described the invention augments the knowledge factor by including a possession factor ("something only the user has"), in this instance the trusted device or more particularly a risk score or verification profile that the invention calculates for the trusted device. Thus the invention provides identity authentication, enabling two-factor authentication for an ASP, enabling the ASP (for example a banking service contact centre) to know when they are communicating with a party (either via an outbound or inbound call), the degree of likelihood that they are communicating with the actual trusted device (for example the phone that is registered against the customer account), and advantageously therefore whether they are compliant with data protection legislation obligations.

The invention by enabling two-factor authentication for inbound and outbound calls for an ASP, enables ASPs directly to be compliant with data protection legislation obligations and/or enables mobile operators to offer additional services to their corporate customers (for example ASPs) to make it very easy for their corporate customers to be compliant with data protection legislation obligations.

3D Secure solution for phone payments

Background

Card Not Present (CNP) fraud, where a payment transaction occurs when the cardholder is not present, accounts for a very significant portion of fraud payments.

3D Secure is an XML -based protocol designed to be an additional security layer for Card Not Present (CNP) / online credit and debit card transactions. Visa originally developed 3D Secure which adds authentication to improve the security of Internet payments, offering the service under the name "Verified by Visa" to customers. Other credit card companies such as for example MasterCard (SecureCode) and American Express (SafeKey) have since adopted 3D Secure.

3D Secure provides ecommerce merchants with greater security for their payment card transactions when the cardholder is not present in person. A key facet of 3D Secure is that the card issuer authenticates the cardholder online. The card issuer assumes any liability for fraud where an Internet retailer or merchant is registered for 3D Secure at the time of the transaction. This is known as liability shift, where the liability is shifted from the Internet retailer or merchant to the issuing bank.

Essential to 3-D secure is that online authentication is coupled with the financial authorization process. The authentication is within the context of a three-domain model (hence 3-D), with the three domains being:

• Acquirer Domain (the merchant and the bank to which money is being paid).

• Issuer Domain (the bank which issued the card being used).

• Interoperability Domain (the infrastructure provided by the card scheme, credit, debit, prepaid or other type of finance card, to support the 3-D Secure protocol). Interoperability Domain includes the Internet, MPI, ACS and other software providers

There are two card not present environments that are common, one is online purchases, and the other is for payments over the phone. The typical 3D Secure solution for online is where a customer goes for example to an online merchant, for example Aer Lingus, and purchases something. When the customer decides what they are buying, and have entered their credit card details, and clicked on buy, at that point the customer is redirected to for example "Verified by Visa" or "SecureCode" by MasterCard. These are 3D Secure implementations by these schemes on behalf of an issuing bank, who issue credit cards to customers, and have the relationship with them. Typically for a potential online payment, the issuing bank will issue some question(s) i.e. knowledge base via for example a web page which pops up and requests for example the customer to enter their Mother's maiden name etc., or the customer may have to generate and enter a PIN code from for example a token generator, a trusted device that is in their possession (i.e. possession factor). Essentially when the issuing bank verifies identity (i.e. that you are who you are), then the payment is approved. Because the issuing bank who has the relationship with the customer has verified their identity, the issuing bank guarantees that payment and the merchant is fully protected. So if for example a stolen credit card has been used, then the issuing bank merchant is going to bear the loss, not the merchant, i.e. as already mentioned this is termed liability shift where the liability is shifted from the merchant to the issuing bank.

If the merchant does not implement 3D Secure or they take the credit card details in a way that is not compliant with 3D Secure, for example card not present over the phone, then the issuing bank cannot verify the card holder and the merchant bears the loss.

Although 3D Secure for online purchase as just described is well known in the art, 3D Secure for payments over the phone is not known. The invention provides a 3D Secure solution for card not present for payments over the phone. This aspect of the invention will be more clearly understood from the following description of an embodiment thereof, given by way of example only.

Referring to Figure 14, in one embodiment a customer rings a service provider for example a betting company, to place and pay for a bet using a credit card. In one embodiment the service provider has an integrated IVR and Point of Sale (POS) system including IVR credit card payment facilities. Using IVR the customer places their wager and enters the payment details, typically for example credit card details (including for example a card security code such as for example a card verification value (e.g. CVV2) number) over the phone.

As already described the network security service according to the invention, in one embodiment a mobile risk management system of the invention (which in this specification is interchangeably referred to as a Risk Management for Mobile (RMM) module) can be applied in many varying embodiments to inbound calls to an ASP (such as for example a betting company) from a customer (for example from their mobile phone) or from a party masquerading as a customer, such as a fraudster. In one embodiment the network system of the invention in the telecommunications network could be, but not limited to, an IN (Intelligent Network) service within the telecommunications network, which in one embodiment could be a Camel based service.

The network system of the invention in the telecommunications network has a 3D Secure Phone Number List, which contains entries for preferred merchant numbers and their associated merchant IDs for which the invention is applied for inbound calls.

The meta information can be generated from the IN service, for example the Camel service or from an intelligent telephony service, or by for example an IMS SIP based service, or by a network element such as a switch or by an intelligent platform or service deployed to provide such meta information to the network security service or by other means, on detection for example of any inbound call to a B party (for example an ASP such as for example a betting company which is detected as being on the 3D Secure Phone Number List), or on detection for example of an inbound call from a particular A party, for example a customer (for example from their mobile phone) or from an A party for example masquerading as a customer, such as a fraudster to a B party (for example an ASP such as for example a betting company which is detected as being on the 3D Secure Phone Number List).

The meta data generated from the network system of the invention (for example IN service) in the telecommunications network to the network security service of the invention includes the Merchant ID of the called party (B party) and the card holder mobile number (for example MSISDN), refer to (2) in Figure 14.

The network security service records the Merchant ID, the card holder mobile number and the time of the call (which can be in the metadata received or can be the time that the metadata is received) in the RMM call log. When the customer has entered the payment details typically for example credit card details using IVR, into the integrated IVR and Point of Sale (POS) system, the Credit card number and Merchant ID are transmitted to the acquiring bank, the credit card scheme, and from there to the issuing bank.

The issuing bank, have the customer's credit card number(s) and the phone number that is registered against the credit card. Thus the issuing bank can verify that the customer's number (for example MSISDN) and credit card number received in the transaction match their records.

The issuing bank then invokes a security check, querying the network security service providing the Merchant ID and card holder mobile number in the query.

The issuing bank not being a party to the call are essentially requesting the invention, is for this card not present transaction payment the end user device for example the mobile phone (registered with the issuing bank against the credit card) in the possession of the customer at that time of the call, i.e. did the user ring from their registered phone to make the payment phone call, i.e. is the possession factor element ("something only the user has") in this instance the trusted device fulfilled, in this instance by the invention performing a risk analysis on the authenticity of the A party end user device.

The network security service (RMM) checks the Merchant ID and card holder mobile number received from the issuing bank, against the RMM call log and verifies if it has an entry that matches those details and what time the call occurred at. The RMM then returns the time of the last call for the Card holder mobile number to the particular Merchant associated with the Merchant ID, to the issuing bank. If no entry is found the response to the issuing bank indicates that, returning for example an error or "no information" etc., to indicate that the RMM does not have any details on the call having taken place. Advantageously the network security service (RMM), has means to perform risk analysis and security checks on the customer phone number that the network detected making the call as it received it earlier from the network (see step (2) in Figure 14).

The risk analysis and security checks performed by the mobile risk management system of the invention can take many forms including but not limited to those which have been previously described for inbound calls. These forms can include for example, SIM takeover protection where analysis is performed to ascertain if the B party SIM has changed in the previous configurable time period, for example in the last 24-48 hours. Such configurable time periods can be agreed with the ASP. Such analysis can include for example the RMM querying the network to ascertain if there have been recent suspicious phone state changes, for example if the RMM obtains a response such as "unknown subscriber" indicating that the phone has been disconnected, that may be considered suspicious and affect the risk score. The network security service of the invention can perform a check such as ascertaining for example if multi-party phone call was active on this connection, at the time the payment was made.

A further check is to ascertain the location of the device which also influences the risk score. On completion of the risk analysis the network security service can use such and other features to determine a risk score, to identify the likelihood or risk that the end user device (for example mobile phone) is or is not actually in possession of the user whose number is registered with the bank against a particular credit card.

If the results of the risk analysis are positive for example if the phone is active and there has not been a SIM change, and a call entry has been found for the user and the respective merchant ID, therefore the risk score reflects the likelihood that the user is in possession of the device whose number is registered with the bank against a particular credit card, and the level of confidence that the RMM can attribute that a phone call originated from the user to the merchant, at a specified time.

The risk score and reason code(s) are returned to the issuing bank, along with the time of last call for the Card holder mobile number to the particular Merchant associated with the Merchant ID. Advantageously in this case the response can be returned potentially very quickly as the risk analysis can begin on receipt from the network of the calling party number i.e. customer number and indeed may have already been performed by the time the issuing bank (step (3) in Figure 14) issues the query to the network security service. This is advantageous as credit card schemes typically allow a maximum end to end processing time of around for example 350 milliseconds for verification of these transactions. Note in many cases the time of last call will be associated with a call that is in progress.

Depending on the risk score returned and the Bank's own checks a response is returned back through the chain via the credit card scheme and the enquiring bank, back to the integrated IVR and Point of Sale (POS) system (including IVR credit card payment facilities), either accepting or rejecting the transaction.

Note the time of last call is a powerful and flexible indicator of the veracity of a calling party, to return to the issuing bank, especially when coupled with metadata such as a risk score and risk reason(s). Notably it is also quite robust as for example not all transactions are submitted immediately, for example could have an offline payment if for example there was a problem with the integrated IVR and point of sale device, or the payment was cached due to the payment being of a low value, for example a payment under a certain threshold (for example 10 euros or whatever threshold the acquiring bank specifies), with a bundle or batch of payments being submitted together at a particular interval, e.g. nightly. The acquiring bank is best placed to do the required correlation as has access to such policies and familiar with ecosystem anomalies and can have access to information from the actors in the ecosystem such as the IVR system and point of sale device which should have the original time of purchase. Thus the network security service (RMM) records the fact that a phone call occurred between a particular mobile number and a merchant, and the time of occurrence. This enables a service provider such as an issuing bank which wants to establish the identity of the calling party to query the RMM to ascertain if such a call took place for a particular card holder. Since the bank have gone through secure methods to register a card holder's mobile number against a credit card, if on providing this mobile number to the RMM along with the merchant with whom the card holder's transaction is with, the RMM of the invention provides the time of the last call and provides results (such as a risk score and risk code(s)) reflecting risk analysis on the mobile number identity of the card holder, then depending on whether the time of the last call matches when the transaction time occurs, coupled with a risk score and reason code(s) reflecting the likelihood and risk that the user is in possession of the device whose number is registered with the bank against a particular credit card, and the level of confidence that the RMM can attribute that a phone call originated from the user to the merchant, at a specified time, then the issuing bank can make an informed decision, that they have a high degree of confidence that the calling party are whom they purport to be or not and can allow the transaction through, or reject the transaction. In the embodiment depicted in Figure 14 the response returned back to the integrated IVR and Point of Sale (POS) system (including IVR credit card payment facilities), indicates that the transaction should be accepted.

Referring to Figure 15, in an alternative embodiment a customer rings a service provider for example a Chinese restaurant, to place an order. The difference between this and the previous embodiment is that rather than the customer contacting the service provider via an integrated IVR and Point of Sale (POS) system including IVR credit card payment facilities (as per the previous embodiment), the order and the payment details, typically for example credit card details (including for example a card security code such as for example a card verification value (e.g. CVV2) number) are taken over the phone, and the person accepting the order enters the credit card details into for example a point of sale machine. Otherwise the same flow as described in the previous embodiment proceeds, in order for the agent to use the invention as part of 3D Secure to verify the identity of the user phone.

Referring to Figure 16, in an alternative embodiment a customer rings a service provider for example a restaurant, to place an order. The order and the payment details, typically for example credit card details (including for example a card security code such as for example a card verification value (e.g. CVV2) number) are taken over the phone. The person accepting the order enters the credit card details into for example a point of sale machine. As part of 3D Secure the agent now wants to verify the identity of the user phone. The point of sale machine prompts the agent for the phone number, instructing the agent for example to press *3 or ## or some such entries on the phone, and on doing this *3 triggers the network or other means to play the customer's phone number for the agent and optionally the calling party, as the merchants phone line is enabled for card not present phone traffic transactions.

The agent enters the phone number into the point of sale device (the payment details for example credit card details which have also been entered are also transmitted) which is transmitted in real or near realtime to the acquiring bank, and from there it is sent to the credit card scheme depending on the customer's credit card, for example Visa or MasterCard, and from there it goes to the issuing bank, i.e. the credit card issuer. The issuing bank then invokes a security check, querying the network security service which performs a security check on the phone number that has been entered.

The risk analysis performed by the mobile risk management system of the invention can take many forms including but not limited to those which have been previously described for inbound calls. These forms can include for example, SIM takeover protection where analysis is performed to ascertain if the B party SIM has changed in the previous configurable time period, for example in the last 24-48 hours. Such configurable time periods can be agreed with the ASP.

The network security service of the invention can perform a check such as ascertaining for example if multi-party phone call was active on this connection, at the time the payment was made.

A further check is to ascertain the location of the device which also influences the risk score. On completion of the risk analysis the network security service can use such and other features to determine a risk score.

The risk score is returned to the issuing bank. Significantly since the issuing bank has the relationship with the customer, they have the customer's credit card number and the phone number that is registered against the credit card. Thus the issuing bank can verify that the calling party's number is the number that is registered against the credit card. Depending on the risk score returned and the Bank's own checks a response is returned back through the chain via the credit card scheme and the enquiring bank, back to the point of sale machine either accepting or rejecting the transaction. Thus the network security service of the invention can obtain the phone identity in a trusted way, and perform risk analysis, and provide a risk score as regards the likelihood that the customer phone in communication with the merchant (which can be over a normal phone call) is whom they purport to be. Thus the invention provides a 3D Secure solution for phone payments (i.e. card not present transactions) including risk management of identity for inbound and outbound calls.

An issuing bank (which may or may not traditionally provide 3D Secure for Internet payments), by integrating with the invention is enabled to offer 3D Secure for phone payments.

Also in the same way that the merchant has to subscribe to 3D Secure for Internet payments, the merchant is also an actor and part of the ecosystem for phone payments and the merchant's phone can as described be directly integrated with the invention.

Although 3D Secure has been described in these embodiments in terms of inbound calls, the network security service of the invention is also applicable in this context to outbound phone calls (for example the merchant could initiate an outbound phone call to a customer requesting payment) from for example a merchant's number or an ASP.

Thus the invention can pre-process (i.e. perform the risk analysis before the transaction is sent to the issuing bank) or post-process (perform the risk analysis after the transaction is sent to the issuing bank) the risk analysis.

The invention can be integrated with a mobile network or fixed line network.

In an alternative embodiment the network security service of the invention could be invoked by the acquiring bank.

2-factor authentication based on mobile device identity and mobile device location

Figure 17 illustrates a network environment in which a network security service according to the invention may operate and communicates with one or more devices and an Application Service Provider (ASP) and one or more network elements. Each device communicates with the ASP via an app which has an adjunct security software module (which can be bundled or standalone) and via for example a WIFI Internet connection directly to the ASP backend server. The network security service according to the invention can be a cloud based service but need not be. Figure 17 also illustrates how an ASP may utilise the invention to by utilising the mobile network and USSD to either collect additional authentication credentials (for example a certain number of digits from a PIN code, a generated ΡΓΝ from a token generator, etc.), or to present a One Time Password (OTP) to the user.

As previously described, 2 Factor Authentication is an approach where verification of someone's identity requires the presentation of at least 2 of the 3 authentication factors; a knowledge factor ("something only the user knows"), a possession factor ("something only the user has") and an inherence factor ("something only the user is"). Once a factor has been presented, it must be validated by the other party, e.g. an Application Service Provider like, but not limited to, a bank or financial institution. Two factor authentication would typically use device separation for increased security, meaning that the user would be required to access the service from a different device to where a verification and authentication code is received. An example of this would be that the user would access the service through a webpage for example on a laptop typically using, but not limited to, a username and password to gain access. This would provide one authentication factor (referred to as 1 factor authentication). 1 factor authentication can be achieved by either the usage of the knowledge factor ("something the user knows" - for example a username and password) or a possession factor ("something the user has" - for example the device the user is using to access the service from). It is not important what factor is used to gain access, but what is important is that one of the three or more factors are used to gain access. When an additional authentication factor must be presented by the user, the authentication factor would typically be provided to the user by sending an SMS to the user's mobile device that the user would enter in the web page.

Typically, 1 factor authentication could be required for basic service tasks. Using online banking services as an example, typically a user would be allowed to, but is not limited to, view current balance on the user's account and make a payment to existing beneficiaries tied to the user's account when at least one authentication factor has been verified by the ASP. If the user then was required to perform a sensitive task like for example, but not limited to, add a new beneficiary to the user's profile, the user would be required to present an additional authentication credential.

With reference to mobile services, but not limited to mobile banking services, which require two factor authentication, the device separation may no longer be in place in the event that the user accesses the online banking service on the mobile device and at the same time receives the 2nd authentication factor on to the same mobile device (for example via an SMS message).

Mobile Device Identity Authentication The invention allows users of mobile applications and Application Service Providers to achieve 2-factor and/or multi-factor authentication with reduced friction and without needing, but not by any means limited to, the user to manually present authentication credentials. The invention further provides functionality to mobile device application users and/or Application Service Providers (ASPs) to specify the level of security required to perform a specific task. Typically a mobile application user will have the ASPs application installed on the user's mobile device (e.g. a mobile phone). The ASP could for example, but is not limited to, be a bank and the mobile application could allow the user to get access to relevant banking services (e.g. online banking application).

Typically, there would be specific tasks (for example to check the bank account balance or to view the transaction history) that the user can perform within a banking application that does not require the user to present additional authentication factors after the initial login. On the other hand, there could also be specific tasks where the ASP would require additional security checks or additional authentication factors required to be presented by the user to the ASP (for example, but not limited to, by requesting the user to enter a password, parts of a PIN Code, a generated token, etc.). Examples where the ASP would require the user to present additional authentication factors could for example, but not limited to, be to add a beneficiary to the online banking application so that the user can transfer funds to this beneficiary without additional security requirements in the future.

Adding a beneficiary presents some risk to the user, for example in the event where the user online banking access credentials have been compromised by a fraudster, it is vital that the fraudster cannot add additional beneficiaries to the user account without any additional security measures being in place. The invention aims to make such services secure and with less friction to the legitimate user.

In one embodiment of the invention will achieve authentication (1 factor) by using the mobile device (something the user has) as the authentication factor. Note that the data used for device factor authentication is in this case not taken from the device itself, but is obtained from the mobile network.

Figure 17 illustrates an embodiment of the invention, but is not limited to where a user of an online banking, or other, application running on a mobile device is connected to the Internet via WIFI. The invention includes for example, but is not limited to, a Java Archive (JAR) file that can be is for example, but is not limited to, be bundled with the mobile application on the mobile device. The user accesses the online banking application on the mobile. The mobile application will check the local settings within the mobile application for the user to see what security settings the user has configured (Please also refer to the heading named "Local Security Settings for Invention" for further clarifications). The mobile application will attempt to connect to the ASP backend server, in this example but not limited to a bank, via the Internet over WIFI. With reference to figure 17 (step 1), the mobile application will send a request to gain access along with a request for a session identifier (Session ID). The ASP will provide the session ID back to the mobile app. Based on the location security settings in the mobile application for the user, the online banking application will use the user's MSISDN (or IMSI) to authenticate the user of the mobile application. At this point, the ASP may or may not have a record of the user's MSISDN, but for this example it is assume that the ASP has a number registered for the user. However, a mobile number can easily be compromised by fraudsters, so the invention will obtain the number of the mobile device used to access the online banking service, but not from the mobile device, instead it will obtain the number from the mobile network. This makes it more difficult for anyone to compromise.

With reference to figure 17 (step 3), the mobile device user's MSISDN is in this embodiment of the invention obtained by sending, but is not limited to, an SMS with the relevant information such as, but not limited to, Session ID, ASP ID, Location information of mobile device, etc. from the users mobile. The SMS sending is performed by the invention's JAR file that is bundled with the ASP application software. The SMS message that is issued by the invention's JAR file, or is not limited to, will not appear in the user's sent items. The SMS is sent, but not limited to, to a short code number to prevent the SMS from being hijacked by a fraudster.

With reference to Figure 17 (step 4), the SMS that was initiated from the mobile application's JAR file is routed through the mobile network (via the SMSC) to the invention's security manager using the above mentioned short code. Once the Invention Security Manager receives the SMS from the JAR file, the invention Security Manager has got the user's MSISDN (basically the sender's address in the received SMS). With reference to figure 17 (Step 6), using the MSISDN, the invention Security Manager can query the Mobile Operator network for additional information, such as Cell ID, Mobile Country Code (MCC), Mobile Network Code (MNC), Location Area Code (LAC) and geographical Location. The invention can also check if there has been any SIM Card changes recently for this mobile device. Using this information, the Invention Security Manager can calculate a risk score. The Risk score can be based on various checks, such as but not limited to, SIM card Swap, if the user is accessing the service from a known or registered mobile device or MSISDIN, location of mobile device (more on this later), etc. The Risk Score can be scored, but is not limited to, as a number between 0 and 1000. Once a Risk Score is calculated for this current session ID, the Risk Score along with a Reason Code. As described previously, the reason code can encode the characteristic that influences the risk score the most, or alternatively multiple reason codes can be included where each reason code encodes a different characteristic that is contributing to the risk score, or alternatively a reason code can encode multiple characteristics reflecting the one or more characteristics that influence the risk score most. If required by the ASP, the invention can also provide a User ID to the ASP that can be mapped to for example an account holder within the bank.

With reference to figure 17 (step 7), the above information; User ID, MSISDN, Risk Score, Reason Code and Session ID is sent to the ASP for further processing.

With reference to figure 17 (Step 11), the ASP backend application receives the information and based on the Risk Score and/or Reason Code determines if the user should be allowed to gain access to the service or not. If the user should be allowed to gain access, the ASP sends an OK to the access request from the mobile application. If the ASP deems the Risk Score and/or Reason code to be too high (meaning potential fraud or risk for compromise) the ASP sends and Access Denied to the user's mobile application.

In a further embodiment of the invention, the above authentication flow can be used as a second authentication factor if the user has already provided an initial authentication factor where the user for example has logged in to the mobile application using a username and password.

Using Device Profiling to verify the identity of the Mobile Device and the user In another embodiment of the invention (not described in the figures), to combat the issue where a mobile user is only connected to the internet over WIFI or similar, but is not connected to the mobile network and therefore has no capability to send an SMS. In this event, to ensure that user can still use the mobile ASP application, the invention performs a device profiling of the mobile device the user is connected with. A device profile for user's mobile devices can be built up by the invention by retrieving various information from the handset. The information retrieved can be, but is not limited to, attributes like the IMEI, IMSI, language setting, the SW version running on the mobile device, the Serial Number of the phone, the CPU, the SIM Card Serial Number (ICCID), the browser version running on the mobile device, the model of the phone, the firmware of the mobile device, etc.

Using the above information for a mobile device, the invention can store this in the database and create a unique signature for the user's mobile device. The invention will perform the same check for all users of the invention and will over time build up a database of all the user's mobile devices signatures. The invention Security manager will retrieve the above information from all user's mobile devices. The invention can for example, but is not limited to, retrieve this using the JAR file that is bundled with the ASP mobile application.

The JAR file will query the mobile phone for the information and send it to the invention Security Manager's web server via a HTTP request. The HTTP Request will also include the Session ID. The invention's security manager will store the information sent from the JAR file and store this as a "finger print" for the mobile device. The invention security manager web server will respond to the HTTP Request with a 200 - OK message, but will not display anything on the mobile device. The mobile device signatures will be stored in the invention's database and can be used to look up and verify the user's device identity when an SMS cannot be sent. The mobile device signature can also be used for added security as part of the invention even when SMS is available to ensure that the user is who he/she claims to be.

Any minor deviation in the mobile device signature can result in a Risk Score being calculated by the invention and this Risk Score can be used by the invention or sent to the ASP for further processing. Any major differences in the mobile device signatures could indicate potential fraud or it could also indicate that the user have legitimately changed their mobile device or performed a major upgrade. In this event, the invention could either abort the service, or it could force the user to present additional authentication credentials, or it could also calculate a risk score that it could pass on to the ASP. Mobile Device Location Authentication ("Safe Place")

In another embodiment of the invention, an additional authentication factor (the knowledge factor) is based on using the user's location (or more specifically the location of the user' mobile device). The invention allows for the user to store one or more "Safe Places" which are physical locations from where the user (and also the ASP) assesses to be safe with regards to accessing specific ASP services. The "Safe Place" locations can be, but is not limited to, stored within the invention Security Manager or within the Application Service Provider. The location of the mobile device can in one embodiment of the invention be obtained from the GPS device present in the mobile device itself (provided that the mobile device has a GPS device and does not have location services disabled generally or for the relevant mobile application), or in another embodiment of the invention be obtained by querying the mobile network for the location of the mobile device either by using, but not limited to, a mobile network operator's mobile positioning/location service or by executing a MAP SRI for SM on the user's mobile number, or by executing a MAP ATI on the user's mobile number. In another embodiment of the invention, the location obtained from the GPS device within the mobile device can be compared with the location of the mobile phone when queried from the mobile network. This can be done to ensure that the user (or potential fraudster) is not trying to spoof the system by pretending that the user is in a different physical location to where the user actually is. This can be a powerful method to combat potential fraud to verify that the legit user (or the legit user's mobile device) is in a different location (even country) to a potential fraudster.

With reference to Figure 17 again, other embodiments of the invention include using the location to verify that the user is who the user claims to be by checking the location of the user's mobile device. There are a couple of parts to this; one is to check the location of the user to be used as input to the risk score calculation, and the other is to verify the location of the user against a location that is stored and known to the user. The stored location is referred to as a "Safe Place" and compromises of one or more locations that either the user or the ASP has registered. By allowing the user or ASP to register a "Safe Place", this can be used as an authentication knowledge factor (something that the user knows). More information on the registration of "Safe Places" under the heading "Registration of Safe Place".

When a user tries to access for example an online banking application from a mobile device like illustrated in figure 17, the invention can trigger a further check as part of the authentication mechanism explained for device authentication above. Figure 17 (Step 1) is the same as above, where the user tries to access the mobile application and a request to gain access and to get the Session ID from the ASP is sent from the mobile application. The session ID is returned as before, but this time the JAR file also obtains the location of the mobile device from the GPS device within the mobile device. With reference to Figure 17 (step 2), the invention JAR file mentioned above queries the GPS device in the mobile device for the location of the mobile device. The JAR file will then include the obtained location information in the SMS message together with the Session ID and ASP ID that is sent to the invention Security Manager via the Mobile Network (SMSC), where it will be used for authentication and/or verification of current session for the user. This GPS check can be turned off or be disabled within the invention to ensure that no privacy issues are breached.

The mobile device location obtained from the GPS device in the mobile device can be used to verify that the person is in the right country, geographical area, etc., and can in one embodiment of the invention be used as input to calculate the Risk Score that is used to decide if the user should gain access or not to the mobile application, or if the user for example should be allowed to perform a sensitive task.

In another embodiment, the invention can use the GPS location received in the SMS send from the invention's JAR file on the mobile device to the invention Security Manager to determine if the user (or more accurate the user's mobile device) is in a location or in near proximity to a location that is registered as a "Safe Place". There can always be slight variations in the GPS Location coordinates, so the invention allows for configuration to specify how accurate the location match needs to be. The invention can be configured to use a proximity factor defining how close the two geographical locations must be before stating that there is a discrepancy or not. Depending on any discrepancy in the GPS Location received from the handset and the registered "Safe Place" location, the RMM in the Security Manager can calculate a Risk Score that reflects how close the two locations are. Based on this a Risk Score can be calculated and together with a Reason Code, Session ID and User ID can either be used by the invention Security Manager or sent to the ASP for further processing.

Referring to Figure 17 (Step 6), In another embodiment of the invention based on the outcome of the location check but also the mobile device identity check mentioned above, the Risk score is calculated, Reason Code set and sent to the ASP together with the Session ID (and possibly the User Identity as described previously). The ASP can then assess the risk score and decide whether or not to allow the user to access the service.

By obtaining the location of the mobile device from the GPS device within the mobile handset itself, it leaves it open for potential fraud as there is software and mobile applications available to "fake" the GPS location of a mobile device. The GPS coordinates that is sent from a mobile device could be spoofed or faked using various mobile application solutions like e.g. "LocationFaker" or "Location Spoofer" for IPhone or "Fake GPS" for Android. The invention would allow the ASP to be able to compare the GPS location received from the mobile device against the mobile cell location or the mobile location obtained from the mobile network for the same mobile device.

In another embodiment, the invention compares the mobile device location obtained from the GPS device in the mobile device against the location of the same mobile device obtained from the mobile network to investigate if the actual location of the mobile device is being compromised. Referring to Figure 17, the user accesses a mobile banking application the user's mobile device. The mobile application checks the security settings configured on the mobile application. These can either be set by the user in the mobile application or the settings can be set by the ASP within the mobile application. The mobile application sends a request to get the Session ID from the ASP. At the same time, the mobile application triggers a request to the invention JAR file to obtain the GPS location from the mobile device (refer to Figure 17 - Step 2). The GPS location was carried out by the invention's JAR file because the mobile application security settings were, for example but not limited to, set to "Safe Place", meaning that the invention allows the user if being in a registered location to gain access to a service. The GPS location is included in the device authentication SMS message that is sent to the invention Security Manager via the mobile network as part of step 3 and 4 in figure 17.

The SMS message is sent from the invention JAR file in the mobile device, but not limited to, a Short Code to prevent the SMS message from being compromised or hijacked. The Invention Security Manager receives the SMS message and performs, but is not limited to, either a MAP SRI for SM (Send Routing Information for Short Message) request or a MAP ATI request to the Telecom network for the Mobile Device in question. The MSISDN would be known to the Invention's Security Service from the mobile number ("From Address") received in the incoming SMS. In one embodiment, a MAP SRI for SM Request can be sent towards the MSC/HLR/VLR and return the following information that can be used by the invention:

IMSI (and also LMSI)

MSC Number OR SMS Router Number OR MME number for MT SMS

Based on the MSC number, the invention can determine if the user is within the relevant area or in the same country as the person trying to access the service. In another embodiment of the invention, a MAP ATI Request towards the MSC/HLR/VLR will result in the following information returned back to the Invention Security Service:

- Mobile Country Code (MCC) and Mobile Network Code (MNC)

- Location Information (e.g. Age of the Location information, geographical information (represented in Longitude and Latitude), VLR Number, Location Number, Cell ID or Location Area ID (LAI), etc.)

The Mobile Network Operator will have a mapping table of the Cell ID to a physical location. The invention uses this mapping table to map the Cell ID to, but is not limited to, Longitude/Latitude coordinates. In addition, the Cell ID itself can be used to verify the location of a user's mobile device.

If Cell ID is used by the invention to determine the approximately physical location of the mobile device, the mapping information from a Cell ID to a physical location can be built up by the invention over time by either going to each cell location and obtaining a physical location in the form of Longitude/Latitude or it can be mapped to a Post Code or it can be mapped to a national grid reference.

Alternatively the invention can monitor and record the geographical location of all new and unique Cell IDs that is using the system and over time a complete mapping between Cell ID and Geographical location is built up. The invention will, but is not limited to, store the mapping data in an internal database.

When in operation, the invention will attempt to do the initial lookup internally first before querying the MNO's mapping table. Alternatively, the Mobile Network Operator's mapping table can be deployed within the invention Security Manager, or the Mobile Network Operator can expose an interface where the invention can look up the longitude and latitude for a specific Cell ID.

Alternatively to retrieving the mobile device location based on a MAP SRI for SM request or a MAP ATI request, the invention could get the mobile device location based from a mobile positioning system or similar from the Mobile Network Operator. The invention is not limited to the method used to obtain the location of the mobile device, but the important point is that the invention allows for comparing the location of the mobile device using the GPS device in the mobile Station against the location obtained from the mobile network.

The invention provides a solution for an efficient, with less friction and secure 2-factor authentication by using the actual physical location of the mobile device for a user using a mobile application. A user can register one or more "Safe Places" from where the user can perform these specific or sensitive tasks in for example using an application in a mobile device. Once a user has registered a "Safe Place", the user can perform specific tasks using a mobile application with less need for manual 2-factor authentication (e.g. token generators, passwords, PIN codes, etc.). The invention will be able to check the physical location of the mobile device where the mobile application is running and to verify that the user is in the location the user claims to be. The invention also addresses any potential issues with spoofing the GPS location within the mobile device. Provided that Location Services are not disabled within the mobile device, the invention will compare the GPS location received from the mobile device against the mobile device location obtained from the telecom network using the cell ID, geographical location resulting from a MAP ATI or MAP SRI for SM, or other mobile positioning services. The cell ID is mapped to an approximately location and the invention will check the difference between the cell location and the GPS location to see if someone is trying to impersonate a legitimate user and is trying to fake the GPS location. In the event that Location Services are disabled (GPS tracking turned off or Location Services is Disabled) in the user's mobile device, the invention will obtain the location of the mobile device and user through the mobile network. In this event, the location can be obtained from the previous mentioned Cell ID or it can retrieve the actual geographical location by performing a MAP ATI or MAP SRI for SM request using the MSISDN for the user's mobile device which was received in the incoming SMS from the invention JAR file. The invention can then determine the user's approximate location and use this information either prevent the user from continuing the service or to calculate a Risk score that can be used by the invention or forwarded to the Application Service Provider.

The Risk score can be, but is not limited to, calculated based on criteria such as the mobile user's location, whether or not the SIM card has recently changed for the user, etc. The Risk score can either be used by the invention Security Manager or be presented to an ASP for further processing.

Registration of "Safe Place"

The invention allows the user of an application running on a mobile device to register one or more "Safe Places" (physical locations) from where the user can perform specific restrictive application tasks. The invention also allows the ASP to register the users "Safe Places". For example in most online banking applications, 2-factor authentication is required by the user to perform specific or sensitive tasks, e.g. to add a beneficiary to an account to allow for quicker payments, or pay a new bill or transfer money to a new beneficiary, or simply to change specific items in the user's profile (e.g. change address, contact details, etc.).

The invention addresses some of the issues around security and usability for the end user to limit the number of times a user needs to authorise a specific tasks that a user can perform through an application running on a mobile device. The invention allows the user to register one or more "Safe Places" which are physical locations from where the user can perform sensitive tasks without additional authorisation actions being required within a mobile application or similar.

The Safe Place could be registered using an application running on the user's mobile device to ensure that the location is accurate at the time of registration. Also the user must use additional authentication methods imposed by the ASP to ensure that the user is legit when registering a location.

The invention would typically, but not limited to, include a Java ARchive (JAR) file that can be, but is not limited to, bundled with the ASPs application. When the user wants to register a "Safe Place", the user would access the ASP application that has been downloaded and installed on the mobile device. The user can select "Add Safe Place" within the menu. The application queries the user if the current physical location should be added as a "Safe Place" for this application. If the user selects to add the current location, the user will be prompted to enter his secure authorisation code or password. This can for example be, but is not limited to, a token generated by a hard token generator, etc. Once the user has been verified by entering the correct authorisation details, the "Safe Place" location is added to the user's list of "Safe Places". The user can store the "Safe Place" using a name that makes sense to the User; for example "Home", "Parents", "Address", etc. The physical location that would be added to the "Safe Place" would typically be retrieved using the GPS device within the mobile handset.

The location can in one embodiment be, but is not limited to, represented in Longitude and Latitude. Alternatively in another embodiment of the invention, the location can be represented using Universal Transverse Mercator (UTM), or in another embodiment by using national grid references, street addresses or postcodes. In another embodiment of the invention, the user can, but is not limited to, be prompted to present an additional authentication factor for each location the user wants to add as a "Safe Place" regardless of what location the user (even a "Safe Place") is in when trying to add new "Safe Places". This is to prevent that if a mobile device is compromised in the user's "Safe Place", that a fraudster cannot add additional "Safe Places" and commit the actual fraud then or at a later date. In another embodiment of the invention, the invention could add additional security measures by performing an additional check on the location of the user's mobile device during the registration process. The GPS location that is obtained and sent from a mobile device could be spoofed or faked using various mobile application solutions like e.g. "LocationFaker" or "Location Spoofer" for IPhone or "Fake GPS" for Android.

The invention would either compare or allow the ASP to be able to compare the GPS location received from the mobile device against the mobile cell location for the same mobile device. The location for the mobile device would be retrieved from the mobile network in the same manner as described above using, but not limited to, either a MAP SRI for SM, MAP ATI or a mobile network operators Mobile Positioning System (refer to Figure 17 - Step 5). If someone where trying to falsely add a "Safe Place" from a location where the user was not physically located, the registration process could deny the user to even register the current location appeared as a "Safe Place" from the mobile device location. In one embodiment of the invention, if during the registration process the GPS location differs significantly from the Mobile Device location (based on the Cell ID or a Location Service), the registration of the "Safe Place" may not be allowed and the user can be asked to contact the ASP for further information. This functionality is to prevent the user from adding or registering new "Safe Places" without physically being there. It could be that the user would like to add multiple "Safe Places" at one time by using a GPS Location Faker to do everything from one location. This embodiment of the invention would prevent this behaviour.

In another embodiment of the invention, the registration process can be performed by the Application Service Provider. The ASP could for example make the user's home address a Safe Place, this can be, but is not limited to, based on the user's address, or post code, etc.

In another embodiment of the patent, the registration of the user's "Safe Place" can be done by the user through an application, some sort of web interface or a Graphical User Interface (GUI) where there user can for example register one or multiple "Safe Places". The user can for example select "Safe Places" by clicking on locations on a map, or by entering an address or a post code. The invention can either let the user perform the registration of Safe Places without additional authentication factors required to be presented, or it can request further authentication factors to be presented by forcing the user to present an additional authentication factor. In another embodiment of the patent, the additional authentication code could be to the user's mobile device using the invention's mentioned USSD communication channel. Alternatively, the invention could request the user to enter an additional authentication factor by requesting it through USSD.

Once a mobile application user has registered a "Safe Place" using the invention security service, the invention can potentially (depending on the configuration and ASP) allow the user to perform sensitive or restrictive tasks without the need for entering the 2-factor authentication manually. The 2 factor authentication is then achieved by the possession factor (something the user has - the mobile device) and also the knowledge factor (something the user knows - the location the user is in which is registered as a "Safe Place"). The invention provides an authentication process with reduced friction. The main purpose for this part of the invention is to allow the user of the ASP application to have a more frictionless login into the application. This could for example be that the username and password is saved within the application running on the mobile device. This would allow the user to open up the ASP application without having to enter a user name and password. This scenario would of course be open to fraud and security risk. If a fraudster for example stole the mobile device from a legit application user, the fraudster can open the application and perform any task that is available to the user without the need to enter additional authorisation details. If more sensitive tasks are required to be done, the user could be required to present an additional authentication credential. Password Secure over USSD

If further authentication is required, the invention also includes a mechanism for securely delivering and collecting the username and password from a Mobile device using USSD as the bearer. In this event, the mobile application user would receive a request to enter a username and password on the mobile device.

The USSD Request would be sent securely over SS7 directly to the mobile handset and will appear in the forefront of all applications on the mobile device. Once the user enters the required authentication credentials, e.g. username and password, and clicks for example "Send" or "Enter", the credentials (e.g. username/password) is sent back to the ASP application server via the invention's Security Manager.

As described previously, USSD is fast and responsive, and uses the signalling network (SS7) as the communication channel. Although USSD traffic is also going through the mobile network, the data is sent through the signalling network and is using separate channel to the other traffic going between the mobile application and the ASP. So even though it is not device separation in true sense, it is more secure than sending the authentication details via SMS from a mobile device that might be compromised by malware.

Referring to Figure 17, the invention allows the ASP to use the invention to request a further authentication factor by collecting the information through USSD. Referring to Figure 17 (Step 8), the ASP can depending on the Risk Score received or other factors determine that an additional authentication factor is required. The ASP then send a request to the invention Security Manager to request an additional authentication factor. Either the ASP can store the settings of which password method to use, or the settings can be stored in the mobile application by the user, or alternatively the settings can be stored in the invention. The invention Security Manager receives the request from the ASP. The request can, but is not limited to, either include the session ID and the invention Security Manager can do the mapping from Session ID to the user's MSISDN or the ASP can send down the MSISDN in the request again.

Referring to Figure 17 (Step 9), the USSD component in the invention Security Manager sends a USSD Request to the user via a USSD Gateway in the Mobile Network. Alternatively, the USSD Gateway can be provided by a 3PP that is integrated with the Mobile Network Operator (MNO). The USSD Gateway forwards the request to the user's mobile device. As USSD is a session-oriented protocol, the session to the user's mobile device is kept open until closed down or times out. Referring to Figure 17 (Step 10), the user is prompted to enter a secure PIN or password in the USSD menu of the mobile device. The user enters the required details and sends the information back.

The USSD Response is received in the USSD Component in the invention Security Manager and is then forwarded back to the ASP again. The ASP verifies the data received and grants the user access (or not if the user input is incorrect). Local Security Settings for Invention

The invention allows for different security settings to be configured. The following terms are used, but the invention is not limited to these terms;

Auto Login - Auto Login refers to the Application allowing for automatic login to the mobile application without the need for the user to enter a user name and password to gain access.

"Safe Place" - "Safe Place" refers to a physical location that the user has registered as a safe location from where the user can perform sensitive and security related actions through a mobile application without the need to enter additional authorisation details to gain access to a service.

Password method - Password method refers to the method used by the user to enter the user name and password to gain access to a mobile application. If the Password Method is set to "Application" it means that the username/password entry will be prompted to the user through the mobile application. If the Password Method is set to "Secure" it means that the user is prompted to enter the authentication details (e.g. username/ Account ID and password/PIN) through the invention's USSD mechanism described earlier.

The invention includes, but is not limited to, the following examples (not explicitly covered in the figures);

1. Auto Login is set to "Enabled" and "Safe Place" is set to "Enabled" and Password Method is set to "Application"

2. Auto Login is set to "Enables" and "Safe Place" is set to "Disabled" and Password Method is set to "Secure"

3. Auto Login is set to "Enabled" and "Safe Place" is set to "Enabled" and Password Method is set to "Application"

4. Auto Login is set to "Enabled" and "Safe Place" is set to "Disabled" and Password Method is set to "Secure" Examples for each of the configurations listed above and further embodiments of the invention are explained below. Note that the below scenarios are not covered explicitly in any of the Figures, but the general functionality of the below examples are based on Figure 17 and Figure 18:

Scenario 1 (Auto Login is enabled, Safe Place is disabled and password is set to application)

1. User starts the ASP Application on mobile device

2. The mobile application checks the local security settings for the user. The security settings is set by the invention JAR file.

3. The mobile application request a Session ID by sending a getSessionID () to the ASP Application server.

4. The ASP Application server returns a Session ID to the mobile application. The Session ID is controlled by the ASP Application Server in the ASP network.

5. (a) The mobile application then attempts to perform an automatic login by sending a doAuthLogin (Session ID) to ASP Application server.

5. (b) At the same time the mobile application calls the doAuth (sessionID, ASP ID) class in the Invention JAR file that is bundled with the mobile application.

6. The invention JAR file gets the GPS location of the mobile device (prerequisite that the mobile device has a built-in GPS device). The location can for example be represented, but not limited to, by longitude and latitude. This GPS location check can be disabled to ensure that any privacy restrictions are breached.

7. The invention JAR file sends an SMS message to the mobile network with the SessionID, the

ASP ID and the GPS location to the invention Security Server. The SMS is sent to a short number to prevent potential hijacking of the SMS message.

8. The mobile network forwards the SMS message based on the short number to the invention

Security Manager with the Session ID and ASP ID

9. The invention Security manager writes the session ID, ASP ID and GPS location into a table.

Table can be stored either in the invention Security Manager, or in the ASP Application server.

10. The doAuthLogin (step 5a) will continually check the above table to see if the session ID is present.

11. Once the Session ID can be matched by the doAuthLogin (Session ID), the device factor is confirmed (something that the user has).

12. The invention Security Manager will then retrieve the location of the mobile device from the mobile network by sending either, but is not limited to, a MAP SRI for SM (Send Routing Information for Short Message) or a MAP ATI (Any Time Interrogation) request. Alternatively, the location can be obtained using a mobile positioning service from the mobile network operator.

13. The mobile network responds with the location of the mobile device to the invention security manager. The location can be in the form of a cell ID that can be mapped to a latitude or longitude location or the mobile network operator can provide the actual longitude and latitude directly.

14. The invention Security Manager compares the GPS location retrieved from GPS device in mobile device (step 6) and location retrieved from the mobile network (step 12 & 13). If the two locations differs significantly, there is a potential risk that the user is a fraudster. The invention

Security manager also performs other checks, e.g. if the user has performed a SIM swap (not covered in this patent application). Based on this information, the invention Security Manager calculates a Risk Score for example between 0 and 1000 and sends this Risk Score together with Reason Code, Session ID, Mobile Number, UID and AC to the ASP Application Server.

15. At this point the ASP Application server knows, based on the received Risk Score, if the user is calling from the registered mobile phone (MSISDN), registered Safe Place (location), etc.

16. The ASP Application will send a response to the mobile application indicating that the auto login is OK and to allow the user to gain access.

17. The mobile application will display the default page for the user.

18. The user will then try to perform a sensitive task within the mobile application that requires 2 factor authentication. A sensitive task can for example be that the user wants to add a beneficiary within an online banking application, or pay a bill using an online banking application.

19. The mobile application sends a PerformSensitiveTask (Session ID, ASP ID) to the ASP Application Server.

20. The ASP Application server checks if the 2 factor authentication criteria is met for this session

ID. In this scenario, Safe Place is disabled and password is set to "Application" (meaning that the user can enter the authentication credentials within the mobile application).

21. The ASP Application server sends a request to the mobile application to prompt the user to enter the authentication credentials, e.g. username and password.

22. User enters the correct authentication credentials in the mobile application.

23. The mobile Application sends the credentials along with the session ID to the ASP Application server

24. The ASP application server checks the credentials against what is stored in the secure database.

25. The credentials are correct and the ASP application server send a response to the mobile application that 2 factor authentication is achieved and allows the user to perform the sensitive task.

Scenario 2 (Auto Login is enabled, Safe Place is disabled and Password is set to Secure)

1. User starts the ASP Application on mobile device

2. The mobile application checks the local security settings for the user. The security settings is set by the invention JAR file.

3. The mobile application request a Session ID by sending a getSessionID () to the ASP Application server.

4. The ASP Application server returns a Session ID to the mobile application. The Session ID is controlled by the ASP Application Server in the ASP network.

5. (a) The mobile application then attempts to perform an automatic login by sending a doAuthLogin (Session ID) to ASP Application server.

5. (b) At the same time the mobile application calls the doAuth (sessionID, ASP ID) class in the Invention JAR file that is bundled with the mobile application.

6. The invention JAR file gets the GPS location of the mobile device (prerequisite that the mobile device has a built-in GPS device). The location can for example be represented, but not limited to, by longitude and latitude. This GPS location check can be disabled to ensure that any privacy restrictions are breached.

7. The invention JAR file sends an SMS message to the mobile network with the SessionID, the ASP ID and the GPS location to the invention Security Server. The SMS is sent to a short number to prevent potential hijacking of the SMS message. 8. The mobile network forwards the SMS message based on the short number to the invention Security Manager with the Session ID and ASP ID

9. The invention Security manager writes the session ID, ASP ID and GPS location into a table.

Table can be stored either in the invention Security Manager, or in the ASP Application server. 10. The doAuthLogin (step 5a) will continually check the above table to see if the session ID is present.

11. Once the Session ID can be matched by the doAuthLogin (Session ID), the device factor is confirmed (something that the user has).

12. The invention Security Manager will then retrieve the location of the mobile device from the mobile network by sending either, but is not limited to, a MAP SRI for SM (Send Routing

Information for Short Message) or a MAP ATI (Any Time Interrogation) request. Alternatively, the location can be obtained using a mobile positioning service from the mobile network operator.

13. The mobile network responds with the location of the mobile device to the invention security manager. The location can be in the form of a cell ID that can be mapped to a latitude or longitude location or the mobile network operator can provide the actual longitude and latitude directly.

14. The invention Security Manager compares the GPS location retrieved from GPS device in mobile device (step 6) and location retrieved from the mobile network (step 12 & 13). If the two locations differs significantly, there is a potential risk that the user is a fraudster. The invention

Security manager also performs other checks, e.g. if the user has performed a SIM swap (not covered in this patent application). Based on this information, the invention Security Manager calculates a Risk Score for example between 0 and 1000 and sends this Risk Score together with Reason Code, Session ID, Mobile Number, UID and AC to the ASP Application Server.

15. At this point the ASP Application server knows, based on the received Risk Score, if the user is calling from the registered mobile phone (MSISDN), registered Safe Place (location), etc.

16. The ASP Application will send a response to the mobile application indicating that the auto login is OK and to allow the user to gain access.

17. The mobile application will display the default page for the user.

18. The user will then try to perform a sensitive task within the mobile application that requires 2 factor authentication. A sensitive task can for example be, but is not limited to, that the user wants to add a beneficiary within an online banking application, or pay a bill using an online banking application.

19. The mobile application sends a PerformSensitiveTask (Session ID, ASP ID) to the ASP Application Server.

20. The ASP Application server checks if the 2 factor authentication criteria is met for this session ID. In this scenario, Safe Place is disabled and password is set to "Secure". (Secure means that the authentication credentials will be collected from the mobile user using USSD as the bearer.)

21. The ASP Application Server sends a getPasswd (sessionID) to the invention Security Manager 22. The invention Security Manager looks up the MSDISN for the session ID and issues an USSD

Request over, but is not limited to, HTTP/HTTPS to the mobile network.

23. The mobile network sends a USSD Request message to the user's mobile handset prompting the user to enter the authentication credentials, for example a username and password, or selected digits from a secure access code, or similar.

24. The user enters the authentication credentials in the USSD menu on the mobile device. At this point the user is not able to perform any other tasks on the mobile device. If another task is performed, the USSD session will end.

25. The mobile phone sends the authentication credentials back to the mobile network in a USSD

Response message

26. The mobile network routes the USSD Response back to the invention Security Manager

27. The invention Security Manager sends it to the ASP Application server, which then authenticates the user provided that the authentication credentials are correct. 28. The ASP Application server allows the user to perform the task through the mobile application.

Scenario 3 (Auto Login is enabled, Safe Place is enabled and password is set to application)

1. User starts the ASP Application on mobile device from a location that is registered as a "Safe Place".

2. The mobile application checks the local security settings for the user. The security settings is set by the invention's JAR file.

3. The mobile application request a Session ID by sending a getSessionID () to the ASP Application server.

4. The ASP Application server returns a Session ID to the mobile application. The Session ID is controlled by the ASP Application Server in the ASP network.

5. (a) The mobile application then attempts to perform an automatic login by sending a doAuthLogin (Session ID) to ASP Application server.

5. (b) At the same time the mobile application calls the doAuth (sessionID, ASP ID) class in the Invention JAR file that is bundled with the mobile application.

6. The invention JAR file gets the GPS location of the mobile device (prerequisite that the mobile device has a built-in GPS device). The location can for example be represented, but not limited to, by longitude and latitude.

7. The invention JAR file sends an SMS message to the mobile network with the SessionID, the ASP ID and the GPS location to the invention Security Server. The SMS is sent to a short number to prevent potential hijacking of the SMS message.

8. The mobile network forwards the SMS message based on the short number to the invention Security Manager with the Session ID and ASP ID.

9. The invention Security manager writes the session ID, ASP ID and GPS location into a table.

Table can be stored either in the invention Security Manager, or in the ASP Application server.

10. The doAuthLogin (step 5a) will continually check the above table to see if the session ID is present.

11. Once the Session ID can be matched by the doAuthLogin (Session ID), the device factor is confirmed (something that the user has).

12. The invention Security Manager will then retrieve the location of the mobile device from the mobile network by sending either, but is not limited to, a MAP SRI for SM (Send Routing Information for Short Message) or a MAP ATI (Any Time Interrogation) request. Alternatively, the location can be obtained using a mobile positioning service from the mobile network operator

13. The mobile network responds with the location of the mobile device to the invention security manager. The location can be in the form of a cell ID that can be mapped to a latitude or longitude location or the mobile network operator can provide the actual longitude and latitude directly.

14. The invention Security Manager compares the GPS location retrieved from GPS device in mobile device (step 6) and location retrieved from the mobile network (step 12 & 13). If the two locations differs significantly, there is a potential risk that the user is a fraudster. The invention Security manager also performs other checks, e.g. if the user has performed a SIM swap (not covered in this patent application). Based on this information, the invention Security Manager calculates a Risk Score for example between 0 and 1000 and sends this Risk Score together with Reason Code, Session ID, Mobile Number, Location, UID and AC to the ASP Application

Server. The location can also be stored in the invention Security Manager.

15. At this point the ASP Application server knows, based on the received Risk Score, if the user is calling from the registered mobile phone (MSISDN), registered Safe Place (location), etc.

16. The ASP Application will send a response to the mobile application indicating that the auto login is ok and that the user can gain access to the service.

17. The mobile application will display the default page for the user 18. The user will then try to perform a sensitive task within the mobile application that requires 2 factor authentication. A sensitive task can for example be that the user wants to add a beneficiary within an online banking application, or pay a bill using an online banking application.

19. The mobile application sends a PerformSensitiveTask (Session ID, ASP ID) to the ASP Application Server.

20. The ASP Application server checks if the 2 factor authentication criteria is met for this session ID. In this scenario, Safe Place is enabled.

21. The ASP Application checks if the current location matches the registered Safe Place location.

22. In this scenario the current location of the mobile device matches the registered location, so 2 factor authentication is achieved. The knowledge factor is now OK, since we know that the user is in a registered location.

23. The ASP application server send a response to the mobile application that 2 factor authentication is achieved and allows the user to perform the sensitive task. Scenario 4 (Auto Login is enabled, Safe Place is enabled, Password is set to Secure)

1. User starts the ASP Application on mobile device

2. The mobile application checks the security settings for the user

3. The mobile application sends a getSessionID () to the ASP Application server. The ASP Application server returns a session ID to the mobile application.

4. (a) The mobile application sends a doAuthLogin () to ASP Application server located in the ASP network.

4. (b) At the same time the mobile application calls the doAuth (sessionID, ASP ID) class in the Invention JAR file that is bundled with the mobile application.

5. The invention JAR file gets the GPS location of the mobile device (prerequisite that the mobile device has a built-in GPS device)

6. The invention JAR file sends an SMS message to the mobile network with the sessionID and ASP ID. The SMS is sent to a short number to prevent potential hijacking of the SMS message.

7. The mobile network forwards the SMS message based on the short number to the invention Security Manager with the Session ID and ASP ID

8. The invention Security Manager will retrieve the location of the mobile device from the mobile network by sending either, but is not limited to, a MAP SRI for SM (Send Routing Information for Short Message) or a MAP ATI (Any Time Interrogation) request. Alternatively, the location can be obtained using a mobile positioning service from the mobile network operator.

9. The mobile network responds with the location of the mobile device to the invention security manager. The location can be in the form of a cell ID that can be mapped to a latitude or longitude location or the mobile network operator can provide the actual longitude and latitude directly.

10. The invention Security Manager uses the received location information (GPS location retrieved from GPS device in mobile device and location retrieved from the mobile network) along with other checks like SIM swap (not covered in this patent application) to calculate a Risk Score for example between 0 and 1000 and sends this Risk Score together with Reason Code, Session ID, Mobile Number, UID and AC to the ASP Application Server.

11. At this point the ASP Application server knows, based on the received Risk Score, if the user is calling from the registered mobile phone (MSISDN), registered Safe Place (location), etc.

12. The user then tries to perform a sensitive task from the mobile application. The mobile application sends a PerformSensitiveTask (Session ID, ASP ID) to the ASP Application Server

13. The ASP Application server checks if the required authentication criteria is met for this session ID. In this scenario secure password is enabled, so the user needs to be authenticated.

14. The ASP Application Server sends a getPasswd (sessionID) to the invention Security Manager 15. The invention Security Manager looks up the MSDISN for the session ID and issues an USSD

Request over, but is not limited to, HTTP/HTTPS to the mobile network. 16. The mobile network sends a USSD Request message to the user's mobile handset prompting the user to enter the authentication credentials, for example a username and password, or selected digits from a secure access code, or similar.

17. The user enters the authentication credentials in the USSD menu on the mobile device. At this point the user is not able to perform any other tasks on the mobile device. If another task is performed, the USSD session will end.

18. The mobile phone sends the authentication credentials back to the mobile network in a USSD Response message

19. The mobile network routes the USSD Response back to the invention Security Manager 20. The invention Security Manager sends it to the ASP Application server, which then authenticates the user provided that the authentication credentials are correct.

21. The ASP Application server allows the user to perform the task through the mobile application.

One of the main advantages this embodiment of the invention is to reduce friction for the user and at the same time provide a secure method for a user to access a mobile application providing a service, e.g. an mobile banking application, without compromising the user's and the application service providers security requirements.

The various embodiments of the invention described above works independently of mobile device type / handset type used, and utilises the mobile network to obtain an identifier (or ID) for the mobile device using a separate communication channel (using the signalling part of the mobile network) to where the data is sent between the mobile application and the application server. The invention uses the most secure part of the mobile Core network to collect the required information, and as a consequence if any part of the mobile core network is compromised in any way or form, the mobile network operator will have great visibility of this compared to individual security certificates (e.g. PKI) being compromised. It is far more difficult to compromise a mobile network than a mobile device. A mobile device can in theory be compromised by malware that is listening to user's entries on the mobile device. The same cannot be achieved in a mobile network. In further embodiments of the invention, the communication channel between the application on the mobile device and the Application Service Provider (ASP) can be over a mobile Internet utilising the mobile network as internet access point instead of for example WIFI. Referring to Figure 18, the embodiments of this invention also applies to the use of the mobile Internet. All the required network nodes required by the Mobile Network Operators are not explicitly described in the figure, but the invention applies to all current and future technologies that enables mobile Internet traffic - 2G, 2.5G, 3G/WCDMA, 4G/LTE, and 5G.

When the mobile Internet is used for traffic, the various embodiments of the invention can be used in conjunction to provide a complete secure authentication and communication channel. For example, mobile device identity authentication can be used, but is not limited to, in conjunction with the Private Data Network routing based on APN's using dedicated GGSNs to provide private access points into an ASP network.

Public Key Infrastructure (PKI)

Users of an essentially unsecure public network such as for example the Internet can use a PKI (Public Key Infrastructure) to securely and privately exchange data through the use of public -key cryptography (the use of a public and a private cryptographic key pair), that is obtained and shared through a trusted authority. Thus PKI provides for a digital certificate and provides an infrastructure for creation, management, distribution, use, storage, and revocation of such digital certificates and enables reliable verification of the identity of a user via such digital certificates. Thus for service providers on the fixed Internet where users are essentially anonymous, the PKI infrastructure allows a service provider verify with a recognized trusted authority (for example Verisign) if the digital certificate provided by a user is one that has been issued by the trusted authority, and if their identity can indeed be trusted.

The invention also provides reliable verification of the identity of a user. Advantageously the invention does not require PKI infrastructure (nor associated cryptographic techniques) to be realised in the mobile domain to achieve this. Such PKI infrastructure would involve significant investment and technical challenges for Mobile Network Operators (MNOs) including but not limited to the secure distribution of private keys, secure certificate storage, potentially mobiles requiring SIM cards supporting PKI, etc.

In the context of the invention a mobile network operator can be considered to be equivalent to a certificate authority (in PKI infrastructure). An MNO having gone through stringent regulatory processes to obtain a licence can be viewed as a trusted entity in itself. Further the identity that a mobile network operator manages and issues are numbers that are not created by them but are issued as number ranges to the MNO by the regulatory authority in the country in which the MNO is operating in, and thus implicitly the number identity has backing by a very trustworthy entity, and thus a very high associated trust and inherent certitude. The security and other controls that the operator enforces before and after issuing a mobile number are very stringent, including rigorous identity checks (for example photo ID, multiple utility bills, sometimes social security number) coupled with credit checks and checks associated with subscription longevity such as historical usage checks, with non-payment or non-use of mobile services resulting in potential loss of number, and can be at least considered comparable to if not greater than what a certificate authority enforces when issuing and managing a digital certificate. Thus the initial trust factor is very high as regards identity and mobile number in a mobile network, with very secure processes behind provisioning new customers for the MNO. This coupled with continued business use, and the subscription of the mobile customer to the mobile number, their mobile account, reinforces the customer identity, notwithstanding all of which, as already described such identity can be compromised by parties such as fraudsters. However when the initial trust is complemented by the invention providing risk management including risk management around identity (which can also be on request), subsequent to all the initial processes that are involved in issuing a mobile number, when the invention has verified the identity then a high trust can be associated with the identity, with the invention providing (which can also be on request) real or near real time identity verification (analogous for example to a certificate authority providing means for reliably verifying user identity in a PKI environment).

Essentially a core aspect of the invention provides a means for complementing initial trust with ongoing repeatable identity trust verification and affirmation. This is a key requirement for application service providers who wish to have an initial and ongoing trust profile of entities who are using their services. Thus ASPs need to be able to validate if the service user (for example mobile device) is the same service user (that they are purporting to be) that used the services provided by the ASP previously. In this way a trust business relationship can be built up over time between for example an ASP and a user (for example mobile device) by the invention providing the ASP with reliable risk management including risk profile and risk score around the user's identity.

Thus in the context of the invention, in terms of identity, one can consider the trust and certitude associated with a mobile phone number to be at least comparable to if not greater than the trust associated with identity in the context of a digital certificate, and advantageously without requiring PKI infrastructure (or associated cryptographic techniques).

The network security service of the invention also advantageously allows the ASP to be trusted because as already described, an ASP ID is issued to the Application Service Provider (ASP) by the network security service to uniquely identify that individual Application Service Provider (ASP) and in order to route information to the ASP.

Thus for example if a mobile device has the security agent installed (which can be standalone or an adjunct security module bundled with another application) and is communicating with an ASP in an MNO which has the network security service of the invention integrated, then not only does the invention enable the device to be trusted, but as described since the ASP has a trusted relationship with the security service of the invention, then the invention enables the ASP to be trusted also. Thus for an MNO which has the network security service of the invention integrated, both parties in this embodiment, the end point device and the ASP can have a common trust in the MNO and thus in each other, and the invention effectively allows the MNO to be viewed with at least as much authoritative trust as a trusted certificate authority.

As already described a PKI infrastructure allows a service provider verify with a recognized trusted authority if the digital certificate provided by a user is one that has been issued by the trusted authority, and if their identity can indeed be trusted.

And as already discussed and described in the context of the invention a mobile network operator can be considered to be equivalent to a certificate authority (in PKI infrastructure).

The security service of the invention can advantageously be used to assure and demonstrate to a B party (for example a customer) that a calling party (an A party) for example an ASP contacting a B party (for example a customer agent in an ASP such as a mobile banking service provider originating a call to a customer) is whom they purport to be, is a secure calling party number, by providing reliable verification of the identity of a calling party which verification can also be made available to a B party.

Thus for example a service provider such as a banking service provider which offers services including mobile banking services, may register a number (such as for example a pilot number) and the name of the service provider with a mobile network operator. The mobile network operator can employ stringent procedures which must be adhered to, in order to allow registration of such a number to an application service provider. The mobile network operator has the network security service of the invention deployed. In an alternative embodiment the application service provider, may register a number and the name of the application service provider with the network security service. In yet a further embodiment the ASP may register the number and the name of the ASP with both the mobile network operator and the network security service.

The invention includes a security agent (for example an app) installed on at least one device (which can be standalone or an adjunct security module bundled with another application), and communicates with the network security service. The app can also be associated with the mobile network operator and used for communication with them.

Thus in one embodiment when a party is calling a user, the call is routed via (or metadata from the call is provided to) a network security service, and routed straight onto the destination. The security service automatically carries out its risk analysis (as already described earlier), based on the A party number, (the security service can also perform risk analysis on the destination number, the B party, and the associated risk scoring profile for the destination number can also play a role in the final risk score). As part of the risk analysis the network security service performs a lookup to establish if the A party number is registered (for example as an ASP, for example a banking service provider) and retrieves the name (for example of the ASP) registered against the number. The lookup can be an internal lookup within the network security service or can be in communication with an external entity (such as a network element), or a combination of an internal and external lookup. The result of the lookup can influence the risk score. The network security service can initiate communication with the B party (for example send a secure notification to the B party device). Various embodiments are possible for communication (regarding whether a calling party such as an ASP is registered with the mobile network operator and/or the network security service) between the network security service and the security agent (e.g. app), including for example USSD, SMS, or any secure method on SS7, or alternative means. If the calling party is registered the network security service can communicate the calling party name (for example ASP name), as well as the calling party number (and the called party number) securely to the app on the B party device. The app on the device can then display the calling party name (for example ASP name and optionally also display the associated number) on the device to the device user, for example flash up "secure call" and the associated calling party name (for example ASP name) on the device screen, and/or an icon associated with the calling party (for example ASP) or the mobile network operator or the network security service etc., and since the network security service has verified that the calling party number (for example ASP number) has been registered with a name (for example an ASP name) with the mobile network operator, or the network security service or both, the B party can have a high degree of confidence that the calling party are whom they purport to be.

If the calling party (for example ASP) is not registered with a name the network security service can communicate this to the app on the B party device (along with the A party number and B party number), which can result in a message being displayed to indicate that the calling party number (for example ASP number) is not registered with a name (for example an ASP name). As described the network security service of the invention can originate communication with the B party device when a call is originated (for example send a secure notification to the B party device), or in an alternative embodiment when the B party device receives a phone call, the security agent (e.g. app) can send a request to the network security service (for example via secure means such as an SS7 connection or a data connection or other communication means) requesting the current call details, including the registered name (for example ASP name) of the A party number, which the network security service (on being satisfied of the identity of the requesting party) can provide (with such details including the A party number and associated name and B party number) in a response if available. As with the embodiment where the network security service originates the communication (which could for example be a secure notification), if such a registered name (for example ASP registered name) is available the app on the device can then display the calling party name (for example ASP name and optionally also display the associated number), and the B party can have a high degree of confidence that the calling party are whom they purport to be, or if the calling party (for example ASP) is not registered with a name the network security service can communicate this to the app on the B party device (along with the A party number and B party number), which can result in a message being displayed to indicate that the calling party number (for example ASP number) is not registered with a name (for example ASP name).

Various embodiments are possible for communication (regarding whether a calling party such as an ASP is registered with the mobile network operator and/or the network security service) between the network security service and the security agent (e.g. app), including for example USSD, SMS, or any secure method on SS7, or alternative means. Advantageously the security of this feature can also be enhanced by the fact that the security agent (the app) can also be a secure element, and could for example be a SIM application, i.e. a secure app running on a device SIM card, for example the app could be created within the context of a SIM application toolkit or a USIM Application Toolkit (USAT) or equivalent or on later technologies etc. (which has already been described earlier in this patent disclosure).

Thus the combination of secure and comprehensive registration (with the mobile network operator and/or network security service), secure lookup and verification (by the network security service), secure communication between the network security service of the invention and the security agent (e.g. application) of the invention on the device (for either notification or query and response), fact that the call is coming via the mobile network (which has an inherently high trust certitude and means the call is coming via a secure path) and the fact that the device application displaying the ASP name to the device user is secure, means that in the context of the invention, in terms of identity, one (for example the called party) can consider the trust and certitude associated with the calling party number and name (for example ASP number and name) to be at least comparable to if not greater than the trust associated with identity in the context of a digital certificate, and advantageously without requiring PKI infrastructure (or associated cryptographic techniques).

In an alternative embodiment security agent (e.g. the app) of the invention on the device need not be a SIM application.

Advantageously the invention supports three-factor authentication.

Three-factor authentication is an approach to authentication or the process of verifying someone's identity which requires the presentation of the three authentication factors: a knowledge factor ("something only the user knows"), a possession factor ("something only the user has"), and an inherence factor ("something only the user is"). After presentation, each factor must be validated by the other party for authentication or identity verification to occur.

The invention's support for two-factor authentication using knowledge factor and possession factor (with the something the user has being for example a mobile device), has already been described in detail. The invention's support for biometrics to contribute to secure identity establishment has also been described. By combining two-factor authentication and an inherence factor (with the something the user is, being based on biometric verification) the invention advantageously achieves three-factor authentication. Thus biometric features are among the features that the RMM of the invention can employ to contribute to risk score and in building up a profile of the user over time. Thus for example voice biometrics (i.e. voice recognition/authentication) could be employed either directly integrated with the invention, or the result of voice recognition analysis in the network (for example biometric IVR such as IVR voice authentication in the network) can be provided as an input to the RMM which can then be used to influence the risk score as a contributor in combination with all the other risk factors that the RMM has available. Thus for example if as part of the criteria for a user is being permitted to use an application on a device, the application (e.g. integrated with the security agent of the invention) could request the device user to repeat a particular sentence for voice biometrics analysis, which the biometrics analysis the user would have to pass in order to use the application.

Any suitable bio-metric factors can be employed including for example fingerprinting (if the device had a fingerprint reader), or facial scan/recognition (for example the security agent on the device could take a photograph of the user), or iris scan, with the application on the device having the ability to ingest the data associated with such bio-metric features, and with such features, or the results of analysis of such features being provided as input to the security agent of the invention on the device, and/or to network elements (which can perform biometric analysis), and/or to the RMM which can then be used to influence the risk score.

Advantageously the RMM is not relying solely on a relatively new technology such as biometrics in order to compute the risk score, but rather as already outlined biometric features can be used in conjunction with other factors available to the RMM of the invention, including those centring around identity such as those already described, including those that associate a user with a particular device (e.g. mobile phone in a mobile network), for example features that establish with high likelihood that a particular user is making a call from a particular device.

The scope of the invention's application of three factor authentication is not limited to but includes verifying and providing secure identity and risk management including risk management associated with identity, for many heterogeneous services and communications including inbound and outbound messaging (such as SMS), inbound and outbound data (such as mobile data), and inbound and outbound voice services (such as voice calls, including multi-party calls) such as for example to/from a service provider, and also includes, scenarios where the user is using their phone as a mobile WiFi hotspot.

The invention applies to all variants of mobile network standards/technologies/ environments and their associated families such as CDMA/3GPP2 family of standards/technologies/environments (for example IS-95/CDMA 2000 lxRTT/CDMA 2000 lxEV-DO/CDMA2000 lxEVDV, etc.), GSM/2G/2.5G/3G/3GPP/4G/5G family of standards/ technologies/environments (for example GPRS, EDGE, UMTS etc.) and beyond including more modern variants such as for example 3GPP IMS or 3GPP LTE/LTE Advanced/4G or 5G or WiMAX/ WiMAX -advanced networks/standards/

technologies/environments, and including hybrid networks/standards/technologies/

environments and future networks/standards/ technologies/environments, and applies also to fixed line such as wireline. The scope of the invention as well as applying to IP networks and any networks involved in packet communication also includes any access networks/standards/technologies/environments such as WiFi, WiMAX, WiMAX-advanced, DSL, Cable etc. or hybrid or variant networks/standards/technologies/ environments or any combination of networks/standards/technologies/ environments, for example WiFi/WiMAX accessing a mobile or fixed (for example cable) network, or any future networks/standards/ technologies/environments.

Depending on the mobile network technology the invention works in a technology environment where the radio access elements can be for example BTS (GPRS) and BSC (GPRS), NodeB (UMTS/WCDMA), or enodeB (LTE) or any other appropriate radio access elements.

Only some mobile network elements are depicted in the figures, and although the invention embodiments are described with reference to network nodes being involved such as SGSNs and Gateway GPRS Support Nodes (GGSN), the invention works equally with alternative nodes such as a PDN Gateway (PGW) and depending on the mobile network technology used, with other core mobile network elements being applicable for example MME (LTE), SGW (LTE), PGW (LTE) or any other appropriate elements.

As is clear from the descriptions of the various embodiments, advantageously the invention lends itself to ease of system integration, requiring minimal or no changes in existing elements in order to integrate the invention (for example in some embodiments requiring only small configuration changes to existing network elements, while in other embodiments no changes may be required), and being able to operate with information that is readily available, such as existing protocol information elements (for example A and B calling party information), or with small changes to protocols that are readily extensible (for example SIP header additions). Thus advantageously, in the context of the network security service of the invention (for example in one embodiment an IMS/SIP enabled service) communicating with an ASP via an IMS network, identifiers such as A party and B party identifiers (such as in the case for example of a user on a device, a MSISDN or UID, and in the case for example of an ASP, an ASP ID or number), as well as other pertinent metadata can be passed in SIP responses and/or SIP requests according as the information is available, for example passed in SIP headers (such as for example in SIP response headers and/or in SIP request headers as available).

The security manager of the invention (refer to Figure 2) can be embodied in the network security service of the invention, or the network security service can be embodied in the security manager, or both entities can be separate and exist independently. Both the security manager and the network security service can inter communicate and leverage functionality and means from each other.

The invention is not limited to but applies to any type of device involved in IP communication or other network communication. Devices on which the security agent can be installed include any mobile device such as a phone (for example smart phone) or tablet, phablet, laptop, wearable technology (e.g. glasses, watch etc.) but also includes any smart device such as Smart TVs, Satellite TV set top box, Game Consoles (for example Wii, Xbox, Windows Media Center etc.), Car, etc., and any IP connected device. The scope of the invention includes M2M or embedded mobile devices and what is being increasingly referred to as emerging devices or embedded devices and further what is referred to as the Internet of Things (IoT) i.e. devices which have IP connectivity whose connectivity can be via access networks, mobile or fixed networks or any combination of such.

The invention supports all device identifiers and all methods of addressing devices, including Mobile IP addressing methods (IPV6), in addition to IPV4, etc. Examples (non-limiting) of identifiers which the invention supports include device identifiers which may also be considered as subscriber identifiers such as a MSISDN, MDN, IMSI, etc., or more formal device identifiers such as an IMEI, ESN or MEID, etc. The invention can endeavour to discover the relationship between an available identifier and other identifiers, by communicating with one or more operator network elements such as an operator's HLR (or HSS) to lookup identification information for example such as the IMSI, or alternatively as described if an IP address identifier is available the invention could query a RADIUS server to obtain an identifier such as a MSISDN.

Other identifier examples which can be available to the invention include ICCID (with the relationship between this and other identifiers such as the IMSI being obtainable via HLR interrogation), URI, IMPI (which can be for example a SIP URI or a TEL URI), TEL URI can for example contain an E.164 number or private number, Fully qualified Domain Name (FQDN), Network Access Identifiers (NAI), IP address V4, IP address V6 etc. For example in the case of a SIP URI, the mapping between this and a particular IMSI or IMPI is obtained for example via HSS (which in many embodiments may be co-located with HLR) interrogation, in networks which support SIP or IMS, and thus can be made available to the network security service of the invention.

The invention includes all types of messaging communications within scope, including and not limited to SMS (as already described), and also applies to any messaging on an IP channel for example IM (including any proprietary Instant messaging protocol), SIP based messaging, MMS, push services (can be proprietary and also not limited to but including examples such as Apple Push Notification Service, Google Android Cloud to Device Messaging (C2DM) service etc.), Over The Top (OTT) messaging services/providers (such as Apple iMessage, BlackBerry Messenger, WhatsApp, Skype, Facebook Messenger, Google Talk, KakaoTalk, Viber, etc.) etc. The invention also applies as described to ESME traffic such as SMPP traffic, including intelligent routing of such traffic. The invention includes performing or contributing to ASP policy control.

Multi-Person Authentication and Authorisation

Another embodiment of the invention relates to a scenario where a transaction request requires authentication and authorisation from multiple (two or more) people as illustrated in Figure 19. This could for example, but is not limited to, be a joint account in a financial institution that is shared by 2 or more persons. It is common practice for joint accounts that at least two persons need to authorise a transaction before a transaction can take place for that account. The scenario could also include for example, but is not limited to, a husband and wife sharing a join savings account where both parties require to authorise any transaction, or it could be a business account where it requires at least two of the partners to authorise a transaction. For simplicity, when referring to a second person, this refers to the person that must provide the final approval of a transaction. A second person can refer to one or more persons, but for simplicity the description is limited to one additional approver. In another embodiment, the invention allows for either one person or both persons not to be present in a common location for example, but not limited to a bank or financial institution, when authorising a transaction. In another embodiment both parties could be in different geographical locations and interact with a third party, i.e. a bank, located in a third location either using an online banking service, a mobile banking application or similar. In another embodiment, one person could be located together with the third party (for example if one person was in a bank to perform a transaction) and the second person could be in a different location. The invention allows for secure authentication and authorisation of a transaction (for example, but not limited to, a financial transaction) by utilising the invention to gain acceptance from the second person. In any scenario where a transaction requires approval from one or more additional parties, the invention can be used to identify and authenticate the second person by using the mobile device as a possession factor (something only the user has) and/or in combination with using the location of the second person as a knowledge factor (something only the user knows).

The invention also covers a scenario where for example a bank account or a credit card is owned by for example a company where multiple persons have access to the a company account or to use the credit card associated with the company account. In this embodiment, it can be envisaged that any person using the card or accessing the account are employees and all the transactions on this account or credit card must be approved by one person, for example a financial controller or a director, or any combination of additional persons to enhance security even further. The invention could in this scenario be used to gain a trusted signoff of the transaction from a mobile device utilising the features of the invention. Any person using a credit card or attempting to perform a transaction on a credit card or bank account could either do this from a mobile device utilising embodiments of the invention already discussed. The person that attempts to perform a transaction could do this by any means available; within the bank itself, using online banking from a web browser or from a mobile banking application. The main difference in this scenario is that one person does not have sufficient authorisation rights to complete the transaction, so the transaction would require additional approval and authorisation from a second person (or more than one additional person).

Similar to banking applications, the invention could also be used in a vast number of areas such as, but not limited to, parent approval of content purchase from a service provider initiated by a child, or approval of an online purchase when a person (for example child, wife or husband) is using a common household credit card or bank card to make the purchase (for example the card could require either husband or wife to approve, etc.).

The invention can work as a standalone solution or in conjunction with other authentication measures, e.g. entry of username/password or entry of generated token, etc. In one embodiment of the invention, the mobile number for each of the users can be registered with the financial institution or service provider. In another embodiment, the mobile number can be retrieved from the telecommunications network utilising an application running on a mobile device as described in other embodiments of the invention by sending an SMS from the user's mobile device to the invention and obtaining the mobile number from the originating address from the SMS. The invention allows for either one or both persons to be authenticated based on the mobile device. Additional security measures such as utilising the "Safe Place" location described previously can also be added to this embodiment of the invention.

The invention allows for either the application running on the mobile device to trigger the second (or more) approval process, or it can be triggered from the service provider (for example a bank) as well. The invention can be used for both parties (first and second person), or it can be used only to identify and authenticate the second person.

In one embodiment, each of the users of a join account must be registered with a bank or a financial institution or similar. The registration of each user must include a mobile number that is unique to each user and linked to the applicable account. The invention has no limitation on the number of users that can be registered for one account. One or more persons must be registered as users and one or more persons must be registered as approver (referred to as the second person above). The registered users can either reside within the financial institution or within the invention, but the information must be available in a persistent storage that can be accessed by the invention or sent to the invention from the bank or the financial institution.

The invention can be implemented by, but is not limited to, installing an application on a mobile device. The invention can include the complete mobile application or a SW part that can be bundled and/or embedded with the mobile application. The invention can either be installed on both users (or all users linked to the account) mobile device, or it could only be installed on the approver(s) mobile device.

When one user wants to perform a transaction on a joint account, the invention can for example verify the identity of the user based on the same principles that is already explained in the invention. The user is authenticated by querying the telecommunication network for the relevant information, e.g. MSISDN. Since the information is coming from a trusted network - the telecommunications network (for example a mobile network) and not the mobile device itself, the information obtained from the telecommunications network can also be trusted.

The mobile device identity is used as one authentication factor for one of the users (possession factor - something only the user has). In addition, the location of the mobile device at the time of the transaction request can be used as an additional authentication factor, provided that the user had registered the location as a "Safe Place" (something that only the user knows). In addition, the invention would allow for additional authentication factors to be presented by the user.

The mobile application could, but is not limited to, detect from the MSISDN that the following transaction was for a joint account or the mobile application could itself alert the invention that the transaction was for a joint account. The mobile application could be a specific mobile application that only applies to joint bank accounts, and this could be used to send down a specific request to the invention to trigger an additional authentication and authorisation request from one or more additional users.

In situations where you have more than two users, the mobile application could for example allow the first user to select which additional user should authorise the transaction.

The invention would keep a database or persistent storage of all mobile identities or have access to the information from a service provider, e.g. MSISDN, associated with the relevant joint account. Additional users must have a mobile number or similar registered with the invention or have access to the information.

The invention will then obtain the MSISDN associated with the same joint account and query the telecommunications network for various information, e.g. to see if there had been any SIM swap for the MSISDN in question in recent time, and/or the invention could check the location of the second user to ensure that the second user was either in a registered "Safe Place" or in a specific area (address)/post code/region/country, etc. After the invention has performed the necessary checks of the second user's mobile number, as described in other embodiments of the invention, and identified and authenticated the user, a risk score can be calculated by the invention. The risk score can be passed on to a financial institution or it can be used by the invention itself to perform further actions. If the second user had been successfully identified and the identity could be trusted, the invention could present the second user with the information about the transaction that needs to be authorised. For example, the second user could be presented with the following information, but not limited to, on the mobile device (for example, either through the mobile application or through a USSD session towards the second user's mobile device);

Transaction ID (common reference - this can be a session ID from the financial institution or it can be a Transaction ID generated by the invention)

Transaction Date (current date and time of the transaction)

Transaction Value (the value of the transaction)

Transaction Currency (the currency of the transaction, e.g. euro, US Dollar, etc.)

Person Requesting Authorisation (in this case the first user, but if the request was initiated by the bank and not the invention or first user, it could be the bank)

In addition to the presentation of the transaction information, the second user would be asked to authorise the transaction as the person is a joint owner or required approver for the relevant account that requires multi -person approval.

Once the mobile identity of the second user was authenticated by the invention from the mobile network by querying the mobile network and the second user's mobile device was in a location that was registered as a "Safe Place", the second user could be asked to click and "Approve" button within the mobile application, or alternatively be prompted to present additional authentication factor(s), e.g. username/password and/or token generated from a token generator, or enter a token that was communicated to the second user from the invention through a USSD message from the invention.

Alternatively, the invention can send a request for approval or signoff by sending a USSD request to the second user's mobile device. The user would then be prompted via USSD on the mobile device to enter a username/password or a PIN Code or a token generated from a token generator directly in the USSD menu on the mobile device.

Once the second user send the correct approval information back to the invention, the invention can either calculate a risk score that it can forward to the service provider or financial institution so that they can make the final authorisation or rejection of the transaction, or the invention can accept or reject the authorisation request based on the information received.

Provided that both the first user and the second user has been verified correctly either by their mobile device identity and/or the mobile device being in a registered safe location and/or one or both users have presented additional authentication factors, the invention has achieved multi-person authentication for a joint account without requiring both persons to be present in a specific location, e.g. a bank or financial institution. One embodiment of the invention can be further understood from the following example:

1. First user opens a banking application for a joint account on a mobile device that is registered within the invention or within the financial institution.

2. The mobile application connects to the application service provider, in this event a bank or a financial institution.

3. The Application service provider returns a session ID or similar that can be used to identify the current session with the first user.

4. The mobile application triggers the invention by sending a request, either as an SMS message (or an USSD Request) from the mobile device application to the mobile network. Alternatively, the invention could also be triggered by a HTTP/HTTPS request from the mobile application. 5. For this example an SMS message is sent from the application on the mobile device to the mobile network using a short code.

6. The short code routes the SMS message to the invention.

7. The invention receives the SMS from the mobile device and identifies the mobile device from the "Originating Address" in the incoming SMS message.

8. The invention verifies the mobile device by query the mobile network to obtain various information for the relevant mobile number. The invention could for example, but is not limited to, retrieve the following information; International Mobile Subscriber Identity (IMSI), Mobile Subscriber Identity Number (MSIN), Mobile Network Code (MNC), Mobile Country Code (MCC), location Information, etc. The information can be obtained by performing a MAP SRI for SM request or a MAP ATI request on the mobile number.

9. The invention uses the obtained information from the mobile network to confirm identity of the mobile device. The invention has also means to check if the MSISDN has been exposed to a SIM card change recently.

10. The invention calculates a risk score based on the information and sends the risks score to the application service provider along with the session ID and Reason Code or alternatively determines if the first user should gain access or not.

11. In this case, the application service provider grants access to the first user.

12. The first user is now logged into the application on the mobile device. From the mobile application, the first user initiates a monetary transaction to another party, e.g. paying a bill.

13. The mobile application sends the request to the application service provider (or alternatively, this request can be sent to the invention) about transferring money to another account.

14. The mobile application or the application service provider knows that the transaction issued by the first user is for a joint account that requires multi-person authorisation. This could for example be triggered if the amount was over a specific value or similar.

15. The application service provider triggers a request to the invention, or the invention triggers a request itself if initial request was sent to invention, to authenticate and obtain authorisation for a second user for the transaction in question.

16. In this event, a second person was registered for this account, and a mobile number was registered for this second user. The invention checks the second user's registered mobile number in the same manner the first users mobile number was checked in step 8.

17. Based on the information obtained for the second user's mobile phone, the invention calculates a risk score for the second user. It could be that the location of the second user's mobile device is in a country that is deemed unsafe, or the second user could recently have changed SIM card, etc.

18. In the event that second user's mobile device is successfully authenticated, the invention can trigger a USSD request directly to the second user's mobile device requesting authorisation of the current transaction that the first user has initiated.

19. The second user is presented with the relevant information about the transaction in the USSD menu of the mobile device; Transaction ID, Transaction Date, Transaction Value, Transaction

Currency, Name of Person Requesting Authorisation (first user), etc.

20. The second user could be requested to authorise the transaction by entering a username/password combination or a PIN Code or a token from a Token generator into the USSD menu.

21. Once the required information is entered by the second user and the user hits the "send" button (or similar), the authorisation is sent back to the invention.

22. Alternatively to requiring the second user to present an additional authentication factor, the invention could use the location of the second user's mobile device to verify if the second user was in a "Safe Place", allowing the second user to authorise the transaction without the need to present any additional authentication factors.

23. The invention can either perform the relevant action for the transaction itself or it can pass on the authorisation information from the second user to the application service provider (the bank). 24. Based on the received information, the application service provider rejects or accepts the transaction for the joint account and informs the first user via the application.

25. There can be a configurable timeout value for the second user to enter the authorisation confirmation. In most cases, it would be assumed that the first user and second user would communicate so that the second user would expect the authorisation request to be sent to the mobile device.

In an alternative embodiment of the invention the first user could access an application service provider website to, e.g. an online banking website, to request a transaction on a joint account or similar.

In this case, the invention does not have the means to communicate with the first user via the application on the mobile device. The first user could be authenticated by the bank's website through normal authentication procedures, e.g. entry of username and password, entry of a PIN Code that the user knows, entry of a PIN code sent to the first users mobile device (the invention could authenticate the user's mobile before sending it), entry of a token from a token generator, etc.

Once the first user has gained access to the banking website and tries to perform a transaction that requires authorisation from a second user, the invention could use the mobile number that is registered for the second user within the bank.

The service provider (in one example a bank) queries the invention directly by sending all the relevant information, but not limited to, like; Second user's registered mobile number, session ID/transaction ID, Transaction Date, Transaction Value, Transaction Currency and name of person requesting authorisation (first user) to the invention. The invention perform a check on the second user's mobile number within the mobile network as described above.

By querying the mobile network, the invention determines that second person's mobile device is a legitimate device and is in a location that the second user has registered as a "Safe Place". The invention either sends a request to the second user's mobile over SMS or over USSD to confirm that the transaction can be authorised. The second user receives the authorisation request on the mobile device, and replies accordingly with the relevant authorisation or not.

Alternatively, the invention can determine that the second user's mobile device is not deemed safe at this time, for example due to a recent SIM Swap or being outside a "safe place" or just in a general location that is not deemed safe, or mobile device being turned off. In this event, the invention would respond to the service provider (the bank) that second authorisation could not be achieved at this point.

Alternatively, the invention can determine that the second user's mobile is most likely the correct one, but that there are a few question mark over some attributes, in this case, the invention can prompt the second user to present additional authentication factors, either over USSD, or similar.

In another embodiment of the invention, the first user could be physically located in a bank trying to perform a transaction on a joint account. The bank can then achieve all the relevant signoffs and authorisations from the first user within the bank, but require additional authorisation from the second user to complete the transaction.

The bank can then manually trigger the invention by sending a request to the second person from for example a webpage or an application integrated to the invention or part of the invention. The bank would then send the relevant data to the invention to authenticate the second user and also request authorisation for the transaction. The relevant information would be as previously described for other embodiments, but not limited to, be the second user's registered mobile number, session ID/transaction ID, Transaction Date, Transaction Value, Transaction Currency and name of person requesting authorisation (first user) to the invention. The invention perform a check on the second user's mobile number within the mobile network as described above.

Once the authentication check has been completed on the second user's mobile phone by querying the mobile network as above and the location of the second user's mobile device has been verified against a registered "Safe Place" location, the invention can either allow the second user to authorise the transaction through a USSD request sent to the second user's mobile device or by triggering a call to the second user (knowing that at least the mobile device has not been compromised and that the second user is in an expected location). Alternatively, the user can be prompted to open up a mobile application to authorise the transaction. The mobile application can then carry out the same checks as described previously.

Figure 19 illustrates one embodiment of the invention where a person (referred to as "user") initiates a transaction that requires approval from a second person (referred to as "approver"). The user initiates the transaction through a mobile banking application or an online banking website (Figure 19 step 1). The user presents all required authentication credentials and initiates the transaction. The bank detects that any transactions associated with this account requires approval from a second person (the "approver"). The bank initiates a request towards the invention and includes information about the transaction (amount, currency, date, time, and the name of person requesting it) and the registered MSISDN of the approver (Figure 19 step 2). The invention receives the authorisation request and can in one embodiment perform a check on the second person's (the approver's) mobile number to make sure it has not been compromised by for example a SIM swap or similar (Figure 19 step 3). In addition the invention can for example check that the user is in a registered safe location (Figure 19 step 10). Once the invention is satisfied that the mobile device of the approver is legit, the invention can initiate a USSD request to user's mobile phone via a USSD Gateway in the mobile network requesting the approver to enter an authorisation code (for example a PIN Code or a token generated from a token generator) along with information about the transaction that requires approval (date, value, currency, requestor, etc.) (Figure 19 step 4). The approver can enter the required information, and send it back to the invention over USSD, and the invention can pass the entered information back to the bank (Figure 19 step 11).

Alternatively, the invention can on reception of the authorisation request from the bank send a request to the user's mobile device either as an USSD message or an SMS message requesting the approver to start the banking application on the approver's mobile device (Figure 19 step 4). The approver opens the mobile banking application on the mobile device. The mobile application opens a connection to the bank's application server to get a session ID (Figure 19 step 5). Once the session ID has been received by the mobile application, the mobile application calls the embedded JAR file (part of the invention) sends an SMS to mobile network by using a short number used by the invention (Figure 19 step 7, 8 & 9). The SMS is routed to the invention and the user's mobile device is checked and verified by querying the mobile network using a MAP SRI for SM, MAP ATI, or similar operations using the MSISDN received by the invention from the originating address in the incoming SMS (Figure 19 step 3).

The invention can determine that the mobile device information retrieved from the mobile network matches the MSISDN registered with the bank (that was sent down from the bank). The invention can also check that there was no SIM swap for the user's mobile device, and the invention can check the location of the mobile device. Either by querying the mobile network to determine the location or the mobile device (Figure 19 step 10), or by retrieving it from a GPS device on the mobile device itself and sending the information to the invention via the initial SMS triggered by the mobile application (Figure 19 step 6). Alternatively, it can retrieve the location from both the mobile device and the mobile network and compare the location to make sure that both are in close proximity to each other.

Once all relevant checks and risk score calculation have been completed by the invention, the invention sends a confirmation or a risk score to the bank to indicate whether or not the user is allowed access to the mobile banking application or not (Figure 19 step 1 1). In this scenario, the user was allowed access and the bank allows the user (the "approver") to gain access (Figure 19 step 12). In this case, the user was also in a location that was registered as a "Safe Place", so this information was also passed onto the bank. Because both the approver's mobile device has been authenticated (something the user has) and the location of the mobile device is in a registered "Safe Place" location (something that the user knows), the mobile application could allow the approver to authorise the transaction initiated by the user by clicking for example, but not limited to, an "approved" button. Alternatively, in other embodiments of the invention, the approver could be requested to present an additional authentication factor for added security.

The embodiments in the invention described with reference to the drawings comprise a computer apparatus and/or processes performed in a computer apparatus. However, the invention also extends to computer programs, particularly computer programs stored on or in a carrier adapted to bring the invention into practice. The program may be in the form of source code, object code, or a code intermediate source and object code, such as in partially compiled form or in any other form suitable for use in the implementation of the method according to the invention. The carrier may comprise a storage medium such as ROM, e.g. CD ROM, or magnetic recording medium, e.g. a floppy disk or hard disk. The carrier may be an electrical or optical signal which may be transmitted via an electrical or an optical cable or by radio or other means.

In the specification the terms "comprise, comprises, comprised and comprising" or any variation thereof and the terms include, includes, included and including" or any variation thereof are considered to be totally interchangeable and they should all be afforded the widest possible interpretation and vice versa.

The invention is not limited to the embodiments hereinbefore described but may be varied in both construction and detail.