Language selection

Search

Patent 2747642 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent Application: (11) CA 2747642
(54) English Title: USER POSITIVE APPROVAL & AUTHENTICATION SERVICES
(54) French Title: SERVICES D'AUTHENTIFICATION ET DE RECONNAISSANCE POSITIVE D'UTILISATEUR
Status: Deemed Abandoned and Beyond the Period of Reinstatement - Pending Response to Notice of Disregarded Communication
Bibliographic Data
(51) International Patent Classification (IPC):
  • G06Q 20/40 (2012.01)
(72) Inventors :
  • SIKLJOVAN, BRANISLAV (Canada)
  • ANDRIC, RADOSAV (Canada)
(73) Owners :
  • BRANISLAV SIKLJOVAN
  • RADOSAV ANDRIC
(71) Applicants :
  • BRANISLAV SIKLJOVAN (Canada)
  • RADOSAV ANDRIC (Canada)
(74) Agent:
(74) Associate agent:
(45) Issued:
(22) Filed Date: 2011-08-01
(41) Open to Public Inspection: 2013-02-01
Availability of licence: N/A
Dedicated to the Public: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): No

(30) Application Priority Data: None

Abstracts

English Abstract


The invention provides Users of Retail Payment and Identification instruments
with the
ability to review transaction details and approve transaction by capturing UVM
in User
controlled environment and Issuers of these instruments with the ability to
positively
authenticate Users in Issuer controlled environment. The invention accounts
for real time
legacy or non-legacy processing systems to provide an authorization request
from POA to
Issuer Host. The invention introduces two UPAAS components - User Gateway and
User
Application. The UPAAS User Gateway is implemented in an Issuer controlled
environment
enabling interface between Issuer legacy Host and UPAAS User Applications. The
UPAAS
User Application can be implemented on any device supporting communication
protocol such
as TCP/IP without any hardware changes enabling the User to login to UPAAS
User Gateway,
review and approve or decline a specific transaction in real time by entering
UVM, such as
PIN, for User authentication purposes.


Claims

Note: Claims are shown in the official language in which they were submitted.


CLAIMS
The invention claims,
1. A method and technology solution enabling Issuers of Retail Payment and
Identification instruments to request approval from Users of these instruments
in real time for the transactions initiated at and processed through legacy or
non-
legacy systems once the transaction authorization request is received from
Acquirer or Network and before it is processed for approval by Issuer Host.
2. A method and technology solution enabling Issuers of Retail Payment and
Identification instruments to authenticate Users of these instruments in real
time
in Issuer controlled environment for the transactions initiated at and
processed
through legacy or non-legacy systems once the transaction authorization
request
is received from Acquirer or Network and after the transaction has been
approved by the User.
3. A method and technology solution enabling Issuers of Retail Payment and
Identification instruments to request additional information from Users of
these
instruments in real time for the transactions initiated at and processed
through
legacy or non-legacy systems once the transaction authorization request is
received from Acquirer or Network and before it is processed for approval by
Issuer Host.
4. A method and technology solution enabling Users of Retail Payment and
Identification instruments to review in real time details of the transaction
initiated at legacy or non-legacy POA and approve or decline the transaction
in
a self controlled environment outside of POA and Acquirer environment.
5. A method and technology solution enabling Users of Retail Payment and
Identification instruments to enter UVM in self controlled environment and
transmission of UVM from the User application to the Issuer Host without ever
capturing, receiving or storing any User or Payment / Identification
instrument
information on the application used for capturing and processing of UVM.

Description

Note: Descriptions are shown in the official language in which they were submitted.


CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
BACKGROUND OF THE INVENTION
The foundation of the invention was a realization of the existing problems and
opportunities that emerging technologies are bringing along in the areas of
transaction approval
and User authentication for Retail Payment and Identification transactions.
Recognized Problems
= For a number of years the Card industry has been facing demands for a
stronger
Cardholder authentication and better protection of User and Payment instrument
proprietary
information. The Card industry responded with EMV- chip cards where an offline
PIN was
introduced replacing or substituting signature as CVM. An Offline PIN is
significantly more
reliable than a signature however it came with a price: the cost of EMV
implementation and
maintenance is significant and is billed to all parties: Merchants/POA,
Acquirer, Network and
Issuers. Another downside is that the PIN remained captured at POA and User
verification
remained within the POA environment. To mitigate the risks the Payment Card
Industry (PCI)
introduced PED and Data Security standards which improved security however
also further
increased the cost of implementation and maintenance. Verification of a CVM at
the POA
means that the Issuer is advised of the Cardholder Verification Result, but
not actually
performing User authentication, which opens up doors for "wedge" (man-in-the
middle) attacks
and other fraud risks.
= The personal and traveler's cheques industry currently provides the ability
to
validate the cheques or drafts being presented, verify the history of the User
(account holder),
to validate the Routing Number and verify the User Account number status,
However User
authentication is not currently available for cheque transactions which along
with the cost of
Cheque Verification processing contributed to the constant decline of cheque
use.
= Users of identification instruments like Insurance and Health cards are
either not
authenticated at all or the authentication is performed by the acceptor using
other pictured IDs,
like a Driver's license.

CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
Perceived Opportunities
= Mass adoption of data enabled devices enables a reach to Users of Retail
payment
and Identification instruments in real time, anytime, anywhere enabling User
transaction
approval and User authentication in Issuer controlled environment that was
previously not
possible.
= Providing Users of Payment and Identification instruments with the ability
to review
and approve transactions and enter UVMs at the devices they control improves
the security of
UVM and effectively externalizes User Transaction approval and User
authentication from
POA / acceptor's environment thus removing the line between User (Cardholder)
Present and
User (Cardholder) Not Present transactions.
= User Transaction approval and User authentication naturally belong to Issuer
environment. Ensuring this decouples the Payment Instrument information
(processed in
authorization request/response) from User Authentication information which
significantly
contributes to fraud prevention.
BRIEF SUMMARY OF THE INVENTION
The invention accounts for legacy or non-legacy real time processing systems
providing
transaction details captured at a POA to the Issuer Host through an Acquirer
and when
appropriate Network environment in the form of transaction authorization
request. At a
minimum the Transaction authorization request provides Payment or
Identification Instrument
ID (i.e. Primary Account Number), POA information (i.e. Acceptor Name and
Location) and
Transaction Amount.
The invention introduces two components:
= UPAAS User Gateway (125) implemented in Issuer controlled environment which
facilitates processing of Approval Request/Response between Issuer Card, Card-
less or ID
Legacy systems and UPAAS User Application (122).
= UPAAS User Application (122) which can be implemented on any device
supporting appropriate data communication protocol such as TCP/IP. It provides
Users with
Page 3

CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
ability to review and accept or decline the transaction once the authorization
request is received
by the Issuer. The User confirms acceptance of a transaction by entering UVM
which is
encrypted by the UPAAS User application and forwarded to Issuer for User
authentication and
Issuer approval.
The invention externalizes User Authentication from a legacy POA, Acquiring
and
Network systems and enables Issuers of Retail Payment and Identification
instruments with
ability to positively authenticate Users of these instruments in real time in
Issuer controlled
environment without any involvement of POA, acquiring and network systems in
User
authentication.
The invention externalizes User transaction approval from a legacy POA and
enables
Issuers of Retail Payment and Identification instruments with ability to
request a transaction
approval from Users in real time after the Issuer receives authorization
request for the
transaction and before the Issuer approval is granted. As a result of this the
invention makes the
Issuer approval contingent to the User's approval ensuring non-repudiation of
Issuer approved
transactions.
The invention provides Users of Retail Payment and Identification instruments
with the
ability to review and approve or decline transaction and capture UVM on self
controlled
devices, thus decoupling Point of (Instrument) Acceptance from Point of
Transaction Approval
and Point of User Authentication, which effectively removes the line between
User Present and
User Not-Present transactions.
By externalizing User Authentication from the POA the invention ensures that
the
Payment Instrument information (i.e. Primary Account Number) and User
Verification
information (i.e. PIN) are neither captured nor processed together at any
point of the transaction
life cycle. This prevents the association of the Instrument and UVM
information by anyone but
the User and Issuer, thus reducing the possibility of creating and using the
counterfeit
instruments.
Page 4

CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
The major benefits of the invention are the following:
= No physical changes or modifications are required to devices where the UPAAS
User Application is implemented.
= Issuer performs User Authentication in its own environment which is
currently
possible for ATM on-us transactions only. The same increases transaction
security and
simplifies implementation and change management: any modification or
improvements can be
done without impacts to Merchant, Acquirer and Network environments.
= Acceptors of Payment or Identification instruments are spared from
implementing
and maintaining User Authentication functions at their POA devices while
enjoying increased
guarantee of payment and non-repudiation.
= Acquirer processors and Networks are spared from implementing and
maintaining
Industry mandates related to User authentication and data security standards
including but not
limited to secure UVM capture, encryption and support of associated key
infrastructure.
= Users are provided with the opportunity to review and approve or decline the
transaction in a self controlled environment and the ability to identify and
decline a fraudulent
or incorrectly processed transaction request before it is processed by the
Issuer Host.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
The drawings provided herein present possible implementation scenarios of the
invention. These scenarios should be taken as examples only and they are not
meant to limit
implementation of the invention beyond presented scenarios, nor limit the
scope,
implementation type or configuration of the invention providing that the
spirit of the invention
is preserved as set forth in the invention claims.
Figure 1 presents a process flow of the embodiment enabling transaction
approvals to
Users and User Authentication to Issuers of non-proprietary Card Retail
Payment Instruments
in legacy Open Loop scenario where Issuer uses its legacy system for PIN
verification.
Page 5

CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
Figure 2 presents a process flow of the embodiment enabling transaction
approvals to
Users and User Authentication to Issuers of non-proprietary Card Retail
Payment Instruments
in legacy Open Loop scenario where Issuer uses UPAAS for UVM verification.
Figure 3 presents a process flow of the embodiment enabling transaction
approval to
Users and User Authentication to Issuers of proprietary Card Retail Payment
Instruments in
legacy Closed Loop scenario where Issuer uses UPAAS for UVM verification.
Figure 4 presents a process flow of the embodiment enabling transaction
approval to
Users and User Authentication to Issuers of Card-less Retail Payment
Instruments in legacy
Open Loop scenario where Issuer uses UPAAS for UVM verification.
Figure 5 presents a process flow of the embodiment enabling transaction
approval to
Users and User Authentication to Issuers of Card-less Retail Payment
Instruments in legacy
Closed Loop scenario where Issuer uses UPAAS for UVM verification.
Figure 6 presents a process flow of the embodiment enabling transaction
approval to
Users and User Authentication to Issuers when Identification Instruments are
used in legacy
Closed Loop scenario where Issuer uses UPAAS for UVM verification.
DETAILED DESCRIPTION OF THE INVENTION
Details of end-to end transaction flow and User transaction approval and User
Authentication processes are as presented in Figures 1-6 and corresponding
descriptions in the
tables below.
Table 1: Detailed description of process flow and relevant business logic
exercised in
UPAAS implementation scenario presented in Figure 1 where User Approval and
Authentication processes are exercised for Card retail payment transactions
initiated and
processed in an Open Loop Card Legacy environment where Issuer verifies PIN in
its legacy
environment.
1110 If unattended POA 111 swipes card; If eCommerce transaction 111 enters
Card
number and other requested information (i.e. CVV2/CVC2) as requested by e-
Commerce web site.
Page 6

CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
2130 If attended POA 213 swipes card and enters amount; If MOTO 213 enters
Card
number and amount;
1117 111 activates 122 in order to establish connection with 125
1227 122 sends Login Request to 125 where User Name is implicitly provided by
122.
Subject to Issuer requirements Password is either entered by 111 or implicitly
provided by 122
1258 125 verifies User Name & Password, checks 111 status and if valid sends
Login
Response to 122 / establishes an open session and awaits for Approval Request
from 116
2141 214 sends Authorization Request to 215 with appropriate 214 information,
Transaction Amount and captured Card Information
2151 215 enriches Authorization Request with appropriate acquirer and merchant
information and Forwards Authorization Request to 315
3151 315 identifies 116 based on PAN BIN and forwards Authorization Request to
116
1163 116 checks PAN provided in 3151 to determine if 111 is registered for
UPAAS
services and if yes sends Approval Request to 125 with PAN, 214 information
and
Transaction Amount
1253 125 identifies 122 using PAN, checks 122 status and if valid sends
Approval
Request to 122
1114 111 reviews 214 Name & Location, Transaction Amount as received in 1253
and
displayed by 122 and confirms acceptance by entering PIN and "From Account
Type"
1224 122 sends Approval Response to 125 with encrypted PIN Block and "From
Account" type
1254 125 sends Approval Response to 116 with encrypted PIN Block and "From
Account" type
1165 116 sends PIN Verification Request to 109
1096 109 verifies PIN and sends PIN Verification Response to 116
1161 116 sends Fund Authorization Request to 118
1182 118 verifies account balance / open to buy and sends Authorization
Response to
Page 7

CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
116
1162 116 sends Authorization Response to 315
3152 315 forwards Authorization Response to 215
2152 215 forwards Authorization Response to 214 at which point goods or
services are
granted to 111
1169 Subject to Issuer Requirement 116 sends Authorization Advice to 125
1259 If 1169 received from 116 then 125 sends Authorization Advice to 122 at
which
point the session is closed
Table 2: Detailed description of process flow and relevant business logic
exercised in
UPAAS implementation scenario presented in Figure 2 where User Approval and
Authentication processes are exercised for Card retail payment transactions
initiated at and
processed through an Open Loop Card Legacy environment where UVM Verification
is
completed between the UPAAS User Gateway and Issuer UVM Verification system.
1110 If unattended POA 111 swipes card; if eCommerce transaction 111 enters
Card
number and other requested information (i.e. CVV2/CVC2) as requested by e-
Commerce web site.
2130 If attended POA 213 swipes card and enters amount; If MOTO 213 enters
Card
number and amount;
1117 111 activates 122 in order to establish connection with 125
1227 122 sends Login Request to 125 where User Name is implicitly provided by
122.
Subject to Issuer requirements Password is either entered by 111 or implicitly
provided by 122
1258 125 verifies User Name & Password, checks 111 status and if valid sends
Login
Response to 122 / establishes an open session and awaits for Approval Request
from 116
2141 214 sends Authorization Request to 215 with appropriate 214 information,
Transaction Amount and captured Card Information
2151 215 enriches Authorization Request with appropriate acquirer and merchant
information and Forwards Authorization Request to 315
Page 8

CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
3151 315 identifies 116 based on PAN BIN and forwards Authorization Request to
116
1163 116 checks PAN provided in 3151 to determine if 111 is registered for
UPAAS
services and if yes sends Approval Request to 125 with PAN, 214 information
and
Transaction Amount
1253 125 identifies 122 using PAN, checks 122 status and if valid sends
Approval
Request to 122
1114 111 reviews 214 Name & Location, Transaction Amount as displayed by 122
and
confirms acceptance by entering UVM and "From Account Type"
1224 122 sends Approval Response to 125 with Encrypted UVM and "From Account"
type
1255 125 sends UVM Verification Request to 109
1096 109 verifies UVM and sends UVM Verification Response to 125
1254 125 sends Approval Response to 116 with "From Account" type
1161 116 sends Fund Authorization Request to 118
1182 118 verifies account balance / open to buy and sends Authorization
Response to
116
1162 116 sends Authorization Response to 315
3152 315 forwards Authorization Response to 215
2152 215 forwards Authorization Response to 214 at which point goods or
services are
granted to 111
1169 Subject to Issuer Requirement 116 sends Authorization Advice to 125
1259 If 1169 received from 116 125 sends Authorization Advice to 122 at which
point
the session is closed
Table 3: Detailed description of process flow and relevant business logic
exercised in
UPAAS implementation scenario presented in Figure 3 where User Approval and
Authentication processes are exercised for Card retail payment transactions
initiated at and
processed through a Closed Loop Card Legacy environment where UVM Verification
is
completed between the UPAAS User Gateway and Issuer UVM Verification system.
1110 If unattended POA 111 swipes card.
Page 9

CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
2130 If attended POA 213 swipes card and enters amount
1117 111 activates 122 in order to establish connection with 125
1227 122 sends Login Request to 125 where User Name is implicitly provided by
122.
Subject to Issuer requirements Password is either entered by 111 or implicitly
provided by 122
1258 125 verifies User Name & Password, checks 111 status and if valid sends
Login
Response to 122 / establishes an open session and awaits for Approval Request
from
116
2141 214 sends Authorization Request to 215 with appropriate 214 information,
Transaction Amount and captured Card Information
2151 215 enriches Authorization Request with appropriate acquirer and merchant
information and Forwards Authorization Request to 116
1163 116 checks PAN provided in 3151 to determine if 111 is registered for
UPAAS services
and if yes sends Approval Request to 125 with PAN, 214 information and
Transaction
Amount
1253 125 identifies 122 using PAN, checks 122 status and if valid sends
Approval Request to
122
1114 111 reviews 214 Name & Location, Transaction Amount as displayed by 122
and
confirms acceptance by entering UVM and "From Account Type"
1224 122 sends Approval Response to 125 with UVM Block Encrypted and "From
Account"
type
1255 125 sends UVM Verification Request to 109
1096 109 verifies UVM and sends UVM Verification Response to 125
1254 125 sends Approval Response to 116 with "From Account" type
1161 116 sends Fund Authorization Request to 118
1182 118 verifies account balance / open to buy and sends Authorization
Response to 116
1162 116 sends Authorization Response to 215
2152 215 forwards Authorization Response to 214 at which point goods or
services are
granted to 111
1169 Subject to Issuer Requirement 116 sends Authorization Advice to 125
Page 10

CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
1259 If 1169 received from 116 then 125 sends Authorization Advice to 122 at
which point
the session is closed
Table 4: Detailed description of process flow and relevant business logic
exercised in
UPAAS implementation scenario presented in Figure 4 where User Approval and
Authentication processes are exercised for Card-less retail payment
transactions initiated at and
processed through an Open Loop Legacy environment where UVM Verification is
completed
between the UPAAS User Gateway and Issuer UVM Verification system.
2330 233 enters amount and Cheque number (manual entry or bar code read)
1317 131 activates 122 in order to establish connection with 125
1227 122 sends Login Request to 125 where User Name is implicitly provided by
122.
Subject to Issuer requirements Password is either entered by 131 or implicitly
provided by 122
1258 125 verifies User Name & Password, checks 131 status and if valid sends
Login
Response to 122 / establishes an open session and awaits for Approval Request
from 136
2341 234 sends Cheque Verification Request to 235 with appropriate 234
information,
Transaction Amount and captured Cheque Information
2351 235 sends Cheque Verification Request with appropriate acquirer and
merchant
information to 335
3351 335 identifies 136 based on cheque number and forwards Cheque
Verification
Request to 136
1363 136 checks Cheque Number provided in 3351 to verify if 131 is registered
for
UPAAS services and if yes sends Approval Request to 125 with Cheque Number,
234 information and Transaction Amount
1253 125 identifies 122 using Cheque Number, checks 122 status and if valid
sends
Approval Request to 122
1314 131 reviews Cheque Number, 234 Name & Location, Transaction Amount as
displayed by 122 and confirms acceptance by entering UVM
1224 122 sends Approval Response to 125 with encrypted UVM Block
Page 11

CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
1255 125 sends UVM Verification Request to 109
1096 109 verifies UVM and sends UVM Verification Response to 125
1254 125 sends Approval Response to 136
1361 136 sends Fund Authorization Request to 138
1382 138 verifies account balance against requested amount and sends Fund
Authorization Response to 136
1362 136 sends Cheque Verification Response to 335
3352 335 forwards Cheque Verification Response to 235
2352 235 forwards Cheque Verification Response to 234 at which point goods or
services or cash withdrawal is granted to 131
1369 Subject to Issuer Requirement 136 sends Cheque Verification Advice to 125
1259 If 1369 received from 136 then 125 sends Cheque Verification Advice to
122 at
which point the session is closed
Table 5: Detailed description of process flow and relevant business logic
exercised in
UPAAS implementation scenario presented in Figure 5 where User Approval and
Authentication processes are exercised for Card-less retail payment
transactions initiated at and
processed through a Close Loop Legacy environment where UVM Verification is
completed
between the UPAAS User Gateway and Issuer UVM Verification system.
2330 233 enters amount and cheque number (manual entry or bar code read)
1317 131 activates 122 in order to establish connection with 125
1227 122 sends Login Request to 125 where User Name is implicitly provided by
122.
Subject to Issuer requirements Password is either entered by 131 or implicitly
provided by 122
1258 125 verifies User Name & Password, checks 131 status and if valid sends
Login
Response to 122 / establishes an open session and awaits for Approval Request
from 136
2341 234 sends Cheque Verification Request to 235 with appropriate 234
information,
Transaction Amount and captured Cheque Information
2351 235 sends Cheque Verification Request with appropriate acquirer and
merchant
Page 12

CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
information to 136
1363 136 checks Cheque Number provided in 3351 to verify if 131 is registered
for
UPAAS services and if yes sends Approval Request to 125 with Cheque Number,
234 information and Transaction Amount
1253 125 identifies 122 using Cheque Number, checks 122 status and if valid
sends
Approval Request to 122
1314 131 reviews Cheque Number, 234 Name & Location, Transaction Amount as
displayed by 122 and confirms acceptance by entering UVM
1224 122 sends Approval Response to 125 with encrypted UVM Block
1255 125 sends UVM Verification Request to 109
1096 109 verifies UVM and sends UVM Verification Response to 125
1254 125 sends Approval Response to 136
1361 136 sends Fund Authorization Request to 138
1382 138 verifies account balance against requested amount and sends Fund
Authorization Response to 136
1362 136 sends Cheque Verification Response to 235
2352 235 forwards Cheque Verification Response to 234 at which point goods or
services or cash withdrawal is granted to 131
1369 Subject to Issuer Requirement 136 sends Cheque Verification Advice to 125
1259 If 1369 received from 136 then 125 sends Cheque Verification Advice to
122 at
which point the session is closed
Table 6: Detailed description of process flow and relevant business logic
exercised in
UPAAS implementation scenario presented in Figure 6 where User Approval and
Authentication processes are exercised for Identification instrument
transactions initiated at and
processed through a Close Loop processing environment where UVM Verification
is
completed between the UPAAS User Gateway and Issuer UVM Verification system
2430 243 enters ID Number (manually or through bar or magstripe read)
1417 141 activates 122 in order to establish connection with 125
1227 122 sends Login Request to 125 where User Name is implicitly provided by
122.
Page 13

CA 02747642 2011-08-01
User Positive Approval & Authentication Services
Inventors: Branislav R Sikljovan, Guelph, ON, Canada, Radosav Andric, Toronto,
ON, Canada
Subject to Issuer requirements Password is either entered by 141 or implicitly
provided by 122
1258 125 verifies User Name & Password, checks 141 status and if valid sends
Login
Response to 122 / establishes an open session and awaits for Approval Request
from 146
2441 244 sends ID Verification Request to 245 with appropriate 244 information
and
captured ID Information
2451 245 forwards ID Verification Request to 146
1463 146 checks ID provided in 2451 to determine if 141 is registered for
UPAAS
services and if yes sends Approval Request to 125 with 214 information
1253 125 identifies 122 using ID, checks its status and if valid sends
Approval Request
to 122
1414 141 reviews 244 Name & Location as displayed by 122 and confirms
acceptance
by entering UVM
1224 122 sends Approval Response to 125 with encrypted UVM Block
1255 125 sends UVM Verification Request to 109
1096 109 verifies UVM and sends UVM Verification Response to 125
1254 125 sends Approval Response to 146
1462 146 sends ID Verification Response to 245
2452 245 forwards ID Verification Response to 244 at which point User
verification has
been confirmed
1469 Subject to Issuer Requirement 146 sends ID Verification Advice to 125
1259 If 1469 received from 146 then 125 sends ID Verification Advice to 122 at
which
point the session is closed
Page 14

CA 02747642 2011-08-01
bUp
z a;
r- N ~n z O
~- r-I ~O N O ^~
-. O -4 I - .~-I O N N N N N N M M M M
cG
U
z
o
o 0
h C!1 U ~" 0
U E
0
0 Z c U U y a, a U U o
w o b W d ) i W '~ W W !~,
z d U w m v)1 r~ w U w as --+
,~ U C7 ~õ~ $-I I ~-I Sr t, I ~I d s..1 Y-I I 1.1 I-I -I
Q a) ~. d d a) a) a) a) ~.
a I
CIO
0.1 O Z n
cn
^^' O 60)
14
z
W a)
m z
U c- a 0 0
a o u
U ~, 0 a A; ~,) a d a1 d 3
64
S o a~~i o y cl
' z W d off, C7
'% A~ d Z z -~ U a; U b
as
y .-+ N M O r+ N M ~t I O w - N M d

