WO2014162116A1 - Canal de communication sécurisé - Google Patents

Canal de communication sécurisé Download PDF

Info

Publication number
WO2014162116A1
WO2014162116A1 PCT/GB2014/051004 GB2014051004W WO2014162116A1 WO 2014162116 A1 WO2014162116 A1 WO 2014162116A1 GB 2014051004 W GB2014051004 W GB 2014051004W WO 2014162116 A1 WO2014162116 A1 WO 2014162116A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
party
communication channel
information
service provider
Prior art date
Application number
PCT/GB2014/051004
Other languages
English (en)
Inventor
Andrew William Smith
Mark Earl SEDDON
Original Assignee
Cloudzync Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cloudzync Ltd filed Critical Cloudzync Ltd
Publication of WO2014162116A1 publication Critical patent/WO2014162116A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • This disclosure relates to a system that provides for secure communications between two or more parties. More specifically, but not exclusively, a security system is provided through which communications between a plurality of communicating parties pass. Due to the security functionality provided by the secure
  • the system is particularly useful for processing and managing financial transactions.
  • bank cards such as debit and credit cards have formed part of a preferred system for making payments.
  • Bank cards reduce the need for people to carry large sums of money on their person, while providing the owner or user associated with the card with the ability to make payments.
  • Such cards work by having personal identification information stored on the card, generally in a magnetic strip formed on the card or a microchip embedded in the card, which is used to identify a bank account from which payment can be taken.
  • bank cards provide access to persons bank account, there are risks regarding security. In particular, there is a risk that if a bank card gets lost or stolen someone other than the owner of the card may be able to obtain access to the card owner's bank account.
  • bank cards can be replicated relatively easily, therefore leading to further security risks.
  • replication of a signature on the back of a card has been used to verify the identity of the user of the bank card.
  • security provisions were deemed insufficient a number of years ago. It then became common for a 4-digit PIN number in accordance with so-called smartcard technology to be used as a means of providing security in the use of bank cards.
  • bank card identity theft is still a major problem, particularly due to the rise of using details provided on bank cards to make payments online.
  • a loyalty card is a card associated with a loyalty account. Whenever a consumer that has such a loyalty card makes a purchase at a store having a loyalty scheme with which the card is associated, the consumer's loyalty card is read by a card reader and based on information obtained by the card reader identifying the card and the purchase made, loyalty points are added to the loyalty account associated with loyalty card. Stores will then often provide vouchers to the consumer associated with the loyalty card, the value of such vouchers depending on the number of points obtained.
  • a method for providing secure communication between a plurality of parties comprises receiving, at an authorisation system, a first communication from a first party.
  • the first communication comprises information identifying a second party to which the first communication is directed.
  • the method further comprises verifying, at the authorisation system, an identity of the first part.
  • the method comprises sending, from the authorisation system when the identity of the first party is verified, a second communication to the second party in accordance with the first communication.
  • the method comprises receiving, at the authorisation system, a third communication from the second party issued in response to the second communication.
  • the method also comprises verifying an identity of the second party responsive to receipt of the third communication.
  • the method may be for providing secure communication between a plurality of parties for processing a financial transaction between the plurality of parties.
  • the first party may be a merchant and the first communication may comprise information identifying the financial transaction to be processed.
  • the second party may be a consumer and the third communication may comprise information indicating that the second party approves the financial transaction.
  • the method may comprise processing the financial transaction when the
  • authorisation system receives approval of the financial transaction from the second party and verifies the identity of the second party.
  • the financial transaction may be cancelled.
  • the first communication may comprise information identifying the merchant.
  • the method may further comprise identifying if the consumer has a loyalty account with the merchant.
  • the method may also further comprise sending, if the consumer has a loyalty account with the merchant, a fourth communication to the merchant comprising information identifying the consumer's loyalty account with the merchant and information identifying the financial transaction for the merchant to add loyalty points to the consumer's loyalty account with the merchant.
  • the method may further comprise determining, at the authorisation system, the identity of the second party from the information identifying the second party provided in the first communication.
  • the method may further comprise receiving location information indicative of a location of the second party. Furthermore, the method may further comprise determining if the location information is indicative of fraudulent activity.
  • Determining if the location information is indicative of fraudulent activity may further comprise comparing the location information indicative of a location of the second party with information indicative of a previous location of the second party.
  • the method may further comprise creating a profile of the second party, the profile indicative of characteristics of the second party.
  • the method may comprise determining current characteristics of the second party.
  • the method may also comprise comparing the profile of the second party with the current
  • the method may also comprise identifying the presence of fraudulent activity by the second party in accordance with the
  • the characteristics of the second party include location information associated with the second party.
  • the method further comprises receiving, with the third communication, information indicative of the current characteristics of the second party.
  • the identity of the first and second parties may be verified in accordance with information provided in the first and third communications respectively.
  • the information provided in the third communication may be security information.
  • the identity of the second party may be verified by comparing the security information received in the third communication with security information stored in a memory of the authorisation system.
  • the security information may comprise information identifying a device being used by the third party and information identifying the third party using the device.
  • the information identifying a device used by the third party may comprise one or more of: information identifying hardware of the device; information identifying the type of the device; information identifying an operating system used by the device; information identifying a version of the operating system of the device; and a UDID or Unique ID of the device.
  • the information identifying the third party using the device may comprise one or more of an OAuth identifier and a PIN code.
  • the information identifying a device being used by the third party and information identifying the third party using the device may be encrypted using an encryption process to form the security information.
  • An item of the information identifying the device being used by the third party or an item of information identifying the third party using the device may be used as an encryption key for producing the encrypted fingerprint.
  • a PIN code associated with the third party may be used as the encryption key.
  • Verifying the identity of the first party may comprise determining if the first party is registered with the authorisation system.
  • apparatus for providing secure communication between a plurality of parties.
  • the apparatus comprises a communication for communicating with a plurality of parties, and a processor arranged to process information.
  • the apparatus is arranged to perform any method for providing secure communication between a plurality of parties as described herein.
  • the apparatus may be a cloud-based server arrangement.
  • a method for verifying validity of communications comprises receiving a communication from a device associated with a user, the communication comprising information identifying the device associated with the user and information for verifying an identity of the user associated with the device.
  • the method also comprises determining if the device is a device registered for use by the user of the device.
  • the method comprises verifying if the user is the registered user of the device.
  • the method may further comprise performing further processing associated with the communication if the device is determined to be registered for use by the user of the device and the user is verified as the registered user of the device.
  • the further processing could be the processing of a financial transaction, or the enabling of the initiation of a direct communication channel.
  • the communication may comprise information identifying a second user to which the communication is directed.
  • communication may comprise sending a communication to the second user.
  • Determining if the device is a device registered for use by the user of the device may comprise comparing information identifying the device associated with the user with information identifying the device associated with the user stored in a memory of an authorisation system performing the verification.
  • the information identifying the device associated with the user may comprise one or more of information identifying hardware of the device, information identifying the type of the device, information identifying an operating system used by the device, information identifying a version of the operating system of the device, and a UDID or Unique ID of the device.
  • Determining if the user is the registered user of the device may comprise comparing information for verifying an identity of the user associated with the device with information for verifying an identifying of the user associated with the device stored in a memory of an authorisation system performing the verification.
  • the information for verifying an identity of the user associated with the device may comprise one or more of an OAuth identifier, and a PIN code.
  • the information identifying the device associated with the user and information for verifying an identifying of the user associated with the device may be received as an encrypted fingerprint providing an individual identifier of the user at the user device.
  • An item of the information identifying the device associated with the user or an item of information for verifying an identifying of the user associated with the device may be used as an encryption key for producing the encrypted fingerprint.
  • a PIN code associated with the user may be used as the encryption key.
  • the method may be for verifying the validity of communications for use in processing of financial transactions.
  • the apparatus comprises a communication unit for communicating with a plurality of parties and a processor arranged to process information.
  • the apparatus is arranged to perform any method for verifying validity of communications disclosed herein.
  • the apparatus may be a cloud-based server arrangement.
  • a method for producing security information to be associated with a communication the security information for verifying the validity of the communication.
  • the method comprises obtaining information identifying a device associated with a user and information for verifying an identity of the user associated with the device.
  • the method also comprises producing security information in accordance with the information identifying a device associated with a user and information for verifying an identity of the user associated with the device.
  • the method may further comprise encapsulating the security information in a communication to be sent by the user device.
  • the security information may be encapsulated within a header of the communication.
  • the information identifying the device associated with the user may comprise one or more of information identifying hardware of the device, information identifying the type of the device, information identifying an operating system used by the device, information identifying a version of the operating system of the device, and a U DID or Unique ID of the device.
  • the information for verifying an identity of the user associated with the device comprises one or more of an OAuth identifier and a PIN code.
  • the security information may be produced by encrypting the information identifying the device associated with the user and the information for verifying an identity of the user associated with the device.
  • An item of the information identifying the device associated with the user or an item of information for verifying an identity of the user associated with the device may be used as an encryption key for producing the encrypted security information.
  • a PIN code associated with the user may be used as the encryption key.
  • the security information may be a fingerprint. The fingerprint may be provided in any form as described herein.
  • apparatus for producing security information to be associated with a communication, the security information for verifying the validity of the communication.
  • the apparatus comprises a processor arranged to perform any method for producing security information to be associated with a communication, the security information for verifying the validity of the communication as disclosed herein.
  • the apparatus may be a smart phone.
  • a method for preparing a packet for secure and efficient transmittal over a network comprises inserting content to be transmitted over a network within a body of a packet.
  • the method also comprises inserting security information for authentication purposes within a header of the packet.
  • the security information may be produced in accordance with any appropriate method described herein.
  • the method may further comprise transmitting the packet to a recipient.
  • apparatus for preparing a packet for secure and efficient transmittal over a network comprises a processor arranged to perform any method for preparing a packet for secure and efficient transmittal over a network as disclosed herein.
  • a method for verifying the validity of information received over a network comprises receiving, over a network, a packet comprising content within a body of the packet and security information for authentication purposes within a header of the packet.
  • the method also comprises obtaining, from the header of the packet, the security information.
  • the method also comprises verifying the received packet in accordance with the security information. The verification may be performed in any suitable way as described herein. It will be appreciated that the packet referred to may also be referred to as a communication herein.
  • the security information referred to may also be referred to as the information identifying the device associated with the user and the information for verifying an identity of the user associated with the device.
  • a method for routing communications from a source to one or more recipients comprises determining a respective communication channel for sending content received from a source to each of one or more recipients.
  • the method also comprises sending a communication including the content to the one or more recipients using the respective communication channel.
  • the step of determining a respective communication channel may further comprise determining a device associated with each recipient, determining a device type of the device associated with each recipient, and determining the respective communication channel for sending the content to each of the one or more recipients in accordance with the device type for the respective recipient.
  • the respective communication channel may be a protocol associated with the device type.
  • the protocol may be a communication protocol for communicating with the device type using one of the following operating systems: iOS, Android, or Windows Phone.
  • the method may further comprise receiving, from the source, the content to be sent to the one or more recipients and the information identifying the one or more recipients.
  • the content to be sent to one or more recipients and the information identifying the one or more recipients may be received in a single communication.
  • the method may further comprise receiving information identifying the one or more recipients, prior to determining a respective communication channel for each of the one or more recipients, in accordance with location information associated with the one or more recipients.
  • the recipients may be identified in accordance with location information when it is determined, from the location information that the one or more recipients are within a predetermined distance of a location associated with the source.
  • the method may further comprise receiving a request from the one or more recipients for information from the source prior to determining a respective communication channel for sending the content received from the source to each of the one or more recipients.
  • the method may further comprise receiving a request from the one or more recipients for a type of information.
  • the method may further comprise requesting the type of information from one or more sources including the source.
  • the method may also comprise receiving the content from the source responsive to the request for the type of information.
  • the method may be performed at or by a data processing system.
  • the apparatus for routing communications from a source to one or more recipients.
  • the apparatus comprises a communication unit for communicating with a plurality of parties.
  • the apparatus also comprises a processor arranged to process information.
  • the apparatus is also arranged to perform any method for routing communications from a source to one or more recipients as disclosed herein.
  • the apparatus may be a cloud-based server arrangement.
  • the method may comprise receiving, at a data processing system, a communication from a first party.
  • the communication comprises information indicative of a communication channel to be set-up from the data processing system to a second party.
  • the method further comprises setting-up, at the data processing system, a communication channel in accordance with the information indicative of a communication channel to be set-up.
  • the second party may be arranged to communicate with parties communicatively coupled to the data processing system through the communication channel.
  • the information indicative of a communication channel to be set-up may comprise a communication channel definition.
  • the method may further comprise producing, at the data processing system, a communication channel definition in accordance with the information indicative of a communication channel to be set-up.
  • the information indicative of a communication channel to be set-up may comprise information for the data processing system to identify the second party for setting-up the communication channel from the data processing system to the second party.
  • the communication channel definition may comprise a definition of an API end point associated with the second party.
  • the API end point may be a RESTful API end point.
  • the communication channel definition may further comprise a return API definition that defines a channel for communications to be transmitted from the second party to the data processing system.
  • the communication channel definition may further comprise content to be transmitted to the second party.
  • the content to be transmitted to the second party may include required data capture information to be obtained from a third party by the second party.
  • the data processing system may verify all communications from parties passing through the data processing system.
  • the apparatus comprises a communication unit for communicating with a plurality of parties.
  • the apparatus also comprises a processor arranged to process information.
  • the apparatus is arranged to perform any method for setting up a communication channel as disclosed herein.
  • the apparatus may be a cloud-based server arrangement.
  • the method comprises producing, at a first party, information indicative of a communication channel to be set-up from a data processing system to a second party.
  • the method further comprises transmitting, from the first party to the data processing system, a communication comprising the information indicative of a communication channel to be set-up from the data processing system to a second party for the data processing system to setup the communication channel.
  • the method may further comprise creating, at a first party, a communication channel definition.
  • the communication channel definition may be arranged to define a communication channel from a data processing system to a second party.
  • the information may be indicative of a communication channel to be set-up comprises the communication channel definition.
  • the communication channel definition may comprise a definition of an API end point associated with the second party.
  • the API end point may be a RESTful API end point.
  • the communication channel definition may further comprise a return API definition that defines a channel for
  • the communication channel definition may further comprise content to be transmitted to the second party.
  • the content to be transmitted to the second party may include required data capture information to be obtained from a third party by the second party.
  • the information indicative of a communication channel to be set-up may comprise information for the data processing system to identify the second party for setting-up the communication channel from the data processing system to the second party.
  • the apparatus comprises a communication unit for communicating with a data processing system.
  • the apparatus also comprises a processor arranged to process information.
  • the apparatus is arranged to perform any method for creating a communication channel definition for setting up a communication channel between a data processing system and a party as described herein.
  • a method for controlling a quantity of cloud-based resources utilised by a system comprises determining a quantity of cloud-based resources required by a system.
  • the method further comprises adjusting a current quantity of cloud-based resources associated with the system in accordance with the determined quantity of cloud-based resources required by the system.
  • the method may further comprise monitoring usage characteristics of the current quantity of cloud-based resources associated with the system.
  • the quantity of cloud- based resources required by the system may be determined in accordance with the monitored usage characteristics.
  • the current quantity of cloud-based resources may comprise a plurality of servers arranged within a cloud structure.
  • the usage characteristics of each of the plurality of servers may be monitored.
  • the monitored usage characteristics may include one or more of database loads, average web server request, and latency.
  • the method may further comprise creating a profile of characteristics of usage of the system over time.
  • the quantity of cloud-based resources required by the system may be determined in accordance with the profile.
  • the method may further comprise predicting a future usage of the cloud-based resources associated with the system, where the quantity of cloud-based resources required by the system is determined in accordance with the prediction of future usage.
  • the the future usage of the cloud based resource may be predicted based on known characteristics of a future time.
  • the method may further comprise determining the adjustment of the current quantity of cloud-based resources by comparing the determined quantity of cloud-based resources and the current quantity of cloud-based resources.
  • the current quantity of cloud based resources may be adjusted by sending a message to a provider of the cloud-based resources requesting that the current quantity of cloud-based resources be adjusted in accordance with the adjustment of the current cloud-based resources.
  • the apparatus comprises a processor arranged to perform any method for controlling a quantity of cloud-based resources utilised by a system disclosed herein.
  • the apparatus may further comprise a communication unit arranged to provide communication functionality as described herein.
  • the apparatus may further comprise a monitoring arrangement arranged to monitor usage characteristics of the current quantity of cloud-based resources as described herein.
  • a method for processing items having associated content for being displayed comprises obtaining a plurality of items having associated content for
  • the method further comprises analysing the plurality of items to determine a number of cells of the cell
  • the method also comprises determining which of the plurality of items to display the respective content of in the cell structure based on the cell structure and the determined number of cells required to display the content associated with each of the plurality of items. Furthermore, the method comprises displaying, in the cell structure, the content associated with the determined items of the plurality of items to be displayed.
  • the cell structure may comprise a number of cells.
  • the determining which of the plurality of items to display the respective content of in the cell structure may comprise comparing the number of cells required to display the information for each of the plurality of items and the number of cells in the cell structure.
  • the number of cells in the cell structure may be arranged in a two-dimensional array.
  • the determining which of the plurality of items to display respective content of in the cell structure may comprise comparing the number of cells required to display the content associated with each of the plurality of items and the cell structure of the two- dimensional array of cells.
  • the plurality of cells required to display the content may be set according to a type of the content associated with the respective item.
  • the analysing may comprise determining the type of the content associated with each of the respective items.
  • the method may further comprise grouping the plurality of items according to type of the content associated with the respective items. The determining which of the plurality of items is to have its associated content displayed may be carried out on a group of the plurality of items corresponding to the type of the content.
  • the type of the content may be determined from a code indicative of the type of the content associated with the item.
  • the type of the content may be one of vouchers, loyalty scheme updates, personalised deals, tickets, electronic receipts, warranties, and travel documentation.
  • the apparatus comprises a memory arranged to store a plurality of items having associated content for being displayed in a cell structure of a user interface.
  • the apparatus also comprises a processor arranged to perform any method for processing items having content for being displayed disclosed herein.
  • the apparatus also comprises a display arranged to display content associated with items that the processor determines are to be displayed.
  • a computer readable medium comprising computer readable code operable, in use, to instruct a computer system to perform any method disclosed herein is provided.
  • each device that is arranged to connect to the service provider system is uniquely identifiable for every single communication exchange between the service provider system and a calling device.
  • the amount of data to be transferred across a network for such communications is dramatically reduced when compared to state of the art systems.
  • Arrangements are disclosed that provide a unique protocol that enables efficient and secure communication between a calling device and a service provider system. This efficient and secure communication may be provided for every single communication request. This protocol may allow for greater security between a calling device and service provider system, while reducing the amount of data passed across a communication network thereby improving network and data transfer efficiency.
  • an application is installed in a user device for providing functionality disclosed herein.
  • This application may create a unique digital fingerprint of the device.
  • the digital fingerprint may be based on hardware and/or software specifications of the user device, and optionally in addition to a configuration of the device.
  • the fingerprint may include specific information related to the user associated with the device.
  • the user associated with the device may be a user registered with the service provider system for using the device.
  • the user information may derive from login information provided by the user. For example, the login could be provided via a supported OAuth protocol such as Facebook, Windows Live, or Google.
  • the fingerprint identifier may be stored on the device and in the service provider system or 'cloud'.
  • a method is disclosed wherein a device initiates communication and then sends this communication directly to the service provider cloud, along with identification data of a second device to communicate with. For example, this may be the second device's mobile number.
  • the communicated instruction is then sent to the second device, where it is displayed on the device screen hardware and requires a user interaction at the second device.
  • the user's input and required communication data is then passed back to the service provider cloud, allowing the service provider cloud to complete the action requested.
  • the cloud then completes the operation and returns the result to both devices.
  • additional information can be associated with a transaction being processed.
  • additional information may include one or more of a voucher and/or loyalty scheme data. All of this information can be provided in a single communication call.
  • a "merchant" can issue direct messages to users registered on the service provider system.
  • the merchant does not need to support multiple device operating systems or understand the individual devices the users may be using.
  • the merchant does not need to have an application installed on the end users mobile device. Instead, just a single call is required identifying information to be sent to one or more recipients, also identified in the call, and the service provider system then delivers the information or content to the required recipients. This reduces the need to manage multiple language, operating systems, and hardware for content delivery and use. Instead the service provider system provides this functionality. Furthermore, such
  • implementations enable developers to use any development language in order to deliver content and operating specific notifications to one or more mobile devices.
  • the requirement for content and notification originators to have their own application installed on the end users mobile device is also removed.
  • Content and single notifications can therefore be distributed to any device - there are no restraints based on hardware or device operating system.
  • FIG. 1 shows a secure communications environment in accordance with an embodiment of the invention
  • Figure 2 is a flow diagram of a procedure for completing a financial transaction using the secure communications environment of Figure 1 ;
  • Figure 3 shows a system in which a third party server is incorporated into the secure communications environment shown in Figure 1 using a workflow
  • Figure 4 is a flow diagram of a procedure for introducing a third party into the secure communications environment as shown in Figure 3 in an exemplary embodiment wherein the third party is the issuer of a warranty;
  • Figure 5 shows a homepage screen for the app installed on the user device shown in Figure 1.
  • a system is described herein that provides a mechanism for secure communications between two or more parties.
  • the system has various applications, but the system shall initially be described with reference to an exemplary embodiment in which the secure communications system is used for processing of a financial transaction taking place between a user or a consumer and a merchant.
  • Figure 1 shows the secure communications environment 100 for processing of payments.
  • the process works by providing a secure cloud-based system or server 101 that controls the payment process operated by the provider of the secure payment service.
  • This server is hereinafter referred to as the service provider system 101.
  • the service provider system 101 When a user wants to complete a financial transaction from a merchant, e.g. the user wants to purchase an item from a shop associated with the merchant, the transaction is processed via user device 102 and merchant device 103 communicating through the service provider system 101. Since communications between the merchant device 103 and user device 102 take place through the service provider system 101 all communications can be subject to the security provisions provided by the server 101.
  • Each device that is to be connected to the service provider system 101 is uniquely identifiable, which is a requirement for the secure communication exchange provided by the service provider.
  • the service provider system 101 is shown as a cloud-based server. As will be described, the service provider system is arranged to dynamically use cloud resources provided by cloud-based servers. Such resources include processing and memory functionality. It will be appreciated that in alternative arrangements fixed rather than cloud-based servers are utilised.
  • the user device 102 is shown as a smart phone in Figure 1. In latter sections of this disclosure it will be appreciated that the user can also complete transactions using other devices such as a computer. However, the following description is based on the concept of the user using a smart phone.
  • the merchant device 103 is shown as a computer. It will be appreciated that the merchant may have a plurality of devices at multiple locations and not just a single device. However, only a single terminal is shown for ease of explanation. Furthermore, the merchant may utilise another electronic device such a smart phone or cell phone-based device.
  • All communications between the merchant device 103 and user device 102 are primarily web-based communications, even though clearly at least part of the communications will also pass through the cellular mobile phone network for communicating with the user device 102.
  • the merchant can register with the service provider system 101 providing the service provider system 101 with:
  • This information can be provided via a web-based registration page.
  • the requirement of providing the geographical location of all of the merchant's stores or operational locations provides an additional level of security because any communications from the merchant must be from a specific merchant account if the transaction is an instore transaction type.
  • Each device that the merchant wishes to use must sign into the merchant's user account, which is done via the merchant's own Active Directory or a shared / bespoke Active Directory provided by the service provider 101.
  • the merchant is also able to select a level of service required from the service provider system 101.
  • the merchant may only want to use the service provider system 101 for processing of payments.
  • the service provider system 101 stores this information in its memory and assigns a unique identifier for that merchant.
  • the merchant user must be "signed" into the system via Active Directory. Their Active Directory account informs the service provider system of the merchant account details and assigned merchant identifier.
  • the first step of the user registration process is for the user to download the service provider's app onto the user device 102.
  • the registration process can then be performed using the app.
  • the user is required to provide the following information: a) Name.
  • OAuth identifier e.g. Facebook login, Google login, Twitter Login, Live login
  • Information identifying the hardware and type of the user device e.g.
  • Device operating system e.g. iOS, Android, or Windows Phone.
  • Device operating system version e.g. iOS 6, Android ice cream sandwich, or Windows Phone 8 (build revision information is also collected, e.g. iOS 6.2.1.3).
  • Channel URI / Device Token this is a unique identifier that is required for push notifications for the specific device and its operating system.
  • the information associated with points a), b), c), and j) can be input by the user into the service provider's app installed on the user device 102.
  • the information set-out at point d) is captured once the user has signed into that OAuth provider.
  • the information associated with each of e), f), 9) and h) are automatically extracted by the service provider's app from the user device 102.
  • the bank account details c) are provided to provide the user's account with the service provider with funds for paying for a transaction.
  • the user pays, from their bank account, a set amount of money, e.g. £50 into their account held by the service provider. This money is then used for transactions until that money runs out. The user is then required to add more funds to their account.
  • the system can automatically add funds from the user's personal bank account to the user's account with the service provider.
  • the service provider may have a direct debit setup with the user's personal bank so that all transactions that are authorised by the service provider are then debited from the user's personal bank account.
  • the service provider account may be set up using a credit based structure, wherein the user is invoiced monthly for their transactions.
  • the service provider system may be able to download a photo of the user, e.g. from facebook.
  • the user may upload a photo of themselves to the system 101.
  • the photo can be used by a merchant as an additional security provision.
  • the PIN code is set by the user at registration.
  • the PIN has to be input by the user every time they log into the application. As will be seen, this means that payments cannot be approved without the user inputting the PIN.
  • the PIN is not required to access the application, but is instead just required to approve a payment.
  • the user can register additional devices for use with his/her account. For example a computer or work smart phone could be registered for use.
  • the next step after the user registration process is for the user app to create a device fingerprint.
  • the device fingerprint is a unique identification of the user and associated user device.
  • the fingerprint is a security measure that is always required for a user device to communicate with and through the service provider system 101.
  • the device fingerprint is created by using the information listed at items a) to j), obtained during the user registration process. In alternative arrangements, only some of the information listed at items a) to j) may be used.
  • This information is encrypted into a unique identifier for the user and the specific device.
  • a key characteristic of the unique identifier is that it is specific to the user and the specific user device, which provides improved security over current financial transaction security. In other words, for someone to use the user's funds stored in the user account held with the service provider, both the registered user device and user specific information must be obtained.
  • the device fingerprint is created by creating a SHA Hash value for the user's PIN and one or more raw data values of the fingerprint.
  • the PIN is taken to increase the level of security, and adding a unique component based on the user to the fingerprint encryption.
  • the PIN hash is then taken and a fixed Salt is added.
  • the fixed Salt is generated in the user device 102 by the app.
  • the fixed Salt may change with each release of the app.
  • RFC 2898 is then used to derive a password Key.
  • the result is then UTF 8 encoded.
  • a HEX encode is then taken.
  • the HEX encode becomes the encryption key for the device fingerprint raw data and can be either 128Bit, 256Bit, or 512Bit.
  • the unique device ID is then encrypted with a derived key using one of the following algorithms: AES algorithm, Triple DeS, RC2, Blowfish, or Rijndael.
  • AES algorithm Triple DeS
  • RC2 Blowfish
  • Rijndael The algorithm used to create the fingerprint can be changed periodically and at random intervals to further increase security.
  • a Base 64 encoded output is provided. This output is stored as the complete device fingerprint identifier on the device and transmitted to service provider system 101 where it is also stored in the user's account information.
  • the data that is encrypted enables the service provider 101 to check that device settings are not altered in any way, which therefore ensures greater levels of security. For example, if a PIN reset has been enforced within the app, it will break the fingerprint and therefore communication with the service provider 101 will not be valid.
  • the device fingerprint can be re-engineered by the service provider, i.e. decrypted. Decryption is required when the device itself is updated to use a new operating system, or a new version of the app is installed.
  • a fingerprint maybe decrypted to retrieve data such as the users PIN.
  • the users PIN is not stored on the service provider system 101 , but is required to decrypt other stored data on the service provider system 101. Authentication can be checked from the decrypted fingerprint, as can authorisation data. Security levels can therefore be ensured.
  • the derived data from the device fingerprint is also used in real time suspicious activity processes, that will be discussed.
  • each device has a unique fingerprint because the fingerprint depends on information specific to the device. Once both the user device 102 and the service provider system 101 have the device fingerprint associated with the user device 102 stored in their memory, the device fingerprint is used as an authentication key for all future communications between these two devices, as will now be discussed.
  • the fingerprint provides particular security because the user's PIN is used as the encryption key or passcode, which means that decryption of the fingerprint and therefore obtaining the secure information that is encrypted is extremely difficult and only possible with the user's PIN. Furthermore, the multiple encryption stages further add to the difficulty of the fingerprint being decrypted to obtain the information that is encrypted.
  • the protocol enables communications from devices to the service provider system 101 to be authorised.
  • the ZyncSign protocol has a specific header set, which includes:
  • a Base 64 encoded output This holds identification data associated with the user device 102 and its associated user. In the example of financial transactions provided by the system provider 101 , this identification data is the device fingerprint. However, in other configurations this identification data could be different to the device fingerprint.
  • the header using the ZyncSign protocol, could take the following form:
  • All communications between any device and the service provider system 101 must use the ZyncSign protocol.
  • Use of the ZyncSign protocol enables the service provider system to correctly identify the device, its state (if a valid device) and specific information such as the device operating system and build version, while also simplifying individual API service calls and reducing the amount of data passed in each call.
  • the security data is encapsulated within the header means that there is such a reduction in data transmitted over networks. Not only does this reduce data loads on networks, but it also maintains higher levels of security during transactional calls to services because the security data is in an encrypted form even before the data is then transmitted over a secure https connection.
  • the ZyncSign protocol enables the service provider to check both user and device credentials on every single call. This is unique, as it enables the service provider to authenticate the user and authorise the hardware used to process the necessary calls.
  • web based APIs use SOAP or other implementations.
  • RESTful based APIs however provide nothing more than a unique URL.
  • the ZyncSign protocol provides a security layer to every single REST based API call, without the calling service (or developer) having to add parameters to an API call.
  • the process starts by the merchant device 103 scanning a barcode of a product to be purchased.
  • the merchant device 103 initiates a communication and builds an initial data set at step 201.
  • This data set includes information identifying the merchant and the item being purchased, or at least the financial value of the item being purchased.
  • the merchant device 103 then initiates communication by sending out a message asking for the user device 102 to identify itself at step 201.
  • This communication can be transmitted using near field communication (NFC) or similar short range communication protocols.
  • NFC near field communication
  • the user device 102 then sends out a message identifying itself in response to the message from the merchant device 103 at step 202. In this configuration the user device 102 must provide certain data that is sent as an encrypted block and includes:
  • a shared secret (a word and/or a number), taken from the registration data.
  • the merchant device in this configuration is then able to identify the user device 102 from this message for this type of face to face transaction.
  • the merchant device could identify the user device in other ways, for example, the user could show a unique identifier, such as a QR code, on a screen of the user device which is scanned by the merchant device 103.
  • a QR code a time stamp may be generated to limit the length of time that the QR code is valid.
  • Other ways of communicating between the devices could include the use of Bluetooth or infrared technology.
  • the merchant device 103 obtains only the block of data. However, in alternative systems all the merchant need obtain is a single identifier for the user device 102 such as a mobile phone number associated with the user device 102. This alternative system is typically used when the merchant is unable to read data from the users device 102 (e.g. transactions made through a website or over the telephone). Such information is sufficient for the service provider system 101 to then identify the user.
  • the merchant device 103 then joins the information identifying the user device 102 to the initial data set that was previously created.
  • the combined information is then sent to the service provider system 101 via a secured HTTPS connection.
  • the service provider system 101 validates the identity of the merchant as will be discussed in more detail. In addition, the service provider system 101 determines who the registered user associated with the user device 102 is by comparing information stored on the service provider system 101 from the user registration process with the information received from the merchant. The complete data set is then checked in real time for suspicious activity which will be discussed later.
  • the service provider system 101 then sends the merchant device 103 additional security information about the user.
  • This information may include one or more of:
  • the user is then verified by the operator of merchant device 103 in accordance with this information. For example, the merchant could ask for additional identification or check that the profile picture received matches that of the person using the user device 102. Then, at step 205, the merchant device sends a communication to the service provider system 101 verifying the identity of the user. In alternative systems, steps 204 and 205 could be skipped. This would provide a simpler, but less secure system.
  • the service provider system 101 then stores information about the transaction in a temporary memory linking the user and the merchant together for the transaction while the transaction is being processed and generates a user approval message at step 206, which is sent to the user device 102.
  • the user approval message provides the user with information regarding the amount of the transaction and requests the user to accept or decline the transaction. Since the user has to input their 8-digit pin to open to app, an additional level of security is provided for the user to authorise the payment.
  • a transaction approved message is sent from the user device 102 to the service provider system 101 at step 207.
  • the service provider system 101 receives the user approval, which it can verify was from the correct user and the correct user device from the fingerprint, the service provider system 101 can process the transaction. For example, the service provider system 101 can debit the user's account for the amount of the transaction. At this point the service provider system checks if the user has sufficient funds for the transaction. This check could also be carried out after step 203. If the transaction is successfully processed, the service provider system 101 then sends a message confirming the transaction is complete to the user device 102 (step 208) and the merchant device 103 (step 209). This message includes a completed transaction authorisation code. The message to the user may be stored as a receipt in the user's account with the service provider.
  • the communication procedure for processing a financial transaction when a user is in store can also be applied to various other situations with minor modifications. For example, if a user is purchasing something over the Internet (e.g. from a website on a computer) or over the telephone, the user provides the merchant, via the Internet or telephone, with information identifying themselves. This information may be information such as name, address, and/or mobile phone number, which can then be sent onto the service provider system 101 by the merchant device 103 and used to identify the user. Hence, this procedure replaces steps 201 , 202 and 203 of Figure 2, but after that the method can proceed in exactly the same way, with the user using a registered device to verify the financial transaction.
  • the above-described financial transaction processing system has a number of inbuilt security provisions to help prevent and detect fraudulent transactions, this is known as the suspicious use detection. Suspicious use detection is split into a real time task and as a background task.
  • the real-time detection checks the validity of both parties, their data, their identifying devices and the authentication of the actual users in the transaction. In addition, the real-time detection checks against the capability of that user to complete the financial transaction, for example by analysing geographic location information.
  • the real time task involves the service provider system 101 validating data provided by the communicating devices by comparing the received data to data stored on the service provider server prior to allowing a transaction to be completed.
  • the following data is validated:
  • the received fingerprint authentication data must match the corresponding data stored on the service provider server 101.
  • the service provider server is validating: the device based on data included in the fingerprint identifying the specific device; and the user based on a pin number and an OAuth identifier, such as a facebook login.
  • the device must be unique, i.e. there must not be a replicated device on the system.
  • the communication type e.g. face to face, online, or over the telephone
  • a check is then carried out to make sure that the transaction is of the type suggested.
  • This procedure can use geographical data captured from the physical device that was included in the data sent to the service provider from the user device at the point of authorisation to determine if the geographical data falls within accepted parameters for the transaction type. For example, for a face to face transaction the user device and merchant device should be at the same location. Furthermore, for an online transaction the user device that approves the transaction should be at the same location as the computer via which the transaction is initiated to ensure that it is the same person making and approving the transaction. The location of the computer can be determined from an IP address.
  • a further geographical check is carried out to ensure that the geographical data captured from the physical device does not exceed travel parameters for that user. In other words, it is determined whether or not the user could have travelled the distance between transactions in the time between transactions.
  • the initiating device fails the suspicious use detection then all communications are stopped immediately and the device is banned. A procedure is provided for a user to unlock their account.
  • the transaction processing procedure may include sending the merchant device 103 information about the user of the user device 102 for verification purposes. If the merchant does not believe that the person using the user device is the valid user then they can send an instruction to the service provider system 101 to stop the transaction and ban the user device 102.
  • the service provider system 101 sends the transaction approval message, i.e. step 206 in Figure 2, to all registered devices. If an additional device has been fraudulently registered with an account then the user will be able to tell from their validly registered device and inform the service provider system 101 accordingly.
  • the geographic location information can assist in identifying the specific location of a fraudulent transaction.
  • the background detection involves monitoring user activity to form a pattern of usage or user profile.
  • other data from the device and how it is utilised is captured and stored for reference. For example: input speed between the user and the device is recorded; and geographical data captured from the device is recorded from which movements and distances between communication points, as well as typical geographic locations for the device can be determined.
  • the type of transactions can be analysed, such as use of a gym or a particular membership card or loyalty scheme. All of this information is incorporated into the user profile.
  • a rules engine is deployed on the service provider system that monitors all captured data from devices and sources. The profile is then checked against new activity, such as a new financial transaction, to measure if the new transaction falls into the acceptable limits for that profile. If not, then the transaction can be suspended and the device / user activity can be suspended until validated.
  • the suspicious use detection methods described above improve the security of communications and transactions. Furthermore, these methods strengthen manual workflows and process checks by providing tangible information through mobile devices that enables end users to make informed decisions against.
  • An example of this is that the merchant can check the picture of the registered user device against the physical person in front of them attempting to complete the financial transaction.
  • the service provider environment 100 provides additional functionality beyond financial transaction processing.
  • the service provider environment also allows for loyalty point updating, use of vouchers for payment, the delivery of notifications such as adverts, and setting up of workflows, for example for completing warranties.
  • the system When a user makes a purchase from a merchant that has a loyalty scheme, the system is able to automatically add loyalty points to a user's loyalty points account held by the merchant.
  • the user must register their loyalty scheme number for a merchant's loyalty scheme in their account on the service provider system 101.
  • the user may perform this by inputting the data via a registered user device.
  • the user could scan a loyalty card using a registered user device.
  • Loyalty points can then be assigned to the user when a financial transaction associated with the user is processed, as follows. Once a transaction between the user and a merchant is confirmed as being processed, the service provider system performs a check to determine if the user has any loyalty scheme registered in their account for the merchant. If the user does have a loyalty scheme registered, the service provider system then sends a communication to the merchant, that identifies the amount of the purchase and the user's loyalty scheme number. The merchant is then able to update their records regarding the user's loyalty points.
  • the loyalty point updating system provided by the service provider system 101 therefore removes the requirement for a user to carry a loyalty card, in addition the system removes the requirement for the user to even remember to indicate that they have a loyalty scheme with the merchant. Instead, the procedure is all carried out automatically.
  • the user account can store electronic vouchers.
  • the user account can be considered an electronic wallet, which has not only a financial account for payments, but also stores vouchers.
  • any vouchers that are applicable can be either automatically added to the transaction, or in alternative settings as configured by the user, that user can be prompted if they wish to use the voucher(s). If the value of the transaction is greater than the value of the voucher then the user is asked to approve payment by virtue of the voucher and the additional required funds. If the value of the transaction is less than the value of the voucher then the value of the voucher may be updated accordingly, but this will depend upon rules set by the merchant.
  • a user may add a voucher to their account by browsing available vouchers made available through the app installed on their registered device. These vouchers may be generally available vouchers or vouchers the merchant has distributed specifically to the user.
  • a user may add a voucher to their account by scanning a physical voucher using the user device 102.
  • the user device 102 will then send a message to the service provider system 101 using the ZyncSign protocol encapsulating information identifying the voucher.
  • the service provider system 101 then communicates with the merchant that has issued the voucher to verify that the voucher is valid. If the voucher is valid the voucher is stored in the user account.
  • Vouchers can also be added to a user account when the user is purchasing something from a merchant's store. For example, if the user spends a certain amount of money with a merchant, this may trigger the issuance of a voucher.
  • the merchant may send a communication identifying the voucher in response to receiving confirmation from the service provider system 101 that the transaction has been approved, i.e. in response to step 209 in Figure 2.
  • a merchant can issue a user with an electronic voucher, for example, using the data pushing procedure discussed below.
  • the service provider system is also able to provide a routing functionality for communications between devices registered with the service provider system. While this functionality has a broad range of applications, it will now be described with reference to an example of delivering advertisements from a merchant to one or multiple users.
  • a merchant is able to send adverts, such as limited offers in store, using the data pushing functionality of the service provider system.
  • the ZyncSign protocol is used to send content created by the merchant to the service provider system, which is then sent by the service provider system directly to one or more user devices, with the final communication from the service provider system to the user device using "push notifications" in the device specific operating system format, e.g. a Channel URI sent through to Microsofts Push Notifications service to deliver a push notification to devices that run Windows Phone 7, 7.5, 7.8 and 8.
  • a notifications URI is automatically created based on the device's operating system.
  • This channel URI is securely stored on the user device and also transmitted to the service provider system 101.
  • the service provider system 101 then stores this Channel URI and confirms the storage of the URI back to the device 102 so that the user device 102 does not continue to resend Channel URIs.
  • Channel URIs are subject to change based on the operating system of the device, this means that they must be continually checked and kept in synchronisation with the service provider.
  • the service provider system 101 also stores the URI.
  • the storage of this Channel URI is in a separate storage location on a data storage server of the service provider system 101.
  • Channel URIs are linked to individual devices as registered by a user.
  • the service provider system 101 joins together the physical datasets of the user, the user's device fingerprint and the active Channel URI.
  • channel URIs change, in order for the service provider system 101 to remain in constant touch with the user device 102, and for the device 102 not to be orphaned, the application installed on a device 102 must check the hardware of the device 102 and detect any changes in the Channel URI, by checking its own internal storage. Any changes must be re-communicated back to the service provider system 101 as to ensure the device 102 is not orphaned from the device communications channel.
  • a merchant can push data to devices by sending the following information, to the service provider system 101 : • Information identifying one or more users for data to be pushed to. This could simply be a mobile phone number associated with a user, which the service provider system can then use to identify the user, or any other data that the service provider system could use to identify a user.
  • advertising information may be sent.
  • this could be any information that one party may wish to transmit to multiple parties.
  • Optional referenced data This could be a link to external data (via a URL) or could be data referenced within the system providers system 101 , for example a link to a particular voucher defined in the system provider system 101
  • the service provider When the service provider receives this message, it firstly determines the user's identification in the message. For those users that can be identified and also have a device communication channel set up, the services provider system 101 is then able to prepare the messages to be sent to the user devices.
  • the service provider system 101 then creates messages for each different type of user device operating system, e.g. iOS, Android, Windows Phone etc, incorporating the content provided by the merchant into the messages.
  • the service provider system 101 is then able to send the messages to each of the selected users using the correct operating system push notification protocol.
  • the service provider system 101 allows for great flexibility and accuracy of timely delivery.
  • the merchant can indicate when they want a message to be delivered, e.g. instantly, as soon as possible, or delayed until a specific date and time.
  • the merchant can specify that they only want the message delivered when one of the identified users is at a specific location. For example, if a user is within a certain radius of the merchants shop on a certain day, an offer could be sent to the user device accordingly.
  • the advantage of this procedure is that device bound content can be distributed to specific devices in a highly efficient fashion without the calling services, such as the merchant, needing to know the device operating system or how notifications for given devices are handled.
  • the URI registration process between each user device and the service provider system sets up these channels of communication automatically.
  • the calling services need not have an established direct link with the user devices themselves, but instead just have some information suitable for the service provider system to identify a respective user. Consequently, the calling service need not know anything about the device operating system, but deliver device operating system specific messages to a user device. Managing notifications and content distribution is therefore simple and highly efficient. Only a single call is required to distribute to multiple devices, supporting any device hardware and any device operating system.
  • the system is arranged so that users are able to block or filter pushed information by indicating on the mobile app on their registered user device 102. A message is then sent from the user device 102 to the service provider system 101 to set-up filtering parameters so that data originating from certain sources is blocked.
  • the service provider system 101 enables any registered device using any development language to distribute content to other registered devices no matter what the other devices operating system is.
  • functionality is provided to enable data pushing responsive to a stimulus. For example, any mobile device within 1-mile of a particular store, for identified users, may be pushed a voucher on a particular day. These users are identified for these vouchers in advance, but the voucher is only distributed to the user once their device is within the given radius of a particular store.
  • a user may indicate that they are travelling to Bristol for the day and would like any vouchers for use in Bristol.
  • the service provider system is then able to send such a request out to all merchants then receive vouchers and distribute the received vouchers accordingly.
  • the user may indicate that they would like to buy a TV and request vouchers accordingly.
  • there are various means for triggering the data pushing functionality there are various means for triggering the data pushing functionality.
  • the service provider system is also able to process communications with third parties that are not registered with the service provider system 101. This is achieved by merging data sets from devices, accounts, businesses and suppliers using a workflow, as will now be discussed.
  • the workflow functionality allows for any third party communication flow to be introduced into a merchant-consumer communication channel. More generally, a workflow is set-up by one business wanting to
  • a workflow definition tool used to define a workflow takes the form of an HTML5 based portal. Endpoints are dynamically generated within the service provider system based on an end point definition provided in the workflow definition. Endpoints can be used to expose a connection to third party workflows and datasets and to provide an end point to allow data and/or content to flow back into the service provider system 101 and seamlessly back down to the user device.
  • a workflow definition is owned by its creator (who can be the service provider) or a specific business account holder.
  • Figure 3 shows a system in which a third party server 104, in this case a manufacturer of a product bought by the user using user device 102 from a merchant using merchant device 103, is incorporated into the communication flow.
  • Figure 4 shows the communication flow between the devices involved.
  • the process starts by a user going to a checkout to purchase a product.
  • the merchant initiates the transaction by instructing the merchant device 103 of the purchase, this might be by scanning a barcode or such like.
  • a handshake then takes place where the merchant device 103 sends a user device request message 301 to which the user device responds 302.
  • the merchant device 103 then prepares the data to be transmitted to the service provider server 103 for the next stages in processing the payment.
  • the merchant device performs a check to determine if any additional workflows are required.
  • a warranty workflow is required, i.e. a warranty is to be provided with the product being purchased.
  • the process of setting up the workflow shall now be described with reference to haw this process relates to the payment process of Figure 2 where necessary.
  • the merchant device 103 sends a pre-created workflow dataset to the service provider system 10 at step 303.
  • This data can be encapsulated with the other transaction information being sent to the service provider system in order to minimise the data traffic through the network (i.e. with the data transmitted at step 203 in Figure 2).
  • the data set provides information necessary for the service provider system to set-up a communication channel with the third party server.
  • Communication channels are defined and then exposed as a unique REST based service through a unique URI.
  • a return URI can also be defined, which also provides a unique REST based service endpoint, available for the third party to post data to, and therefore back into the service provider system 101.
  • the workflow is built using a proprietary building language, ZyncFlow.
  • ZyncFlow exposes building blocks of ZyncFlow script to an end user; these blocks are sequentially dragged onto a "definition grid" which enables the user to define the following:
  • Data capture fields are defined fields and capture necessary data from the user's device or account, or alternatively request the data to be manually entered by the user into the data form dynamically created
  • Data actions For example, update a database, format data, and/or exposure of data.
  • the service provider system 101 sends a request for a warranty to the third party server 104 using the defined API as specified in the workflow definition at step 304.
  • the third party server is defined within the service provider system by an XML based Schema external to the service provider server 101 which was set up when the workflow was built as described above.
  • the third party server returns the required warranty.
  • a tracking key is used to ensure that the warranty being moved within the workflow relates to the specific merchant, the third party warranty provider and the end user.
  • the service provider system 101 When the service provider system 101 receives the warranty it then pre-populates the warranty with all of the required consumer data that it has stored in its memory.
  • the merchant device 103 may then be sent a message requesting the unique identifier for the product, but this is preferably automatically included in the initial communication at step 303.
  • the service provider server 101 then sends the warranty document to the user device 102.
  • the warranty is preferably sent to the user with the message for requesting approval of the payment or once the payment process has been completed along with the transaction completion authorisation code.
  • the user is then able to fill in any information into the warranty that has not been autocompleted by the service provider system 101 , and then approve the warranty at step 307.
  • the approval of the warranty is sent from the user device 101 to the service provider system 101 when the user approves the transaction.
  • the user could save the warranty and continue the completion of the warranty process at a later point in time. This might be preferable if the user is paying at a shop counter.
  • a tracking code is used to check where the warranty is in terms of which step in the defined workflow, and to also enable data being sent back to the service provider to be injected into the correct workflow for the correct warranty.
  • a copy of the warranty certificate is sent to both the third party server 104 and the user device 102.
  • the warranty can then be stored in the user device 102 by the mobile app, which allows the warranty to be easily accessed at any time.
  • the warranty process is then complete.
  • Another application of the workflow functionality is delivery tracking. If a consumer purchases a product to be delivered, it is common for there to be information available for tracking such a product. When the consumer purchases a product to be delivered, a workflow with a third party delivery company can be set-up to "pull" tracking data into the workflow.
  • the consumer can then use their mobile device to track the delivery information without the need for the merchant to issue a tracking code to the consumer, or the consumer having to visit a 3rd party website to manually enter a tracking code and track their delivery.
  • the tracking information is provided to the user within the service provider environment 100.
  • the same principles apply to a consumer wishing to have their goods made available to them for collection at a local store.
  • the merchant's system connects back with the service provider system to indicate the store where the goods are to be picked up from and when the goods are available.
  • the service provider system connects to the merchant's endpoints through the defined workflow and populates necessary data for that store to process.
  • the consumer's mobile device can now locate the store where their goods are to be picked up from, and read any other attached data in the workflow.
  • the merchant has not had to develop an internal workflow nor rely on the consumer speaking to staff to see when their goods are ready to be picked up.
  • the consumer's mobile device now provides the main interaction point between the merchant and the consumer. The consumer uses their own mobile device to track data on their pick up.
  • the workflow functionality can also be used to enable a user device as an input device to capture data for market research using a survey or basic questionnaire.
  • a business can create a "data form" and have it made available on the user's mobile device, e.g. after a purchase.
  • the user may complete the form by providing the requested data.
  • the completed form is then captured, along with user identifying and hardware specific data, all of which is then sent back into the defined workflow within the service provider system.
  • a third party market research company may therefore be included in the process for collecting the results of the questionnaire. This process allows for better data capture of individuals completing questionnaires. In addition, the efficiency of the questionnaire completion process is improved.
  • the security provisions provided by the service provider system mean that the requirement for secure communication certificates to be purchased and installed for secure questionnaires is not required.
  • the user device is provided with a user interface known as the Pinboard.
  • the Pinboard is a single user interface provided on the user device that allows for messages such as pushed messages used to deliver vouchers, loyalty scheme updates, and information on personalised deals to be displayed, without the user needing to go beyond the Pinboard section of the device.
  • Other information that can be included in the Pinboard includes electronic receipts, warranties, travel documentation, and presentations, which may be sent to the user by the pushing services or workflow functionalities described above.
  • Content can be delivered to the mobile device and stored locally through the communications channel (either pushed or pulled).
  • New content made available to the user is therefore delivered through a single efficient point, making the mobile device hardware more efficient at relaying tangible content to an end user.
  • the user no longer needs to browse their device for different content that is available to them, rather the user is taken directly to that content from the Pinboard and provided with options to "claim" and/or store that content, where appropriate, within their virtual wallet, i.e. the user account with the service provider.
  • the service provider system allocates the claimed content to a given user and registers it to a particular device. This process therefore removes the need for the device to remain connected to the service provider system as "claimed" content is now directly accessed from memory storage on the user's device.
  • some Pinboard messages deliver a direct link to external content.
  • FIG. 5 shows a homepage screen 400 for the app installed on the user device 102.
  • the homepage screen comprises various items 402, 403, 404, 405 that link the user to different parts of the service provider app. For example, each of these items links the user to one of account information, purchase information, loyalty information, or any other part of the app. The user is therefore able to browse content via items 402, 403, 404 and 405.
  • the pinboard icon 401 is also provided on the homepage of the app, which as has already been mentioned, provides a simple user interface that allows the user to quickly and easily view messages stored within the app.
  • the Pinboard is arranged as a celled or tiled screen that shows all of the latest messages to the user, informing them of Pinboard and associated content without the need for the user to access each and every message directly.
  • the Pinboard can be defined with different cell strucutres, for example, the size of cells, the number of cell, and when in a two dimensional array, the shape of the array can be variable, as can how the cells interconnect. In Figure 5, six interconnecting cells are shown, but the number of cells differs in alternative arrangements.
  • the cells are arranged in a rectangular grid structure.
  • the Pinboard Icon cells are split vertically and horizontally. However, in alternative arrangements cells may even be split diagonally so that multiple content is displayed on the cells.
  • the cells are arranged so that some messages can be displayed on a single cell, while other messages or content may be displayed on multiple cells. Multiple messages are therefore selected to be displayed on the cells of the Pinboard such that all of the cells are filled with information. For example, in Figure 5, three messages that are not related are displayed: a ticket is displayed across the top three cells, a voucher in the bottom left cell, and a loyalty point message in the bottom middle and bottom left cells. Providing multiple messages on the array of cells enables greater efficiency for a user to consume overview content at a glance.
  • the application operating the Pinboard groups new messages received by the user device 102 together based on their type and referenced content. For example, all new messages relating to vouchers are grouped together. These groups of messages are then ordered in terms of when they will be displayed on the Pinboard Icon cells. Complete groups are processed first, for example messages all containing vouchers are displayed, with each voucher being allocated a single cell that is animated and then locked with the other cells to deliver a single icon, displaying 3 vouchers. In some cases it is not possible to group messages in this way and also provide messages on all cells. Hence, in such circumstances a determination is made as to which content is to be displayed to fit on the available Pinboard cells. Figure 5 shows such circumstances.
  • the Pinboard icon remains static for a set period of time, before each cell unlocks and rotates to thereby display another cell.
  • the Pinboard cells can rotate in opposite directions and independently of each other.
  • the next Pinboard message content overview is displayed to the user, either on a single cell or across multiple cells to form one larger icon / cell.
  • New content at this point is allocated to each of the cells (complete group content again). This process is repeated so that the messages and content being displayed continually changes.
  • the user's Pinboard messages that are stored in the devices memory are cycled through in the Pinboard display.
  • Certain content for example a boarding pass on a flight, requires 3 cells to display sufficient detail to make the details of the boarding pass clear on the Pinboard. In such a case, the boarding pass is loaded only on the Pinboard when three cells are available together.
  • Other messages such as vouchers only need a single cell in order to provide sufficient detail to the user.
  • the number of cells taken up by each message depends on the information in the message that needs to be displayed.
  • each message is provided with a code indicative of a number of cells required by the message. This code is assigned according to the type of message, e.g. whether the message is a ticket or a voucher.
  • the required number of cells for a type of message is determined based on an average amount of information that needs to be presented to a user to make the message intelligible to the user.
  • each message is analysed to determine key information to be displayed and the content of the Pinboard message is created and the number of cells required to display the content is assigned.
  • the Pinboard message as displayed in the Pinboard icon is typically a "summary" of the full content. This is set-up when the Pinboard message was created. However, in some configurations and for some content, a summary is not provided, rather rules are applied to the message to determine the summary. For example, a voucher code and name is provided. Once the user selects a Pinboard message, they are taken to the full message (displayed full screen).
  • the system is arranged to determine which messages are to be displayed by analysing the possible messages that could be displayed and determining which of those messages could fit within the cell structure to thereby maximise the usage of the cell structure. While the above-exemplary embodiment of the invention relates to displaying content relating to a virtual wallet, it will be appreciated that the principles of the Pinboard are applicable for providing an efficient use of screen space for displaying any type of content to a user.
  • the service provider system is preferably
  • the service provider system When implemented as a cloud-based system, the service provider system includes intelligent cloud resource scaling functionality in order to maximise efficiency of resource usage.
  • the intelligent cloud resource scaling functionality is arranged to monitor the server capacity used by the service provider system and adjust the size of the cloud resources used to support the service provider system according to the monitored usage.
  • demand for use of the service provider system is high, for example for financial transactions in the run up to Christmas in the UK, the system is able to obtain additional resource from the cloud.
  • resource is low, the system is able to shed resource from the cloud. This therefore maximises the efficiency of resource usage, reduces the cost associated with use of such resources and raises the energy efficiency of the physical datacentre.
  • a monitoring system is required.
  • the monitoring is provided locally to the relevant cloud-based servers. This is necessary because scaling may take place within a certain country or geographical region when shops close at the end of the day and demand for use of the service provider system substantially drops. Whereas in other countries or geographical regions shops may just be opening due to time differences.
  • Local monitoring systems are deployed locally to a localised cloud data centre. For example, European servers may be located in Ireland and Amsterdam, while servers providing service to Canada and the USA may be situated in 2 locations across northern America. Hence, separate monitoring of these disparate servers is required. These monitoring services are connected to the cloud underlying operating system platform.
  • the local monitoring can be installed on a physical server located anywhere in the world.
  • the local monitoring system uses a scaling rules engine that uses the data captured by the system along with profile data obtained over a period of time to decide if new resources are required.
  • the parameters monitored by the local monitoring system include one or more of:
  • Database loads i.e. the amount of activity on the service provider system
  • the local monitoring system issues basic web requests to the service provider system and monitors the length of time it takes to receive a response.
  • Promotional offers i.e. if a large or popular merchant has recently issued an offer that may mean that a large number of users may soon be using the service provider system.
  • the system is able to vary, add or remove resources based on the current characteristics of the system as determined in accordance with the above
  • the system is able to perform a prediction as to what resources will be required in the future based on current information and past trends. It is preferable to predict expected resource requirements in order to attempt to ensure that there are sufficient resources in place to meet increased demand before demand forces the cloud resources to scale, which causes a lag period where the system will slow down as required resources are brought online.
  • the frequency with which the cloud resources are varied will depend on the frequency at which the cloud provider allows for resources to be added and/or removed.
  • the resources are monitored to allow for the resources to be adjusted as near to constantly as is possible.
  • Two specific independent algorithms are used by the service provider in order to determine scalability requirements.
  • the first focusses on the actual load of the service provider and allocates a numerical value based on the results obtained. This numerical value is checked against a tolerance number (an upper and lower value is configured based on that geographical location for that virtual cloud / server).
  • the second algorithm identifies anticipated loads and performance requirements on the service provider based on previous trends and analytics of data captured over a period of time. This result is allocated a numerical value and again, upper and lower tolerance values are read from configuration.
  • the two numerical values and tolerance values are then added to deliver a final numerical value and tolerance (lower and upper value).
  • the numerical value is then checked against a system configuration value and measured against the tolerance value. If the final value exceeds the upper tolerance value, then additional resources are required. The amount of additional resources is determined by the difference in the tolerance value. If the required resources are below the lower tolerance value then resources may be removed by the system.
  • the various methods described above may be implemented by a computer program.
  • the computer program may include computer code arranged to instruct a computer to perform the functions of one or more of the various methods described above.
  • the computer program and/or the code for performing such methods may be provided to an apparatus, such as a computer, on a computer readable medium or computer program product.
  • the computer readable medium could be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, or a propagation medium for data transmission, for example for downloading the code over the Internet.
  • the computer readable medium could take the form of a physical computer readable medium such as semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disc, and an optical disk, such as a CD-ROM, CD-R/W or DVD.
  • a physical computer readable medium such as semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disc, and an optical disk, such as a CD-ROM, CD-R/W or DVD.
  • An apparatus such as a computer may be configured in accordance with such code to perform one or more processes in accordance with the various methods discussed herein.
  • Such an apparatus may take the form of a computer system or data processing system.
  • a data processing system may be a distributed system.
  • such a data processing system may be distributed across a network.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Software Systems (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé, un appareil et un support lisible par ordinateur servant à paramétrer un canal de communication. Le procédé consiste à recevoir, au niveau d'un système de traitement de données, une communication venant d'une première partie, la communication comprenant des informations indiquant un canal de communication à paramétrer du système de traitement de données à une deuxième partie, et à paramétrer, au niveau du système de traitement de données, un canal de communication conforme aux informations indiquant un canal de communication à paramétrer.
PCT/GB2014/051004 2013-04-03 2014-03-28 Canal de communication sécurisé WO2014162116A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1306018.1 2013-04-03
GB1306018.1A GB2512615A (en) 2013-04-03 2013-04-03 Secure communications channel

Publications (1)

Publication Number Publication Date
WO2014162116A1 true WO2014162116A1 (fr) 2014-10-09

Family

ID=48445203

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2014/051004 WO2014162116A1 (fr) 2013-04-03 2014-03-28 Canal de communication sécurisé

Country Status (2)

Country Link
GB (1) GB2512615A (fr)
WO (1) WO2014162116A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017064295A1 (fr) * 2015-10-16 2017-04-20 Sdc A/S Sécurité de transaction améliorée

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110246377A1 (en) * 2010-03-31 2011-10-06 Bank Of America Corporation Conditional Establishment of a Communications Connection with a Mobile Terminal in Response to a Query From the Mobile Terminal

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101482949A (zh) * 2001-12-04 2009-07-15 M概念有限公司 使用移动电信设备以便于电子财务交易的系统及方法
WO2008119168A1 (fr) * 2007-04-03 2008-10-09 Cpni Inc. Système et procédé pour une découverte de vendeur et un transfert de données de paiement
US9634988B2 (en) * 2011-07-20 2017-04-25 Visa International Service Association Expansion device placement apparatus
MX2013002598A (es) * 2012-02-07 2013-11-05 Izettle Merchant Services Ab Verificacion de pin de sistema radial de integracion.

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110246377A1 (en) * 2010-03-31 2011-10-06 Bank Of America Corporation Conditional Establishment of a Communications Connection with a Mobile Terminal in Response to a Query From the Mobile Terminal

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017064295A1 (fr) * 2015-10-16 2017-04-20 Sdc A/S Sécurité de transaction améliorée

Also Published As

Publication number Publication date
GB201306018D0 (en) 2013-05-15
GB2512615A (en) 2014-10-08

Similar Documents

Publication Publication Date Title
US20210027272A1 (en) Switch Server System Interoperable with Mobile Devices Providing Secure Communications
CN109328445B (zh) 唯一令牌认证验证值
JP2022177233A (ja) 位置照合を使用する認証システムおよび方法
JP6400270B2 (ja) セルフサービス端末装置トランザクション
US11443301B1 (en) Sending secure proxy elements with mobile wallets
US20190356489A1 (en) Method and system for access token processing
US11580524B2 (en) Automated digital method and system of providing or sharing access
US8856043B2 (en) Method and system for managing data and enabling payment transactions between multiple entities
US20170200155A1 (en) Generating and sending encrypted payment data messages between computing devices to effect a transfer of funds
US9852479B2 (en) Mechanism for reputation feedback based on real time interaction
US20120028612A1 (en) Method and system for verifying an identification of a person
WO2015107442A1 (fr) Systèmes et procédés d'émission de cartes de paiement mobile par réseau de communication mobile et dispositifs connectés à internet
US11763275B2 (en) System and method for cryptocurrency point of sale
EP3616111B1 (fr) Système et procédé permettant de générer des justificatifs d'accès
US20150154584A1 (en) System to enable electronic payments with mobile telephones without risk of any fraud
CN114787845A (zh) 利用密码的计划交互
US20200294045A1 (en) Interaction processing system and method
WO2014162114A1 (fr) Système de traitement de contenu
WO2014162116A1 (fr) Canal de communication sécurisé
WO2014162113A2 (fr) Système de communication sécurisée
GB2512616A (en) Resource control system
WO2014162115A1 (fr) Système d'acheminement de communications
KR101596434B1 (ko) 결제정보 분리를 이용한 온라인 전자금융거래 인증방법
US20230120485A1 (en) Token-For-Token Provisioning
US20230409752A1 (en) System and method for localized permission-based sharing of personal information

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14715099

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14715099

Country of ref document: EP

Kind code of ref document: A1