Note: Descriptions are shown in the official language in which they were submitted.
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
SYSTEMS FOR PROCESSING ELECTRONIC TRANSACTIONS
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims all benefit, including priority, of
United States Provisional
Patent Application Serial No. 62/062,467, filed 10 October 2014 and entitled
SYSTEM AND
METHOD FOR ELECTRONIC PAYMENT, the entire contents of which are incorporated
herein
by this reference.
FIELD OF THE INVENTION
[0002] The present disclosure relates generally to systems, methods, and
machine-
interpretable programming and/or other instruction products for the secure
processing of data.
In particular, the disclosure relates to the secure generation, processing,
manipulation, storage,
and administration of electronic data useful in the processing of payments and
other electronic
transactions.
[0003] Aspects of the generation, processing, manipulation, storage, and
administration of
data disclosed herein may be subject to regulation by governmental and other
agencies. The
disclosure herein is made solely in terms of logical, economic, and physical
communications
possibilities, without regard to statutory, regulatory, or other legal
considerations. Nothing herein
is intended as a statement or representation that any system, method or
process proposed or
discussed herein, or the use thereof, does or does not comply with any
statute, law, regulation,
or other legal requirement in any jurisdiction; nor should it be taken or
construed as doing so.
INTRODUCTION
[0004] Electronic payment schemes utilize various techniques and
methodologies to reduce
risks association with counterfeiting and other forms of fraud, while
providing convenient and/or
otherwise advantageous forms of payment.
[0005] Such payment schemes may be employed in the execution of
transactions involiving
the transfer of any type of value, including for example debit transactions;
credit transactions;
transactions involving virtual currency; coupons; gift cards, loyalty,
discount, and other rewards
programs, etc., and may be implemented through the use of various forms and
components of
networked systems, including for example various forms of backend payment-
processing
servers, point-of-sale terminals, and/or account administration systems
operated by financial
1
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
institutions, in addition to mobile and/or other networked systems used by
purchasers and other
users.
[0006] Electronic payment schemes may adhere to electronic payment
standards. An
example electronic payment standard is the EuropayTM, MasterCardTM and Visa TM
(EMV)
standard, which enables interoperation of integrated circuit cards (chip
cards) with various
systems.
[0007] Security is an important consideration in electronic payment
schemes. The EMV
standard provides a set of rules and procedures that improve security against
counterfeiting and
fraudulent activities through the use of technologies such as encryption,
processing restrictions,
multi-factor authentication, etc.
[0008] However, the requirement for protection against fraudulent
transactions co-exists
with the desirability of efficiency, convenience, and other considerations in
conducting
transactions. Various technologies may be used to obtain and/or otherwise
collect data when
generating a request to authorize a transaction, with varying effects on such
considerations.
[0009] For example, such technologies may include the use of contact chips,
e.g., in
accordance with the ISO 7816 standard. According to this standard, data
elements read from an
EMV contact chip card may be used to initiate the financial transaction. The
data, including for
example cardholder verification results, may allow a financial institution to
verify that a proposed
transaction in fact originated with, or through, a genuine bank-issued chip
card, and thereby
allow authorization to be completed with a higher degree of confidence than
through
conventional means.
[0010] Other types of technology may include the use of contactless
chips, e.g., in
accordance with the ISO 14443 standard. According to this standard, data
elements read from
an EMV contactless chip card may be used to initiate a financial transaction.
[0011] A potential challenge associated with conducting electronic payment
transactions
may be the need for backwards compatibility with existing technology. A wide
variety of
systems and technologies are currently in use; and existing infrastructure and
systems may be
slow to adapt to technological advances. As a result, there may be a wide
range of different
technologies in use in the market. For example, while some technologies may be
based solely
on Near-Field Communications (NFC) technologies, not all point-of-sale (POS)
terminals and/or
mobile communication devices (e.g., smart phones, tablet computers, etc.) have
the ability to
communicate using NFC without potentially costly upgrades.
2
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
[0012]
In such and other circumstances backwards compatibility can provide
significant
improvements in the efficiency and palatability of systems upgrades.
[0013]
Additional limitations may be associated with the use of NFC technologies in
implementing POS terminals and/or mobile communications devices. For example,
such
devices may be configured based on the specifications of individual issuers
(e.g., bank) and/or
payment schemes (e.g., MasterCard(R) or Visa(R)); and where it is even
possible to modify the
configurations of such devices, it may be necessary to do so repeatedly, in
order to to
communicate with each new desired issuer, payment scheme, etc. For example,
where an NFC
antenna is tuned the specifications of a first issuer at a POS terminal, it
may be necessary to
turn the antenna off to enable processing of a transaction from another
issuer.
[0014]
Further, some NEC based payment processes may be configured such that only one
transaction is processed at a time by a given POS or merchant transaction
processing system;
and transactions may need to be processed in a particular order. This can
cause unnecessary
and undesirable delays where, for example, customers must form lines in order
to complete
purchase transactions.
[0015]
Accordingly, the ability to receive and/or process a high volume of
transactions may
be impacted, which may result in commercial disadvantages for retailers.
Further, there may be
a number of different technologies available at a given time and a flexible
solution may be
required to reach a wide number of users whose mobile devices have
heterogeneous
functionality.
[0016]
Delivery of payment information from purchaser devices and/or payment
information/processing platforms (such as POS terminals) to payment networks
(such as back-
end payment or transaction processing systems) is a critical process that may
benefit from
flexible and secure solutions that may be interoperable across a range of
different technologies.
[0017] Another challenge that may exist with conventional solutions is the
difficulty in
integrating other types of information into a payment transaction. For
example, a purchaser or
other user may be subscribed to various loyalty programs, collecting various
coupons, etc., and
may benefit from solution(s) wherein a transaction processor automatically
applies associations
and relationships between the user and/or his or her purchasing device, and
such programs
and/or coupons.
[0018]
It may be difficult and/or inconvenient for a user to carry all such
information in the
form of separate physical cards, and there may be lost opportunities for
collecting credits in
3
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
other types of programs as users may often forget to carry cards and/or it may
be too
inconvenient as an extra step to input the information.
[0019] Accordingly, new, improved, secure, and/or flexible solutions may
be helpful for
overcoming some or all of the shortfalls of solutions currently available in
the market.
SUMMARY
[0020] In one aspect, there are provided a variety of computer-
implemented platforms,
including account administration systems, back-end and other transaction-
processing systems,
and various controllers, configured for use in conducting electronic payment
and other electronic
transactions between purchasers, lessors, and/or other acquirers or
transferees of property,
services, etc., and merchants. In various embodiments, such platforms include
any or all of
computer system(s) configured for the generation of payment and other
transaction data sets, or
structures, containing various type(s) of payment data; mobile communication
device(s)
operable by human and/or other users to communicate with such platforms and
configured to
interpret and use the generated data structures or sets to communicate and/or
otherwise
process electronic messages or signals reflecting payment and/or other
instructions; and point-
of-sale (POS) and/or other merchant terminal(s) or transaction processors
configured for
communication with such mobile device(s) and/or platform(s) to receive the
same and other
electronic messages, and generate requests to process various aspects of such
transactions.
[0021] In a further aspect, there are provided methods, implemented by,
at, or in
conjunction with mobile communication devices, which may be used as
transaction system
controllers for conducting electronic payment and other transactions. Such
methods can
include, for example, submitting a payment or other transaction request to a
computer system,
such as a back-end or other. transaction processing system, and/or a financial
institution (El)
data processing system; receiving from the computer system one or more data
sets, or
structures, containing payment and/or other transaction data; and generating
one or more
electronic messages representing payment and/or other transaction instructions
using the data
set(s).
[0022] In a further aspect, there are provided further methods
implemented by, at, or with
such controllers or communication devices, for conducting electronic payment
and other
transactions. Such methods can, for example, include: receiving and/or
interpreting data
representing identifiers and/or other codes associated POS and/or other
merchant transaction
terminals or systems; receiving data sets which include payment and/or other
transaction data,
4
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
or instructions, from back-end or other transaction processing computer
systems; generating
electronic messages representing payment and/or other transaction
instructions, and using the
data sets and the identifiers associated with the merchant terminals in
processing transaction
requests.
[0023] In further aspects, there are provided methods, implemented at back-
end and other
transaction-processing computer systems, which include various forms of
generating data sets
containing payment and/or other transaction data and/or instructions; and
transmitting such data
sets to mobile communications devices and other network communication systems
associated
with consumers and other users.
[0024] Payment and/or other transaction data suitable for use in
implementing various
aspects and embodiments of the invention may include locators or other
references, such as
uniform resource locators (URLs) useful for accessing or otherwise identifying
payment and/or
transaction data stored in remote memories, or memory(ies) not immediately
associated with or
controlled by the requesting device(s). Methods in accordance with such
aspects and
embodiments may include retrieving, interpreting, and/or otherwise processing
such additional
transaction information using the locators.
[0025]
Transaction-related data sets suitable for use in implementing various aspects
and
embodiments of the invention, and messages comprising or consisting thereof,
may include
data useful for generating visual and/or other types of human- and/or machine-
readable
representations of data sets or structures.
[0026]
Transaction-related data structures suitable for use in implementing various
aspects
and embodiments of the invention may include one or more EMV-compliant data
tags.
[0027]
Transaction-related data structures suitable for use in implementing various
aspects
and embodiments of the invention may include one or more EMV-compliant and
other payment
data tags, or elements, comprising delimiters adapted to configure the payment
elements to
single or other limited numbers of use.
[0028]
Transaction-related data structures suitable for use in implementing various
aspects
and embodiments of the invention may include one or more EMV-compliant data
sets or
elements, each configured or otherwise associated with one or more maximum
transaction
value limits.
[0029]
Transaction-related data structures suitable for use in implementing various
aspects
and embodiments of the invention may include data representing information
associated with at
5
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
least one of loyalty programs; coupon, discount, and gift cards or accounts;
and/or other reward
programs.
[0030] Computer systems suitable for use in implementing various aspects
and
embodiments of the invention may be configured for the generation and updating
of user
profiles associated with user of mobile communications devices and other
components of such
systems.
[0031] In various aspects and embodiments, there are provided methods,
implemented at
POS and/or other merchant terminals, which can, for example, include:
receiving data
messages from mobile communication devices, the messages representing payment
and/or
other transaction-related instructions; parsing and/or otherwise interpreting
the messages to
extract transaction information; and generating requests to process pending
transactions
associated with the transaction information.
[0032] In various aspects and embodiments, reception of messages from
mobile devices or
other controllers by merchant and/or other transaction processing systems may
include optically
scanning, or otherwise implementing machine-reading processes, to interpret
the messages
received from the mobile devices.
[0033] In various aspects and embodiments, the invention provides
methods for conducting
electronic payment and/or other transactions through the use of multiple
mobile communication
devices or controllers. Such a method can, for example, include: submitting,
by a first mobile
device, a payment request to a merchant, financial institution and/or other
transaction-
processing computer system for a payment to be made by a second mobile device
using
payment data from a first user; receiving, by the second mobile device, a data
structure
containing payment data for the first user from the computer system; and
generating, by the
second mobile device, a message reflecting payment instructions to an account
associated with
the first user using the received data structure.
[0034] In various aspects and embodiments, the invention provides
platforms, such as
back-end and other transaction-processing platforms, for conducting electronic
payments and
other electronic transactions under the entire or partial control of such
controllers. Such
platforms can, for example, include: one or more utilities (i.e.,
applications, programs, and/or
other instruction sets) for processing of transaction requests; one or more
utilities for generating
data elements and sets; and one or more utilities for provisioning mobile
devices; wherein the
one or more utilities for processing transaction requests, the one or more
utilities for generating
6
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
data elements and sets, and the one or more utilities for provisioning mobile
devices are
configured for communication and co-operation in conducting electronic payment
transactions,
wherein transaction requests are parsed, data elements are generated based on
the parsed
transaction requests, and the mobile devices are provisioned using the
generated data
-- elements, and sets thereof.
[0035] In various aspects and embodiments, the invention provides
platforms, such as
back-end and other transaction-processing platforms, for conducting electronic
payments and
other electronic transactions under the whole or partial control of such
controllers. Such a
platform can, for example, include: one or more non-transitory computer-
readable memories
-- storing data representing instruction sets; one or more processors for
execution of such
instruction sets, the instruction sets including instructions which when
executed, cause the
processors to: generate data structures containing payment and/or other
transaction data; and
transmit data structures to mobile devices associated with users.
[0036] In various aspects and embodiments, the invention provides
merchant terminals for
-- conducting electronic payment and other electronic transactions. Such
merchant terminals can,
for example, include: one or more non-transitory computer-readable memories
storing data
representing instruction sets; one or more processors for execution of the
instruction sets, the
instruction sets including instructions which when executed, cause the
processors to: receive
messages from mobile and/or other communication devices representing
instructions pertaining
-- to electronic payments and other electronic transactions; parse the
messages to extract
transaction information; and generate requests for processing various aspects
of the
transactions.
[0037] In various further aspects, the disclosure provides corresponding
systems and
devices, and logic structures such as machine-executable coded instruction
sets for
-- implementing any or all of such systems, devices, and methods.
[0038] It is to be understood that the various aspects and embodiments
of the invention are
not limited in their scope or application to the details of construction and
to the arrangements of
the components set forth in the following description or illustrated in the
drawings. As will be
appreciated by those skilled in the relevant arts, the invention is suitable
for implementation in a
-- very wide variety of embodiments, using components or parts substantial
portions of which may
be currently known, and others of which will doubtless hereafter be developed.
It is further to be
understood that the phraseology and terminology employed herein are for the
purpose of
description and should not be regarded as limiting.
7
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
BRIEF DESCRIPTION OF THE DRAWINGS
[0039]
Various aspects and embodiments of the invention are illustrated in the
accompanying drawings, which are meant to be exemplary and not limiting, and
in which like
references are intended to refer to like or corresponding parts:
[0040] FIG. 1 is a block schematic diagram of a system for processing
electronic
transactions in accordance with various aspects and embodiments of the
invention.
[0041]
FIG. 2A is a schematic diagram of an embodiment of a process for conducting
electronic transactions in accordance with various aspects of the invention.
FIG. 26 is a
schematic process flow diagram showing data communications flow consistent
with the
embodiment of FIG. 2A.
[0042]
FIG. 3A is a schematic diagram of an embodiment of a process for conducting
electronic transactions in accordance with various aspects of the invention.
FIG. 36 is a
schematic process flow diagram showing data communications flow consistent
with the
embodiment of FIG. 3A.
[0043] FIG. 4A is a schematic diagram of an embodiment of a process for
conducting
electronic transactions in accordance with various aspects of the invention.
FIG. 4B is a
schematic process flow diagram showing data communications flow consistent
with the
embodiment of FIG. 4A.
[0044]
FIG. 5A is a schematic diagram of an embodiment of a process for conducting
electronic transactions in accordance with various aspects of the invention.
FIG. 56 is a
schematic process flow diagram showing data communications flow consistent
with the
embodiment of FIG. 5A.
[0045]
FIG. 6 is a schematic diagram illustrating possible data flow schemes between
various systems and/or components during a payment flow pull transaction,
according to some
embodiments of the invention.
[0046]
FIG. 7 is a schematic diagram illustrating the possible data flow between
various
systems and/or components during a payment flow push transaction, according to
some
embodiments.
[0047]
FIG. 8 is a schematic diagram of a system for processing electronic
transactions in
accordance with various aspects and embodiments of the invention, including
namely a
computer device, and associated communications networks, devices, software and
firmware
8
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
that may be configured to provide a platform for implementing one or more
aspects and
embodiments of the invention.
DETAILED DESCRIPTION
[0048]
Currently-preferred embodiments of methods, systems, and apparatus according
to
the invention are described through reference to the drawings.
[0049]
Electronic payments may be utilized to conduct payment transactions between
one
or more parties, and may be linked to a wide variety of further types and uses
of financial data
systems. In some embodiments, financial information may also be transferred
through to one or
more external and/or backend systems, such as those associated with various
acquirers, point-
of-sale (POS) and other merchant service providers, third party payment
processing services,
loyalty, reward, and other financial services companies, regulators and other
financial
institutions, etc. Electronic payment transactions may be conducted through
the use of various
types of funding sources or accounts, including for processes involving
virtual currency, gift
cards, credit cards, charge cards, debit cards, InteracTM transactions,
virtual credits (e.g. airtime
credits), loyalty points, rewards programs, etc., and corresponding value
accounts. In some
embodiments, electronic payment transactions may also be linked to other types
of systems
and/or accounts (e.g. payment through a credit card at certain merchants may
also be
associated with one or more loyalty programs administered by or otherwise
associated with that
merchant or other merchants or service providers). In some embodiments,
electronic payment
transactions may also be linked to coupons and other forms of discounts. In
some
embodiments, electronic payment transactions may also include refunds, void
transactions, etc.
[0050]
Various aspects and embodiments of the invention are suitable for use in
conjunction
with a wide variety of purchase, lease, rental, borrowing, transfer, and other
types of
transactions relating to products, services, and intangible properties. For
example, such
transactions may be initiated in-store, online, between individuals, etc., and
may involve the use
of POS terminals and/or various other types of merchant transaction devices.
In some
embodiments, a POS or other merchant transaction processing system may simply
be
represented by an image or graphically-embedded code, such as a machine-
readable quick
response (QR) code or a bar code; or by a radio frequency identification
(RFID) or NFC tag
comprising a machine-readable coded identifier which serves to adequately or
uniquely identify
the merchant system. Such codes may, for example be used in regards to payment
information
transactions where the payment information is pushed from a mobile device to a
point-of-sale
terminal, a checkout counter, etc.
9
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
[0051] Transactions implemented in accordance with various aspects and
embodiments of
the invention may be processed synchronously and/or asynchronously, in real
time, near real-
time, batch mode, or according to any other desired or otherwise suitable
process, protocol, or
mode.
[0052] Electronic payments may involve the communication of transactional
and/or other
financial information between one or more parties, any or all of which
communication(s) may be
conducted using any suitable media and/or technologies, including for example
QR codes, bar
codes, NFC exchanges or transmissions, Bluetooth, TCP/IP / UDP messages,
extended
markup language (XML) messages, SMS or other text files or protocols, database
records, etc.
[0053] The communication of transactional and/or financial information may
be in conformity
with any of a wide variety of standards or protocols, including for example
the payment cards
industry (PCI) security standards, the EuropayTM, MasterCard TM and Visa 1M
(EMV) standard,
the Financial Information Exchange (FIX) protocol, etc. Such standards may be
used, in
implementing various aspects and embodiments of the invention, in ways which
allow for
increased flexibility in transaction implementation, and/or to increase
security, authentication,
fraud protection, privacy, and other aspects of transaction processing.
[0054] In various aspects and embodiments the present disclosure provides
systems,
methods and non-transitory computer readable memories for electronic payments.
Such
memories may comprise either or both of informational data (representing
account numbers and
other identifiers, algorithmic operands, etc.), and instruction sets which may
be read,
interpreted, and executed by various forms of data processors in order to
implement a wide
variety of tasks disclosed or suggested herein. Various methodologies and
techniques can be
used to conduct electronic payments, including for example (1) the ability for
payment
information to be pulled from a mobile or other network communication device,
and (2) the
ability for payment information to be pushed from such a device (for example,
to authorize future
transactions or to authorize pending transactions).
[0055] The various embodiments described herein may interact with a wide
variety of
physical elements or components, such as physical POS terminals, mobile and
other
communication devices and controllers, etc.; and may interconnect with a wide
variety of
computer and/or electronic signal (e.g., data) processing systems
incorporating various
processors and/or computer readable media. There may be significant cost
savings and/or
commercial advantages where computerized and/or electronic implementation is
used, as there
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
may be a high volume of transactions utilizing complex authorization and/or
cryptographic
means to conduct transactions securely and privately.
[0056]
Integration of a very wide variety of types of information (e.g. coupons,
loyalty
information, gift cards, promotions, and other useful information) along with
data directly related
to a payment transaction during a payment or other transaction process may
provide significant
advantages, particularly due to the establishment and use of trusted
relationships (sometimes
referred to as "circles of trust") as a typically desirable, pre-existing
aspect of the validation and
authentication of payment and other transactions.
[0057]
Among the advantages provided by various aspects and embodiments of the
invention are the ability to process a large volume of transactions; the
ability to interoperate with
mobile and other communication devices with a wide range of available
technologies; the ability
to automatically recognize and process beneficial information (e.g. coupons,
loyalty) which may
not be strictly required in order to complete a payment or other transaction.
[0058] In some embodiments, the generation and/or provision of unique
payment
information, including for example limited or unlimited payment
authorizations, to a mobile or
other communication device may be performed for each transaction. So, for
example, payment
information may be unique for each transaction process, and accordingly may be
valid or
otherwise authorized for only one transaction.
Alternatively, such authorizations and
information may be provided with the suitable flags or other delimiters
identifying them as good
for use in multiple transactions. For example, a pre-authorized payment token
may be provided
with a purchase value or cap, the token being good for multiple transactions,
with the value or
cap being decremented accordingly upon completion of each transaction, until
the value is fully
or sufficiently exhausted (e.g., until the value of the token falls to zero or
beneath a minimum
pre-defined threshold).
[0059] Payment tokens and other transactional data sets may be generated in
such fashion
as to adhere to any one or more desired electronic payment standards or
protocols (e.g., the
EMV standard). Conveniently, in some process workflows for some embodiments,
such
generation permits transaction processing, once payment information has been
received at a
POS or other merchant processing terminal, to be performed in substantially
the same manner
as where payment information is provided by way of conventional payment means
(e.g., a
conventional chip or magnetic-stripe payment card).
11
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
[0060] In some embodiments, the provision and/or generation of payment
information to a
mobile or other purchaser device are not contemporaneous with a transaction.
For example,
data elements and/or data representing authorized payment information may be
provisioned to
a mobile device in advance of a transaction, such that the mobile device is
able to generate
and/or present sufficient payment information independent of a backend system.
Functionality
to allow the provisioning of a mobile device independent of a transaction may
be used to enable
transactions where, for example, a mobile device is unable to connect to a
network. In such
situations, the mobile device may simply utilize information previously stored
on the device to
generate and/or display a suitable message (e.g., reflective of payment
instructions) for
transmission to a POS terminal. In some cases, such stored, pre-authorized
payment
information may expire after a pre-defined time period (e.g., one hour, one
day, etc.). In some
cases, the stored information may be used only for a pre-defined number of
transactions (e.g.,
one transaction, or a few transactions).
[0061] Similarly, the input of codes or other identifiers to identify a
POS terminal or other
merchant system in order to facilitate completion of a transaction, for
example in order to enable
a communications exchange between a back-end payment processing system and a
merchant
transaction processor in establishing or conducting a push payment transaction
as described
herein, may also be temporally distinct from a transaction. Such functionality
may be useful in a
variety of circumstances, such as when the mobile device is unable to connect
to a suitable
network, or where batch or other parallel processing is desired, in order to
balance information
transfer and reduce customer waiting times in checkout lines, etc.
[0062] FIG. 1 is a block schematic diagram of a transaction processing
system 1000
suitable for use in implementing electronic payments and other transactions in
accordance with
the disclosure herein. System 1000 may include a wide number and variety of
components,
some or all of which may be commonly or separately controlled, including for
example any one
or more data generation systems 100, such as account administration systems;
financial
institution systems 114; mobile communications devices or other controllers
106; POS terminals
102 and/or other merchant transaction processing systems 103, third-party
transaction
processing and/or adjudication systems (sometimes referred to herein as
"backend" systems)
108, and a wide variety of supporting external systems 110 and databases 112,
116, etc.
[0063] A payment token generation system 100, for example, may be
independent of, or
may be associated, either by ownership, partnership, administrative control,
contract, or other
means with, one or more financial institutions 114. In some embodiments, for
example, a
12
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
system 100 may include one or more servers operated by a financial institution
114, and one or
more databases 124. In other embodiments, an account administration or other
data generation
system 100 may be a system operated independently of the financial institution
114. For
example, a system 100 may be implemented using one or more servers having one
or more
processors, operating in conjunction with one or more computer-readable
storage media,
configured to provide backend services, such as data processing, data storage,
data backup,
data hosting, among others.
[0064] The various systems, subsystems and/or databases depicted in FIG.
1 are provided
as examples. So, there may be more, less, different and/or alternate systems,
subsystems
and/or databases, and two or more subsystems may be implemented as a single
system,
subsystem and/or database. Each of the systems, subsystems and/or databases
may be
implemented using any software, hardware, firmware, and/or other technologies,
and/or any
combination(s) thereof suitable for implementing the systems and process
described herein, for
example, as further described below with reference to FIG. 8.
[0065] Databases 112, 116 and 124, for example, may be implemented using
various
database technologies, such as relational databases (e.g. SQL databases), flat
databases,
Microsoft Excel TM spreadsheets, comma separated values, etc. If for example
any of databases
112, 116 and 124 are implemented using relational database technology, the
databases 112,
116 and 124 may be configured to further store relationships between various
data records.
Moreover, any databases 112, 116 and 124 may be implemented using various
hardware or
software technologies, such as solid state or hard disk drives, redundant
arrays of independent
disks, cloud storage, virtual storage devices, etc.
[0066] The systems, subsystems, databases, and or other components of
system 1000 may
be configured for communication between one another, and any means suitable
for
implementing the purposes described herein; for example any of a wide variety
of application
programming interfaces (APIs) and/or other types of communication may be
utilized. Such an
API may be implemented via various technologies, such as Simple Object Access
Protocol
(SOAP), interfaces developing through exposing functionality using programming
code,
representational state transfer (REST adhering programming techniques), etc.
[0067] System 1000 and any of its components may be implemented in various
ways, and
some embodiments may require implementation using one or more processors,
which may be
connected to one or more non-transitory computer readable media. In some
embodiments, any
or all components of a system 1000 may be implemented through the use of
distributed
13
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
networking resources, which, for example, may include various cloud-computer
based
implementations.
[0068] In some embodiments of the invention, system 1000 comprises or
consists of a set
of distributed computing devices connected through a communications network.
An example of
such a set of distributed computing devices would be what is typically known
as a "cloud
computing" implementation. In such a network, a plurality of connected devices
operate together
to provide services through the use of their shared resources.
[0069] A cloud-based implementation for conducting electronic payments
may provide one
or more advantages including: openness, flexibility, and extendibility;
centralized or
decentralized management; reliability; scalability; being optimized for
computing resources;
engaging variable computing resources based on demand, having an ability to
aggregate
information across a number of users; and ability to connect across a number
of users and
conduct data mining and/or other data analytics.
[0070] While embodiments and implementations of the present invention
may be discussed
in particular non-limiting examples with respect to use of the cloud to
implement aspects of the
system platform, a local server, a single remote server, a software as a
service platform, or any
other computing device may be used instead of the cloud.
[0071] Token generation system(s) 100 may be configured for
interoperability, directly or
indirectly, with POS terminals or other merchant transaction processing
systems 102, backend
systems 108, external systems 110, external databases 112, database 124 and/or
account
databases 116. System(s) 100 may be configured for communication with any
number of
mobile communication devices 106 through any one or more public and/or private
networks
150, the mobile device 106 generally being associated with and operated by a
human user 104.
The one or more networks 150 may include any or all of the internet,
intranets, point to point
networks, wireless/wired links, public or private telephone systems and local
and wide-area
networks, etc. Networking technology may include any suitable technologies,
such as TCP/IP,
UDP, WAP, etc.
[0072] In some embodiments, database(s) 124 may be configured to store
data
representing information and/or transaction logic elements related to users,
such as profile(s)
having their corresponding account information and related or unrelated
coupons, loyalty
program information, etc. Such database(s) 124 may also be configured to store
a set of rules
and relationships, which may be applied during transactions to automatically
relate or otherwise
14
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
introduce or involve transactions with loyalty programs and/or coupons. For
example, a fuel
purchase transaction at a gas station may also trigger the crediting of the
user's frequent flyer
miles program.
[0073]
Mobile communication device(s) or controller(s) 106 can be of any type(s) or
form(s),
and comprise any systems and/or components suitable for implementing, or
otherwise
compatible with, the purposes disclosed herein. In various embodiments, for
example, a
controller 106 may include one or more electronic data processors configured
for interpreting
and processing coded data representing mobile applications and other
instruction sets that may
be configured for use in communicating and/or otherwise interacting with the
system 100. In
some embodiments, for example, such mobile applications may also be configured
for the
manual and/or automated input and/or storage of other information associated
with payment
transactions, such as loyalty rewards information, gift cards, coupons, etc.,
and the mobile
applications may be configured for operation based upon a user's profile,
which may be stored
locally or in the database 124. The user's profile may also be received and/or
accessed from
account databases 116. In some embodiments, account databases 116 may also
store loyalty,
gift card, and/or coupon information associated with an account associated
with a user 104.
[0074]
Mobile device(s) 106 (also referenced as 800 in Figure 8) may be configured to
present and/or interpret various types of machine-readable codes (e.g. bar
codes, OR codes,
RFID and/or NFC codes) using displays 808, cameras and other optical readers
835, etc.,
and/or NFC, RFID, and other wireless transceivers; to wirelessly, optically,
and/or otherwise
transmit various messages and types of messages using network interfaces 811;
and to display
images, notifications, prompts, interactive or other interface screens, etc.
using I/O interface
devices 804. Optically-interpretable, wireless, and other codes, signals, or
data types may, for
example be presented by a device 106 to a POS 102 as part of the process of
setting up or
completing the communication of payment and other transaction instructions.
[0075]
In various embodiments, the mobile device/controller 106, 800 may be
configured to
generate codes of various types or formats, in order to facilitate processing
in accordance with
the disclosure. In some embodiments, the device 106 receives codes containing
the various
messages, in various forms, generated by various types and forms of external
systems (e.g., at
system 100).
[0076]
Device(s) 106, 800 suitable for use in implementing various aspects and
embodiments of the invention may comprise various network and other
communications
systems and interfaces, such as Bluetooth, RFID, NEC and other wireless, wired
or wireless text
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
messages, etc. The mobile device 106 may include various user input means,
such as one or
more keyboards, keypads 815, touchscreens 808, cameras or other optical
interfaces 835, etc.
Mobile device(s) 106 may include various sensory devices 835, such as
accelerometers;
gyroscopes; satellite positioning or other location sensing or determining
means; fingerprint
readers, retina scanners, and other biometric sensors 835; etc. Mobile
device(s) 106 may also
include various forms of output systems, including wireless, wireline, and
optical, sonic, and
tactile output devices such as vibrators. Such optical devices may, for
example, include
screens, lights, etc., adapted to generate and output human and/or machine-
readable signals,
including for example images on display screens, coded light signals, etc.
[0077] Data representing codes, instruction sets, and/or other data
generated, received, or
otherwise accessed by, or stored within, mobile devices 106 in accordance with
the invention
may be stored in any persistent, transient, or other memory(ies) and/or memory
devices 801,
823, 803, 804, 806, etc. (see e.g., FIG. 8), comprised by or otherwise
accessible by such
device(s) 106 and compatible with the purposes disclosed herein. Such
memory(ies) may, for
example, include secure memory elements incorporated by the device(s) 106, SD
or other
removable memory cards coupled to the device(s), and/or memories residing off
the device
(e.g., in the 'cloud' or other remote networked location) accessible by the
device by wireless or
other means, etc.
[0078]
It should be understood that mobile device(s) and other controller(s) 106
suitable for
use in implementing the various aspects and embodiments of the invention may
be of any types
or forms compatible with the purposes disclosed herein. They may, for example,
comprise or
consist of any of a wide variety of hand-held two-way wireless paging
computers, wirelessly-
enabled palm-top computers, smart or other mobile telephones with data
messaging
capabilities, tablet computers, portable digital media players, or wirelessly
enabled laptop
computers, but could be any type of mobile data communication device capable
of sending and
receiving messages, e.g., via a network connection. These can include, for
example,
automobiles, bicycles; wallets, briefcases, and other accessories; smart
watches, necklaces,
bracelets, and other forms of jewelry or clothing; and/or any other things or
devices comprising
suitable data processors and communications systems
[0079] Point-of-sale (POS) terminals and other merchant transaction
processing systems
102, 103 may be software based, hardware based, or combination(s) of both. In
some
embodiments, POSs 102 may be configured to connect and/or otherwise
communicate with
network(s) 150. POS terminals 102 may include a wide variety of transaction-
related and non-
16
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
transaction-related components, including for example cash registers, and
other forms of
payment-receiving, holding, or processing devices. POS terminal(s) 102 may
include or be
coupled to back-end or other computer systems 103 located at or otherwise
associated with the
corresponding merchant enterprise. Such merchant computer systems 103 may, for
example,
be configured to access, store, and/or provide information associated with
payment
transactions, such as loyalty rewards information, payment card data, customer
data, etc. In
some embodiments, a separate POS device may be used to capture payment
information, and
thereafter passed to back-end merchant 103 or third party processors 102, 108,
114, etc. In
some embodiments, POS terminal(s) 102 may include or otherwise access and
execute
software configured to integrate the POS(s) with multiple external and backend
systems 110,
etc., including systems associated with the storage, administration, or other
processing of
coupons, loyalty points, discounts, etc., to process a secure payment
transaction.
[0080]
POS terminal(s) 102 in accordance with the invention may be configured such
that
they may receive transaction information from one or more users, which may
then be
transmitted to backend or transaction adjudication systems 108 for processing.
Such
information may be transmitted to the backend systems 108 by way of network
105, and/or by
way of direct link(s) interconnecting terminal(s) 102 and backend system(s)
103, 108. POS
terminals 102 may be of various types, and may have differing input
capabilities.
[0081]
For example, some POS terminals 102 may include attached or integrated
scanning
devices, cameras, RFID/NFC receivers/transmitters, and/or other input means.
Such input
means may be used to capture various pieces of information related to
transaction information,
which may be embedded or otherwise included in QR codes, bar codes, RFID or
NFC
message, tags etc.
[0082]
In some embodiments, POS terminals 102 may also be configured to receive
messages in other formats and across other media, such as through Bluetooth
messages, NFC
messages, RFID or other wireless messages, text messages, etc., as may be
transmitted by
mobile devices 106 as part of payment instructions.
[0083]
POS terminal(s) 102 may also be configured to receive, parse, and/or otherwise
data
elements, such as those related to various electronic payment standards. POS
terminal(s) 102
may be configured to communicate with external systems 110 to obtain various
pieces of
information associated with a transaction, such as loyalty information, coupon
information,
advertising and/or tracking information, etc. For example, a POS terminal 102
may be
configured such that the terminal may recognize that a purchaser or other user
is a member of a
17
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
loyalty program and associate a purchase accordingly. In some embodiments,
such information
may be retrieved by a POS terminal 102 from an external system 110 using
location data (e.g.,
in a form of an URL included in a message received from a mobile device 106.
[0084] In some embodiments, merchant system(s) 102, 103 may be
configured to receive
information regarding a user's loyalty programs or coupons and communicate
with external
system(s) 110 to indicate that a transaction should be credited or debited
towards a particular
loyalty program or a coupon has been used. In some embodiments, merchant
system(s) 102,
103 may be configured to communicate with external system(s) 110 to determine
whether a
particular user is associated with various loyalty programs and/or coupons,
etc.
[0085] POS terminal(s) 102 may be configured for online and/or offline
operation. POS
terminal(s) 102 and/or other merchant transaction processing systems 103 may
also be
configured for continuous and/or batch processing of transactions.
[0086] Point-of-sale terminals 102 may be associated with unique
individual and/or group
identifiers, such as suitably-configured optical or wirelessly-readable codes.
Such codes may,
for example, be displayed proximate to the corresponding POS terminal(s) 102
so that a user
104 of, for example, a mobile device 106 may be able to use the device 106 to
identify the POS
terminal 102 and associate it with a proposed transaction. For example, such
codes may be
posted or displayed in promininent, conveniently-accessible locations on
posters, placards, or
tags. The codes may then, for example, be accessed by a user 104 and logged to
the user's
mobile device 106 and associated with other transaction-related data, such
that the mobile
device 106 may be able to push transaction information to the point-of-sale
terminal 102, and/or
route it independently to a third-party system 108, such as a payment
processor, for processing.
[0087] In some embodiments, identification codes associated with POS
terminals and/or
other merchant transaction processing systems 102, 103 may be displayed in
passive,
machine-interpretable form, such as a QR code, bar code, and/or RFID or NFC
tags, for reading
by device(s) 106 and association with proposed transactions. For example, a
suitably-encoded
QR image may be displayed on a wall, sign-post, or other convenient or
appropriate location in
or near a merchant premises, for easy access and reading by a user 104 using a
device 106.
[0088] Third-party backend and other transaction processing systems 108
may be various
systems that may be configured for the acquisition of transaction information,
the aggregation of
transaction information, and/or the adjudication or other processing of
transactions. Such
systems may, for example, adjudicate proposed transactions by confirming, by
means of
18
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
suitable signal communications with user devices 106, merchant devices 102,
103, and financial
institution systems 100 114, that all relevant parties are satisfied with
proposed transfer of value
for property, etc.
[0089] In some embodiments, such backend systems 108 may be configured
for
interoperability in compliance with various standards (e.g. PCI compliance,
EMV compliance)
and/or payment schemes (e.g., Visa Tm , MasterCard, EuropayTM, Diner's CIubTM,
American
Express Tm, lnteracTM, various virtual currencies, Bitcoin, etc.).
[0090] Backend system(s) 108 may further communicate with external
systems 110 for the
processing of transactions and/or association of payment transactions
involving use of loyalty
programs, redemption of coupons, redemption of rewards, redemption of gift
cards, etc., and/or
other alternative means of payment.
[0091] External systems 110 may include various systems that may be
related to payment
transactions, such as loyalty membership tracking systems, rewards programs,
coupon
databases, etc. External databases 112 may store information associated with
the various
programs related to the external systems 110. For example, the external
systems 110 in
conjunction with the external databases 112 may store information such as a
frequent flyer
rewards record for a user.
[0092] Financial institutions 114 may include organizations such as
banks, payment card
companies, etc. that may for example administer and/or otherwise control
source accounts for
funds used in completion of purchase and other transactions as disclosed
herein, information
pertaining to which may for example be stored in account databases 116, such
as information
regarding a user's bank accounts, debit cards and/or credit cards, and user
identification,
including names and personal information such as birthdates, addresses,
finger, eye, and other
biometric data.
[0093] In some embodiments, account database(s) 116 may include data
representing one
or more sets of rules, interpretable or otherwise processable by any or all of
systems 100, 120,
118, 122, 114, 106, 102, 103, 108, 110, etc., which may indicate various
limitations on liability,
when additional authentication measures must be used (e.g. the point-of-sale
terminal 102 is in
a different country than the user's known residence). Such limitations on
liability may vary
depending on the authentication means applied by any or all of system(s) 100,
user(s) 104,
mobile device(s) 106, external or backend systems 108, 110, and/or POS or
other merchant
19
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
systems 102, 103 and the rules established for a particular payment scheme
(e.g., Vise"' ,
MasterCard TM etc.).
[0094] In some embodiments, the account databases 116 may also include
data
representing secondary verification information related to account holders and
other users, such
as two-factor authentication information, passwords, PINs, frequent locations,
biometrics, etc.
[0095] System(s) 100 may include various subsystems, including for
example any or all of
transaction request processing subsystem(s) 118, data element generation
subsystem(s) 120,
and mobile drive provisioning subsystem(s) 112. The subsystems are provided as
examples,
the system 100 may include more, less, different and/or alternate subsystems,
and various
subsystems may be combined with one another.
[0096] Transaction request processing subsystem(s) 118 may be configured
for receiving
transaction requests from one or more device(s) 106 via network(s) 150
requesting that a
mobile device be provisioned with data sets or elements that may be used in
conjunction with
payment transactions. Such transaction requests may be issued and/or received
for various
reasons, such as a user 104 requesting that a mobile device be provisioned in
anticipation of a
transaction, etc.
[0097] Transaction request processing subsystem(s) 118 may be configured
to receive
inputs from a mobile device 106 identifying a particular POS terminal or
merchant backend
system 102, 103, or group(s) thereof. Such inputs may include information such
as a code
identifying the POS or merchant systems 102, 103. Identifying information may
include the
location of a merchant, department of a store or other merchant premises, a
particular check-out
lane or area associated with the point-of-sale terminal 102, etc. For example,
a transaction
request processing subsystem 118 may receive data representing an identifier
"TOR-GS04-
10018", associated with a particular pump at a particular gas station in
Toronto. The transaction
request processing subsystem 118, in some embodiments, may determine which
code matches
with which point-of-sale terminal 102 through stored information on a database
124, for
example, a stored look-up table.
[0098] Data element generation subsystem(s) 120 may be configured for
the generation of
data elements and/or data sets associated with users' accounts, including for
example individual
pre-authorized payment tokens, etc. Account information may be requested
and/or received
from account databases 116 and the data elements may be generated in
accordance with
various standards, such as EMV.
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
[0099] In some embodiments, the data elements and/or sets generated by
subsystem 120
may represent single-use transaction tokens, limited time tokens and/or
limited value tokens
(e.g. up to a predetermined threshold). In some embodiments, such data
elements may be
generated based upon various rules as stored on account database 116. For
example, there
may be rules that limit the value of tokens having a two-week expiry to a
certain threshold, while
tokens having a one hour threshold are provided subject to a higher threshold.
The rules may
for example be used to manage overall risk and liability.
[00100] In some embodiments, data elements or sets generated by a subsystem
120 may
include data representing tags and/or identifiers, including URLs and other
call-outs or
references to remotely stored data, useful for generating ISO 8583 compliant
transaction
messages.
[00101] The generation of data elements and/or data sets by subsystem(s)
120 may include
the generation of cryptograms and/or data sets (for example, indicating issuer
information,
cardholder name, application expiry date, issuer country, language,
transaction currency,
account numbers, sequence numbers, public/private keys, amount, amount
authorized,
merchant category, verification information, transaction limits, etc.). The
generation of the data
elements may be in accordance with any suitable electronic payment standard or
protocol (e.g.,
the EMV standard).
[00102] In some embodiments, one or more of the data elements generated
by subsystems
120 may be encrypted and also include various other information related to a
user's financial
accounts.
[00103] Mobile device provisioning subsystem(s) 122 may be configured for
assembling and
formatting data elements or sets generated by subsystem(s) 120 into
transaction data sets for
transmission to mobile device(s) 106. For example, a mobile device
provisioning subsystem
112 may embed the payment tags and/or otherwise format a payment transaction
data set
intended for use in an EMV-compliant transaction into a format that may be
processed by a
mobile device 106 for output to a display screen associated with the mobile
device 106 in the
form of a QR code readable by another device, such as a POS system 102,
merchant backend
system 103, etc., and/or by another mobile communication device 106, such as a
mobile device
used or controlled by another user 104. Upon being interpreted by a recipient
device 102, 103,
106, etc., tags encoded in such fashion may be similar to or the same as those
used in NFC
contactless transactions, and a proposed transaction may be processed
accordingly.
21
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
[00104] In some embodiments, mobile device provisioning subsystem(s) 122
may be
configured for incorporating data representing rule sets or logic operands
into transaction data
sets or messages. For example, limitations on liability, transaction monetary
limits, time limits
for use of a payment token, associations with loyalty, rewards, discount, and
other programs,
etc., may be incorporated.
[00105] Transaction data sets generated by system(s) 100 may include data
representing
additional information, such as advertising, tracking information, loyalty
program information,
coupons, etc.
[00106] In some embodiments, transaction data sets and other messages
generated by
systems 100 may include locators or references, e.g., Uniform Resource
Locators (URLs)
identifying locations where such other information is stored (e.g., at an
external system 110).
Such locators, when relayed by a mobile device 106 to a point-of-sale terminal
102, can allow
information stored at an identified location to be retrieved by the merchant
system 102, 103
(e.g., by way of network 150). Conveniently, through use of such locators,
information providd,
maintained, or secured by independent parties may be retrieved as needed by
POS or
merchant systems 102, 103, e.g., by way of tailored requests. The amount of
information that
may be retrieved by the merchant system 102,103 may be greater than what may
be provided
to the system 102, 103 by a mobile device or controller 106. Further, in some
cases, the
merchant system 102, 103 may submit information to the identified location.
For example, the
the merchant system 102, 103 may submit transaction information to an external
loyalty
program. The locator may be unique to a particular user, to a particular
merchant, or to a
particular transaction. The locator may expire after a pre-defined period of
time and/or number
of readings/accessings.
[00107] In some embodiments, transaction messages generated at a mobile
device
provisioning subsystem 122 may include further locators or references that
identify, for example,
IP addresses where the payment tags or data sets (e.g., EMV data tags), or
other information,
associated with a particular transaction are stored, or to be stored (e.g., at
a system 100, 114,
etc). Such locators, when relayed by a mobile device 106 to a POS terminal or
merchant system
102, 103, allow the payment tags to be retrieved by the point-of-sale terminal
102 (e.g., by way
of network 150). In such embodiments, the generated message need not include
the payment
tags, thus increasing opportunities for transaction security.
[00108] Transaction data sets and other messages may be formatted into
various forms or
compliance with various protocols, and/or transmitted over various media, for
example, using or
22
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
in the form of wireless messages, text messages, Bluetooth messages, NEC
messages, bar
codes, QR codes, etc. In some embodiments, images of bar codes and/or QR code
smay be
generated and displayed, and used to communicate information optically between
devices; and
corresponding data sets transmitted using any suitable processes and/or
devices. Such
messages may, for example, be wirelessly transmitted to a mobile device 106
and thereafter
formatted for display as a QR code, displayed, and accessed by another device
using optical
reading techniques.
[00109]
Database(s) 124 may be configured for storing information related to system
100 and
transactions initiated or otherwise enabled thereby, such as whole or partial
transaction data
sets, provisioning messages, received transaction requests, transaction logs,
etc.
Payment Pull Transaction Workflow
[00110]
FIG. 2A is a schematic diagram of an embodiment of a process for conducting
electronic transactions in accordance with various aspects of the invention,
and FIG. 2B is a
corresponding process flow diagram. In the embodiment shown in FIGS. 2A and
2B, payment
information is pulled from a payment device, such as a mobile phone or other
networked
purchaser communication device 106, by a point-of-sale terminal 102. A payment
flow pull
transaction is a transaction wherein a customer control device 106 such as a
suitably-configured
mobile communication device may be provisioned, e.g., by a data generation
system 100, with a
transaction data set representing, for example, a pre-authorized payment
token, some or all
elements of which may be communicated with a POS terminal 102 in relation to a
particular
transaction as a payment request. The POS terminal 102, upon receiving and
parsing the set of
data elements, may transmit a second message to a backend system 108, and/or
103 to
indicate that a payment should be processed.
[00111]
Referring to FIGS. 2A and 2B, at 202 a transaction request is received by the
system
100, for example from a mobile communication system 106A,B. The transaction
request may
relate to various types of transactions, such as a pre-authorized payment, a
purchase, a rental,
a refund, a cash advance, etc. The transaction request may be parsed and/or
otherwise
proscessed by, for example, the transaction request processing subsystem 118,
so that, if
authorized by a system 100, 114, etc., a data generation subsystem 120 is
caused to generate
a corresponding transaction data set and forward it to a provisioning
subsystem 122 for
transmission or other routing to the purchaser communication device 106 for
receipt, for
example, using a wireless network communication system and storage in secure,
persistent
memory.
23
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
[00112] In some embodiments, as shown at 207 in FIG. 2b, a first user 104
of a first
communication device 106A may be able to request that a second user 104B's
mobile device
106B be provisioned with data elements associated with the first user's
request, so that for
example a preauthorized payment token authorized on the basis of funds
available through the
first user's financial account may be routed to the second user's device 106.
For example, a
first user 104 may wish to allow a second user 104B, such as a friend,
relation, associate,
employee, or subordinate, to pay for a product using the first user's account.
In some such
embodiments, the first user may be able to indicate a transaction limit for
tokens routed to the
first or second user's device, and such limits may be the same or different.
For example, a
business user 104 may authorize a payment token to be used to complete a
transaction using a
second communication device 106B, with a lower maximum transaction value than
a maximum
transaction authorization associated with the business's account. In some
further embodiments,
the first user may be able to indicate that one-time data elements be
generated, and/or that a
payment token issued to a second user be valid only in connection with
transactions initiated or
completed within or before a pre-determined time. This may, for example, be
accomplished by
including in the transaction authorization data set one data representing or
more suitable
delimiter operands.
[00113] At 204, the data element generation subsystem 120 may be configured to
generate a
set of data elements (such as those corresponding to the EMV standard), based
on information
provided within the transaction request, and may use the data elements to
generate a
transaction data set pursuant to the request received at 202.
[00114] At 206, the system 100 may route for wireless transmission, or
otherwise provision to
a user's mobile device 106, the transaction data set generated at 204. In some
embodiments,
such provisioning may include the generation and/or transmission of a set of
machine-
interpretable instructions to build a corresponding transaction data set or
other message at the
mobile device. In some embodiments, the provisioning of a user's mobile device
106 may
involve only the transmission of the data elements containing payment data,
for use by a
software or other-type application operable on the mobile device in building a
transaction data
set that is acceptable to a relevant merchant in connection with a desired
transaction.
[00115] For example, such a set of instructions may cause the mobile device
106 to generate
a transaction data set or other message suitable for transmission to a point-
of-sale terminal (e.g.
a QR code, a Bluetooth message, a text message, a NEC message) for completion
of a desired
transaction.
24
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
[00116]
Such a set of instructions may, for example, include a set of data elements
pertinent
to the specific transaction request, or type of transaction request, and may
be formatted into a
transaction data set in various ways. In some embodiments, the set of
instructions may also
include instructions associated with other types or items of information, such
as loyalty
information, any associated programs, advertisements, tracking information,
coupons, etc. In
some embodiments, the set of instructions may also include one or more of the
locators
described above.
[00117]
At 208 (and/or at 208' in FIG 2B), the first or second user's mobile device
106, 106A,
106B can communicate the transaction data set to a POS terminal 102 or other
merchant
transaction processing system 103. In some embodiments, a suitable data
message or signal
may be wirelessly transmitted to the point-of-sale terminal by a wireless
network communication
system of the mobile device. For example, the mobile device may be configured
to transmit a
suitably configured Bluetooth message, a NEC message, a text message, etc. to
the point-of-
sale terminal, which may be configured to receive the message.
[00118] In some embodiments, a transaction data set stored on a device 106
may be read
from the device 106 by the POS terminal or other merchant system 102, 103. For
example, the
mobile device 106 may be configured to display a bar code or a QR code, which
the point-of-
sale terminal may then read, e.g. through operation of a scanner or other
image capture device
835 etc.
[00119] Alternatively, or in addition, at 208, 208" the purchaser
communication device 106
may transmit the same or another transaction data set to a third party backend
server 108, such
as an independent transaction processing system, which as shown at 208- may
optionally
transmit required and or desired portions thereof, with or without additional
information, to the
point-of-sale terminal 102.
[00120] At 210, the message containing at least the data set associated
with the transaction
request may be processed by the point-of-sale terminal 102 and/or other
merchant system 103.
This can, for example, include reading from any merchant and/or user devices
102, 103, 106
and interpreting all pertinent data relating to the proposed transaction.
[00121]
At 212, the point-of-sale terminal 102 can generate the same or another
transaction
data set for transmission or other routing to an external, or third party,
backend payment
processing system 108 to confirm or otherwise validate the transaction. Such
second message
may include any or all data elements received from the mobile device 106, as
well as data
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
representing any additional or desired information. Again, any or all such
data elements may
adhere to the EMV or any other desired standard or protocol. In some
embodiments, it may be
particularly advantageous for POS terminal or merchant system 103 to include
in the message
routed at 212 some unpredictable data interpretable by system 108, as a means
of ensuring the
security of an apparently valid transaction request.
[00122] In some embodiments, the transaction data set forwarded by the
merchant system
102, 103 may be formatted in conformance with ISO 8582 standard, or other
desired standard
or protocol, which may be similar to messages used in known contactless
transactions. Any or
all of such data may represent information such as relevant financial
accounts, merchant or
purchase identification systems, or they may represent substitute data
representing such
information, so that actual identification or verification information need
not be transferred.
[00123] At 214, the external backend system 108 may process the
transaction. This may, for
example, involve provisionally or finally clearing the transaction with a
financial institution server
110, 114 associated with a payment token or account identified by, or
otherwise associated
with, the user system 106's transaction request, through the use of suitably-
configured signal
exchanges.
[00124] At 216, a message confirming or otherwise indicating that the
transaction was
approved or not approved may be transmitted back to the POS/merchant terminal
102, 103,
and/or to the controller 106. For example, an electronic alert may be provided
to the user (e.g.,
through the mobile device 106) indicating whether or not the payment was
approved, using the
same, partially the same, or different data sets.
[00125] In some embodiments, the message indicating that the payment was
approved or
not approved may be transmitted to the mobile device 106.
[00126] If provided, an approval message routed to the mobile device /
controller 106 may
also include various other messaging, such as messaging from advertising
partners, indications
that a loyalty or other rewards account was credited, indications that a gift
card was used,
indications that a coupon or other discount was applied, indication that
rewards were redeemed,
etc. In some embodiments, the approval message may also include an itemized
electronic
receipt, which may be issued at system 100 on behalf of the merchant system
102, 103.
Alternatively, the approval message may include a locator (e.g., an URL) to
data representing,
or otherwise useful for generating, such an electronic receipt.
26
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
[00127] For example, in a system adapted for use by or in conjunction with
a merchant
system 102, 103, a user of a communication device or controller 106 may be
enabled to simply
walk through a store and gather items the user wishes to purchase, using a bar
code or other
scanner or optical or wireless reading device 835 (such as an NEC and/or RFID
system) to scan
and record data about items suitable for use in generating an appropriate
transaction request
data set. The user may then initiate processes such as those described above,
complete
payment for the items, and prepare to leave the premises. Upon approaching an
exit, the user
may be enabled to show to a human or automated security system, or make
otherwise make
available to such a system or guard, information sufficient to evidence a
validly-completed
purchase transaction, so that the purchasing user may be permitted to leave
the store
unmolested, and without setting off alarms, with the items in her or his
possession. For
example, such a mobile communication device 106 can be configured to output to
the same or
another merchant transaction processing system 102, 103 data useable by the
merchant
system for confirming execution of the transaction, using at least one of the
wireless data output
system and the same or another network communication system.
[00128] Thus, among other improvements, the invention provides mobile,
desktop, and other
user communication devices or controllers 106, each such device comprising one
or more
wireless data commmunication systems 811, such NFC, RFID, and/or other
wireless signal
transmitters and/or receivers; one or more data processors 822; one or more
user input
systems, such as keyboards, keypads, touchscreens, 804, 805, 835, 815, 812,
etc.; and one or
more persistent memory devices 804, 802, 806, the persistent memory device(s)
comprising
stored data representing instructions interpretable by the at least one
processor 822 and
configured to cause the device to, in response to one or more command signals
generated by
the user input system, access data representing an authorized transaction data
set, the
authorized transaction data set comprising data representing at least an
authorized transaction
limit and one or more identifiers associated with a transaction payment
account. Such data may
be accessed in memory comprised by the device 106, and/or remotely in memory
controlled by
any one or more of systems 100, 114 through the use of suitable resource
locators. The
controller 106 can further use the accessed payment transaction data set to
generate a
tokenized transaction data set, the tokenized transaction data set comprising
data representing
at least an authorized transaction value and data useable by a transaction
adjudication system
such as a third party transaction processing system 108 for adjudicating
completion of a
payment transaction. Moreover, the device 106 can, using the at least one
wireless data output
system, output the tokenized transaction data set for use by a second mobile
communication
27
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
device 106 in completing the payment transaction, as for example described
above and shown
in Figures 2A and 2B.
[00129]
Optional or additional features of such devices 106 can include use of
wireless data
output systems 811, 805, 808 to output such tokens or data sets in formats
suitable for use by
the second mobile communication devices in generating machine-readable optical
object, such
as OR and/or bar codes, or other images, comprising elements representing the
tokenized
transaction data sets, as shown for example in either of FIGs 6 and 7.
[00130]
Further features include incorporation, as a part of or in association with
such
tokenized transaction data sets, of data interpretable by the transaction
adjudication system 108
as a single- or multiple-use delimeters, and/or elapsed-time or date use
delimiters; and
authorized transaction limits which can be the same or different for the first
and second user
devices 106. For example, a payment token can be subject to a lower
transaction limit than the
same or a similar token used by the first device 106A, when used by the second
device 106B.
Moreover, such differentiated transaction values may be set by an authorized
user of a first
device 106A, for example through use of a keyboard, touchscreen, and/or other
user input
system.
[00131]
To facilitate processing of transactions by such first-second device
combinations
106A, 106B, as described, the invention further provides for transfer of such
tokens from the
second devices 106B to merchant systems 102, 103 and/or adjudication systems
108. For
example, in various aspects and embodiments the invention provides mobile
communication
devices comprising wireless data input and output systems; data processors,
and input
systems; the devices being configured to, in response to one or more command
signals
generated by the user input system, use the one wireless data input systems to
receive from a
such a first mobile communication device data representing a tokenized
transaction data set,
the tokenized transaction data set comprising data representing an authorized
transaction value
and data useable by a transaction adjudication system 108 for adjudicating
completion of a
payment transaction; and, using the at least one wireless data output system,
output the same
or another tokenized transaction data set for use by the transaction
adjudication system 108 in
adjudicating the payment transaction.
[00132] Purchaser control devices 106 can further be configured to receive
the tokenized
transaction data sets in formats suitable for use by the mobile communication
device in
generating a machine-readable optical object, such as a OR or bar code,
comprising elements
28
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
representing the tokenized transaction data set, and displaying such codes on
output display
screens for reading by merchant devices 102, 103.
[00133]
Such devices can further be configured to receive, from either or both of
merchant
systems 102, 103 and/or transaction adjudication systems 108, data
representing receipts or
other confirmations of the completion of the payment transactions, and to
generate confirmation
data sets suitable for transfer to the (first) user devices 106A from which
the tokenized payment
data set was received. Thus, for example, a friend, relation, or co-worker or
employee who
uses a payment token transferred to his or her device 106B from a first device
106A can provide
to such first device 106 a receipt or other confirmation that a requested
proxy transaction has
taken place. Such confirmation may also be used, as described above, to
confirm for merchant
security systems and/or officials that a transaction has successfully been
completed, so that a
purchaser or other user is now entitled to custody and control of merchandise,
receipt of
purchased services, etc.
Alternative Payment Pull Transaction Workflow
[00134] In some embodiments, a POS terminal 102 may be configured to
directly indicate to
the adjudication or transaction processing system 108 that it wishes to
conduct a transaction
related to a specific user 104 and/or device 106, and/or where there is a
pending transaction
related to user 104/ device 106. For example, such a situation may arise where
a point-of-sale
terminal 102 is already aware of the identity of user 104, such as when a user
104 has already
logged on to a website, local area network, or otherwise identified
him/herself.
[00135]
In such embodiments, the point-of-sale terminal 102 may transmit a payment
request
for a particular user 104 or device 106 to an adjudication or other backend
processing system
108 directly.
[00136] The backend system 108 may be configured to transmit a request to
mobile device
106 associated with the particular user 104 to obtain an approval for or
validation of the
transaction.
[00137]
Upon receipt of an indication of whether the user 104 approves or disapproves
the
transaction, for example through suitably-configured requests for transaction
validation
communicated to the user's device 106, the mobile device 106 may be configured
to transmit a
message with the user's indication of approval/disapproval to backend system
108.
[00138]
Upon receiving an approval of the transaction, the backend system 108 may be
configured to process the transaction. Backend system 108 may obtain payment
information
29
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
from the mobile device 106 or from system 100. Optionally, a confirmation may
be sent to the
point-of-sale terminal 102 and/or the mobile device 106.
Payment Push Transaction Workflows
[00139]
FIGS. 3, 4 and 5 are sample workflows including steps for conducting payment
push
flow transactions.
[00140]
Payment push flow transaction may include transactions where, for example, a
point-
of-sale terminal 102 and/or other merchant device 103 may be associated with a
code or other
identifier, and the identifier may be acquired by a user 104 of a device and
inputted into the
user's device, for example by manual keyboard or touchscreen entry or by
scanning a bar code,
QR code, or RFID or NEC tag, as described herein. The user 104 may then use
the user's
mobile device 106 to provide information in regards to a transaction involving
the point-of-sale
terminal 102, 103 to a transaction adjudicator or other transaction processor
108, etc. Payment
flow push transactions to pre-authorize future purchases and payment flow push
transactions to
authorize real time, contemporaneously-pending transactions are contemplated.
Further types
of payment flow push transactions are also enabled by the disclosure herein.
[00141]
The use of payment push flows may be particularly advantageous where, for
example there exist or are anticipated a large number of transactions,
potentially avoiding the
delays that would result from requiring users to provision a mobile device to
present a code to
be read by a point-of-sale terminal by, for example, waiting in a checkout
line. Further, backend
systems 103, 108 may be configured to receive and/or process large numbers of
pushed
payment transaction requests, by for example parallel and/or shared processing
techniques,
and the backend systems 103, 108 may have additional processing power than for
example
POS systems 102, the ability to engage in a larger number of connections,
etc., as the backend
system may not be subject to the same constraints as a point-of-sale system.
Payment Push Transaction With Notification to Merchant
[00142]
FIG. 3A is a schematic diagram of an embodiment of a process for conducting
electronic transactions in accordance with various aspects of the invention.
FIG. 3B is a
schematic process flow diagram showing data communications flow consistent
with the
embodiment of FIG. 3A. In the embodiment shown in FIGS 3A and 3B, a pending
transaction
at, for example, a merchant premises such as a gas station or brick-and-mortar
store may have
been initiated prior to the providing of information identifying a point-of-
sale terminal 102 by the
mobile device 106. For example, such a transaction could include a payment,
such as for
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
groceries at a grocery store check-out lane, after a customer or other user
104 has gathered
and optionally scanned items the user wishes to purchase.
[00143]
In various embodiments such transactions may allow for payment by the user 104
inputting or otherwise providing a code identifying the point-of-sale terminal
102 to his or her
mobile device 106, and, optionally, approving a proposed transaction amount on
the mobile
device 106. For example, by operating a purchase application running on the
mobile device
106, the user can scan all the items the user wishes to purchase, using QR,
barcode, NEC,
RFID, and/or other devices and processes; and thereby allow the application to
build a list or
other data set representing such items, and/or corresponding quantities, and
prices, for
presentation to and approval by either or both of merchant systems 102, 103
and/or
adjudication systems 108.
[00144]
At 302, a user's mobile device 106 may be provisioned for use with payment
push.
For example, the mobile device 106 may be provisioned by a system 100 with
payment
information sufficient for conducting a particular transaction in manners
described above. Such
information may, for example, include a data set representing a preauthorized
payment token
associated with a user's deposit, credit, loyalty, or rewards account
administered by a bank or
other financial institution 114, 110, or other back-end system 100, 108. Such
provisioning may
take place at the time of requested adjudication of the transaction, or at any
time prior thereto.
[00145]
At 304, an application stored on the mobile device 106 may be configured to
and
acquire or otherwise receive a code identifying the point-of-sale terminal or
merchant system
102, 103 from a user 104, for example by manual keypad/touchpad input, or by
RFID, NFC, QR,
barcode, or other scanning, as described above. At 304, for example, the
mobile device 106
may receive a code from a user 104 through inputting keystrokes on a keyboard,
the code
being, for example, displayed proximate to a particular check-out lane at the
grocery store or
other merchant premises.
[00146]
At 306, the user's mobile device 106 may transmit a message, e.g., a suitably-
configured transaction request date set including the provisioned payment
information and the
information indicating the point-of-sale terminal 102, to a transaction
adjudication or other third-
party backend system 108, which may be a financial institution which
administers or is
otherwise responsible for or in control of a deposit, credit, loyalty, or
rewards account
associated with the user and/or the mobile device 106, or another transaction
processing
system.
31
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
[00147] At 308, the backend system 108 may transmit a transaction confirmation
message or
data set to the identified point-of-sale terminal 102, or an associated
merchant back-end system
103 to provide notification that the user 104 wishes to pay or otherwise
complete the requested
transaction electronically, and request confirmation that the merchant system
102, 103 wishes
to proceed.
[00148] At 310, the point-of-sale terminal 102 can transmit relevant
transaction information or
other confirmation, such as a total price, and optionally quantities and/or
item identification and
pricing data, along with, optionally, any desired payment instructions, such
as information
identifying a deposit account associated with the merchant and any other
desired or requested
information, taxation requirements, etc., to the backend system 108.
[00149] Optionally, at 312, the backend system 108 transmits transaction
information to
mobile device 106, and at 314, the mobile device 106 may request the user 104
to validate the
transaction. Validation may be requested in particular circumstances, as
dictated by pre-defined
rules of a particular electronic payment scheme, by the merchant, or by a
financial institution
114 associated with a designated payment account. For example, validation may
be required if
the transaction amount exceeds a pre-defined threshold, or if a given amount
of time has
elapsed between provisioning of the user device 106 with payment authorization
data and the
request for transaction provided at 306.
[00150] At 316, upon receiving user validation, the mobile device 106 may
transmit a
message to the backend system 108 to indicate that the transaction has been
approved. In
some embodiments, for example, where the value of the transaction is above a
pre-defined
threshold, the mobile device 106 may require verification such as the input of
a PIN, a time
sensitive code, a second password, etc., or biometric data such as a
fingerprint or retina scan.
[00151] As noted above, the approval message may also contain other
information, such as
advertising or other promotional information, information indicating that a
loyalty account was or
is to be credited, a coupon applied, a gift card balance applied, etc.
[00152] At 318, the backend system 108 may complete processing of the
transaction using
the payment information received at 306.
Payment Push Transaction Without Notification to Merchant
[00153] FIGS. 4A and FB illustrate a further sample workflow including
steps for an
embodiment where, for example, a pending transaction, or transaction value,
may have been
authorized and/or initiated prior to the providing of information identifying
a point-of-sale terminal
32
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
102 by the mobile device 106. The workflow of FIGS. 4A and 4B is similar to
the workflow of
FIG. 3A and 3B, with the exception that notification of the transaction (e.g.,
at 308) is not
provided to the point-of-sale terminal 102, 103.
[00154] At 402, a user's mobile device 106 may be provisioned for use with
payment push
processes. For example, the mobile device 106 may be provisioned by system 100
with
payment information for conducting a particular transaction in manners and in
accordance with
relative timing sequences described above. Further, an application stored on
the mobile device
106 may be configured to acquire or otherwise receive a code from a user 104
and/or user
device 106, as described above.
[00155] At 404, the mobile device 106 may acquire or otherwise receive a
code identifying a
merchant POS or backend system 102, 103 from a user 104 and/or device 106,
using manual
and or automated input devices and/or processes such as keyboards, QR codes,
etc., as
described above.
[00156]
At 406, the user's mobile device 106 may transmit a message including the
provisioned payment information and the information indicating the point-of-
sale terminal 102 to
a backend system 108.
[00157]
At 408, the point-of-sale terminal 102 may transmit a message including
information
identifying itself and/or merchant system(s) 103 associated therewith, and
transaction
information, to the backend system 108. The transaction information can
include, for example,
an amount to be paid by the user 104 in completing the transaction.
[00158]
At 410, the back end / adjudication system 108 can match the request received
from
the user 106 with the message received from the point-of-sale terminal 102,
based on an
identifier of the point-of-sale terminal 102 included in each message. In this
way, a particular
user 104 and/or device may be confidently associated by system 108 with a
particular proposed
transaction.
[00159]
The acceptability of either message by the adjudication system 108, i.e.,
validity of
any transaction so requested, if not matched within a pre-defined time period
(e.g., a few
minutes) may expire. If a match is not found at backend system 108, then
transaction
processing may be terminated at 420. In some embodiments, the backend system
110 may
continue searching for a match for a pre-defined time period, may proactively
query one or more
merchant systems 102, 103, and/or request verification or authority to
continue waiting from a
33
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
user of the device 106, to allow for a delay between when the mobile device
106 transmits its
message and when the point-of-sale terminal 102 transmits the corresponding
message.
[00160]
Optionally, at 412, the backend system 108 may transmit transaction validation
signals to the mobile device 106, so as to cause, at 414, the mobile device
106 to request the
user 104 to validate the transaction. At 416, upon receiving user validation,
the mobile device
106 may transmit a message to the backend system 110 to indicate that the
transaction has
been approved, and at 418, the backend system 108 may process the transaction.
Payment Push Transaction: Pre-authorized Transaction Workflow
[00161]
FIGS. 5A and 5B illustrate a sample workflow including steps for an embodiment
where transaction may occur following the providing of the information
identifying a point-of-sale
terminal 102 by the mobile device 106.
[00162]
For example, such a transaction can include the pre-authorization of a
payment,
such as the purchase of gasoline. A user can input or cause his/her device 106
to acquire a
code or other identifier (which may be, for example, displayed proximate a
particular gas pump
at a gas station), and the user's mobile device may transmit a transaction
purchase data set, or
other message including information indicating the point-of-sale terminal 102
and/or merchant
system 103, to an adjudication or other backend system 108.
[00163]
Upon a subsequent purchase request at the same or a corresponding point-of-
sale
terminal 102 or merchant system 103, the point-of-sale terminal may transmit
information to a
backend system to indicate that a particular transaction has taken place at
the point-of-sale
terminal.
[00164]
Optionally, the backend system 108 may then transmit a message to the mobile
device 106 containing transaction-related information, such as the amount of
the transaction,
the time of the transaction, and various other details, and request the user's
approval of the
transaction.
[00165]
Upon receipt of a request for approval, a notification may be displayed to the
user
wherein the user may choose to accept or decline the transaction. A message
may be
generated and transmitted by the mobile device to indicate whether the
transaction was
accepted or declined.
[00166] At 502, a user's transaction control device 106 may be provisioned
for use with
payment push. For example, the mobile device 106 may be provisioned by system
100 with a
34
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
payment transaction data set for conducting a particular transaction in
manners described
above. Further, an application stored on the mobile device 106 may be
configured to receive a
code from a user 104.
[00167]
At 504, the mobile device 106 may receive from a user 104 or otherwise acquire
a
code, which may be, for example, displayed proximate a particular gas pump at
a gas station.
[00168]
At 506, the user's controller 106 may transmit a message including the
provisioned
payment information and the information indicating the point-of-sale terminal
102 to a backend
system 108. The backend system 108 may process the payment information to pre-
authorize
the transaction. The backend system 108 may send a message to point-of-sale
terminal 102
indicating that a future transaction has been pre-authorized and is associated
with the user 104.
[00169]
In some embodiments, a point-of-sale terminal 102 may be configured to
indicate
that a next or other subsequent transaction has been authorized. For example,
a gas station
pump may turn on a light or output some other form of notification indicating
to the user that the
upcoming gas pumping transaction has been authorized. Optionally, a
notification that the
transaction has been authorized may be sent to the mobile device 106. The gas
station pump
may be unlocked or otherwise activated for use by the user 104.
[00170]
In some embodiments, transaction data sets and other messages generated by or
otherwise provided from the mobile device 106 may include a set of data
elements related to the
transaction (e.g. EMV data elements) and the backend system 108 may push this
information to
the point-of-sale terminal 102.
[00171]
At 508, upon a transaction being conducted, the merchant system 102, 103
recognizes that the transaction has already been authorized and transmits
transaction
information to backend system 108. The transaction information includes, for
example, an
amount to be paid by the user 104.
[00172] Optionally, at 510, the backend system 108 may transmit transaction
information to
mobile device 106, and in some embodiments, at 512, the mobile device 106 may
request the
user 104 to validate the transaction. In some embodiments, validation may be
deemed
unnecessary (e.g. transaction values below a particular threshold).
[00173]
Transaction information displayed to the user 104 through the mobile device
106
may include other information, such as advertising information, information
indicating that a
loyalty account was credited, a coupon applied, a gift card balance applied,
etc.
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
[00174]
At 514, upon receiving user validation, the mobile device 106 may transmit a
message to the back end system 108 to indicate that the transaction has been
approved. In
some embodiments, for example, where the value of the transaction is above a
threshold, the
mobile device 106 may require further verification, such as the input of a
PIN, a time sensitive
code, a second password, etc.
[00175]
At 516, the back end system 108 may then process the transaction using the
payment information received at 506, with any appropriate adjustments from the
pre-authorized
amount.
[00176]
Thus, reference to the disclosure above, including particularly the
descriptions
I 0 associated with Figures 3A ¨ 5B, it may be seen that in various aspects
and embodiments the
invention provides, among other improvements, mobile and other communication
devices or
controllers 106, each of which can comprise one or more network communication
systems 811,
data processors 822, input systems 815, 812, 808, 835 etc., and persistent
memory devices
802, 804, 806, the memory devices comprising stored data representing
instructions
interpretable by the at least one processor and configured to cause the
devices to receive, from
the user input systems, data representing identifiers associated with merchant
transaction
processing systems 102, 103; generate transaction data sets comprising data
representing the
same or identifiers associated with the merchant transaction processing
system(s) 102, 103 and
pre-authorized transaction payment values; use the network communication
systems to route
the transaction data sets to third-party transaction adjudication systems 108
for adjudication of
transactions associated with the transaction data sets; and receive from the
transaction
adjudication system data useful for confirming execution of the transactions.
[00177]
Such controllers 106 may further include output display systems such as
display
screens 808, and be configured to use the data useful for confirming execution
of the
transaction received from the transaction adjudication systems to cause the
output display
systems to display, in human-interpretable form, requests for user validation
of the transaction;
to receive, from the same or other user input systems, such as keypads,
touchscreens, or
biometric sensors, data representing validation of the transactions; and
generate and return to
the adjudication system(s) 108 validation data sets suitable for causing the
transactions to be
completed.
[00178]
As described above, identifiers associated with merchant systems 102, 103 in
such
devices 106 may include optical or other scanners 835 adapted to acquire data
by optical,
RFID, NFC, or other techniques.
36
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
[00179]
Such devices 106 may further be configured to use their network communication
systems 811 and/or optical output systems 808 to route to or otherwise provide
for interpretation
by the same other merchant transaction processing systems data useful for
confirming
execution of the transaction, so that, for example, a purchaser who has
completed a transaction
can satisfy a merchant official or security system that the purchaser has paid
and is entitled to
remove the purchased item(s) for the merchant's premises.
[00180]
It may further be seen that, in related aspects, the invention provides
transaction
adjudication systems 108 comprising network communication systems suitably
configured data
processors, such that the adjudication systems 108 may be caused to receive,
using their
network communication systems, from one or more mobile communication devices
or other
purchaser controllers 106 purchaser transaction data sets, the purchaser
transaction data sets
comprising data representing at least identifier associated with merchant
transaction processing
systems 102, 103 and pre-authorized transaction payment values; use the same
or other
network communication systems to receive from the merchant transaction
processing systems
102, 103 associated with the identifiers one or more merchant transaction data
sets, the
merchant transaction data sets comprising data representing at least
transaction payment
amounts and corresponding transaction identifiers and/or the same or further
identifiers
associated with the merchant transaction systems 102, 103; use the the
purchaser transaction
data sets and the merchant transaction data sets to authorize completion of a
transaction and
generate a transaction confirmation data set; and, using the same other
network communication
systems, route the transaction confirmation data sets to the respective mobile
devices 106,
merchant transaction processing systems 102, 103, and/or account
administration processing
system(s) 100, 114.
[00181]
Such transaction adjudication systems 108 may be configured to trigger receipt
from
the merchant transaction processing systems 102, 103 of the merchant
transaction data sets
through the use of prompts through generation by the transaction adjudication
systems of
merchant transaction notification data sets and routing by the transaction
adjudication systems
108 of the merchant transaction notification data sets to the merchant
transaction processing
system(s) 102, 103 associated with the identifiers, and the merchant
transaction notification
data sets include data representing at least identifier associated with the
transaction processing
systems; and identifier associated with the corresponding mobile communication
devices.
[00182]
Such transaction adjudication systems 108 may further generate and send to
corresponding purchaser devices 106 data representing requests for validation
of transactions,
37
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
wherein authorization of the transactions is contingent upon receipt of
suitable verification
generated, e.g., by means of user entry of PIN, biometric, or other validating
data.
Other Figures
[00183]
FIG. 6 is a schematic diagram further illustrating possible data flows between
various
systems and/or components 100, 114, 106, 108, 102, 103, etc. during a payment
flow pull
transaction. Among other features, FIG. 6 illustrates processes for transfer
of data between
user devices 106 and merchant systems 102 by means of QR codes.
[00184]
FIG. 7 is a schematic diagram illustrating the possible data flow between
various
systems and/or components during a payment flow push transaction. Among other
features,
FIG. 7 illustrates processes for transfer of data between user devices 106 and
merchant
systems 102 by means of OR codes, RFID/NFC devices, etc.
[00185]
In both FIGS 6 and 7 it is also shown that communications between adjudication
or
other third-party systems 108 and financial institutions or account
administration systems 114
can be conducted in accordance with any desired transaction data protocols, or
schemes,
including for example EMV, FIX, etc.
Computer-Implemented Embodiments
[00186]
With respect to computer-implemented embodiments, those skilled in the
relevant
arts, will understand that the description provided above describes how one
could, for example,
either build a purpose-specific computer system, and/or modify one or more
existing computer
or communication components to implement various aspects and embodiments of
the invention.
[00187] Computer-related implementation and/or solutions may be commercially
advantageous and provide unexpected and unforeseen advantages in various
contexts; at least
for the reasons of providing scalability (the use of a single platform/system
to manage a large
number of activities); the ability to quickly and effectively pull together
information from disparate
networks; improved decision support and/or analytics that would otherwise be
unfeasible; the
ability to integrate with external systems whose only connection points are
computer-
implemented interfaces; the ability to achieve cost savings through
automation; the ability to
dynamically respond and consider updates in various contexts (such as
interactions with various
external systems having dynamic information related to loyalty accounts,
coupons, gift cards,
promotions, further transaction validation, etc.); the ability to apply
complex logical rules that
would be infeasible through manual means; the ability to apply computerized
technologies for
increased privacy and security; among others.
38
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
[00188]
Using electronic and/or computerized means to provide a platforms that may are
more convenient, secure, sealable, efficient, accurate, and/or reliable than
traditional, non-
computerized means enables new, innovative, and commercially desirable
efficiencies and
operational possibilities. Further, many systems may be computerized and the
platform may
advantageously be designed for interoperability, and manual operation may be
difficult and/or
impossible.
[00189]
Scalability may be useful as it may be advantageous to provide a system that
may
be able to effectively manage a large number of transactions and/or
interconnections and/or
integration with external systems. A potential advantage of some embodiments
over
conventional solutions is the ability to receive a large number of
transactions and to process
these transactions in a commercially reasonable period of time.
[00190]
The convenience and effectiveness of a solution may be valuable in the context
of
electronic payments as individuals often make many electronic payments over
the course of a
day, even a small improvement in convenience on each transaction may become
more
significant taken in the context of a high volume of transactions.
General
[00191]
As will be further understood by those skilled in the relevant arts,
significant
advantage may be realized through the full or partial automation of any of the
processes
described above, or portions thereof. Such automation may be implemented by,
for example,
the automatic generation and application of rules through programming logic
and/or workflows.
Such automation may be provided in any suitable manner, including for example
the use of
automatic data processors executing suitably-configured, coded, machine-
readable instructions
using a wide variety of devices. Processor(s) suitable for use in such
implementations can
comprise any one or more data processor(s), computer(s), and/or other
system(s) or device(s),
and necessary or desirable input/output, communications, control, operating
system, and other
devices or components, including software, that are suitable for accomplishing
the purposes
described herein. For example, a suitably-programmed data processor provided
on one or
more circuit boards will suffice.
[00192]
The following discussion provides many example embodiments of the inventive
subject matter. Although each embodiment represents a single combination of
inventive
elements, the inventive subject matter is considered to include all possible
combinations of the
disclosed elements. Thus if one embodiment comprises elements A, B, and C, and
a second
39
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
embodiment comprises elements B and D, then the inventive subject matter is
also considered
to include other remaining combinations of A, B, C, or D, even if not
explicitly disclosed.
[00193] The present system and method may be practiced in various embodiments.
A
suitably configured computer device, and associated communications networks,
devices,
software and firmware may provide a platform for enabling one or more
embodiments as
described above.
[00194]
By way of example, FIG. 8 shows a user communication device or controller 800,
106 that may include a central processing unit ("CPU") 802 connected to a
storage unit 804 and
to a random access memory 806. The CPU 802 may process an operating system
801,
application program 803, and data 823. The operating system 801, application
program 803,
and data 823 may be stored in persistent memory storage unit 804 and loaded
into memory
806, as may be required. Computer device 800 may further include a graphics
processing unit
(GPU) 822 which is operatively connected to CPU 802 and to memory 806 to
offload intensive
image processing calculations from CPU 802 and run these calculations in
parallel with CPU
802. A user or operator 807, 104 may interact with the computer device 800,
106 using a video
display input/output device 808 connected by a video interface 805, and
various input/output
devices such as a keyboard or keypad 815, mouse or pointing device 812, and
disk drive or
solid state drive 814 connected by an I/O interface 809. In known manner, the
pointing device
812 may be configured to control movement of a cursor in the video display
808, and to operate
various graphical user interface (GUI) controls appearing in the video display
808 with a mouse
button. The disk drive or solid state drive 814 may be configured to accept
computer readable
media 816. The computer device 800 may form part of a network 105 via a
network interface
811, allowing the computer device 800 to communicate with other suitably
configured data
processing systems (not shown). One or more different types of sensors 835 may
be used to
receive input from various sources.
[00195] Various aspects and embodiments of the present systems and methods may
be
practiced on virtually any manner of computer devices, including desktop
computers, laptop
computers, tablet computers, and/or wireless handheld devices. The present
system and
method may also be implemented as a computer-readable/useable medium that
includes
computer program code to enable one or more computer devices to implement each
of the
various process steps in a method in accordance with the present invention. In
case of more
than computer devices performing the entire operation, the computer devices
are networked to
distribute the various steps of the operation. It is understood that the terms
computer-readable
CA 02963287 2017-03-31
WO 2016/054727
PCT/CA2015/000532
medium or computer useable medium comprises one or more of any type of
physical
embodiment of the program code. In particular, the computer-readable/useable
medium can
comprise program code embodied on one or more portable storage articles of
manufacture (e.g.
an optical disc, a magnetic disk, a tape, etc.), on one or more data storage
portioned of a
computing device, such as memory associated with a computer and/or a storage
system.
[00196]
The mobile application of the present invention may be implemented as a web
service, where the mobile device includes a link for accessing the web
service, rather than a
native application.
[00197]
The functionality described may be implemented to any mobile platform,
including
the iOSTM platform, ANDROIDTM, WINDOWSTM or BLACKBERRYTM.
[00198]
It will be appreciated by those skilled in the art that other variations of
the
embodiments described herein may also be practiced without departing from the
scope of the
invention. Other modifications are therefore possible.
[00199]
In further aspects, the disclosure provides systems, devices, methods, and
computer
programming products, including non-transient machine-readable instruction
sets, for use in
implementing such methods and enabling the functionality described previously.
[00200]
Although the disclosure has been described and illustrated in exemplary forms
with a
certain degree of particularity, it is noted that the description and
illustrations have been made
by way of example only. Numerous changes in the details of construction and
combination and
arrangement of parts and steps may be made. Accordingly, such changes are
intended to be
included in the invention, the scope of which is defined by the claims.
[00201]
Except to the extent explicitly stated or inherent within the processes
described,
including any optional steps or components thereof, no required order,
sequence, or
combination is intended or implied. As will be understood by those skilled in
the relevant arts,
with respect to both processes and any systems, devices, etc., described
herein, a wide range
of variations is possible, and even advantageous, in various circumstances,
without departing
from the scope of the invention, which is to be limited only by the claims.
41
