U.S. patent application number 15/360357 was filed with the patent office on 2017-05-25 for providing shipping details on a pay transaction via the internet.
The applicant listed for this patent is Parveen Bansal, Aparna Krishnan Girish, Gurumoorthy Hariharan, Ashish Kulpati, Koni Uttam Nayak, PANKAJ RAJURKAR, Michelle Scurrah. Invention is credited to Parveen Bansal, Aparna Krishnan Girish, Gurumoorthy Hariharan, Ashish Kulpati, Koni Uttam Nayak, PANKAJ RAJURKAR, Michelle Scurrah.
Application Number | 20170148013 15/360357 |
Document ID | / |
Family ID | 58719682 |
Filed Date | 2017-05-25 |
United States Patent
Application |
20170148013 |
Kind Code |
A1 |
RAJURKAR; PANKAJ ; et
al. |
May 25, 2017 |
PROVIDING SHIPPING DETAILS ON A PAY TRANSACTION VIA THE
INTERNET
Abstract
E-commerce personal account numbers, shipping addresses, and
other data may be tokenized to facilitate transaction completion by
establishing e-commerce browser standards. Tag data may be received
from a website associated with an e-commerce transaction. The tag
data may include an indication that a merchant payment webpage is
configured to receive a payment transaction via a token. Tokens may
then be created from a personal account number and a shipping
address corresponding to the personal account number in response to
a request for token data.
Inventors: |
RAJURKAR; PANKAJ;
(Singapore, SG) ; Kulpati; Ashish; (Singapore,
SG) ; Nayak; Koni Uttam; (Mumbai, IN) ;
Hariharan; Gurumoorthy; (Mumbai, IN) ; Girish; Aparna
Krishnan; (Foster City, CA) ; Bansal; Parveen;
(Foster City, CA) ; Scurrah; Michelle; (Victoria,
AU) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
RAJURKAR; PANKAJ
Kulpati; Ashish
Nayak; Koni Uttam
Hariharan; Gurumoorthy
Girish; Aparna Krishnan
Bansal; Parveen
Scurrah; Michelle |
Singapore
Singapore
Mumbai
Mumbai
Foster City
Foster City
Victoria |
CA
CA |
SG
SG
IN
IN
US
US
AU |
|
|
Family ID: |
58719682 |
Appl. No.: |
15/360357 |
Filed: |
November 23, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62321094 |
Apr 11, 2016 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 20/3674 20130101;
G06Q 30/0601 20130101; G06Q 20/102 20130101; G06Q 20/12 20130101;
G06Q 20/385 20130101; G06Q 2220/00 20130101; G06Q 20/405 20130101;
G06Q 20/42 20130101; G06Q 20/3276 20130101; G06Q 20/401
20130101 |
International
Class: |
G06Q 20/36 20060101
G06Q020/36; G06Q 20/10 20060101 G06Q020/10; G06Q 20/40 20060101
G06Q020/40; G06Q 30/06 20060101 G06Q030/06 |
Foreign Application Data
Date |
Code |
Application Number |
Nov 23, 2015 |
IN |
6294/CHE/2015 |
Claims
1. A payment transaction system comprising: a token requestor
module for receiving tag data associated with an e-commerce
transaction for goods or services, the tag data including an
indication that a merchant payment webpage is configured to receive
a payment transaction via a token; and a token service for creating
one or more tokens from a personal account number and a shipping
address corresponding to the personal account number in response to
a request for token data from the token requestor module; wherein
the token requestor module includes an instruction to push the one
or more tokens to the merchant payment webpage.
2. The system of claim 1, wherein the token requestor is further
for validating the tag data.
3. The system of claim 1, wherein the token requestor is further
for receiving an input indicating selection of a payment
device.
4. The system of claim 1, wherein the cryptogram includes payment
device data and shipping data.
5. The system of claim 1, wherein the token requestor module
includes a further instruction to encrypt the token before pushing
the token to the merchant payment webpage.
6. The system of claim 1, wherein the token service is further for
creating one or more cryptogams that each correspond to a token of
the one or more tokens.
7. The system of claim 6, wherein the merchant payment webpage is
configured to send the token and a cryptogram corresponding to the
token to an issuer server.
8. The system of claim 7, wherein the token service is further for
receiving the personal account number corresponding to the token
and an approval decision from the issuer server.
9. The system of claim 8, wherein the token service is further for
exchanging the personal account number for the token.
10. The system of claim 9, wherein the merchant payment website is
configured to map the token to an e-commerce authorization request
and to send the request and token to the issuer server.
11. A method for completing an e-commerce payment transaction
comprising: receiving tag data associated with an e-commerce
transaction for goods or services, the tag data including an
indication that a merchant payment webpage is configured to receive
a payment transaction via a token; creating one or more tokens from
a personal account number and a shipping address corresponding to
the personal account number in response to a request for token data
from the token requestor module; and pushing the one or more tokens
to the merchant payment webpage.
12. The method of claim 11, further comprising validating the tag
data.
13. The method of claim 11, further comprising receiving an input
indicating selection of a payment device.
14. The method of claim 11, wherein the cryptogram includes payment
device data and shipping data.
15. The method of claim 11, further comprising encrypting the token
before pushing the token to the merchant payment webpage.
16. The method of claim 11, further comprising creating one or more
cryptogams that each correspond to a token of the one or more
tokens.
17. The method of claim 16, further comprising sending the token
and a cryptogram corresponding to the token to an issuer
server.
18. The method of claim 17, further comprising receiving the
personal account number corresponding to the token and an approval
decision from the issuer server.
19. The method of claim 18, further comprising exchanging the
personal account number for the token.
20. The method of claim 19, further comprising mapping the token to
an e-commerce authorization request and sending the request and
token to the issuer server.
Description
CROSS-REFERENCES TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Application No. 62/321,094, entitled "EXPEDITED E-COMMERCE
TOKENIZATION" filed Apr. 11, 2016 and priority to Indian patent
application IN 6294/CHE/2015, entitled "A SYSTEM AND METHOD FOR
CONDUCTING A TRANSACTION" filed Nov. 23, 2015. The disclosures of
both applications are incorporated herein by reference.
BACKGROUND
[0002] The background description provided herein is for the
purpose of generally presenting the context of the disclosure. Work
of the presently named inventors, to the extent it is described in
this background section, as well as aspects of the description that
may not otherwise qualify as prior art at the time of filing, are
neither expressly nor impliedly admitted as prior art against the
present disclosure.
[0003] When cards are used for payment purposes during checkout,
E-Commerce merchants as well as payment service providers (PSPs)
may traditionally allow browser auto-form fills during checkout to
expedite the consumer's payment process. Merchants and PSPs then
use the card information stored on file during this process.
However, when a card on file has expired, the merchant/PSP has to
nudge the consumer to either provide the refreshed expiry date or
select another card. This practice often leads to consumer
drop-offs.
[0004] When these merchants/PSPs tokenize the cards using a token
service token requestor such as Browser Partners or E-Commerce
Enablers, while the benefits of tokenization are reaped, these
token numbers cannot be auto-filled or key entered in the consumer
browser.
[0005] Likewise, the use of communication devices such as mobile
phones in conducting financial transactions is becoming widespread.
In some cases, mobile phones enable consumers to scan graphical
codes, such as quick response barcodes, to initiate payments in
favor of a merchant displaying the graphical code.
[0006] While these techniques enable consumers to quickly initiate
a payment in favor of a merchant, in many transaction types,
additional information will be required by the merchant. For
example, in the case of an electronic commerce (e-commerce)
transaction, the merchant will typically require a shipping address
and possibly contact information of the consumer to enable the
merchant to ship the purchased product to the consumer.
[0007] Requiring the user to provide such further information may
slow down the process of transacting and may in turn increase the
difficulty experienced by consumers in transacting.
[0008] It may further be troublesome for merchants to receive a
consumer's shipping address from one source and confirmation of
payment from another source. Receiving information from disparate
sources may increase back-end processing which the merchant needs
to perform, for example, in tying the shipping address of the
consumer received from one source with the payment confirmation
received from another source such as the merchant's financial
institution.
SUMMARY
[0009] Features and advantages described in this summary and the
following detailed description are not all-inclusive. Many
additional features and advantages will be apparent to one of
ordinary skill in the art in view of the drawings, specification,
and claims hereof. Additionally, other embodiments may omit one or
more or all of the features and advantages described in this
summary.
[0010] Systems and methods described herein may expedite e-commerce
tokenization and transaction completion by establishing e-commerce
browser standards around tokenization for merchants and PSPs,
reducing friction during checkout thereby increasing conversion
rates, and circumventing the expired cards problem with
tokenization by requesting a valid and unique cryptogram. Another
aspect may include tokenization of the card used in checkout.
[0011] A method for conducting a transaction in which funds are
transferred from a payer to a payee, may be conducted at an issuer
server computer associated with the payer. The method may include
receiving, from a communication device of the payer, a transaction
message including an amount associated with the transfer of funds,
an account identifier of the payee, and a permission indication
that presents the payer's approval or denial in respect of sharing
with the payee personal information requested by the payee. If the
permission indication indicates that the requested personal
information may be shared with the payee, the method may generate a
transaction request message including the amount, the account
identifier of the payee and the requested personal information. The
method may then transmit the transaction request message for
receipt by an acquirer server computer associated with the payee
for processing the transaction and conditional forwarding of the
requested personal information to the payee.
[0012] A further feature provides for the method to include, if the
permission indication indicates that the requested personal
information may not be shared with the payee, generating a
transaction request message including the amount and the account
identifier of the payee.
[0013] Still further features provide for the transaction to be a
push transaction; and for the transaction request message to an
original credit transaction request message.
[0014] A yet further feature provides for the personal information
to include one or more of the group of: a shipping address, an
email address, and a phone number.
[0015] An even further feature provides for the permission
indication to include the requested personal information.
[0016] A further feature provides for the method to include
retrieving the personal information from a data record associated
with the payer.
[0017] A still further feature provides for the method to include
receiving a transaction response message confirming or denying the
transaction.
[0018] Yet further features provide for transmitting the
transaction request message for receipt by the acquirer server
computer to include transmitting the transaction request message to
the acquirer server computer via a payment processing network, and
for the account identifier of the payee to include routing
information usable by the payment processing network in routing the
transaction request message to the acquirer server computer. The
payment processing network may be an interoperable payment
processing network.
[0019] A method may also conduct a transaction in which funds are
transferred from a payer to a payee. The method may be conducted at
a communication device of the payer comprising: obtaining, from a
tag, an account identifier of the payee and a personal information
flag indicating that personal information of the payer is requested
by the payee; prompting the payer for permission to share the
requested personal information with the payee; receiving the
payer's approval or denial in respect of sharing the requested
personal information with the payee; generating a transaction
message including an amount associated with the transfer of funds,
the account identifier of the payee and a permission indication
indicating the payer's approval or denial in respect of sharing the
requested personal information with the payee; and, transmitting
the transaction message to an issuer server computer associated
with the payer for processing the transaction and conditional
forwarding of the requested personal information to the payee.
[0020] A further feature provides for the tag to be one of: a radio
frequency beacon, a near sound communication beacon, or graphical
code.
[0021] Still further features provide for the personal information
to include one or more of the group of: a shipping address, an
email address, and a phone number, and for the personal information
flag to indicate that one or more of a shipping address, an email
address, and a phone number of the payer is requested by the
payee.
[0022] A yet further feature provides for prompting the payer for
permission to share the requested personal information with the
payee to include displaying the personal information which will be
shared with the payee.
[0023] A still further feature provides for prompting the payer for
permission to share the requested personal information with the
payee to include providing the payer with an option to edit the
personal information which will be shared with the payee.
[0024] A yet further feature provides for prompting the payer for
permission to share the requested personal information with the
payee to include providing the payer with an option to select
personal information of a contact of the payer which will be shared
with the payee.
[0025] A system may conduct a transaction in which funds are
transferred from a payer to a payee, the system including an issuer
server computer associated with the payer, comprising: a payer
messaging component for receiving, from a communication device of
the payer, a transaction message including an amount associated
with the transfer of funds, an account identifier of the payee, and
a permission indication indicating the payer's approval or denial
in respect of sharing with the payee personal information requested
by the payee; a generating component for, if the permission
indication indicates that the requested personal information may be
shared with the payee, generating a transaction request message
including the amount, the account identifier of the payee and the
requested personal information; and, a payment network messaging
component for transmitting the transaction request message for
receipt by an acquirer server computer associated with the payee
for processing the transaction and conditional forwarding of the
requested personal information to the payee.
[0026] A further feature provides for the generating component to
be for, if the permission indication indicates that the requested
personal information may not be shared with the payee, generating a
transaction request message including the amount and the account
identifier of the payee.
[0027] Still further features provide for the transaction to be a
push transaction and for the transaction request message to be an
original credit transaction request message.
[0028] A yet further feature provides for the personal information
to include one or more of the group of: a shipping address, an
email address, and a phone number.
[0029] An even further feature provides for the permission
indication to include the requested personal information.
[0030] A still further feature provides for the system to include a
retrieving component for retrieving the personal information from a
data record associated with the payer.
[0031] A further feature provides for the payment network messaging
component further to be for receiving a transaction response
message confirming or denying the transaction.
[0032] A still further feature provides for the payment network
messaging component to transmit the transaction request message to
the acquirer server computer via a payment processing network, and
for the account identifier of the payee to include routing
information usable by the payment processing network in routing the
transaction request message to the acquirer server computer. The
payment processing network may be an interoperable payment
processing network.
[0033] A system may also conduct a transaction in which funds are
transferred from a payer to a payee, the system including a
communication device of the payer, comprising: an obtaining
component for obtaining, from a tag, an account identifier of the
payee and a personal information flag indicating that personal
information of the payer is requested by the payee; a prompting
component for prompting the payer for permission to share the
requested personal information with the payee; an input component
for receiving the payer's approval or denial in respect of sharing
the requested personal information with the payee; a generating
component for generating a transaction message including an amount
associated with the transfer of funds, the account identifier of
the payee and a permission indication indicating the payer's
approval or denial in respect of sharing the requested personal
information with the payee; and, a transmitting component for
transmitting the transaction message to an issuer server computer
associated with the payer for processing the transaction and
conditional forwarding of the requested personal information to the
payee.
[0034] A further feature provides for the tag to be one of: a radio
frequency beacon, a near sound communication beacon, or graphical
code.
[0035] A still further feature provides for the personal
information to include one or more of the group of: a shipping
address, an email address, and a phone number, and for the personal
information flag to indicate that one or more of a shipping
address, an email address, and a phone number of the payer is
requested by the payee.
[0036] A yet further feature provides for the prompting component
to display the personal information which will be shared with the
payee.
[0037] A further feature provides for the prompting component to
provide the payer with an option to edit the personal information
which will be shared with the payee.
[0038] A still further feature provides for the prompting component
to provide the payer with an option to select personal information
of a contact of the payer which will be shared with the payee.
[0039] A computer program product may conduct a transaction in
which funds are transferred from a payer to a payee, the computer
program product comprising a computer-readable medium having stored
computer-readable program code for performing the steps of:
receiving, from a communication device of the payer, a transaction
message including an amount associated with the transfer of funds,
an account identifier of the payee, and a permission indication
indicating the payer's approval or denial in respect of sharing
with the payee personal information requested by the payee; if the
permission indication indicates that the requested personal
information may be shared with the payee, generating a transaction
request message including the amount, the account identifier of the
payee and the requested personal information; and, transmitting the
transaction request message for receipt by an acquirer server
computer associated with the payee for processing the transaction
and conditional forwarding of the requested personal information to
the payee.
[0040] Another computer program product may conduct a transaction
in which funds are transferred from a payer to a payee, the
computer program product comprising a computer-readable medium
having stored computer-readable program code for performing the
steps of: obtaining, from a tag, an account identifier of the payee
and a personal information flag indicating that personal
information of the payer is requested by the payee; prompting the
payer for permission to share the requested personal information
with the payee; receiving the payer's approval or denial in respect
of sharing the requested personal information with the payee;
generating a transaction message including an amount associated
with the transfer of funds, the account identifier of the payee and
a permission indication indicating the payer's approval or denial
in respect of sharing the requested personal information with the
payee; and, transmitting the transaction message to an issuer
server computer associated with the payer for processing the
transaction and conditional forwarding of the requested personal
information to the payee.
[0041] Further features provide for the computer-readable medium to
be a non-transitory computer-readable medium and for the
computer-readable program code to be executable by a processing
circuit.
BRIEF DESCRIPTION OF THE DRAWINGS
[0042] FIG. 1 illustrates a system including a merchant, a token
requestor and a token service;
[0043] FIG. 2 illustrates a system including a merchant payment
processor, a token requestor and a token service;
[0044] FIG. 3 illustrates a method or data flow using the systems
of FIG. 1 and/or FIG. 2;
[0045] FIG. 4 is a schematic diagram which illustrates an exemplary
system for conducting a transaction;
[0046] FIG. 5 is a block diagram which illustrates components of
the system illustrated in FIG. 4;
[0047] FIG. 6 is a flow diagram which illustrates an exemplary
method for conducting a transaction;
[0048] FIG. 7 is a schematic diagram which illustrates an exemplary
scenario of the described system and method in use from the
perspective of a payer;
[0049] FIG. 8 illustrates an example of a computing device in which
various aspects of the disclosure may be implemented; and
[0050] FIG. 9 shows a block diagram of a communication device that
may be used in embodiments of the disclosure.
[0051] Persons of ordinary skill in the art will appreciate that
elements in the figures are illustrated for simplicity and clarity
so not all connections and options have been shown to avoid
obscuring the inventive aspects. For example, common but
well-understood elements that are useful or necessary in a
commercially feasible embodiment are not often depicted in order to
facilitate a less obstructed view of these various embodiments of
the present disclosure. It will be further appreciated that certain
actions and/or steps may be described or depicted in a particular
order of occurrence while those skilled in the art will understand
that such specificity with respect to sequence is not actually
required. It will also be understood that the terms and expressions
used herein are to be defined with respect to their corresponding
respective areas of inquiry and study except where specific
meanings have otherwise been set forth herein.
DETAILED DESCRIPTION
[0052] The present invention now will be described more fully with
reference to the accompanying drawings, which form a part hereof,
and which show, by way of illustration, specific exemplary
embodiments by which the invention may be practiced. These
illustrations and exemplary embodiments are presented with the
understanding that the present disclosure is an exemplification of
the principles of one or more inventions and is not intended to
limit any one of the inventions to the embodiments illustrated. The
invention may be embodied in many different forms and should not be
construed as limited to the embodiments set forth herein; rather,
these embodiments are provided so that this disclosure will be
thorough and complete, and will fully convey the scope of the
invention to those skilled in the art. Among other things, the
present invention may be embodied as methods, systems, computer
readable media, apparatuses, or devices. Accordingly, the present
invention may take the form of an entirely hardware embodiment, an
entirely software embodiment, or an embodiment combining software
and hardware aspects. The following detailed description is,
therefore, not to be taken in a limiting sense.
[0053] Payment services may be designed to make payments easier and
smoother. In one aspect, payment services may receive one or more
payment devices such as credit cards or payment accounts. The
account data such as account number, account name, billing address,
shipping address, etc., may only need to be entered once and the
payment service will securely store the account data using an
account name. In use, a user may only need to have a payment system
log-on and password to make a payment using any of the various
accounts that the user has added to the payment system. In
operation, the payment system may not communicate an actual account
number to a merchant but may communicate a short term account
number in a token for that specific transaction with the payment
service may translate into the actual account number on the
backend.
[0054] As illustrated in FIG. 1, in a payment system 100, back end
components 102 such as a token server 102 may include on or more
modules such as a Token Requestor Browser Partners or E-Commerce
Enablers 104 that may be integrated with a token service 106 such
as back-end or cloud-based modules executing, at least partially,
on the server 102, as described herein. Front end components 108
e.g., such as Merchants may integrate with the Token Requestor 104
to receive token data 110 (FIG. 1). Tokens may be used by merchants
and payment service providers to enable electronic payments.
[0055] FIG. 2 may illustrate that the merchant interface 108 or a
merchant partner interface 202 e.g., Payment Service Providers
PSPs, a hosted order page, merchant payment processor interface,
etc. may be integrated with the Token Requestor 104 to receive
token data 110, 204. In some embodiments, the merchant partner
interface 202 may not have a direct relationship with the token
service. Merchant interface 106 may receive token data 110, 204
from their partner interface or PSPs. These interfaces may then be
integrated with the Token Requestor 104 to receive token data 110,
204. A partner interface 202 may include prerequisite functions to
make sure the electronic payment system 200 works as desired. For
example, a direct merchant or E-Commerce Enabler may have to adopt
one or more standards, i.e., the E-Commerce browser standard 206,
and may need to make their payment page "Token Ready." A consumer's
browser may need to be compatible for the experience. An entity
requesting token payload from Token Requestor 104 may have the
authorized credentials.
[0056] Token Data 110, 204 may include one or more of unencrypted
and encrypted data. In some embodiments, unencrypted data of the
token data 110, 204 may include non-sensitive information for
display purposes to the consumer without requiring decryption. For
example, the unencrypted token data may include a last four digits
of a credit card number, or PAN, a customer ZIP code, country, or
other data. In further embodiments, encrypted data of the token
data 110, 204 may include sensitive information for transaction
purposes. For example, encrypted token data 110, 204 may include
payment fields as obtained from the token server which may include
a token number, a token expiration date, a token cryptogram TAVV, a
card or PAN number, or an ECI indicator. Consumer profile fields
may also be unencrypted or encrypted, as available by the Token
Requestor and depending on a customer's data sensitivity. For
example, a billing address, a shipping address, an email address,
or phone numbers may be tokenized as encrypted or unencrypted data.
Of course, any or all of the data may be tokenized as needed by the
systems and method described herein. For example, the shipping
information for a purchase may be tokenized and inserted into a
transaction so that a customer does not have to enter the details
once a payment method is selected.
[0057] A token requestor 104 may be integrated with the token
server 102. One or more APIs executing on the server 102 may also
enroll and provision Personal Account Numbers PANs as well as
receive cryptograms for provisioned tokens. Table 1 below may
provide an overview of the basic APIs corresponding to the server
102 used to explain some of the use cases.
TABLE-US-00001 TABLE 1 API Reference Description Enroll PAN API to
enroll a PAN in a token service and also retrieve card art details
for a given PAN. A successful action enrolls a card with the token
service for subsequent provisioning. It also retrieves the card art
metadata associated with the card. Provision using PAN API to
provision token using PAN Enrollment ID. Enrollment ID Provision
Token API API where token requestor provides PAN data to using PAN
provision a token. A successful action may provision a token from
the Token Vault to a token requestor. Get Payment Data API API
where token requestor obtains a cryptogram using Token for a
provisioned token.
[0058] FIG. 3 may illustrate one embodiment of a method or data
flow 300 in the system 100 or 200. Each step of the method or data
flow 300 may be performed on a server or other computing device
including instructions that, when executed by a processor, perform
the action or block described herein.
[0059] At 302, a consumer browser 302 may be directed to a website
interface 304. In some embodiments, the interface 304 may include a
merchant payment webpage 304a of the interface 304 that is
configured to initiate the checkout process such as when a consumer
has selected items and is preparing to pay for the items. A local
or remote shopping server (e.g., a server 203 hosting the partner
interface 202) may host the merchant interface 304.
[0060] At 306, one or more tags 304b at the merchant's payment page
304a may be sent to a token requestor module 312. In some
embodiments, the tags 304b may include a "Token Ready" tag and/or a
"Token Client ID" tag. The tags 304b may be visible to the consumer
or may only be available to backend servers such as the payment
service 308.
[0061] At 310, in response to receiving the "Token Ready" tag
and/or a "Token Client ID" tag, the token requestor module 312 may
identify the page to be "Token Ready," validate the Token Client ID
tag via the one or more tags 304b, and, via the consumer browser
module 302, present the Consumer the option to select a payment
device such as an existing credit card or a new card using the
payment system. Logically, if the page is not token ready and/or
the token client ID is not validated, the customer may not be able
to use a token-based payment service as represented by the flow of
data 300. The token requestor 312 may be part of the shopping
server 203 or may be a separate server which is physically
configured to request tokens.
[0062] At block 314, the consumer browser 302 may receive an input
indicating selection of a payment device such as a card on file or
add a new card to the payment application. The selection may be as
simple as clicking on a visual representation of one of the
accounts that have been added to the payment system via the browser
304. The selection may then be sent to the token requestor module
312.
[0063] At block 316, a token requestor 312 may receive token data
from a token server 308 at the token service 308a for the payment
device or card and other information. In some embodiments, if the
payment device is an existing card with a provisioned token, the
token requestor 312 may request the token server 308 for a
cryptogram and receive the cryptogram using a Get Payment Data API
call to the checkout module 308b. In further embodiments, if the
payment device is an existing card with a provisioned token, the
token requestor 312 may request the token server 308 for a further
cryptogram and receive the further cryptogram using a Get Shipping
Details API call to the checkout module 308b corresponding to a
token that includes the shipping details of the customer. The token
server 308 may be a server physically configured to handle the
request, creation or provisioning, and communication of tokens. If
the payment device is a new card, the token requestor 312 may
enroll the card and provision the PAN first (i.e., execute both an
Enroll PAN API call and a Provisioned Token API call to the
checkout module 308b), and then may request a cryptogram from the
token service 308a for the token using Get Payment Data API. A user
interface may be presented to the user via the browser 304 to
assist in adding the new payment device.
[0064] At block 318, the token requestor 312 may use a Token Client
ID API to encrypt the token data 110, 204 as well as other data
elements provided in token data 110, 204, as described herein. The
encryption may be any known encryption that is appropriate and
widely accepted in the payment system.
[0065] At block 320, the token requestor 102 may push token details
to the browser 304 in the "Token Data" tag structure 320a,
described below, via the merchant interface 304. As the tag
structure is known and standard, the merchant interface 304 may be
configured to auto fill data 320b from the payment system which may
make payments easier for consumers and may mean more sales for
merchants. For example, consumers have become accustomed to
shipping addresses being auto-filled and the described system
enables such auto-filling to continue using a payment service.
[0066] Further, assuming the standard is followed by other payments
systems, receiving auto fill data 320b from a variety of systems
may be simplified. For example, currently Payment System A may have
a name field as the first element in a communication while Payment
System B may have a name field as the fifth element in a
communication. By following a standard, the Merchant will not have
to have separate procedures for Payment System A and Payment System
B but will simply have to follow the standard for payment system
data exchange.
[0067] At block 322, the Merchant Interface 304 or PSP may obtain
the token details in the "Token Data" tag, and may display
appropriate card details, shipping data, and other information from
the token data 110, 204 to the consumer. In some embodiments, the
interface 304 may be configured to use a cryptogram created by the
token service 308a to decipher and display the token data within
the merchant payment webpage 304a. From the displayed information,
a user may be able to accept or reject the displayed card and
account details.
[0068] At block 324, the consumer may review the payment device
card information and may submit the order. For example, if the
payment details are not as expected, the order may be canceled but
if the payment details are as expected, the order may proceed. In
some embodiments, the Merchant Interface 304 or PSP may select to
display one or more of the following from the token data 320a to
the consumer: a) Payment data; b) Last 4 of card; and/or c) Value
added data elements as decided by the Merchant/PSP (e.g. Shipping
& Billing Details).
[0069] At block 326, the merchant interface 304 or PSP may map the
token details to an e-commerce authorization request 326a, and may
submit the request 326a to the issuer server 328 through its
acquiring channel for approval. The approval may be made by an
approval module 328a which may be local or remote to the issuer
server 328 and may be physically configured to make and communicate
authorization decisions.
[0070] At block 330, the e-commerce authorization request may be
approved or declined, and the corresponding authorization response
330a may be sent back to the merchant. If the authorization is
declined, a user may be permitted to submit the authorization data
again. In some embodiments, the flow 300 may execute a Get Shipping
Details API call to the checkout module 308b and insert shipping
details into the transaction upon receiving an indication that the
transaction was approved.
[0071] To aid implementation of the method 300, the various
requirements as well as recommendations to Token Requestors 312,
the Merchant Interface 304 as well as Payment Service Providers
PSPs in the payment experience, the following system elements and
tags 304b may be communicated among the various modules, entities,
etc., of the flow 300 as follows:
[0072] "Token Ready" Tag
[0073] 1. Merchant or PSP Interface 304 receiving the token details
may need to enable an HTML tag on the payment page to mark it
"Token Ready."
[0074] 2. Token Requestor 312 may need to be able to identify the
payment page as being "Token Ready," and subsequently trigger the
corresponding E-Commerce payment experience in executing the steps
of the flow 300 described herein.
[0075] "Token Client ID" tag
[0076] 1. Merchant or PSP Interface 304 receiving the token details
may need to enable an HTML tag "Token Client ID" tag to specify its
relationship with Token Requestor 312.
[0077] a. Merchant Interface 304 may have a direct relationship
with Token Requestor 312, or
[0078] b. Merchant Interface 304 may be connected to the Token
Requestor 312 via a PSP or partner Acquirer/Gateway/E-Commerce
Payment Service Provider.
[0079] 2. Token Requestor 312 may be able to validate the "Token
Client ID" tag 304b as well as use it to encrypt token data.
[0080] "Token Data" Tag 320a
[0081] 1. Token Requestor 312 may need to be able to return token
details obtained from token server 308 required for the consumer's
order confirmation, receipt as well as payment authorization in
"Token Data" tag 320a.
[0082] 2. Merchant or PSP Interface 304 receiving token elements
may need to be able to receive token data in the "Token Data" tag
320a.
[0083] 3. The value added data elements (e.g., customer shipping
information as retrieved and tokenized using the Get Shipping
Details API call to the checkout module 308b) may contain more
elements than the ones specified in the list below, and may be
dependent on their availability and data sensitivity.
[0084] Table 2, below, shows some procedures which may make the
e-commerce tokenization procedures described herein more expedited
and efficient.
TABLE-US-00002 TABLE 2 Area Description Token Provisioning
Merchants or PSPs may need to present their tokenization content in
the service terms and privacy policies to the cardholder prior to
provisioning a token. Consumer Interface/ Merchants or PSPs may
include appropriate Customer Service messaging to educate
cardholders on tokenization. Tokens may not be
auto-filled/key-entered in the browser. Merchants or PSPs may need
to use the term "digital account number" instead of the term
"token" in all their communication with the cardholder. For
consumer-receipt purposes, where the card expiration date is used
today, the last four digits of the PAN without the expiration date
may need to be used display purposes.
[0085] Data Encryption
[0086] The token data 110, 204, tag data 304b and other data to
implement the embodiments described herein may be encrypted. As
shown in Table 3, the encryption may apply to personal account
identifiers or other information that may be traced to an account
that is sent by the token requestor 312 to the merchant or PSP
interface 304.
TABLE-US-00003 TABLE 3 Area Description Possible Requirement Data
Encryption Secure encryption of transmission and Keysizes 128-bits
or highersym; secure storage of encrypted data. An Keysizes RSA
Modulus 2048-bits or authority may recommend the use of higher
asym. ECC keysize of 256- symmetric e.g., AES-GCM, CBS, CCM or bits
or higher. As per Industry best asymmetric e.g., PKI keys. The
practices and protocols. encryption keys may be securely protected.
Integrity and non- Secure encryption of transmission and Keysizes
128-bits or highersym; repudiation of sensitive secure storage of
encrypted data. An RSA Modulus 2048-bits or higher data if
applicable, for authority may recommend the use of asym. ECC
keysize of 256-bits or data in transit symmetric e.g., AES-GCM,
CBS, CCM or higher. As per Industry best asymmetric e.g., PKI keys.
The practices and protocols. encryption keys may be securely
protected. Transmission An authority may recommend two-way SSL/TLS
secure communication, as SSL to secure communication of per
Industry best practices and personally identifiable information
e.g., protocols. cardholder address as well as personal account
identifiers e.g., token. Authentication and All communications may
have UserName/Password, PIN, OAuth session management appropriate
authentication methods 2.0, SAML 2.0, etc., as per Industry between
applications e.g., mobile app, best practices and protocols. web
redirects or between business entities e.g., client-to-server,
server-to- server Access Control Appropriate access control
measures Role-based Access Control, as per may be recommended to
prevent Industry best practices. identity attacks.
[0087] Finally, the Merchant or PSP interface 304 may decrypt the
encrypted information in token data 304b to assist in auto-filing
fields and presenting data to users to speed transactions and make
transactions more trustworthy from a user's perspective.
[0088] As a result of the system and the unified format described
herein, a merchant may be able to make a single request for a
certain type of data without regard to the payment service
receiving the request. Currently, each payment service has a
different way to name each data field, a different API to call for
certain data, a different manner of delivering the data, etc. As a
result, a merchant has to add programming for each payment service
that is supported along with the appropriate APIs for each payment
service. By having a consistent manner of naming data, calling for
data, receiving data, etc., the amount of programming may
significantly drop. Further, the exchange with payment applications
may be more reliable as the data exchange should follow a
standard.
[0089] A more recent complexity is the use of tokens. Tokens are
not actual PANs but may be used as a proxy for a PAN wherein an
authority can translate the token data 304b into a PAN but the
token data is the only data disclosed on a network. By following
the blocks of the embodiments described herein, account data which
may be stored by the token server 308 may still be accessed and
used for autofill purposes to assist users in filling out forms
which can be filled with autofill data. Such data was often
previously unavailable to merchants when tokens were used. By
addressing this technical problem of user data being hidden behind
tokens, the user data may now be available to merchants in an
encrypted manner.
[0090] Another benefit may be that expired cards may not limit a
user from using a payment application to make a purchase. The
merchant may request a valid and unique cryptogram which may be
provided even if the underlying card has expired in certain
circumstances. Instead of having to bother users to enter data on
new cards with updated expiration dates, the old card may be
leveraged to allow a user to continue to use the payment
application to make payments. In other embodiments, the user may
only have to update an expiration data and all the other card data
may be auto-filled.
[0091] With reference to FIG. 4, a system 400 may be utilized for
person-to-person payments or for consumer-to-merchant payments in
which the payee a merchant displays its account identifier to the
payer a consumer to enable the payer to initiate payments in favor
of the payee. In other scenarios, the payer may be a donor wishing
to make a donation to the payee, being a charitable organization
displaying its account identifier on, for example a poster or
digital display.
[0092] In the embodiments described herein, the payee may provide
its account identifier to the payer in a tag e.g., tags 304b, etc.
which includes a personal information flag indicating that certain
personal information of the payer is requested by the payee.
Embodiments described herein may also include personal information
in the tags which may be requested by the payee including one or
more of the group of: a shipping address, an address of a contact
other than the payer, contact information of the payer such as an
email address and/or a phone number, know-your-customer KYC
information, an identity number, a social security number and the
like. Accordingly, and depending on whether the payer grants
permission for the personal information requested by the payee to
be shared with the payee, the transaction request message may
include the requested personal information of the payer 412 which
will be shared with the payee.
[0093] The issuer and acquirer server computers 410, 420
respectively may be any appropriate server computers, server
computer clusters, distributed server computers, cloud-based server
computers and the like. Each of the server computers 410, 420 may
include a processor and a non-transitory computer readable medium
comprising code executable by the processor to perform functions,
such as generating messages, electronically receiving and
transmitting messages or data, parsing messages or data, and the
like. The server computers 410, 420 may be configured to transmit
and receive financial system transaction messages such as ISO 8583
messages, debit and credit financial accounts, transmit messages to
and receive messages from the communication devices 414, 424
respectively and the like.
[0094] The issuer server computer 410 may be maintained or operated
by financial institution 416 controlling a financial account 418 of
the payer. The financial account of the payer may be associated
with an account identifier. Similarly, the acquirer server computer
420 may be maintained or operated by another financial institution
426 controlling a financial account 428 of the payee 412. The
financial account 428 of the payee 422 may be associated with an
account identifier.
[0095] The account identifiers of the payer and the payee may
include routing information usable by the payment processing
network 430 in routing financial system transaction response
messages between the server computers 410, 420. The routing
information may be a bank identification number BIN associated with
the respective financial institution 416, 426 and which is usable
by the payment processing network 430 in identifying the
appropriate financial institution 416, 426 to which the financial
system response messages should be transmitted.
[0096] The payment processing network 430 may include data
processing subsystems, networks, server computers and operations
used to support and deliver authorization services, exception file
services, and clearing and settlement services. The payment
processing network 430 may be any suitable network able to transmit
and receive financial system transaction messages e.g., ISO 8583
messages, and process original credit and debit card transactions.
Payment processing systems are able to process credit card
transactions, debit card transactions, and other types of
commercial transactions, including virtual card and mobile wallet
transactions. The payment processing network 430 may be an
interoperable payment processing network.
[0097] The payer's communication device 414 may be any appropriate
electronic device capable of communicating over a communication
network 450. The communication device 414 may be one or more of: a
mobile phone, a smart phone, a wearable computing device, tablet
computing device, a personal digital assistant, a laptop or desktop
computer or the like. The communication device 414 may have a
software application resident therein and installed thereon which
may enable the communication device 414 to transmit data messages
to and receive data messages from the issuer server computer 410.
In other embodiments, the communication device 414 may exchange
data messages with the issuer server computer 410 using
Unstructured Supplementary Service Data USSD sessions or Short
Messaging Service SMS messages via the communication network
450.
[0098] The payee's communication device 424 may be any appropriate
electronic device capable of communicating over the communication
network 450. Depending on the application, the payee communication
device 424 may be a mobile phone, a point of sales device, an
electronic transaction server or the like. The payee's
communication device 424 may also have an appropriate software
application resident therein and installed thereon which may enable
the communication device 424 to transmit data messages to and
receive data messages from the acquirer server computer 420.
[0099] By enabling the payer's communication device 414 to exchange
messages with the issuer server computer 410, the payer 412 may be
able to use the communication device 414 to transact against the
financial account 418 of the payer controlled by the payer's
financial institution 416. The payer may be able to initiate
transactions in favor of the payee's financial account 428 by using
the payer's communication device 414 to generate and transmit a
transaction message, including the account identifier of the payee
and an amount associated with the transfer of funds, to the issuer
server computer 410. When initiating a transaction in favor of the
payee, the payer may be able to indicate whether he or she permits
personal information, such as a shipping address or contact
information, to be shared with the payee.
[0100] In response to receiving the transaction message requesting
the issuer server computer 410 to initiate a transfer of funds in
favor of the payee's financial account 428, the issuer server
computer 410 debits the financial account of the payer and
transmits a transaction request message, including the account
identifier of the payee and the amount, to the acquirer server
computer 420. If the payer has indicated that personal information
may be shared with the payee, the issuer server computer 410 may
include this personal information in the transaction request
message.
[0101] A transaction request message may be any suitable financial
system transaction message transmitted from the issuer server
computer 410 to the acquirer server computer 420 through the
payment processing network 430. A transaction request message may
be in the standard ISO 8583 messaging format, or in any other
suitable financial system transaction messaging format. Suitable
messages may also be in an "0200" message format. The transaction
request message may be an Original Credit Transaction OCT type
message.
[0102] An OCT is typically a clearing and settlement credit
transaction designed for use in business applications such as a
business money transfer or business-to-consumer repayments. A
special indicator identifies an OCT to the recipient of the
message. OCT messages may also include an Electronic Commerce
Indicator ECI to indicate an Internet OCTs if appropriate.
Representational State Transfer Extensible Markup Language
REST-XML, REST-JavaScript Object Notation REST-JSON, and
REST-Name-Value-Pairs REST-NVP templates may be used for the OCT
request messages. OCT request messages described herein may include
an amount associated with the transfer of funds, an account
identifier of the payee, an account identifier of a payer, personal
information of the payer, a message type indicator, a transaction
identifier, currency information and any other appropriate
information.
[0103] The transaction request message may thus be routed from the
payment processing network 430 to the acquirer server computer 420.
The acquirer server computer 420 credits the payee's financial
account 128 and transmits a transaction response message, either
confirming or denying the transaction, to the issuer server
computer 410 via the payment processing network 430. A transaction
response message may be any suitable message transmitted from the
acquirer server computer 420 to the issuer server computer 410
through the payment processing network 430, in response to the
transaction request message. A transaction response message may be
in the standard ISO 8583 messaging format, or in any other suitable
financial system transaction messaging format. The transaction
response message may include an indication that the transfer of
funds was approved or not approved.
[0104] The acquirer server computer 420 may transmit a payment
confirmation message to the payee indicating the amount paid by the
payer and including the personal information of the payer requested
by the payee. The payee may then be able to use the personal
information to communicate with the payer, for example by shipping
a product purchased by the payer to the address included in the
transaction request message or by acknowledging a donation received
from the payer.
[0105] Turning now to FIG. 5, components of the payer's
communication device 414, the issuer server computer 410 and the
acquirer server computer 420 are illustrated.
[0106] The communication device 414 of the payer may include a
communication network interface 502 arranged to enable the
communication device 414 to communicate with the issuer server
computer 410 over the communication network 450. Further details of
an embodiment of a communication device are provided with reference
to FIG. 9 and described below.
[0107] The communication device 414 may include a processor for
executing the functions of the described components which may be
software units executing on the communication device 414 either
being resident thereon or provided remotely. Instructions may be
provided to the processor to carry out the functionality of the
described components.
[0108] The communication device 414 may host a banking or payment
functionality provided by a payment application 503 which may
include secure transaction capabilities. A payment application 503
may be provided by a financial institution or payment processing
network and may be resident on the communication device 414 or may
be provided as a remotely based service application.
[0109] The payment application 503 may include an obtaining
component 504 which is configured to obtain information from a tag
provided by the payee. The obtaining component 504 may include
access to hardware components of the communication device 414
including one or more of the group of: a camera 504A for capturing
information from a tag in the form of a graphical code such as a
barcode, two-dimensional barcode or the like; an antenna and
transceiver 504B for receiving information from a tag in the form
of a radio frequency beacon such as a Near Field Communication NFC,
Radio Frequency Identification RFID, Bluetooth.TM. Low Energy BLE
beacon or the like; and a microphone 504C for receiving information
from a tag in the form of a near sound communication beacon. The
information obtained from the tag may include one or more of the
group of: an account identifier of the payee; a personal
information flag indicating that personal information of the payer
is requested by the payee; an amount e.g. $200; information about
the payee such as a name of the payee, an address of the payee, a
merchant category code where applicable of the payee and the
like.
[0110] The payment application 503 may also include a prompting
component 506 arranged to prompt the payer operating the
communication device 414 for permission to share the requested
personal information with the payee. The prompting component 506
may prompt the payer via a message displayed on a display screen
508 of the communication device 414. The prompting component 506
may also display the personal information which will be shared with
the payee together with the prompt. In some embodiments, the
prompting component 506 may be configured to provide the payer with
an option to edit the personal information which will be shared
with the payee. It is also anticipated that the prompting component
506 may be arranged to provide the payer with an option to select
personal information of a contact of the payer which will be shared
with the payee, for example, where the payer is purchasing a gift
for one of the payer's contacts.
[0111] The payment application 503 may further include an input
component 510 which is arranged to receive the payer's approval or
denial in respect of sharing the requested personal information
with the payee. The input component 510 may further be configured
to receive input by the payer editing the personal information to
be shared with the payer or alternatively the payer's input as to a
contact whose personal information should be shared with the payee.
In some embodiments, the input component 510 is further configured
to receive an amount input by the payer in respect of the transfer
of funds e.g. where this is not included in the information
received from the tag.
[0112] The payment application 503 may include a generating
component 512 configured to generate a transaction message. The
generating component 512 may be arranged to include one or more of:
the amount associated with the transfer of funds; the account
identifier of the payee obtained from the tag; the account
identifier of the payer; and a permission indication indicating the
payer's approval or denial in respect of sharing the requested
personal information with the payee in the transaction message. In
some embodiments, the generating component 512 includes a
retrieving component 512A for retrieving the requested personal
information from a digital memory of the communication device and
including the retrieved personal information with the permission
indication in the transaction message. In other embodiments, the
personal information may be stored at the issuer server computer
410 for retrieval thereat.
[0113] The payment application 503 may also include a transmitting
component 514 configured to transmit the generated transaction
message to the issuer server computer 410 associated with the payer
for processing the transaction and conditional forwarding of the
requested personal information to the payee. The communication
device 414 may further include a receiving component 516 for
receiving a transaction confirmation or denial message confirming
or denying the transaction. The transmitting component 514 and
receiving component 516 may use the communication network interface
502 to transmit the transaction message to and receive the
transaction confirmation or denial message from the issuer server
computer 410 via the communication network 450. The issuer server
computer 410 may include at least one processor, a hardware module,
or a circuit for executing the functions of the described
components which may be software units executing on the at least
one processor.
[0114] The issuer server computer 410 may include a communication
network interface 520A arranged to enable the issuer server
computer 410 to communicate with the communication device 414 of
the payer over the communication network 450. The issuer server
computer 410 may include a payment processing network interface
520B configured to enable the issuer server computer 410 to
communicate with the payment processing network 430 and in turn the
acquirer server computer 420. The payment processing network
interface 520B may, for example be configured to parse messages
into ISO 8583 formatted messages for transmission over the payment
processing network 430 as well as performing handshaking and other
networking operations.
[0115] The issuer server computer 410 may also include a payer
messaging bcomponent 522 which is configured to receive the
transaction message from the communication device 414 of the payer.
The payer messaging component 522 may receive the transaction
message via the communication network interface 520A of the issuer
server computer 410.
[0116] The issuer server computer 410 may also include an
identifying component 524 arranged to identify a financial account
and/or a data record associated with the payer. The identifying
component 524 may use the account identifier of the payer included
in the transaction message to identify the financial account and/or
the data record. The identifying component 524 may also include a
debiting component 524A for debiting the financial account with the
amount associated with the transfer of funds.
[0117] The issuer server computer 410 may include an evaluating
component 526 which is arranged to evaluate the permission
indication included in the transaction message to determine whether
the payer has granted or denied permission to the issuer server
computer 410 to share personal information requested by the payee
with the payee.
[0118] In some embodiments, the issuer server computer 410 includes
a retrieving component 528 configured to retrieve the requested
personal information, in respect of which the payer has granted
permission for sharing with the payee, from the data record
associated with the payer. In other embodiments, the personal
information is included with the permission indication in the
transaction message.
[0119] The issuer server computer 410 may include a generating
component 530 arranged to, if the permission indication indicates
that the requested personal information may be shared with the
payee, generate a transaction request message. The generating
component 530 may include one or more of the amount; the account
identifier of the payee; the account identifier of the payer; the
requested personal information in respect of which the payer has
granted permission for sharing with the payee; and optionally
additional information in the transaction request message. The
transaction request message generated by the generating component
530 may be an OCT request message.
[0120] If the permission indication indicates that the requested
personal information may not be shared with the payee, the
generating component 530 may be configured to generate a
transaction request message including the amount and the account
identifier of the payee and optionally other information. In other
embodiments, the transaction may fail if the permission indication
indicates that the requested personal information may not be shared
with the payee.
[0121] The issuer server computer 410 may also include a payment
network messaging component 532 which is arranged to transmit the
transaction request message for receipt by the acquirer server
computer 420 associated with the payee. The payment network
messaging component 532 may also be arranged to receive a
transaction response message from the acquirer server computer
either confirming or denying the transaction. The payment network
messaging component 532 may send and receive transaction request
and response messages to and from the payment processing network
using the payment processing network interface 520B.
[0122] The acquirer server computer 420 may include at least one
processor, a hardware module, or a circuit for executing the
functions of the described components which may be software units
executing on the at least one processor.
[0123] The acquirer server computer 420 may include a communication
network interface 540A arranged to enable the acquirer server
computer 420 to communicate with the communication device 424 of
the payee over the communication network 450. The acquirer server
computer 420 may include a payment processing network interface
540B configured to enable the acquirer server computer 420 to
communicate with the payment processing network 430 and in turn the
issuer server computer 410.
[0124] The acquirer server computer 420 may include a payment
network messaging component 542 for receiving transaction request
messages from the issuer server computer 410 via the payment
processing network 430. The payment network messaging component 542
may also be arranged to transmit transaction response messages to
the issuing server computer via the payment processing network
either confirming or denying the transaction. The payment network
messaging component 542 may send and receive transaction response
and request messages to and from the payment processing network
using the payment processing network interface 5408.
[0125] The acquirer server computer 420 may also include an
extracting component 544 configured to extract the amount
associated with the transfer of funds, the account identifier of
the payee and the personal information from the transaction request
message.
[0126] The acquirer server computer 420 may also include an
identifying component 546 for identifying the financial account of
the payee associated with the payee account identifier and a
crediting component 546A for crediting the financial account of the
payee with the amount.
[0127] The acquirer server computer 420 may further include a payee
messaging component 548 arranged to transmit a confirmation or
denial message to the communication device 424 of the payee either
confirming or denying the transaction. The payment confirmation
message may include the amount in respect of the transfer of funds
as well as the personal information which was requested by the
payee.
[0128] It should be appreciated that the issuer server computer 410
may be configured to act as and perform the operations of an
acquirer server computer and vice versa. Thus embodiments of the
described system anticipate an issuer server computer including the
components of and being able to perform the functions and
operations of an acquirer server computer and similarly an acquirer
server computer including the components of and being able to
perform the functions and operations of an issuer server computer.
For example, a server computer may be an acquirer server computer
to one entity and an issuer server computer to another entity. In
some cases, depending on whether the entity is a payer or a payee
in a particular transaction, the server computer may act as and
perform the operations and functions of an acquirer server computer
or an issuer server computer as may be required.
[0129] An exemplary method 600 for conducting a transaction using
the system described above is illustrated in FIG. 6. Each step of
the method may be performed on a server or other computing device
including instructions that, when executed by a processor, perform
the action or block described herein.
[0130] The method may be implemented in a number of transaction
scenarios. For example, in one scenario, a payer may be a consumer
who notices an advertisement which advertises a product which the
payee a merchant is selling. The advertisement may be a digital
display and may include a tag in which the account identifier of
the payer, an amount which must be paid for the product, as well as
a personal information flag indicating that certain personal
information of the payer will be required by the payee. The
personal information flag may, for example, indicate that the payee
will require a shipping address of the payer so that the product
can be shipped to the payer.
[0131] In another exemplary scenario, the payee may be a charity
appealing to donors to make donations. The payee may place
advertisements including a tag in public spaces. The tag may
include the account identifier of the payer, a suggested donation
amount, as well as a personal information flag indicating that
certain personal information such as an email address of the payer
will be required by the payee.
[0132] Upon noticing the advertisement and wishing to act on it,
the payer may use his or her communication device 414 to obtain
information from the tag. At a first stage 602, the communication
device 414 of the payer obtains information from the tag. The
information obtained from the tag may include an account identifier
of the payee, a personal information flag indicating that personal
information of the payer is requested by the payee, optionally an
amount, and optionally additional information. Obtaining the
information from the tag may include scanning a graphical code or
receiving the information from a radio frequency or near sound
communication beacon.
[0133] The communication device 414 may then, at a following stage
604, detect that the information includes a personal information
flag indicating that personal information of the payer is requested
by the payee. The personal information flag may indicate that one
or more of a shipping address, an email address, and a phone number
of the payer is requested by the payee.
[0134] At a next stage 606, the communication device 414 prompts
the payer for permission to share the requested personal
information with the payee. This stage 606 may include displaying
the personal information which will be shared with the payee to the
payer. In some embodiments, the stage 606 of prompting the payer
for permission to share personal information includes providing the
payer with an option to edit the personal information which will be
shared with the payee and/or with an option to select personal
information of a contact of the payer which will be shared with the
payee. The prompt may, for example, allow the payer to select a
contact from an address book stored in the communication device
414, where the payer is purchasing a gift for the contact.
[0135] The payer may decide that the requested personal information
may be shared with the payee or alternatively that he or she does
not wish for the requested personal information to be shared with
the payee. The communication device 414 may then receive the
payer's approval or denial in respect of sharing the requested
personal information with the payee in a following stage 608. This
stage 608 may include receiving edits to the personal information
made by the payer and/or personal information of a contact other
than the payer. In some embodiments, the payer may also input an
amount for example where the payer is making a donation to the
payee while in other embodiments the amount is included in the
information obtained from the tag.
[0136] At a next stage 610, the communication device 414 generates
a transaction message including the amount associated with the
transfer of funds, the account identifier of the payee, a
permission indication indicating the payer's approval or denial in
respect of sharing the requested personal information with the
payee and optionally additional information. In some embodiments,
the step 610 of generating the transaction message may include a
step of retrieving the requested personal information for inclusion
with the permission indication in the transaction message. In other
embodiments this step is performed by the issuer server
computer.
[0137] At a following stage 612, the communication device 414
transmits the transaction message to the issuer server computer 410
associated with the payer for processing the transaction and
conditional forwarding depending on the permission indication
included in the message of the requested personal information to
the payee.
[0138] The issuer server computer 410 then receives the transaction
message at a following stage 614. The transaction message may
include the amount associated with the transfer of funds, the
account identifier of the payee, a permission indication indicating
the payer's approval or denial in respect of sharing with the payee
personal information requested by the payee, and optionally
additional information.
[0139] At a following stage 616, the issuer server computer 410
identifies a financial account and/or a data record associated with
the payer, for example using the account identifier of the payer
included in the transaction message. This stage 616 may include
debiting the financial account of the payer with the amount
associated with the transfer of funds.
[0140] The issuer server computer 410 may then, at a following
stage 618, evaluate the permission indication included in the
transaction message to determine whether the payer has granted or
denied permission to the issuer server computer 410 to share the
requested personal information with the payee.
[0141] If 620 the permission indication indicates that the
requested personal information may be shared with the payee, the
issuer server computer 410 may retrieve the requested personal
information from the data record associated with the payer at a
next stage 622. In other embodiments, the permission indication may
include the requested personal information. At a next stage 624,
the issuer server computer 410 may then generate a transaction
request message including the amount, the account identifier of the
payee, the requested personal information and optionally additional
information. The transaction request message generated by the
issuer server computer may be an OCT request message.
[0142] Alternatively, if 620 the permission indication indicates
that the requested personal information may not be shared with the
payee, the issuer server computer 410 may generate a transaction
request message including the amount, the account identifier of the
payee and optionally additional information at an alternative stage
626. In other cases, where the requested personal information may
not be shared with the payee, the transaction may fail and messages
to that effect may be transmitted.
[0143] At a following stage 628, the issuer server computer 410
transmits the transaction request message for receipt by the
acquirer server computer 420 associated with the payee.
Transmitting the transaction request message may transmit the
message via the payment processing network.
[0144] The acquirer server computer 420 may then receive the
transaction request message at a following stage 630.
[0145] The acquirer server computer 420 may then, at a further
stage 632, extract the amount associated with the transfer of
funds, the account identifier of the payee and the personal
information if any from the transaction request message.
[0146] At a next stage 634, the acquirer server computer 420 may
identify the financial account of the payee associated with the
payee account identifier and credit the financial account with the
amount.
[0147] The acquirer server computer 420 may then generate and
transmit a transaction response message to the issuer server
computer 410 either confirming or denying the transaction at a
following stage 636. The transaction response message may be an OCT
response message.
[0148] The acquirer server computer 420 may also transmit a
confirmation or denial message to the communication device of the
payee either confirming or denying the transaction at a next stage
638. The payment confirmation message may include the amount in
respect of the transfer of funds as well as the personal
information which was requested by the payee.
[0149] Having received the payment confirmation message together
with the personal information of the payer, the payee may cause the
product purchased by the payee to be shipped; may send an email to
the payer thanking the payer for his or her donation or the
like.
[0150] The issuer server computer 410 may receive the transaction
response message at a following stage 640 and may then transmit a
payment confirmation or denial message to the communication device
of the payer either confirming or denying the transaction.
[0151] The embodiments described herein thus enable personal
information of a payer to be transmitted together with payment
information e.g. an account identifier of a payee and an amount in
respect of the transfer of funds to be sent together in a single
message. The personal information and payment information may thus
be received from a single source as opposed to disparate sources as
may previously have been the case. Furthermore, embodiments
described herein provide for payment information and personal
information of the payer to be transmitted over an interoperable
payment processing network. Embodiments described herein provide a
system and method in which push payment transaction messages are
transmitted over an interoperable payment processing network and
include both payment information and personal information of the
payer which may be used by the payee.
[0152] The system and method described herein may be advantageous
in that receiving information by payees such as merchants from
disparate sources is obviated. This may reduce the time and
processing required at the payee to tie related pieces of
information together e.g. a payment confirmation received from a
bank and address information received directly from the payer.
[0153] FIG. 7 is a schematic diagram which illustrates an exemplary
scenario of the described system and method in use from the
perspective of a payer. The payer may notice an advertisement 702
advertising a product for sale by a payee. The advertisement 702
includes a tag 704. The tag 704 includes an account identifier of
the payee 706, an amount associated with the price of the product
708 and a personal information flag 710 indicating that the payee
requests personal information of the payer. The payer uses his or
her communication device 414 to obtain 711 the account identifier
706, amount 708 and a personal information flag 710 from the tag
704. Responsive to detecting the personal information flag 710, the
communication device 414 prompts 712 the payer for permission to
share the payer's personal information with the payee. The prompt
may display the relevant personal information which will be shared.
The payer inputs 714 his or her approval indicating that the
personal information may be shared with payee and causes the
communication device 414 to transmit a transaction message
including a permission indication indicating the payer's approval
in respect of sharing the personal information requested by the
payee with the payee as well as the amount and the account
identifier of the payee. The payer then receives a transaction
confirmation message 716 confirming the transaction and indicating
that the product will be shipped to the payer's shipping
address.
[0154] FIG. 8 illustrates an example of a computing device 800 in
which various aspects of the embodiments described herein may be
implemented. The computing device 800 may be suitable for storing
and executing computer program code. The various participants and
elements in the previously described system diagrams may use any
suitable number of subsystems or components of the computing device
800 to facilitate the functions described herein.
[0155] The computing device 800 may include subsystems or
components interconnected via a communication infrastructure 805
for example, a communications bus, a cross-over bar device, or a
network. The computing device 800 may include at least one central
processor 810 and at least one memory component in the form of
computer-readable media.
[0156] The memory components may include system memory 815, which
may include read only memory ROM and random access memory RAM. A
basic input/output system BIOS may be stored in ROM. System
software may be stored in the system memory 815 including operating
system software.
[0157] The memory components may also include secondary memory 820.
The secondary memory 820 may include a fixed disk 821, such as a
hard disk drive, and, optionally, one or more removable-storage
interfaces 822 for removable-storage components 823.
[0158] The removable-storage interfaces 822 may be in the form of
removable-storage drives for example, magnetic tape drives, optical
disk drives, floppy disk drives, etc. for corresponding removable
storage-components for example, a magnetic tape, an optical disk, a
floppy disk, etc., which may be written to and read by the
removable-storage drive.
[0159] The removable-storage interfaces 822 may also be in the form
of ports or sockets for interfacing with other forms of
removable-storage components 823 such as a flash memory drive,
external hard drive, or removable memory chip, etc.
[0160] The computing device 800 may include an external
communications interface 830 for operation of the computing device
800 in a networked environment enabling transfer of data between
multiple computing devices 800. Data transferred via the external
communications interface 830 may be in the form of signals, which
may be electronic, electromagnetic, optical, radio, or other types
of signal.
[0161] The external communications interface 830 may enable
communication of data between the computing device 800 and other
computing devices including servers and external storage
facilities. Web services may be accessible by the computing device
800 via the communications interface 830. The external
communications interface 830 may also enable other forms of
communication to and from the computing device 800 including, voice
communication, near field communication, Bluetooth.TM., etc.
[0162] The computer-readable media in the form of the various
memory components may provide storage of computer-executable
instructions, data structures, program modules, and other data. A
computer program product may be provided by a computer-readable
medium having stored computer-readable program code executable by
the central processor 810. A computer program product may be
provided by a non-transient computer-readable medium, or may be
provided via a signal or other transient means via the
communications interface 830.
[0163] Interconnection via the communication infrastructure 805
allows a central processor 810 to communicate with each subsystem
or component and to control the execution of instructions from the
memory components, as well as the exchange of information between
subsystems or components.
[0164] Peripherals such as printers, scanners, cameras, or the like
and input/output I/O devices such as a mouse, touchpad, keyboard,
microphone, joystick, or the like may couple to the computing
device 500 either directly or via an I/O controller 535. These
components may be connected to the computing device 500 by any
number of means known in the art, such as a serial port. One or
more monitors 545 may be coupled via a display or video adapter 540
to the computing device 500.
[0165] FIG. 9 shows a block diagram of a communication device 900
that may be used in embodiments of the disclosure. The
communication device 900 may be a cell phone, a feature phone, a
smart phone, a satellite phone, or a computing device having a
phone capability.
[0166] The communication device 900 may include a processor 905
e.g., a microprocessor for processing the functions of the
communication device 900 and a display 920 to allow a user to see
the phone numbers and other information and messages. The
communication device 900 may further include an input element 925
to allow a user to input information into the device e.g., input
buttons, touch screen, etc., a speaker 930 to allow the user to
hear voice communication, music, etc., and a microphone 935 to
allow the user to transmit his or her voice through the
communication device 900.
[0167] The processor 905 of the communication device 900 may
connect to a memory 915. The memory 915 may be in the form of a
computer-readable medium that stores data and, optionally,
computer-executable instructions.
[0168] The communication device 900 may also include a
communication element 940 for connection to communication channels
e.g., a cellular telephone network, data transmission network,
Wi-Fi.TM. network, satellite-phone network, Internet network,
Satellite Internet Network, etc. The communication element 940 may
include an associated wireless transfer element, such as an
antenna.
[0169] The communication element 940 may include a subscriber
identity module SIM in the form of an integrated circuit that
stores an international mobile subscriber identity and the related
key used to identify and authenticate a subscriber using the
communication device 900. One or more subscriber identity modules
may be removable from the communication device 900 or embedded in
the communication device 900.
[0170] The communication device 900 may further include a
contactless element 950, which is typically implemented in the form
of a semiconductor chip or other data storage element with an
associated wireless transfer element, such as an antenna. The
contactless element 950 may be associated with e.g., embedded
within the communication device 900 and data or control
instructions transmitted via a cellular network may be applied to
the contactless element 950 by means of a contactless element
interface not shown. The contactless element interface may function
to permit the exchange of data and/or control instructions between
mobile device circuitry and hence the cellular network and the
contactless element 950.
[0171] The contactless element 950 may be capable of transferring
and receiving data using a near field communications NFC capability
or near field communications medium typically in accordance with a
standardized protocol or data transfer mechanism e.g., ISO
14443/NFC. Near field communications capability is a short-range
communications capability, such as radio-frequency identification
RFID, Bluetooth.TM.' infra-red, or other data transfer capability
that can be used to exchange data between the communication device
900 and an interrogation device. Thus, the communication device 900
may be capable of communicating and transferring data and/or
control instructions via both a cellular network and near field
communications capability.
[0172] The data stored in the memory 915 may include: operation
data relating to the operation of the communication device 900,
personal data e.g., name, date of birth, identification number,
etc., financial data e.g., bank account information, a bank
identification number BIN, credit or debit card number information,
account balance information, expiration date, loyalty provider
account numbers, etc., transit information e.g., as in a subway or
train pass, access information e.g., as in access badges, etc. A
user may transmit this data from the communication device 900 to
selected receivers.
[0173] The communication device 900 may be, amongst other things, a
notification device that can receive alert messages and access
reports, a portable merchant device that can be used to transmit
control data identifying a discount to be applied, as well as a
portable consumer device that can be used to make payments.
[0174] The foregoing description of the embodiments of the
invention has been presented for the purpose of illustration; it is
not intended to be exhaustive or to limit the invention to the
precise forms disclosed. Persons skilled in the relevant art can
appreciate that many modifications and variations are possible in
light of the above disclosure.
[0175] The user devices, computers and servers described herein may
have, among other elements, a microprocessor such as from the Intel
Corporation, AMD or Motorola; volatile and non-volatile memory; one
or more mass storage devices i.e., a hard drive; various user input
devices, such as a mouse, a keyboard, or a microphone; and a video
display system. The user devices, computers and servers described
herein may be running on any one of many operating systems
including, but not limited to WINDOWS, UNIX, LINUX, MAC OS, or
Windows XP, VISTA, etc. It is contemplated, however, that any
suitable operating system may be used for the present invention.
The servers may be a cluster of web servers, which may each be
LINUX based and supported by a load balancer that decides which of
the cluster of web servers should process a request based upon the
current request-load of the available servers.
[0176] The user devices, computers and servers described herein may
communicate via networks, including the Internet, WAN, LAN, Wi-Fi,
other computer networks now known or invented in the future, and/or
any combination of the foregoing. It should be understood by those
of ordinary skill in the art having the present specification,
drawings, and claims before them that networks may connect the
various components over any combination of wired and wireless
conduits, including copper, fiber optic, microwaves, and other
forms of radio frequency, electrical and/or optical communication
techniques. It should also be understood that any network may be
connected to any other network in a different manner. The
interconnections between computers and servers in system are
examples. Any device described herein may communicate with any
other device via one or more networks.
[0177] The example embodiments may include additional devices and
networks beyond those shown. Further, the functionality described
as being performed by one device may be distributed and performed
by two or more devices. Multiple devices may also be combined into
a single device, which may perform the functionality of the
combined devices.
[0178] The various participants and elements described herein may
operate one or more computer apparatuses to facilitate the
functions described herein. Any of the elements in the
above-described Figures, including any servers, user devices, or
databases, may use any suitable number of subsystems to facilitate
the functions described herein.
[0179] Any of the software components or functions described in
this application, may be implemented as software code or computer
readable instructions that may be executed by at least one
processor using any suitable computer language such as, for
example, Java, C++, or Perl using, for example, conventional or
object-oriented techniques.
[0180] The software code may be stored as a series of instructions
or commands on a non-transitory computer readable medium, such as a
random access memory RAM, a read only memory ROM, a magnetic medium
such as a hard-drive or a floppy disk, or an optical medium such as
a CD-ROM. Any such computer readable medium may reside on or within
a single computational apparatus and may be present on or within
different computational apparatuses within a system or network.
[0181] It may be understood that the present invention as described
above can be implemented in the form of control logic using
computer software in a modular or integrated manner. Based on the
disclosure and teachings provided herein, a person of ordinary
skill in the art may know and appreciate other ways and/or methods
to implement the present invention using hardware, software, or a
combination of hardware and software.
[0182] The above description is illustrative and is not
restrictive. Many variations of the invention will become apparent
to those skilled in the art upon review of the disclosure. The
scope of the invention should, therefore, be determined not with
reference to the above description, but instead should be
determined with reference to the pending claims along with their
full scope or equivalents.
[0183] One or more features from any embodiment may be combined
with one or more features of any other embodiment without departing
from the scope of the invention. A recitation of "a", "an" or "the"
is intended to mean "one or more" unless specifically indicated to
the contrary. Recitation of "and/or" is intended to represent the
most inclusive sense of the term unless specifically indicated to
the contrary.
[0184] One or more of the elements of the present system may be
claimed as means for accomplishing a particular function. Where
such means-plus-function elements are used to describe certain
elements of a claimed system it will be understood by those of
ordinary skill in the art having the present specification, figures
and claims before them, that the corresponding structure is a
general purpose computer, processor, or microprocessor as the case
may be programmed to perform the particularly recited function
using functionality found in any general purpose computer without
special programming and/or by implementing one or more algorithms
to achieve the recited functionality. As would be understood by
those of ordinary skill in the art that algorithm may be expressed
within this disclosure as a mathematical formula, a flow chart, a
narrative, and/or in any other manner that provides sufficient
structure for those of ordinary skill in the art to implement the
recited process and its equivalents.
[0185] While the present disclosure may be embodied in many
different forms, the drawings and discussion are presented with the
understanding that the present disclosure is an exemplification of
the principles of one or more inventions and is not intended to
limit any one of the inventions to the embodiments illustrated.
[0186] The present disclosure provides a solution to the long-felt
need described above. In particular, the systems and methods
described herein may be configured for improving payment systems.
Further advantages and modifications of the above described system
and method will readily occur to those skilled in the art. The
disclosure, in its broader aspects, is therefore not limited to the
specific details, representative system and methods, and
illustrative examples shown and described above. Various
modifications and variations can be made to the above specification
without departing from the scope or spirit of the present
disclosure, and it is intended that the present disclosure covers
all such modifications and variations provided they come within the
scope of the following claims and their equivalents.
[0187] Additionally, certain embodiments are described herein as
including logic or a number of components, modules, or mechanisms.
Modules may constitute either software modules e.g., code or
instructions embodied on a machine-readable medium or in a
transmission signal, wherein the code is executed by a processor or
hardware modules. A hardware module is tangible unit capable of
performing certain operations and may be configured or arranged in
a certain manner. In example embodiments, one or more computer
systems e.g., a standalone, client or server computer system or one
or more hardware modules of a computer system e.g., a processor or
a group of processors may be configured by software e.g., an
application or application portion as a hardware module that
operates to perform certain operations as described herein.
[0188] In various embodiments, a hardware module may be implemented
mechanically or electronically. For example, a hardware module may
comprise dedicated circuitry or logic that is permanently
configured e.g., as a special-purpose processor, such as a field
programmable gate array FPGA or an application-specific integrated
circuit ASIC to perform certain operations. A hardware module may
also comprise programmable logic or circuitry e.g., as encompassed
within a general-purpose processor or other programmable processor
that is temporarily configured by software to perform certain
operations. It will be appreciated that the decision to implement a
hardware module mechanically, in dedicated and permanently
configured circuitry, or in temporarily configured circuitry e.g.,
configured by software may be driven by cost and time
considerations.
[0189] Accordingly, the term "hardware module" should be understood
to encompass a tangible entity, be that an entity that is
physically constructed, permanently configured e.g., hardwired, or
temporarily configured e.g., programmed to operate in a certain
manner or to perform certain operations described herein. As used
herein, "hardware-implemented module" refers to a hardware module.
Considering embodiments in which hardware modules are temporarily
configured e.g., programmed, each of the hardware modules need not
be configured or instantiated at any one instance in time. For
example, where the hardware modules comprise a general-purpose
processor configured using software, the general-purpose processor
may be configured as respective different hardware modules at
different times. Software may accordingly configure a processor,
for example, to constitute a particular hardware module at one
instance of time and to constitute a different hardware module at a
different instance of time.
[0190] Hardware modules can provide information to, and receive
information from, other hardware modules. Accordingly, the
described hardware modules may be regarded as being communicatively
coupled. Where multiple of such hardware modules exist
contemporaneously, communications may be achieved through signal
transmission e.g., over appropriate circuits and buses that connect
the hardware modules. In embodiments in which multiple hardware
modules are configured or instantiated at different times,
communications between such hardware modules may be achieved, for
example, through the storage and retrieval of information in memory
structures to which the multiple hardware modules have access. For
example, one hardware module may perform an operation and store the
output of that operation in a memory device to which it is
communicatively coupled. A further hardware module may then, at a
later time, access the memory device to retrieve and process the
stored output. Hardware modules may also initiate communications
with input or output devices, and can operate on a resource e.g., a
collection of information.
[0191] The various operations of example methods described herein
may be performed, at least partially, by one or more processors
that are temporarily configured e.g., by software or permanently
configured to perform the relevant operations. Whether temporarily
or permanently configured, such processors may constitute
processor-implemented modules that operate to perform one or more
operations or functions. The modules referred to herein may, in
some example embodiments, comprise processor-implemented
modules.
[0192] Similarly, the methods or routines described herein may be
at least partially processor-implemented. For example, at least
some of the operations of a method may be performed by one or
processors or processor-implemented hardware modules. The
performance of certain of the operations may be distributed among
the one or more processors, not only residing within a single
machine, but deployed across a number of machines. In some example
embodiments, the processor or processors may be located in a single
location e.g., within a home environment, an office environment or
as a server farm, while in other embodiments the processors may be
distributed across a number of locations.
[0193] The one or more processors may also operate to support
performance of the relevant operations in a "cloud computing"
environment or as a "software as a service" SaaS. For example, at
least some of the operations may be performed by a group of
computers as examples of machines including processors, these
operations being accessible via a network e.g., the Internet and
via one or more appropriate interfaces e.g., application program
interfaces APIs.
[0194] The performance of certain of the operations may be
distributed among the one or more processors, not only residing
within a single machine, but deployed across a number of machines.
In some example embodiments, the one or more processors or
processor-implemented modules may be located in a single geographic
location e.g., within a home environment, an office environment, or
a server farm. In other example embodiments, the one or more
processors or processor-implemented modules may be distributed
across a number of geographic locations.
[0195] Some portions of this specification are presented in terms
of algorithms or symbolic representations of operations on data
stored as bits or binary digital signals within a machine memory
e.g., a computer memory. These algorithms or symbolic
representations are examples of techniques used by those of
ordinary skill in the data processing arts to convey the substance
of their work to others skilled in the art. As used herein, an
"algorithm" is a self-consistent sequence of operations or similar
processing leading to a desired result. In this context, algorithms
and operations involve physical manipulation of physical
quantities. Typically, but not necessarily, such quantities may
take the form of electrical, magnetic, or optical signals capable
of being stored, accessed, transferred, combined, compared, or
otherwise manipulated by a machine. It is convenient at times,
principally for reasons of common usage, to refer to such signals
using words such as "data," "content," "bits," "values,"
"elements," "symbols," "characters," "terms," "numbers,"
"numerals," or the like. These words, however, are merely
convenient labels and are to be associated with appropriate
physical quantities.
[0196] Unless specifically stated otherwise, discussions herein
using words such as "processing," "computing," "calculating,"
"determining," "presenting," "displaying," or the like may refer to
actions or processes of a machine e.g., a computer that manipulates
or transforms data represented as physical e.g., electronic,
magnetic, or optical quantities within one or more memories e.g.,
volatile memory, non-volatile memory, or a combination thereof,
registers, or other machine components that receive, store,
transmit, or display information.
[0197] As used herein any reference to "some embodiments" or "an
embodiment" or "teaching" means that a particular element, feature,
structure, or characteristic described in connection with the
embodiment is included in at least one embodiment. The appearances
of the phrase "in some embodiments" or "teachings" in various
places in the specification are not necessarily all referring to
the same embodiment.
[0198] Some embodiments may be described using the expression
"coupled" and "connected" along with their derivatives. For
example, some embodiments may be described using the term "coupled"
to indicate that two or more elements are in direct physical or
electrical contact. The term "coupled," however, may also mean that
two or more elements are not in direct contact with each other, but
yet still co-operate or interact with each other. The embodiments
are not limited in this context.
[0199] Further, the figures depict preferred embodiments for
purposes of illustration only. One skilled in the art will readily
recognize from the following discussion that alternative
embodiments of the structures and methods illustrated herein may be
employed without departing from the principles described herein
[0200] Upon reading this disclosure, those of skill in the art will
appreciate still additional alternative structural and functional
designs for the systems and methods described herein through the
disclosed principles herein. Thus, while particular embodiments and
applications have been illustrated and described, it is to be
understood that the disclosed embodiments are not limited to the
precise construction and components disclosed herein. Various
modifications, changes and variations, which will be apparent to
those skilled in the art, may be made in the arrangement, operation
and details of the systems and methods disclosed herein without
departing from the spirit and scope defined in any appended
claims.
* * * * *