CA 02747642 2011-08-01
N
bA
Gr
~O N M V 1 M M M V~ V1 V) tn V1
-+ -- r- N N N M M M d d - N M IT
N N N N N N N N N N N N M M M M
U
CIO
ZO o o o
j o O O
0
O c~ 0 c~ `a p
N ~= U
C;S
O C+ N
vj Q C e~ y Ar O A O
p~ 3¾ vs 3 3 0 3 b¾ b
t= b
w o U i 0 i o U i o b v x x x
v ¾ a^ ¾ v~ 3 3 3 3
~ v p U v p U U p U U Q a> i a~
o O CA ¾ a¾¾ a¾¾ a¾¾ a¾ Z z z Z
Qn,
a. o
E
r
a~ o
~ C U
cd
o o
w fit
N ~+ O
I1 L.~
U U
~o N 00 Cl o

CA 02747642 2011-08-01
bA
z ` o v~
z a 0
o + z w
z +~ O w
O Q
cz
~, as W -
y Q~
V 6> o 0 O O s
Ln CA
00
'O O iii it N ¾+ C G~ d C1+
z z M o
a d
0
y y
u w
N iN
a s Q Q W -- N
N
.-a ! N
Q+~. N
o
o
CA
0
cn 00 y c
con r.
w
04, N
IZ+ il, d d d d cn
z
a O Z N 00 O\

CA 02747642 2011-08-01
M
3 a
Q
0 03 1=4 E
o an - O c"c 4 >1 v
u cu ;..4
H u o 0 H o
z 0 -d
O a .., 0 o
W .0
H a~ O
o A o 0
-d
H O U 0. 404 CA
H p N
00 0
Loo
0-4 El
b U
]C C 3
C> N y V y,,,b A 0
m "S 41
U
= E
cm 0
b o b H
U Oa
CIS u
; Q 3
C) 4w4
¾ W O C b o
C45 (a)
0 r.
co)
a~
> O A U -o U v
W5 4.4
E
ry o 0 3 >, o 4, 0
a v, F~ nc ``" U U o Q o a a~i a a i A,
> ."' 'd G U U ~'" N iG t~
03 d)
U U H H U py = W a w'
c
y
$-4 0
O Q) ti
>
o
0
0
o a
U O
M
a H ~
U U U U S U

