Abstract: As uploaded
8
associated payment account. In some instances, a check may be considered a payment card where
applicable.
[0031]
“
Record information
”
shall mean information comprising identity information or
financial history information (or both) corresponding to a payment card, payment card account or
payment card holder.
[0032]
“
Terminal device
” shall mean any device that is capable of receiving information for
identifying a payment card, or card holder
, authenticating a card holder
, and transmitting payment
card information or customer information directly or indirectly to one or more of an acquirer
network, card network or issuer network. Non-limiting embodiments of terminal devices include
POS terminals, computing devices including desktops, laptops, tablets and personal digital assistants,
and telecommunication devices including wired line telephones, mobile phones and smartphones.
[0033]
Figure 1 illustrates a system 100 that can be used for implementing electronic
transactions based on a payment card or payment card information presented by a card holder at a
terminal device 102. System 100 includes terminal device 102, acquirer network 104, card network
106 and issuer network 108.
[0034]
Acquirer network 104 may be communicably coupled with terminal device 102, and
comprises server 104a, acquirer network database 104b and interface gateway 104c. Server 104a may
be configured to receive and process information relating to payment card transactions. In an
embodiment, the acquirer network may receive or process transactions received only from
merchants having a merchant account with the acquirer
–
which determination may be made based
on information retrieved from acquirer network database 104b. Interface gateway 104c may include
a hardware or software network gateway configured to enable acquirer network 104 to communicate
with card network 106.
[0035]
Card network 106 may be communicably coupled to both acquirer network 104 and
issuer network 108.
9
[0036]
Issuer network 108 comprises server 108a, issuer network database 108b and interface
gateway 108c. Server 108a may be configured to receive and process information relating to payment
card transactions. In an embodiment, the issuer network may only receive or process transactions
received from merchants having a merchant account with the issuer
–
which determination may be
made based on information retrieved from issuer network database 108b. Interface gateway 108c
may include a hardware or software network gateway configured to enable issuer network 108 to
communicate with card network 10
6.
[0037]
It would be understood that terminal device 102 may comprise any of POS terminal
102a, computing device 102b, wired line telephone 102c or mobile phone or smartphone 102d.
[0038]
The present invention contemplates multiple authentication keys (for example multiple
PINs) being assigned to (or associated with) a payment card, payment card account or card holder
.
In an embodiment a payment card, payment card account or card holder has at least a first
authentication key and a second authentication key associated therewith. In other embodiments,
each payment card, payment card account or card holder may have more than two authentication
keys
associated therewith.
[0039]
Each authentication key associated with a payment card, payment card account or card
holder additionally has an associated designated function. Association of functions designated for
each authentication key may depend on the implementation that is contemplated. In a preferred
embodiment, a first authentication key associated with the payment card, payment card account or
card holder may be associated with an instruction for authorizing an
electronic transaction that has
been requested at a terminal device, while a second authentication key associated with the payment
card, payment card account or card holder may be associated with an instruction for communicating
identity information or financial history information corresponding to the card holder (or
corresponding to the payment card), to the terminal device at which the second authentication key
h
as been input by the card holder
. In an embodiment, the invention also enables enrolling or
registration of authentication keys corresponding to a card holder, and correlating each enrolled
authentication key to a corresponding designated function.
10
[0040]
Figur
e 4 illustrates an exemplary data structure 400 (for example a database schema) or
part thereof, configured to store (i) an authentication key associated with a payment card, payment
card account or card holder, and (ii) the corresponding unique functions designated with each
authentication key
.
[0041]
For example, as illustrated in Figure 4, account ID “WWWW.XXXX.YYYY.ZZZZ” has
numeric authentication keys 1234, 2345 and 3456 associated therewith
–
each authentication key
having a corresponding designated function associated therewith
–
such that receipt of card
information identifying account ID “WWWW.XXXX.YYYY.ZZZZ” and
receipt of one of the
authentication key associated therewith, would result in implementation of the designated function
associated with the received authentication key. Figure 4 is discussed in more detail later in this
specification.
[0042]
Figure 2 illustrates
a
method in accordance with the present invention.
[0043]
Step 202 comprises receiving user account information at a terminal device. User
account information may include (i) account identification information (e.g., payment card
information or payment card account identification information) and (ii) user authentication
information (for example, a password or PIN). In an embodiment when
the terminal device is a
POS terminal, the account identification information may be acquired by the POS terminal reading a
payment card magnetic stripe. In an embodiment when
the terminal device is a computing device or
telecommunication device, acquisition of the account identification information may be achieved by
way of user input at the terminal device (for example by way of user input specifying the payment
card number and optionally one or more of the payment card expiry date and card verification value
number, or by submitting an image or snapshot of the payment card through an imaging device). In
an embodiment, the authentication information may be input by the user through the terminal
device or any peripheral device coupled with the terminal device that enables user inputs. The user
authentication information may in various embodiments comprise one or more of numeric
information, alphanumeric information, biometric information or any other information capable of
serving as a secure authentication key.
11
[0044]
Step 204 comprises receiving at an authentication engine, one or both of account
identification information and user authentication information received at the terminal device at step
202.
In an embodiment, the user authentication information received at the authentication engine
may comprise an authentication key input by or received from a user at the terminal device, either in
encrypted or unencrypted form. In another embodiment, the received user authentication
information may comprise an encrypted or unencrypted derivative of
an
authentication key input by
or received from a user at the terminal device.
[0045]
It would be understood that the authentication engine discussed in connection with step
204 may comprise any processing device configured to implement an authentication function
–
an
d
that the authentication engine may in various embodiments be located within any one of the card
network, issuer network or acquirer network or for that matter may be located outside of all of said
networks (in which case said authentication engine is communicably coupled with at least one of
said networks).
[0046]
Step 206 comprises comparing user authentication information received at the
authentication engine, against a plurality of authentication keys associated with a specific account
identifier (for example a payment card number or a payment card account ID). In an embodiment
the account identifier selected for matching of authentication keys may be based on account
identification information received at step 202 at the terminal device.
[0047]
Step 208 comprises responding to identification of a match at step 206 (
i.e.
, between the
received user authentication information and one of the plurality of user authentication keys
associated with a specific account identifier
)
by performing
a
designated function or action
associated with the matched authentication key. The performed designated function may be selected
from among a group of designated functions associated with the specific account identifier, based
on identifying a predefined association between the performed designated function and the matched
authentication key. Once again referring for example to Figure 4, in the event step 204 comprises
receiving account identification information corresponding to account ID
“WWWW.XXXX.YYYY.ZZZZ” and
receiving authentication key 1234, step 206 would determine
a match with one of the authentication keys associated with said account ID, and step 208 would
12
thereafter result in implementation of the designated function that is associated with authentication
key 1234
–
i.e.
,
authorization of a requested payment
card transaction.
[0048]
In an embodiment of step 208, selection of a designated function from among the group
of designated functions associated with the specific account identifier, is based exclusively on
existence of a predefined association between the selected designated function and the matched
authentication key. Stated differently, selection of a designated function from among the group of
designated functions associated with the specific account identifier is independent of any additional
user inputs (other than input of user authentication information) necessary to identify a designated
function for selection. In a particular embodiment, the user input at the terminal device is limited to
input of a payment card identifier and user authentication information, and excludes any additional
input for selecting a designated function.
[0049]
The invention additionally contemplates methods for enrolling one or more
authentication keys corresponding to a payment card, payment card account or card holder, and for
correlating the authentication key with a corresponding designated function. In an embodiment, the
enrollment process may involve the steps of
(i)
receiving from a user, user input selecting a specific function from among a plurality of
functions that are capable of being executed or implemented in response to an
instruction from the authentication engine. For example, the plurality of functions may
include authorizing a payment card transaction, generating and transmitting a financial
report based on account holder data available with the issuer network, generating and
transmitting a financial report based on account holder data available with the card
network, and generating and transmitting a financial report based on account holder data
available with both the issuer network and the card network.
(ii)
responsive to selection of a specific function from among a plurality of functions that are
capable of being executed or implemented in response to an instruction from the
authentication engine, the user may be provide user input for use as an authentication
key
th
at can be associated with the selected specific function.
13
(iii)
the received user input (or a set of data or information derived from the user input
–
for
example by way of a hash function or other processing function) may thereafter be
recorded as the authentication key associated with the selected specific function
–
such
that subsequent receipt of said authentication key may thereafter be used as an
instruction to implement the selected specific function (i.e. as a result of the recorded
association)
.
(iv)
The above process may be repeated so as to associate unique authentication keys with
more than one (and preferably all) of the plurality of functions that are capable of being
executed or implemented in response to an instruction from the authentication engin
e.
[0050]
In certain embodiments, the step of prompting a user to input an authentication key may
be preceded by a step of prompting a user to specify an authentication key type, or to select from
among a plurality of authentication key types. Exemplary authentication key types may include an
alphanumeric key type, iris, retina or eye based biometric key types, facial feature based biometric
key type, fingerprint based biometric key type, image based key type, audio based key type, etc.
Depending on the authentication key type selected by the user, the user may thereafter be provided
with specific instructions for enrolling the authentication key
–
e.g., in case of a fingerprint or iris
based biometric key type, the user may be provided with directions for positioning the desired
biometric feature in a specific orientation relative to the biometric sensor. The authentication key or
user input may thereafter be acquired/captured and processed in the manner discussed above. It
would be understood that in certain embodiments, the user may select (or alternatively the method
or apparatus may mandatorily require) different authentication key types to be associated with
different functions. For example, an authentication key associated with authorization of a payment
transaction may comprise a first authentication key type (e.g., an alphanumeric key), while an
authentication key associated with generation of a financial report may require a second
authentication key type (e.g., a biometric feature based authentication). In one embodiment,
authorization of payment transactions below a predefined amount may require a first authentication
key type (e.g.,
a less secure authentication key type such as an alphanumeric key), while authorization
of payment transactions above the predefined amount may require a second authentication key type
(e.g., a more secure authentication key type such as a biometric feature based key). In certain
embodiments, the invention may permit for associating specific designated functions with a plurality
14
of authentication keys
–
such that triggering the designated function would require input of the
associated plurality of authentication keys. By way of an explanatory example, the function of
authorizing payment transactions above a certain limit may require an alphanumeric key as well as a
biometric based key associated therewith
–
wherein a user would be required to correctly provide an
alphanumeric authentication key and also to present the enrolled biometric feature to authenticate or
trigger the transaction.
[0051]
Figure 3 illustrates a flowchart illustrating a specific embodiment of method step 208
that has been more generally discussed in connection with Figure 2 above. The embodiment of
Figure 3 involves a system configuration wherein each payment card or payment card account (or
account ID corresponding to a payment card or payment card account) has at least a first
authentication key and a second authentication key associated therewith. The first authentication key
has a corresponding first designated function associated therewith, while the second authentication
key has a corresponding second designated function associated therewith. In the specific
embodiment illustrated in Figure 3, the first designated function comprises authorizing a payment
card transaction that has been requested at the terminal device, while the second designated function
comprises generating and transmitting card holder profile information or financial history
information (or both)
associated with the payment card, payment card account or
card holder
.
[0052]
Accordingly, at step 302, determination of a match between user authentication
information (that has been received at step 204 and matched at step 206 of Figure 2), and a first
authentication key associated with the transmitted account identification
information (that has also
been transmitted at step 204 of Figure 2)
,
results in authorization of a payment card transaction
requested at the terminal device (i.e. implementation of the first designated function associated with
the first authentication key).
[0053]
Responsive to a non-match decision at step 302, the method moves on to step 304. At
step 304, a determination of a match between the user authentication information and a second
authentication key associated with the transmitted account identifier information results in retrieval
and transmission of one or both of card holder
profile information and financial history information
associated with the payment card, payment card account or card holder (i.e., implementation of the
15
second designated function associated with the second authentication key). Said information may in
an embodiment be transmitted to the terminal device.
[0054]
While Figure 3 illustrates only a two-step method step corresponding to an embodiment
involving two authentication keys (and corresponding designated functions) associated with a
payment card or a payment card account, it would be understood that any number of authentication
keys (and corresponding designated functions) may be associated with each payment card or
payment card account. In such cases, the method of Figure 3 would continue checking for a match
between user authentication information received from a terminal device and the authentication keys
associated with a payment card account (also identified based on information received from the
terminal device) until a match is found or until all associated authentication keys have been checked
and have been determined to be non
-matching
.
[0055]
In an embodiment of the invention, the card holder
profile information or financial
history information (or both) associated with the payment card, payment card account or card
holder may include one or more of the card holder name or address, location of the card holder
or
the card holder
’s business esta
blishment, the total value of transactions carried out using a payment
card over a fixed period of time (e.g., over the last six months), categories of spend in connection
with recent transactions made over a fixed period of time, credit score, repayment score, total value
of late payment penalties accumulated or paid over a fixed period of time, and any other information
that may be useful to establishing or representing a card holder
’s
antecedents or financial credibility.
In an embodiment of the invention, the transmitted card holder profile information or financial
history information (or both) may be in the form of a consolidated information report. In various
embodiments, the content of card holder profile information or financial history information (or
both) that is generated at step 304 may be determined based on a predefined set of rules.
[0056]
In an embodiment of the method discussed in connection with Figure 3 (and
subsequently in connection with Figure 5), transmission of the card holder profile information or
financial history information (or both) may involve payment of a service fee. In a specific
embodiment, this service fee may be charged as a service fee to the payment card or to the payment
card account associated with the card holder
.
We claim:
1.
A method for implementing
a
selective response to presentation of payment card
information, comprising:
receiving from a terminal device, payment card account information comprising a
payment card account identifier and user authentication information;
responsive to the received user authentication information matching one of a plurality of
predefined authentication keys associated with the payment card account identifier, selecting a
predefined function from among at least first and second predefined functions associated with the
payment card account identifier, wherein selection of the predefined function from among the first
and second predefined functions is based on
an
association between the selected predefined
function and an authentication key that has been matched with the received user authentication
information; and
implementing the selected predefined function;
wherein:
the first predefined function comprises authorization of a requested electronic payment
transaction; and
the second predefined function comprises transmitting to the terminal device, financial
history information corresponding to the payment card account identifier.
2.
The method as claimed in claim 1, wherein the transmitted financial history information
is displayed, printed
or rendered at the terminal device.
3.
The method as claimed in claim 1, wherein selection of the predefined function from
among the first and second predefined functions is based exclusively on the association between the
25
selected predefined function and the authentication key that has been matched with the received
user authentication information.
4.
The method as claimed in claim 1, wherein the financial history information is retrieved
from at least one of a card network database and an acquirer network database.
5.
The method as claimed in claim 4, wherein the financial history information comprises
data retrieved from both the card network database and the acquirer network database.
6.
The method as claimed in claim 1, wherein responsive to selection of the second
designated function, a service fee associated with transmission of financial history information is
charged to the payment card.
7.
The method as claimed in claim 5, wherein responsive to selection of the second
designated function, a service fee associated with transmission of financial history information is
charged to the payment card, and a first share of the service fee is credited to the card network and a
second share of the service fee is credited to the issuer network.
8. A system for implementing a selective response to presentation of payment card
information, comprising:
a processor implemented authentication engine configured to:
receive from a terminal device, payment card account information comprising a
payment card account identifier and user authentication information;
responsive to the received user authentication information matching one of a
plurality of predefined authentication keys associated with the payment card account
identifier, select a predefined function from among at least first and second predefined
functions associated with the payment card account identifier, wherein selection of the
predefined function from among the first and second predefined functions is based on an
26
association between the selected predefined function and an authentication key that has been
matched with the received user authentication information; and
implement
the selected predefined function;
wherein:
the first predefined function comprises authorization of a requested electronic
payment transaction; and
the second predefined function comprises transmitting to the terminal device,
financial history information corresponding to the payment card account identifier.
9. The system as claimed in claim 8, wherein the terminal device is configured to display,
print
or render
the transmitted financial history information
.
10.
The system as claimed in claim 8, wherein the authentication engine is configured such
that selection of the predefined function from among the first and second predefined functions is
based exclusively on the association between the selected predefined function and the authentication
key that has been matched with the received user authentication information.
11
. The system as claimed in claim 8, wherein the authentication engine is configured such
that the financial history information is retrieved from at least one of a card network database and
an acquirer network database.
12
. The system as claimed in claim
11
, wherein the authentication engine is configured such
that the financial history information comprises data retrieved from both the card network database
and the acquirer network database.
13
. The system as claimed in claim 8
,
configured such that responsive to selection of the
second designated function, a service fee associated with transmission of financial history
information is charged to the payment card.
27
14
. The system as claimed in claim
12,
configured such that responsive to selection of the
second designated function, a service fee associated with transmission of financial history
information is charged to the payment card, and a first share of the service fee is credited to the card
network and a second share of the service fee is credited to the issuer network.
15.
A computer program product for implementing a selective response to presentation of
payment card information, comprising a non-transitory computer usable medium having compute
r
readable program code embodied therein, the computer readable program code comprising
instructions for:
receiving from a terminal device, payment card account information comprising a
payment card account identifier and user authentication information;
responsive to the received user authentication information matching one of a plurality of
predefined authentication keys associated with the payment card account identifier, selecting a
predefined function from among at least first and second predefined functions associated with the
payment card account identifier, wherein selection of the predefined function from among the first
and second predefined functions is based on an association between the selected predefined
function and an authentication key that has been matched with the received user authentication
information; and
implementing the selected predefined function;
wherein:
the first predefined function comprises authorization of a requested electronic payment
transaction; and
the second predefined function comprises transmitting to the terminal device, financial
history information corresponding to the payment card account identifier
| # | Name | Date |
|---|---|---|
| 1 | 201711032269-STATEMENT OF UNDERTAKING (FORM 3) [12-09-2017(online)].pdf | 2017-09-12 |
| 2 | 201711032269-REQUEST FOR EXAMINATION (FORM-18) [12-09-2017(online)].pdf | 2017-09-12 |
| 3 | 201711032269-PROOF OF RIGHT [12-09-2017(online)].pdf | 2017-09-12 |
| 4 | 201711032269-POWER OF AUTHORITY [12-09-2017(online)].pdf | 2017-09-12 |
| 5 | 201711032269-FORM 18 [12-09-2017(online)].pdf | 2017-09-12 |
| 6 | 201711032269-FORM 1 [12-09-2017(online)].pdf | 2017-09-12 |
| 7 | 201711032269-FIGURE OF ABSTRACT [12-09-2017(online)].pdf | 2017-09-12 |
| 8 | 201711032269-DRAWINGS [12-09-2017(online)].pdf | 2017-09-12 |
| 9 | 201711032269-DECLARATION OF INVENTORSHIP (FORM 5) [12-09-2017(online)].pdf | 2017-09-12 |
| 10 | 201711032269-COMPLETE SPECIFICATION [12-09-2017(online)].pdf | 2017-09-12 |
| 11 | 201711032269-Power of Attorney-150917.pdf | 2017-09-21 |
| 12 | 201711032269-Correspondence-150917.pdf | 2017-09-21 |
| 13 | 201711032269-OTHERS-200917.pdf | 2017-09-25 |
| 14 | 201711032269-Correspondence-200917.pdf | 2017-09-25 |
| 15 | abstract.jpg | 2018-01-15 |
| 16 | 201711032269-REQUEST FOR CERTIFIED COPY [01-09-2018(online)].pdf | 2018-09-01 |
| 17 | 201711032269-FORM 3 [04-02-2019(online)].pdf | 2019-02-04 |
| 18 | 201711032269-FER.pdf | 2019-11-11 |
| 19 | 201711032269-PETITION UNDER RULE 137 [18-03-2020(online)].pdf | 2020-03-18 |
| 20 | 201711032269-OTHERS [18-03-2020(online)].pdf | 2020-03-18 |
| 21 | 201711032269-Information under section 8(2) [18-03-2020(online)].pdf | 2020-03-18 |
| 22 | 201711032269-FORM 3 [18-03-2020(online)].pdf | 2020-03-18 |
| 23 | 201711032269-FER_SER_REPLY [18-03-2020(online)].pdf | 2020-03-18 |
| 24 | 201711032269-CLAIMS [18-03-2020(online)].pdf | 2020-03-18 |
| 25 | 201711032269-US(14)-HearingNotice-(HearingDate-12-12-2022).pdf | 2022-11-16 |
| 26 | 201711032269-REQUEST FOR ADJOURNMENT OF HEARING UNDER RULE 129A [11-12-2022(online)].pdf | 2022-12-11 |
| 27 | 201711032269-US(14)-ExtendedHearingNotice-(HearingDate-12-01-2023).pdf | 2022-12-12 |
| 28 | 201711032269-Correspondence to notify the Controller [09-01-2023(online)].pdf | 2023-01-09 |
| 29 | 201711032269-Written submissions and relevant documents [24-01-2023(online)].pdf | 2023-01-24 |
| 30 | 201711032269-Annexure [24-01-2023(online)].pdf | 2023-01-24 |
| 31 | 201711032269-PatentCertificate24-02-2023.pdf | 2023-02-24 |
| 32 | 201711032269-IntimationOfGrant24-02-2023.pdf | 2023-02-24 |
| 1 | Searchstrategy_14-10-2019.pdf |