Abstract: Embodiments of the present invention provide systems and methods of generating a secure transaction, particularly when the transaction is made using a mobile computing device. This is achieved by eliminating the need for cryptographic keys to be stored on the mobile computing device, by firstly creating a strong link between users and their devices, and storing this pre-defined link with a trusted authentication service (i.e. in a secure backend payment system), and secondly using the pre-defined link between user and device to generate a unique, electronic or digital signature for a transaction which will authorise a payment, wherein the digital signature having been generated by using authentication information comprising a first authentication identifier and a second authentication identifier.

Abstract: A security core supports a networked banking app for a client application device communicating with a server, such as e.g. a smartphone. It provides a secure environment for the banking app to conduct registration, enrollment, and transaction workflows with corresponding back-end servers on the network. It includes defenses against static analysis, attempts at reverse engineering, and real-time transaction fraud. A principal defense employed is obfuscation of the protocols, APIs, algorithms, and program code. It actively detects, thwarts, misdirects, and reports reverse engineering attempts and malware activity it senses. A routing obfuscator is configured to operate at the outer layer. Previous core designs are retained as camouflage. An internal TLS library is used rather than the OS TLS layer. Cookies are managed internally in the core rather than in the webkit-browser layer.

Abstract: A secure payment system provisions a payment transaction proxy with virtual EMV-type chipcards on secure backend servers. Users authorize the proxy in each transaction to make payments in the Cloud for them. The proxy carries out the job without exposing the cryptographic keys to risk. User, message, and/or device authentication in multifactor configurations are erected in realtime to validate each user's intent to permit the proxy to sign for a particular transaction on the user's behalf. Users are led through a series of steps by the proxy to validate their authenticity and intent, sometimes incrementally involving additional user devices and communications channels that were pre-registered. Authentication risk can be scored by the proxy, and high risk transactions that are identified are tasked by further incrementally linking in more user devices, communications channels, and user challenges to increase the number of security factors required to authenticate.

Abstract: A method for preventing a user from being lured into an electronic transaction that is different than one they intended to launch uses a transaction processor to encrypt a payment instruction message for private display and viewing by a user mobile electronics device. The mobile electronics device is configured to forward an encrypted payment instruction from the transaction processor to decoding and display circuitry secure from other access and reserved to the display of decoded payment instructions on a private display. The user is signaled when the private display is presenting a payment instruction from the transaction processor. The user is able to signal back to the transaction processor that the payment instruction is approved. Electronic transactions can only be completed if the user has signaled back to the transaction processor that the payment instruction is approved.

Abstract: A payment authorization system includes a network server configured to create strong bindings between individual user identifiers and a peculiar combination of devices corresponding users employ, and the associated communications services each utilizes. The combination of user-devices-services reduces the possibilities to the one user who is authorized to establish access to a set of security keys held by another secure server. The principal goal being to authorize a payment transaction without exposing the security keys. A secure backend payment server is configured to produce a surrogate output that will satisfy a payment processor when asked to do so by an authorized user. Such surrogate duplicates what a payment chip card or secure element would have presented in person, but here the security keys never have to leave the backend payment server.

Abstract: A virtual payment chipcard service depends on a secure, back-end network server configured to maintain chipcard authorization data and computational services as virtual assets in the Cloud. These are behind tamper resistant boundaries, and, on user transaction request, arranged to electronically sign a transaction on the user's behalf as a proxy to a virtual chip-card payment. Two independent and concurrent user communication channels connected to the network server are configured to receive user transaction requests on one user communication channel, and to enable the network server to make confirmations with said user on the other user communication channel.

Abstract: An authentication service for hosting in trusted server environments includes a validation process for validating the identities of mobile users from a server's vantage point in the Cloud. A confidence scoring process is further included for estimating the certainty to which (1) a particular user, (2) a user's device apps and devices hosting them, and (3) a user's intent to carry out a given transaction have been correctly identified.

Abstract: Water supply systems use readily available heat sources like the sun and waste heat from industrial plants to heat intake air and water so more water can be used to saturate the intake air. That extra water is condensed out at another place even miles away where the now distilled water would be more useful.

Abstract: A security core supports a networked banking app for a client application device communicating with a server, such as e.g. a smartphone. It provides a secure environment for the banking app to conduct registration, enrollment, and transaction workflows with corresponding back-end servers on the network. It includes defenses against static analysis, attempts at reverse engineering, and real-time transaction fraud. A principal defense employed is obfuscation of the protocols, APIs, algorithms, and program code. It actively detects, thwarts, misdirects, and reports reverse engineering attempts and malware activity it senses. A routing obfuscator is configured to operate at the outer layer. Previous core designs are retained as camouflage. An internal TLS library is used rather than the OS TLS layer. Cookies are managed internally in the core rather than in the webkit-browser layer.

Abstract: A water supply system, the system comprising: an evaporation station, the evaporation station comprising a water inlet, an air conduit, and a water evaporation system coupled to the water inlet and to the air conduit for converting water from the water inlet into water vapour and for providing the water vapour onto the air conduit to provide humidified air; a condensation station having an air inlet to receive the humidified air, a water outlet, and a water condensation system coupled to the air inlet and to the water outlet to extract water from the humidified air and provide the extracted water to the water outlet; a pipe coupled between the air conduit of the evaporation station and air inlet of the condensation station; and a system for driving an airflow through the air conduit of the evaporation station past the water evaporation system to enhance the spray evaporation.

Abstract: A secure payment system provisions a payment transaction proxy with virtual EMV-type chipcards on secure backend servers. Users authorize the proxy in each transaction to make payments in the Cloud for them. The proxy carries out the job without exposing the cryptographic keys to risk. User, message, and/or device authentication in multifactor configurations are erected in realtime to validate each user's intent to permit the proxy to sign for a particular transaction on the user's behalf. Users are led through a series of steps by the proxy to validate their authenticity and intent, sometimes incrementally involving additional user devices and communications channels that were pre-registered. Authentication risk can be scored by the proxy, and high risk transactions that are identified are tasked by further incrementally linking in more user devices, communications channels, and user challenges to increase the number of security factors required to authenticate.