CA 02747642 2011-08-01
co~
04
0
y ~ a o
cd Q+ y U ~' y 'O
U y , c? O
z b 3 -
O N
U
04
o w o U
E~ 0
~' p=
O CL b N
V+ h! S ti U
00
Vj Q O O ~ bA y C N y "O
U
c>d y O ~,, V >, y w U
O N r~r Gw cz N N 40. E-+
CID CA ca
C ^O A ,~ ^ ~ O c~ ~,
x "O N tN y >> ~p, Ur
`~ Q c~ N ~CC cd d" U
d 'b "d ~r w y U G1 U
ed 0 o cW O O O Q .~ w
z v, z y o y b b C7
co .. c .~ w y o 0 Q a~ v~
N O -= Gin it, 'b
0
0 >1 04
,~ ZFi U =.V+ =~ 0 .O h 04 N y c~
> al
N wO U Q -
cqs .
> ?;r+ k 0< o I 3 ti
O_ > co >..
o~i ?~ i1. a~ Pa O a0i cl v U a~
04 ej a4 0
o
1-4 W a4
04 40.
o oo Z y
U W a t-+ r=, i S ~~, H U U
GO
;;.N
S ~ S
04
Q O
CA
con
v U W w - - U

CA 02747642 2011-08-01
o~i0
b o
yy RS
bA xO+ 2 O 4)
.~ RS 3 N .+ a'S
U a) '~ Q Q O
CIO ' at v ~n
O O U N '- b O
O Q cn
."O O =~ =w ..
y U N O t, O
40. o
q 0 a u CZ Q b [ y ~7 r =.-r a~)+ b
V- 0
sn s. > v c - U GL C
G4 O V g 0 O
cts
rA 4.4
co >1 cz
j t'3 o o a)
,,y,y a, a4
'~ ~ ojj c~ O ^N~+ O
,O O rn N Lam. U G y A yNy V~ b h
f~. >> =.. U W .. a+ eQ
c~ O a7
:3 0
cz Go
A 'ti '" b c 0
co 0 0. u co 04
> aj t4.4 t=
O
rY O c~d ca v O CIO w 'o
03 0 0 (71
cqs
aa) a w a a ,$ o o S a
as
64
0
a)
0-4
Q d 0 y
a a a 0
H

Representative Drawing
A single figure which represents the drawing illustrating the invention.
Administrative Status

2024-08-01:As part of the Next Generation Patents (NGP) transition, the Canadian Patents Database (CPD) now contains a more detailed Event History, which replicates the Event Log of our new back-office solution.

Please note that "Inactive:" events refers to events no longer in use in our new back-office solution.

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Event History , Maintenance Fee  and Payment History  should be consulted.

Event History

Description Date
Time Limit for Reversal Expired 2017-08-01
Application Not Reinstated by Deadline 2017-08-01
Deemed Abandoned - Failure to Respond to Maintenance Fee Notice 2016-08-01
Inactive: Abandon-RFE+Late fee unpaid-Correspondence sent 2016-08-01
Letter Sent 2015-02-13
Reinstatement Requirements Deemed Compliant for All Abandonment Reasons 2015-02-12
Deemed Abandoned - Failure to Respond to Maintenance Fee Notice 2014-08-01
Application Published (Open to Public Inspection) 2013-02-01
Inactive: Cover page published 2013-01-31
Inactive: IPC deactivated 2012-01-07
Inactive: First IPC from PCS 2012-01-01
Inactive: IPC expired 2012-01-01
Inactive: IPC from PCS 2012-01-01
Inactive: First IPC assigned 2011-09-06
Inactive: IPC assigned 2011-09-06
Inactive: Office letter 2011-08-16
Inactive: Office letter 2011-08-16
Application Received - Regular National 2011-08-11
Filing Requirements Determined Compliant 2011-08-11
Inactive: Filing certificate - No RFE (English) 2011-08-11
Small Entity Declaration Determined Compliant 2011-08-01

Abandonment History

Abandonment Date Reason Reinstatement Date
2016-08-01
2014-08-01

Maintenance Fee

The last payment was received on 2015-02-12

Note : If the full payment has not been received on or before the date indicated, a further fee may be required which may be one of the following

  • the reinstatement fee;
  • the late payment fee; or
  • additional fee to reverse deemed expiry.

Please refer to the CIPO Patent Fees web page to see all current fee amounts.

Fee History

Fee Type Anniversary Year Due Date Paid Date
Application fee - small 2011-08-01
MF (application, 2nd anniv.) - small 02 2013-08-01 2013-07-04
Reinstatement 2015-02-12
MF (application, 3rd anniv.) - small 03 2014-08-01 2015-02-12
MF (application, 4th anniv.) - small 04 2015-08-03 2015-02-12
Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
BRANISLAV SIKLJOVAN
RADOSAV ANDRIC
Past Owners on Record
None
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column. To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Description 2011-08-01 19 780
Abstract 2011-08-01 1 27
Drawings 2011-08-01 6 182
Claims 2011-08-01 1 47
Representative drawing 2012-01-18 1 18
Cover Page 2013-01-16 1 52
Filing Certificate (English) 2011-08-11 1 156
Notice: Maintenance Fee Reminder 2013-05-02 1 129
Notice: Maintenance Fee Reminder 2014-05-05 1 119
Courtesy - Abandonment Letter (Maintenance Fee) 2014-09-26 1 174
Second Notice: Maintenance Fee Reminder 2015-02-03 1 126
Notice of Reinstatement 2015-02-13 1 164
Reminder - Request for Examination 2016-04-04 1 117
Notice: Maintenance Fee Reminder 2016-05-03 1 129
Courtesy - Abandonment Letter (Request for Examination) 2016-09-12 1 164
Courtesy - Abandonment Letter (Maintenance Fee) 2016-09-12 1 172
Second Notice: Maintenance Fee Reminder 2017-02-02 1 131
Notice: Maintenance Fee Reminder 2017-05-02 1 120
Fees 2013-07-04 1 154
Correspondence 2011-08-11 1 21
Correspondence 2011-08-11 1 18
Fees 2015-02-12 1 24