Patent 2779774 Summary

(12) Patent Application:	(11) CA 2779774
(54) English Title:	UNIVERSAL RECOGNITION PLATFORM
(54) French Title:	PLATEFORME DE RECONNAISSANCE UNIVERSELLE
Status:	Deemed Abandoned and Beyond the Period of Reinstatement - Pending Response to Notice of Disregarded Communication

Bibliographic Data

(51) International Patent Classification (IPC):
(72) Inventors :	MOSCOE, JEFFREY (Canada) DIAB, SACHA (Canada) LAVINE, MARC (Canada)
(73) Owners :	ONE INC.
(71) Applicants :	ONE INC. (Canada)
(74) Agent:	INTEGRAL IP
(74) Associate agent:
(45) Issued:
(22) Filed Date:	2012-05-30
(41) Open to Public Inspection:	2013-11-30
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

Sorry, the abstracts for patent document number 2779774 were not found.

Claims

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

Sorry, the claims for patent document number 2779774 were not found.
Text is not available for all patent documents. The current dates of coverage are on the Currency of Information page

Description

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

CA 02779774 2012-05-30
, . =
. . ,
.,=
= 1
Application number / numero de demande: 0-31- '11 -Ty
Figures:
Pages: 19 021 e.P .93 ac-t 30 gµf 35 3c, 41 ci-?,..51,
521 6,044 r, 4,-?100( -f-qt 14-1,,- 49,i___-}-1&4_1-o-4----(1311'15,.o1
J3$ __13`t f3.1_14/_,J5it 151 I 5 (t. k_,x_kac.4 ILaccili4;_on
/Si" /601:CA/et rivei&la..rbJa: rin
,;.5;_g__)'_9,1_p_cay 3 (40
ekg45(11-N ______________________________ AdoL-4.1n_ 0
.I clirk
_________ 42c1.4-..a- 1.41ski-4-1 .rol42/34-Ificcater.kith LiAiR4s4.iõ------
----------------------------------------------------------
= = =
itak.LerSad
5.1OLL'
=
Unscannable items
received with this application
(Request original documents in File Prep. Section on the I 0' floor)
Documents recu avec cette dernande lie pouvant etre balayes
(Commander les documents originaux dans la section de preparation des dossiers
au
10eme etage)

CA 02779774 2012-05-30
001CS , a's ahi iuu,ptLb2
Ot-. Joftl40r61)0()
Upc=rot-z4.1.-ci:or s rn (0.4_ bam.. ..(QQ).4jAcjL4
unC..,r 'ten t,*6
S.Du-Ska. aierreLS ,
SS4C-V4q 7.-12Cot Z-ocialto_12 pa.grleK loccd.cans.
ctufl c.Akt.e)
.=
= = .
, .
= '
=

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
Inc.
ONE INC.
UNIVERSAL RECOGNITION
MANUAL
Page 1 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
This Manual contains the following Sections
Overall Introduction ¨ Business Overview
Executive Summary
One Inc ¨ Customer Universal Recognition - Introduction
Registration and Enrollment
Universal Recognition
One Inc. - Central Processing Platform
One Inc. ¨ Data Classification and Encryption
One Inc. ¨ Card and Token Issuance
Requirements Information Gathering for One Inc. and Partners
Project Management Methodology
Testing Strategy
This manual is organized so that it can be read end to end.
The sections within the manual are also created to stand alone.
In this way, the processes and functions within Universal Recognition and
Enrolment can be
clearly identified and shared with partners within specific areas.
It should be noted that even though there is one overall table of contents,
certain stand alone
sections also contain their own table of contents for easier extraction.
Page 2 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
Table of Contents
BUSINESS OVERVIEW ............................................................
8
Executive Summary ............................................................
9
The Marketplace Challenge ....................................................
9
Universal Recognition Token ..................................................
10
Registration with Customers and Partners .....................................
10
Enrollment ...................................................................
10
Data Maintenance .............................................................
10
Universal Recognition ........................................................
11
Security, access control, and encryption .....................................
11
Technology platform ..........................................................
12
Conclusion ...................................................................
13
SECTION - Enrollment for Customer Universal Recognition ......................
14
One Inc. - Card Registry and Enrollment ¨ highlights .........................
15
One Inc. - Card Numbering and Issuance - Overview ............................
16
One Inc. ¨ Number assignment and tracking ....................................
17
Major industry identifier ....................................................
17
Issuer identifier number - 636831 ............................................
17
Number Assignment Registry ...................................................
18
One Inc. - Card Numbering and Issuance ¨ Example Process Flow ................
19
One Inc. - Number Issuance ¨ Process .........................................
20
Card Number Assignment and Linkage ...........................................
20
One Inc. Card Inquiry ........................................................
21
One Inc. - Card Numbering and Issuance ¨ Enrollment Data Flow ¨ Example
Loyalty Issuer
Verification Option ..........................................................
22
One Inc. - Card Numbering and Issuance ¨ Example Enrollment Data Flow One Inc
Verification
Option .......................................................................
23
One Inc. Customer Enrollment Screen ..........................................
24
SECTION - Universal Recognition ..............................................
25
Universal Recognition Platform Possible Capabilities .........................
26
Business Capability to Technology Map ........................................
27
Universal Recognition Token ..................................................
28
Universal Recognition ........................................................
29
Participants in the Universal Recognition Program ............................
29
Card-Issuing Bank ............................................................
29
Processor ....................................................................
29
Cardholder ...................................................................
29
Merchant .....................................................................
29
Acquirer .....................................................................
29
Card Association / Payment Networks ..........................................
29
One Inc. .....................................................................
29
One Inc. Hub Interaction Model ...............................................
30
Universal Recognition ¨ Point of Sale Systems ................................
31
Pos Systems ¨ Usage ¨ Capability ¨ Benefits ..................................
31
Page 3 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
POS Systems and Pin pads ...................................................
32
PCI compliance
32
Personal identification number (PIN) .......................................
32
Customer facing PIN pad ....................................................
32
Smart card .................................................................
32
Hand-held POS PIN pad ......................................................
32
Compatibility ..............................................................
33
Swiped Cards and data stored on the Magnetic Stripe ........................
33
Universal Recognition ¨ Example Payment and Token Process Flow .............
34
Payment and One Inc. Token Usage ...........................................
37
Merchant Environment Components ............................................
39
Example Implementation Option 1 ¨ Merchant Pos Recognizing and Routing To One
Inc. 40
POS Recognition and Route to One Inc - Example Flow ........................
41
Pos Direct to One Inc Illustration .........................................
42
POS System Transaction Creation ............................................
43
Primary account number (PAN) ...............................................
43
Expiration date ............................................................
43
Service code ...............................................................
43
POS changes for Universal recognition ......................................
44
Using a Chip Card at POS ¨ Recognizing the Card ............................
47
Certification ..............................................................
48
Hardware ...................................................................
48
Network Connectivity .......................................................
48
Performance ................................................................
49
Data Storage ...............................................................
49
Compliance .................................................................
49
Example Implementation Option 2 - Merchant Server Recognizing and Routing To
One Inc. 50
Merchant Routing directly to One Inc - Example Flow. .......................
51
Software ...................................................................
53
Example of Data to be from POS to the Merchant Server. .....................
53
Deployment of a Table resident on the Merchant servers .....................
54
Example of the One Inc. Card Range Table at the Merchant ...................
54
Example of Data to be sent to One Inc ......................................
54
Timing: ...................................................................
55
Changes for implementation: ................................................
55
Example of Data to be sent to the Merchant Server ..........................
56
Hardware ...................................................................
56
Network Connectivity .......................................................
56
Security ...................................................................
57
Performance ................................................................
57
Data Storage ...............................................................
57
Compliance .................................................................
57
Example Implementation Option 2 - Summary and Costs ........................
58
Example Implementation Option 3 ¨ Routing From Card Association or Issuer!
Processor 59
Example Issuer or Card Association routing process flow ....................
60
Issuer ¨ Card Association Software changes .................................
62
Link Table - (if One Inc. does not store Card Number). .....................
62
Example of Data to be sent to One Inc. from Issuer/ Processor or Card
Association 62
Page 4 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
Example of Data to be sent to Issuer/Processor or Card Association from One
Inc. 63
Hardware .....................................................................
63
Network Connectivity .........................................................
63
Security .....................................................................
63
Performance ..................................................................
64
Data Storage .................................................................
64
Compliance ...................................................................
64
Universal Recognition for Access .............................................
65
Universal Recognition ¨ Access Control Systems ...............................
66
Universal Recognition Token or Payment card as Access ¨ example flow .........
67
Access control models ........................................................
68
Attribute-based access control ...............................................
68
Discretionary access control - DAC ...........................................
68
Role-based access control ....................................................
68
Access control system operation ..............................................
69
Access Readers ...............................................................
69
Security Considerations and Authentication on Access .........................
69
Access control system components .............................................
70
Example access control topology ..............................................
70
Appendix A - Universal Recognition ISO 8583 POS Messaging Standard ...........
71
Message type indicator .......................................................
72
ISO 8583 versions ............................................................
72
Message class ................................................................
73
Message function .............................................................
74
Message origin ...............................................................
74
Bitmaps ......................................................................
76
Data elements ................................................................
77
ISO 8583 POS Messaging Format ................................................
79
Appendix C ¨ Merchant POS Certification ¨ EMV - PCI ..........................
87
Purpose ......................................................................
87
Introduction .................................................................
87
Example Phases of the EMV Compliance Process .................................
89
POS Device Hardware ..........................................................
89
POS Compliance by Payment Brand (Card Association) ...........................
90
Example Requirements by Payment Brand ........................................
90
Example Payment Application Software .........................................
90
Merchant Connection to the Acquirer Network ..................................
91
End to End Validation ........................................................
91
SECTION - Central Processing Platform ........................................
93
Central Processing Platform ..................................................
94
One Inc. ¨ Central Processing Platform .......................................
94
Example Message Flow Overview ................................................
96
Enrollment Web Services ......................................................
97
Cardholder Information Updates ...............................................
97
Example Real Time Message Flows ..............................................
98
Example Customer Recognition ................................................
98
Example Loyalty Real Time Transaction ........................................
99
Example Access to Premises Request Real Time Transaction .....................
100
Page 5 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
Example File Transfer Data Flow ..............................................
101
Example Transaction Types ....................................................
102
Merchant POS - Recognition ...................................................
102
Enrollment in a Program at POS ...............................................
103
Purchase at POS ..............................................................
104
Example Partner Initiated Transactions: .....................................
105
Customer Profile Update ......................................................
105
File Transfer Batch Transactions .............................................
106
Example Data Model ...........................................................
107
Data Dictionary ..............................................................
108
Example System Platform Architecture .........................................
113
Example Transmission Protocol ................................................
114
Example Database Security Protocol ..........................................
114
Example Secure File Transfer Architecture ....................................
115
Secure File Transfer Standard ................................................
116
SECTION - Data Classification and Encryption .................................
117
One INC. Universal Recognition ¨ Data and Encryption Overview ................
118
One INC. Universal Recognition ¨ Data Classification ........................
119
One INC. Universal Recognition ¨ Cryptographic Keys ..........................
121
One INC. Universal Recognition ¨ Key Life Cycle ..............................
122
Key Life Cycle Events ........................................................
122
Key Generation ...............................................................
122
Key Distribution ............................................................
122
Key Loading ..................................................................
122
Key Backup ...................................................................
122
Key Usage ....................................................................
122
Key Storage Environment ......................................................
122
Key Archive ..................................................................
122
Key Destruction ..............................................................
122
One INC. Universal Recognition ¨ Example Key Encryption Key ..................
124
One INC. Universal Recognition ¨ Example Base Derivation Key .................
125
One INC. Universal Recognition ¨ Example PIN Verification Key ................
126
One INC. Universal Recognition ¨ Example PIN Block ...........................
127
One INC. Universal Recognition ¨ Data Encryption Standard - DES ..............
128
One INC. Universal Recognition ¨Key Exchange .................................
129
One INC. Universal Recognition ¨ Example Key Ceremony ........................
130
One Inc. Example Key Ceremony ................................................
130
One INC. Universal Recognition ¨ Example Cryptography Options ................
132
One Inc. In-House Cryptography Example .......................................
133
One Inc. Outsourced Cryptography Example .....................................
134
CHIP CARD Keys (EMV) .........................................................
135
Issuer Private Key ...........................................................
136
Payment Systems Environment ..................................................
136
Issuer Public Key ............................................................
137
Example Contact and Contactless Chip .........................................
138
Example Fields on the traditional Payment Chip. ..............................
139
One INC. Universal Recognition ¨ Example Data Authentication .................
140
One INC. Universal Recognition ¨ Static Data Authentication .................
141
Page 6 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Example Static Data Verification Steps ......
142
One INC. Universal Recognition ¨ Example Dynamic Data Authentication .........
143
One INC. Universal Recognition ¨ Dynamic Data Authentication ¨ Example
Verification steps 144
One INC. Universal Recognition ¨ Combined Data Authentication ¨ Future .......
145
One INC. Universal Recognition ¨ Example Hardware Security Modules ...........
146
One INC. Universal Recognition ¨ Cloud Cryptography ..........................
147
SECTION - Card and Token Issuance ............................................
148
Card and Token Issuance - Introduction .......................................
149
Example Steps for production of Cards and Tokens .............................
150
1). Customer Enrolment .......................................................
150
2). Customer Verification ....................................................
150
3). Customer Confirmation / Rejection
150
4). Customer and Form Factor Data Creation (Embossing Files) .................
150
5). Form Factor Personalization .............................................
150
6). Form Factor Production and Distribution ..................................
150
7). Form Factor Activation, Usage ............................................
150
8). Reissue and Replacement ..................................................
150
Important concepts in Issuance and Enablement of Cards and Tokens
152
Personalization ..............................................................
152
Embossing ....................................................................
152
Provisioning .................................................................
152
Recognition Devices ..........................................................
153
Card Types ...................................................................
153
Bar code .....................................................................
153
Magnetic-stripe ..............................................................
153
Smart Card ¨ Contact .........................................................
153
Smart Card - Contactless (RFID) ..............................................
154
ISO Standards for Cards ......................................................
154
Contactless and Mobile Chips .................................................
155
Contactless tokens ...........................................................
155
Comparison between Magnetic Stripe and Chips .................................
156
Dual Interface and Hybrid Chips ..............................................
157
Global Chip Card Deployment Map ..............................................
160
Enablement ¨ Chip Cards ......................................................
161
Enablement ...................................................................
161
Enablement Data ..............................................................
161
Enablement Data ¨ encryption .................................................
162
Enablement Data ¨ How it is obtained .........................................
162
Embossing File Data ..........................................................
163
File Data ....................................................................
163
Pin Data .....................................................................
163
Encryption Key Details .......................................................
164
Production and Delivery Details ..............................................
164
Mailer Details ..............................................................
164
Embossing Details ...........................................................
165
Matrix of Example Card Technologies and approximate costs ....................
166
Page 7 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
BUSINESS OVERVIEW
Page 8 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
Executive Summary
One Inc. solves the problem of the Customer carrying too many loyalty and
membership cards.
We offer the same level of membership and Loyalty participation through an
easy to use Card or
Token. By allowing a person to use the card or token of their choice as an
identifier at many
locations, One Inc. increases customer participation and satisfaction.
The Marketplace Challenge
For Consumers
= Consumers have too many loyalty and membership cards in wallet
= Billions of loyalty memberships worldwide ¨2 billion in the US, 18.4 per
house hold and 130
million in Canada
= On average Canadians have 10+ cards in wallet
For Merchants
= 54% of loyalty cards are left at home and not used. In 2009, a survey by
Isle Ventures
supported this Colloquy finding as their respondents indicated that they
forgot their cards 61%
of the time
= Active loyalty program member spend on average 13% more than non members
= Loyalty program administrators recognize that member data is critical to
driving business
economics
= Technology advancements are presenting platforms allowing for the
consolidation of loyalty
programs and payment solutions ¨ chip, e-wallet, NFC etc.
For Credit Card Issuers & Payment Brands (MasterCard, Visa, American Express &
Interac)
= Becoming and staying the "first card in wallet"
= Increase spend on the card
= Increase market share
= Need for competitive differentiation
= Innovation required to remain card of choice during rapidly changing
payment environment
(E-wallets, PayPal)
Page 9 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
Universal Recognition Token
In order to have our Card or Token universally recognized, One Inc. has
obtained a unique
identification number from the Canadian Standards Council and the
International Standards
Organization.
In one example, any of One Inc.'s Partners may immediately recognize a One
Inc. product with the
Identification number starting with 636831.
This unique number enables all participating Merchants, Partners and Customers
to instantly
recognize and act upon a One Inc. issued form factor.
Registration with Customers and Partners
One Inc. may have a matching One Inc. number for every Payment Card Issued by
our Payment
Network Partners and may also issue cards and tokens in concert with our
partners.
Customers may be able to register their Payment, Loyalty, Identity, Gift or
Pre-paid and Identity
numbers linked to a single One Inc. number through Web or Merchant Access
points.
One Inc.'s recognition and identification service provides a real-time
translation from a customer-
chosen identification "token" to the loyalty or membership number required by
a retailer's systems.
One Inc. also provides services to keep customer contact information current
and to enroll new
customers with little or no effort by the customer or partner staff.
Enrollment
One Inc. increases membership and participation in a partner's program by
making it easy (effortless)
to enroll in programs. When One Inc. sees a token for a customer who is not
already enrolled in a
program, One Inc. can supply the program with enrollment information to have
the customer set up
without any action required by the customer, the merchant, or the loyalty
program staff.
Data Maintenance
One Inc. data maintenance services improve the quality and effectiveness of
customer
communication and engagement. A demographic change (address, email contact,
phone number
changes) that a customer makes at any One Inc. partner is propagated to all
other partners where the
customer has a membership, if the customer opts into this service.
Page 10 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
Universal Recognition
The One Inc. Enrolment and Registration capability, combined with the unique
Issuer Identification
number allows all participants in the program the ability to recognize
customers at their points of
presence.
We offer Merchants, Payment Networks and Issuers the flexibility of
communicating with One Inc, in
order to recognize a customer using a One Inc. or One Inc. Linked number.
Merchants are able to recognize and route One Inc. numbers from their Point of
Sale or Access, as
well as from their processing centers in order to recognize and reward their
customers. This is a
significant feature as 54 to 61 percent of customers do not usually have their
Loyalty cards present.
Cash paying customers are also accommodated under the One Inc. identification
program and can
accrue points or gain access to facilities by presenting their unique One Inc.
identification.
For Merchants who choose to have the Payments networks or Issuers recognize
their customers,
One Inc. has the ability to retrieve the Loyalty number for the Customer /
Merchant combination and
to send it directly to the merchant or to have the Payment Network or Issuer
include the information
when they are responding to the requestor.
Security, access control, and encryption
One of the greatest concerns of any customer, merchant, payment network or
issuer in participating
in programs involving personal or payment information is the issue of privacy,
identity management
and data security.
One Inc. technology and certifications may provide the protection of real time
data in transit as well as
any stored data.
Page 11 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
Technology platform
The One Inc. state of the art Service Platform may meet or exceed the Payment
Card Industry (PCI)
and Personal Data protection (PIPEDA) and storage standards in any of the
following manners:
= Physical Premises. The Production processing environment may be housed in
a secured Data
Centre, with access by authorized and authenticated personnel.
= Access Controls. System Access and Changes to One Inc.'s System (Servers,
Database)
components may be limited to authenticated authorized personnel, with Change
Control
processes that require Management Review and Approval.
= Firewall. The production Network may be firewalled and configured to
allow only authenticated
and authorized limited access to a pre-defined business capability.
= Real time transaction data. Network transmission with external partners
for Real Time
transactions may be encrypted, using either a dedicated VPN connection or
https protocol with
SSL 128 bit encryption.
= File Transfers. This may be done with Secure File Transfer Protocol
(SFTP) based on Secure
Shell Protocol(SSH), which uses encrypted transmission, and the files may be
encrypted using
asymmetric Key (Public/Private key pairs) with external partners.
= Customer Critical Data at Rest. Critical Data may be 3DES or higher level
encrypted using a
Hardware Security Module to protect the Master Keys. The Master Key is not
known to any
one individual, but two or more separate individuals know a part of the key,
which is then
stored in the HSM device. This is also banking level security mandated by the
Card
Associations to store and process PIN based transactions. Critical Data to be
stored with this
level of encryption includes, Credit Card number, Customer website login data,
such as a
website password.
= High Performance 24X7 real time processing with Failover Redundancy for
Maximum uptime.
Page 12 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
Conclusion
One Inc. - A single universal recognition token that replaces all of your
current cards!
One Inc., is a groundbreaking solution that allows consumers to consolidate
all of their loyalty
program and membership cards into one number that can be stored and attached
to a payment card,
a co-branded One Inc. card, a mobile app, a fob, or any other token that the
consumer chooses and
the merchant or institution accepts.
Simply put, One Inc. is a universal recognition platform connecting millions
of members to issuers,
clubs, museums, and more, in the way they choose.
Page 13 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
0
Inc.
SECTION - Enrollment for Customer Universal Recognition
Page 14 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
One Inc. - Card Reclistry and Enrollment ¨ hkihlicihts
Registration and Tracking of all One Inc. and Partner Cards issued under One
Inc. Issuer
Identification Number (IN)
Flexibility in Issuing One Inc. numbers or accommodating Partner numbering
systems
Tracking Card Issuance and Activation by Customer
'j-= Enabling the Customer to Link Loyalty program numbers to a Financial and
One Inc. Number
Issuance of Loyalty Program numbers on behalf of Partners
`e Ability to verify Card , One Inc. and Loyalty on our stand alone platform
or in Real Time with
the Loyalty program Partner
Ability to Register and Track Numbers on varying form factors (Card, Virtual,
Fob, Mobile)
Page 15 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
One Inc. - Card Numbering and Issuance - Overview
One Inc. issues identification numbers from a Registered Issuer Identification
Number range granted
via our application through the Canadian Standards Council (CSC) and the
International Standards
Organization (ISO).
In one example, all of One Inc. cards and tokens may be identified by the
first 6 digits "636831".
These numbers represent virtual cards as well as other form factors such as
Magnetic Stripe,
Integrated Circuit (Chip), Fobs and mobile devices.
One Inc. has a state of the art card tracking system which assigns and tracks
card number ranges in
concert with Merchants, Loyalty Partners, Card Associations and Issuing Banks
participating in our
unique offering.
Using the IIN number assigned to One Inc., the Number tracking system assigns
a One Inc. known
number range to each partner. The assigned numbers, when used, may indicate
One Inc. enrolled
customer activity across a variety of channels and recognition points.
A cardholder may make a purchase, accrue loyalty points or gain access to
facilities with just one
device.
Page 16 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
One Inc. ¨ Number assignment and tracking
In one example, the Canadian Standards Association and the International
Standards Organization
assigns One Inc. their own exclusive 19 digit Card Numbering system based upon
the Major Industry
in which we operate. The major industry identifier categories are listed in
the table below.
Major industry identifier
The major industry identifier (MII) is the first digit of the ISO/IEC 7812
number. It identifies the
industry within which the card is primarily to be used.
MII digit value Issuer category
0 ISOfTC 68 and other industry assignments
1 Airlines
2 Airlines and other future industry assignments
3 Travel and entertainment and banking/financial
4 Banking and financial
Banking and financial
6 Merchandising and banking/financial
7 Petroleum and other future industry assignments
8 Healthcare, telecommunications and other future industry
assignments
9 For assignment by national standards bodies
If the major industry identifier is 9 the next three digits are the numeric-3
country code.
Issuer identifier number - 636831
The issuer identification number is unique to One Inc. and is recognized by
all organizations who
participate in ISO accredited functions. The IIN is broken down as follows:
The first six digits, including the major industry identifier, compose the
issuer identifier number (IIN).
This identifies the issuing organization. The official ISO registry of IINs,
the "ISO Register of Card
Issuer Identification Numbers", is not available to the general public. It is
only available to institutions
which hold IINs, issue plastic cards, or act as a financial network or
processor. Institutions in the third
category may sign a license agreement before they are given access to the
registry.
Upon receipt of this number, One Inc. controls the assignment and distribution
of the remaining 13
available digits based upon the current and future requirements of its
partners.
Page 17 of 166

CA 02779774 2012-05-30
ONE INC. UNIVERSAL RECOGNITION
One Inc. - Number Issuance ¨ Process
Card Number Assignment and Linkage
1. After receiving the ISO IIN number, One Inc. may initiate the generation
and linkage of the One
Inc. number by requesting a current and future numbering requirement from the
Partner or
Partner may generate within the One Inc. range.
2. The Partner may be assigned a number range from One Inc.'s Tracking system.
3. The Partner may then generate the Partner Card number and One Inc. linked
card number and
send them back in a batch file transmission using an encrypted Managed Secure
File Transfer
system.
4. Subsequent updates can be sent via batch or online secure channels
depending on the
partner capability.
5. Upon receipt of the secure data, One Inc. may transform and encrypt the
partner number and
record the used numbers into One Inc.'s tracking system, such that the number
and linkage
may represent a unique combination.
6. Our entire processes may be PCI and PIPEDA compliant and may adhere to
Industry Security
standards.
7. The Cardholder may receive marketing information detailing the Enrollment
process and may
use a financial institute or Loyalty partner to link any Loyalty program to
the form factor of their
choice.
8. The cardholder may click thru a link from the partner site and may be
served a pre-populated
Enrollment screen showing the cardholder number and dropdown menu of Loyalty
programs
available for linkage.
9. The cardholder may opt into the One. Inc program by entering the Loyalty
number of each
program of which they are a member.
10. The data may be sent back to the One Inc. Authorization engine which may
verify the Card
number and may also validate the Loyalty numbers by either at One Inc.'s site
or the Loyalty
program's site.
11.0ne Inc. may also create the ability for assigning new numbers for
customers wishing to enroll
in a program either by assigning the number or informing the Loyalty program
that the
customer wishes to register.
12.The Partner may then be able to record the Enrollment of that Loyalty
number into the One Inc.
Program.
Page 20 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
1 Inc.
SECTION - Universal Recognition
Page 25 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Universal Recognition Platform Possible Capabilities
One Inc. provides a state of the art, high performance robust platform that
may be capable of serving
multiple concurrent connectors in real time, near real time and batch modes.
The Platform enables the consumer to link their Financial Card to multiple
Loyalty programs and to
accumulate points in Real Time with a single number in a physical or
electronic wallet.
Cash paying customers are accommodated through the use of a One Inc. offering
which may identify
them to merchants and loyalty programs participating in the Program.
Industry standards for access, security and cryptography are supported by a
secure and hardened
hardware, infrastructure and internal and external network connectivity.
The platform is hosted within a certified and secure datacenter with disaster
recover capabilities and
intrusion detection (physical and system) 24 hours a day. Physical and access
security include
biometric and two factor authentication as well as gating (mantraps).
The processes for monitoring, first line support and escalation are clearly
defined and governed by
Service Level Agreements and the Network Operations Center monitors the health
of the One Inc
system at a database, application, infrastructure, network and security level.
One Inc. has a clearly documented and defined methodology for managing all
aspects of IT
Operations under the control of the Project Management Office.
Page 26 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Business Capability to Technology Map
Business requirement Technology Component
Flexibility ¨ Integration with partners Standard Industry Interfaces ISO,
XML
Configurable formatters
High Performance and throughput of Database
transactions Messaging engine
Secure Storage and Networks Transformation, Encryption, Access
Security, - HSM
Encrypted Data while in flight or at rest HSM ¨ Key Ceremony ¨ Key
Exchanges
Industry Standard Compliance ¨ PCI DSS PCI Self Assessment ¨ GAP / Risk
QSA Agent
Audit Based on Classification
Robust (Failover and Load Balancing) Routers
Load Balancing
Monitoring
Manual and Automatic Failover
Channel Agnostic ¨ (All sources - IVR, Configurable Interfaces
WEB, MOBILE, B2B, B2C) TCP-IP capability
Over the Air Provisioning
Open Platform Messaging (ISO, XML) ISO, XML and Configurable - Custom
Content Serving Web Server, Screens
Real Time transaction capability Routing, Logging , Authorization, Store
and
forward
Secure Managed File Transfers Security, Encryption, Tracking,
Guaranteed Delivery - Re-transmission
Guaranteed Delivery Mechanisms (Store Transaction storage and replay
mechanism
and Forward capability)
Capable of Authorizing Card, Loyalty and Encryption, Decryption ¨ HSM
One Inc. numbers Check Digit Validation
International Standards Organization and Application Form
Canadian Standards Council Numbering
(IIN)
Routing to all parties Messaging , Routing, Network Connectivity
Transaction Logging Databases
Reporting Data analysis and classification,
retrieval
Settlements Reconciliation, Settlement, Clearing
Page 27 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Universal Recognition Token
One Inc.'s Universal Recognition enables customers to use a single token in
order to identify
themselves at a point of presence in order to purchase, accrue points into
Loyalty program of their
choice or to gain access to facilities.
One Inc. may enroll customers, merchants and their Loyalty partners into a
program which may link
traditional Payment Cards to a One Inc. Number and to the Customer's Loyalty
or Access facilities.
Merchants, Card Networks, Issuers and their processors may be equipped with
the capability to use
the traditional existing networks to communicate with One Inc.'s Universal
Recognition Platform in
Batch or Real time modes. These parties may also have the option of directly
connecting to the One
Inc. Platform.
Page 28 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Universal Recognition
Participants in the Universal Recognition Program
Card-Issuing Bank
The cardholder's financial institution, also a licensed member of a Card
Network (such as
MasterCard, or VISA).
Processor
The entity that receives and approves transactions on behalf of the Card
Issuing Bank
Cardholder
A consumer who is solicited, screened, and approved by the issuer who
establishes a line of credit for
the consumer and issues the credit card.
Merchant
Any company wishing to recognize the presence of its customer.
Acquirer
A licensed member of the Payment Networks that screens and accepts merchants
into its credit card
program, processes transactions, and completes financial settlement to them.
Card Association / Payment Networks
Associations which provide their brands to member financial institutions that
in turn provide services
to consumers and merchants. (E.g. Visa and MasterCard).
American Express is both the Payment Network and the Card Issuer for Amex
Products.
One Inc.
A High Availability, High Performance, Fault Tolerant, Secure and Encrypted
platform capable of
connecting to all parties in a real time or batch mode. One Inc. has domain
and subject matter
expertise in the areas of Loyalty, Payments, Emerging Technologies, Security,
Cryptography and real
time message exchange. This expertise enables us to provide a unique customer
experience "in the
moment" when the customer uses their Financial or One Inc. card number for
identification, Payment
or Facilities Access. Our flexibility in delivering these experiences are
tailored to minimize changes to
existing merchant and Payment Processing systems and are supported by three
models, however,
we are capable of handling special requests on our open system.
Page 29 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Universal Recognition ¨ Point of Sale Systems
A POS system, or Point of Sale system, refers to the location in which
transactions are made in a
business. The major components of a POS system are the hardware and software
needed to run the
system, such as the cash register, a computer, credit or debit card acquirer
pin pads, and checkout
system.
Pos Systems ¨ Usage ¨ Capability ¨ Benefits
1. Increased efficiency
POS systems reduce the time that employees spend in maintaining inventory and
calculating sales
and cash flow. Equipment included in POS systems, such as cash registers and
barcode scanners
allow employees to quickly process customers and streamline the checkout
process. In addition, POS
systems reduce the chance of human error, leading to increased sales and
productivity.
2. Customer Satisfaction
Using a POS system allows employees to rapidly address the customer's needs.
It allows them to
process customers through the check-out process quickly and efficiently. In
addition, some of the
features of POS systems include the ability to create gift cards, process
discounts, and maintain
customer loyalty programs. Another feature of POS systems is that it can
collect customer data that
can be further used for specialized marketing and advertising campaigns.
3. Reduced Losses
POS systems keep track of inventory and prices of each individual product in
the store. A major
problem that businesses may address is shrinkage, or the loss of products due
to theft, misuse or
waste. This computerized system can minimize shrinkage through the ability to
track inventory as it
moves from storage to checkout.
4. Access to Real-time Information
With POS systems, employees can instantly access data that gives them
information on inventory
and sales at any point of the day. For example, POS systems can inform staff
members of how much
of a product they have sold yesterday, a week ago, or the month before.
Another benefit is that POS
systems can give alerts when a certain inventory stock runs low, or when a
frequent customer has
entered the store.
Page 31 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
POS Systems and Pin pads
POS (point of sale) pin pads are a convenient way for businesses to accept
credit and debit card
transactions. There are three different types of PIN pads available including
those that only have a
number pad, those that provide a card swipe and those that offer a way for
customers to provide a
digital signature. POS PIN pads may be compliant with existing software and
terminal hardware to
make transactions secure.
PCI compliance
POS PIN pads that are certified by the Payment Card Industry (PCI) as
compliant meet PCI data
security standards. These standards help to protect information when payments
are made through
debit and credit cards. This helps to create consistency for security measures
across the globe. The
Pin pads are tamper proof and key injected by the Acquirer or the entity
deploying the Pin pad.
Personal identification number (PIN)
The personal identification number is a four digit code issued to or chosen by
a cardholder. This PIN
is a security measure used to validate the identification of the cardholder.
Customer facing PIN pad
A customer facing PIN pad provides many additional features for the customer.
Instead of having the
cashier swipe the card and sign a paper receipt, a customer facing PIN pad
allows customers to
swipe their own cards and provide a digital signature.
Smart card
Some POS PIN pads are equipped with Smart card technology. This technology
allows users to
make payments securely and, in many cases, without the card making physical
contact with a
terminal.
Hand-held POS PIN pad
A hand-held POS PIN pad is a convenient piece of equipment. The hand held PIN
pad allows
cashiers to hand the unit to the customer so they can enter the PIN number for
their card without
assistance. This is an added level of security directed to PIN privacy. These
units can be both wired
or wireless.
Page 32 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Compatibility
Compatibility for POS PIN pads refers to their ability to work with the
software for the POS terminal. If
these are not compatible, transactions may not properly process and security
can be compromised.
Swiped Cards and data stored on the Magnetic Stripe
Swiped Cards yield a limited set of data known as "Track 2" Data
1, Card Number
1- Expiry Date
)=. Service Code
Page 33 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Payment and One Inc. Token Usage
One Inc. may implement a solution for merchants. This solution may minimize
changes to the
Merchant software and processes while delivering a valuable real time customer
experience. The
customer may not require a Merchant Loyalty card if they choose to register
with the One Inc.
universal recognition program.
1). The customer checks out and uses their enrolled Credit Card or One Inc.
token to identify their
presence.
2). The Merchant Pos may create a Financial Transaction Request for
Authorization (e.g. ISO 8583 ¨
MT 100) and may send to the Merchant Processing System.
2A). At this point, if the Merchant is capable , they may send the Card Number
or token along with
Route information directly to One Inc. from the POS system. One Inc. would
link the request to the
Loyalty Number and return it to the POS system.
3). The Merchant Processing System may pass the Financial Transaction Request
for Authorization
(ISO 8583 ¨ MT 100) to the Acquirer (e.g. Moneris, Chase Paymentech).
3A). The Merchant Processing System may send the Card Number or token along
with Route
information directly to One Inc.. One Inc. would link the request to the
Loyalty Number and return it to
the Merchant Processing system.
4). The Acquirer examines the Issuer Identification Number (first 6 digits of
DE2 - Primary Account
Number IIN number) and routes the Transaction to the appropriate Payment
Network (e.g. VISA,
MASTERCARD, AMEX)
5). The Payment Network sends the transaction to the Issuer's Processor.
5A). If the Payment Network is connected and participating in the One Inc.
Program, they may map
the PAN to the One Inc Number and send a request to One Inc. The Payment
Network could also
send the PAN to be mapped by One Inc. For the participating Payment Network,
One Inc. would
return the Loyalty number to be placed in a data field (TBD) on the outbound
leg of the transaction
from the Issuer's Processor or send back a "Do not Wait" code if we return the
Loyalty number
directly back to the Merchant Server or Merchant POS (5B or 5C).
5B). One Inc. extracts the appropriate routing fields from the Card
Association feed and sends the
transaction with the Loyalty Number to the Merchant Server. This route may be
arranged when the
Merchant enrolls.
5C). One Inc. may extract the appropriate routing fields from the Card
Association feed and may send
the transaction with the Loyalty Number to the Merchant POS.
Page 37 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
6). Issuer's Processor authorizes the transaction amount against its limits
and current balance. The
Issuer Processor formats a Response to Authorization message (MT 110) and may
include the
Loyalty number from One Inc (6A). The transaction may then be sent back to the
Payment Network.
6A). If the Issuer's Processor is a One Inc. participant, they may either
route the Card Number or
perform the One Inc. translation and send a request to the Universal
Recognition platform. One Inc.
would then return a Loyalty Number or a "Do Not Wait" code if we are sending
directly back to the
Merchant Server or POS.
6B). One Inc. may extract the required fields from the Processors message and
may send the
transaction with the Loyalty Number to the Merchant's Server. The Routing
information may be set up
when the Merchant enrolls.
6C). One Inc. may extract the required fields from the Processors message and
may send the
transaction with the Loyalty Number to the Merchant POS
7). the participating Payment Network (CA) may insert the Loyalty Number if
required and send to the
Acquirer.
8). The Acquirer routes the transaction back to the Point of Origin by
applying the original Routing
Information it received in the request portion of the message.
9). The Merchant may have several options at this point.
= If the Loyalty Number was sent back directly to either the POS or
Merchant Server, they would
be able to calculate the Points and Balance for inclusion into the message
back to the POS
printer for approved transactions.
`) If the Loyalty Number is sent back within the ISO response message,
they would extract it and
apply their Points and Balance calculations in the message going back to the
POS on
approved transactions.
= In a Cash scenario, they would calculate the points as a result of their
direct link to One Inc.
and send Points, Balance and Payment amount to the Customer's endpoint.
10). Points and Balance are sent back to Customer on Approved or Cash
transactions
Page 38 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Merchant Environment Components
Most Merchants installations, depending on the Industry, have the following
components:
), Vendor packaged, customized or developed Checkout Software
Loyalty Software
1, Payment Software
= Acquirer Secure Pin pads and ISO (Financial) Message capabilities
), Connectivity to Store, Loyalty and Financial Systems (Acquirer)
), Access Recognition and Entry systems
= PCI Certifications on Equipment, Network and Software
)=- Encryption, Key Exchange and Secure Transmissions in Batch and Real Time
Modes
Page 39 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Example Implementation Option 1 ¨ Merchant Pos Recognizing and Routing To One
Inc.
Merchant and Access systems may be required to recognize the Payment Card or
One Inc. token at
their Points of Sale, Payment and Checkout Systems.
Upon recognition of the Payment Card or One Inc. token, the Merchant system
may be asked to
route the transactions to a One Inc. server located on the One Inc. platform
or within the Merchant's
designated secure area hosting a one Inc. Server.
Traditionally, the Payment card is read by the POS payment system by swipe,
Contact Chip,
Contactless tap on a secure reader (e.g. pin pad) or hand entry by the
attendant if the magnetic strip
swipe is not readable.
In the event that the Loyalty program runs on the Chip, terminal software
changes would be needed
to recognize and route the Loyalty Number to the appropriate destination.
In traditional Merchant systems the Loyalty Cards are also recognized by the
system via a scan or
swipe NOT usually at the Pin Pad. The customized merchant software would then
link the Payment
and Loyalty number so that the Loyalty points can be calculated on eligible
Stock Keeping Unit
number (SKU) of the items at checkout.
In fifty-four percent of the cases, the Customer may not have their Merchant
Loyalty card in their
possession and could lose out on the opportunity to accrue points and receive
offers.
One Inc. Universal Recognition provides the Merchant the opportunity to
recognize the
customer's presence 100% of the time.
Page 40 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
POS System Transaction Creation
The minimum set of data collected by a swipe is known as Track 2 data and
yields the following
information. Chip and Pin Data is detailed in the Appendix.
Primary account number (PAN)
The PAN is an ISO defined field up to 19 digits in length. The first 6 digits
are the Issuer Identification
Number (IN).
Expiration date
The date after which the card should be renewed or reissued - four characters
in the form YYMM.
Service code
Three digits field obtained on a card swipe and detailed below:
The first digit specifies the interchange rules, the second specifies
authorization processing and the
third specifies the range of services.
Service code values common in financial cards are:
First digit
1: International interchange OK
2: International interchange, use IC (chip) where feasible
5: National interchange only except under bilateral agreement
6: National interchange only except under bilateral agreement, use IC (chip)
where feasible
7: No interchange except under bilateral agreement (closed loop)
9: Test
Second digit
0: Normal
2: Contact issuer via online means
4: Contact issuer via online means except under bilateral agreement
Third digit
0: No restrictions, PIN required
1: No restrictions
2: Goods and services only (no cash)
3: ATM only, PIN required
4: Cash only
5: Goods and services only (no cash), PIN required
6: No restrictions, use PIN where feasible
Page 43 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
7: Goods and services only (no cash), use PIN where feasible
The rest of the Payment Message is constructed by the certified software
running on the POS
system. Refer to the ISO Message format in Appendix A of this document.
POS changes for Universal recognition
In order for the Merchant to detect the presence of a customer changes may be
required at the
Merchant POS. If the Payment card is swiped or hand entered only a minimum set
of data is initially
available. The payment message may be built from the three track 2 fields
described above.
Recognizing the Payment Card or Token at the Merchant POS:
One Inc. may provide data which may enable the Merchant to determine Card or
Token eligibility and
may drive the decision to create and send requests for Loyalty numbers to the
One Inc. platform.
Example of the One Inc. Card Ramie Table at the Merchant POS.
Institution Card Card Range Product One Inc One Inc.
Range End (if (Optional) Primary Route
Secondary
Start required) (alternate)
Route
MasterCard 5118 10 PC Financial 255.255.255.255
255.255.213.200
MasterCard
Credit Card
MasterCard 5178 05 Capital One 255.255.255.255
255.255.213.200
MasterCard
Credit Card
One Inc 1234 56 One Inc Token 1
255.255.255.255 255.255.213.200
When the Payment Card or One Inc. Token is recognized by the Merchant POS
software, the POS
system may invoke new logic to check the One Inc. Card Range Table to see if
the Card or Token is
eligible under our program.
If a match is found, the Merchant POS system would retrieve the One Inc.
Routing information and
pass the encrypted Card number or One Inc. token to the location described as
the primary route.
In the event that the primary route is unavailable, the alternate or secondary
route would be used.
This redundancy may ensure that transaction is delivered to One Inc. in time
for the Card or Token to
be linked to the Loyalty number and returned to the Requestor as there may be
no single point of
failure.
When the Merchant enrolls in the One Inc. program, they would be registered on
a similar routing
table established on the One Inc. Platform.
Page 44 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Data to be sent to One Inc.
Example of Data to be sent to One Inc.
Payment Terminal Merchant Tran ID Tran Tran Unique
Card ID ID Date Time Identifier
Number (Retrieval
Ref
Number)
Using
One Inc One Inc.
Primary Secondary
Route Route
Note: If additional Fields are required, these may be determined during the
detailed design with the
Merchant technical team in order to determine when the fields are populated
and available during
their checkout process. Fields such as terminal ID and Merchant ID are not
dependent upon SKU
items and can be delivered to One Inc. prior to the calculation of the amount.
The Amount is usually the last item which is determined as all of the SKU
items would have to be
scanned and tabulated.
Also, of note is that the Card Number may be encrypted from the source and may
never be exposed
or stored within a non- secure system. PCI rules apply.
Timing:
Usually, the Payment Card is not presented by the Customer until the end of
the checkout and after
the total calculated.
Changes for implementation:
A procedural change would be requested so that there is no additional time in
lane. We
would request that the customer tap the card into the POS system prior to or
during checkout.
')=- The Merchant would send the Card Number, Terminal and Merchant ID along
with the
provided routing data.
Page 45 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Merchant Software changes to identify the customer and to send the transaction
o Load and Maintain the One Inc. IIN and Routing tables at the merchant
o Recognize the tap or swipe of the Payment Card or Token
o Check the One Inc. IIN table
o Retrieve the route
o Create a transaction in an agreed upon format to be sent to One Inc.
o Do a round robin check for an available route
o Log the transaction into a state table which would wait for the response
o Send the transaction with a unique identifier so that the response from
One Inc. can be
matched to the original transaction request
o Log the response
o Interface with the Loyalty system passing the Loyalty number and terminal
data so that
the Points and Balance can be sent to the customer
One Inc. may verify the Merchant, match the Card or token number and respond
with the
Loyalty number using the merchant route stored at the One Inc. Merchant
routing facility.
The transaction may delivered back to the Merchant POS in adequate time to
enable the
merchant to calculate the points and balance for the customer. One Inc would
also log the
transaction into the One Inc. database so that Reconciliation and Balancing
can be done with
the Merchant.
Data to be sent to the Merchant POS
Loyalty Terminal Merchant Tran Tran Tran Unique
Number ID ID ID Date Time Identifier
to match
the
Merchant
message
(Retrieval
Ref
Number)
Using
Merchant Merchant.
Primary Secondary
Route Route
Page 46 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
In order to achieve the recognition and routing, One Inc. may choose to
develop and deploy an
Application Program Interface (API) along with the Card Range and Routing
Tables. The API may
integrate with the Merchant Customized Software to recognize and route
transactions to One Inc.
This software would have to portable and reusable as there are a variety of
POS equipment vendors
and operating systems currently in use on the market.
Industry experts such as AJB Software and Tender Retail have developed
interfaces which integrate
with Payment and Checkout systems.
Using a Chip Card at POS ¨ Recognizing the Card
The terminal has a list containing the Application Identifier (AID) of every
EMV application that it is
configured to support, and the terminal may generate a candidate list of
applications that are
supported by both the terminal and chip. The terminal may attempt to obtain a
directory listing of all
chip applications from the chip's PPSE (Proximity Payments Systems
Environment). If this is not
supported or fails to find a match, the terminal may iterate through its list
asking the chip whether it
supports each individual AID.
If there are multiple applications in the completed candidate list, or the
application requires it, then
the cardholder may be asked to choose an application; otherwise it may be
automatically selected
The Cardholder selects the application at the Point of Service and, using the
cardholder's input, the
terminal selects the application on the chip.
The chip may then supply the correct data records for the transaction.
The Application Identifier (AID) may be encoded according to [IS07816-5] and
may be made up of a
byte Registered Application Provider Identifier (RID) and an optional
Proprietary Application
Identifier Extension (PIX) of up to 11 bytes, for example.
The AID of each application shall be set during personalization so it needs to
be provided to the
Service Bureau (producers of the card).
E.g. the AID for contactless VISA (AO 00 00 03 10 10) and is the same for MSD
(Magnetic Stripe
Format)
For dual interface cards with dual applications, the AIDs may be different for
each application.
Page 47 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Certification
PCI Certification may require that changes to Software running in a Payment
environment may
require that the software be certified within that environment as PCI
compliance encompasses
Hardware, Software and connectivity.
Key Points/ Questions
)- Can the software be developed and certified independently of Acquirers and
Processors
Does the merchant have to re-certify their systems when the recognition and
routing software
is added
Do we have to develop specific software for each type of equipment or is there
a universal
type of application
PCI and EMV compliance documentation clearly states that "Terminal compliance
requires the participation of the terminal manufacturer, Payment Brands and
Acquirer/
VAR". See Appendix C for Certification details.
This process may be verified and detailed by the QSA assessor.
Hardware
One Inc. could deploy computers into the Store System in order to store
encrypted data enabling the
Merchant to recognize One Inc. Numbers or Card Numbers. This may require a
review of PCI and
PIPEDA rules. This equipment would be accessible to One Inc. for batch and
Real Time updates.
The hardware option may still include the POS software changes described
above. Additionally,
there may be a requirement to exchange key protected data with this server.
Hardware Security Modules (HSM's) may be required at the Merchant location in
order to decrypt
data encrypted under the One Inc. key system. This process is detailed in the
Cryptography Section
of this document.
Network Connectivity
In order to achieve Real Time and Batch Connectivity with Merchants, One Inc.
and the Merchant
may establish.
Secure and Encrypted Primary and Alternate routes (e.g. VPN)
> Development and Test Route
Managed Secure File Transfer Route
Page 48 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Security
In scenarios where Card or Personal Identifiable Information is exchanged and
stored, Encrypted
and Secure transmissions may be required for information in transit and at
rest. Hardware Security
Modules (HSM) and Secure tunnels are industry standard for this practice. Keys
are exchanged in
strictly supervised Key Ceremonies so that both partners in the exchange are
able to use the
information. Key Ceremonies and HSM's will be addressed in the Cryptography
section of this
Manual.
Performance
Service Level Agreements detailing One Inc and Partner commitments to Request
/ Response
thresholds, Uptime and throughput may be in place.
End to end testing may be required to confirm performance within the Service
Level Agreements and
a monitoring process and reporting may be in place for audit purposes.
Data Storage
Data being stored at One Inc. and partner sites would need to be classified
(rated) and assigned
categories. Usually Data is classified in the following manner:
= Public
= Internal Use
= Confidential
= Restricted
Personal and Financial Data are usually in the Restricted Category. This
detailed in the Data
Classification and Cryptography section of this document
Compliance
The result of the Data Classification exercise may drive the Compliance
requirements.
The Standards are set by the:
Payment Card Industry ¨ PCI
Canadian Government - Personal Information Protection and Electronic Documents
Act (PIPEDA)
Canadian Marketing Association ¨ Privacy Guidelines
Page 49 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Example Implementation Option 2 - Merchant Server Recognizing and Routing To
One Inc.
The Merchant and One Inc. may agree that it would be a better choice to modify
the application on
the Merchant's own system to identify and route the Card or Token to One Inc.
This modification at Merchant or In-store servers provides more flexibility
for software customization
by the Merchant.
One Inc. would receive and send transactions back to Merchant Servers rather
than individual POS
endpoints.
Depending on the design, the Merchant POS system could "blind route" all of
the transactions that it
acquires and the One Inc. Bin route tables would reside on the Merchant
Servers rather than at the
POS.
This solution could minimize the requirement for a re-certification with
Acquirers if the POS system
does not have to be changed.
Page 50 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Software
The POS system would still have to be able to recognize and route the minimum
data to the
Merchant Servers.
The Merchants are more in control of these systems and are less dependent on
third parties for
modification and certifications. The implementation requirements and options
may be similar to the
POS options.
Example of Data to be from POS to the Merchant Server.
Payment Terminal Merchant Tran ID Tran Tran Unique
Card ID ID Date Time Identifier
Number (Retrieval
Ref
Number)
Using
Merchant Merchant
Primary Secondary
Route Route
Page 53 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Deployment of a Table resident on the Merchant servers
The tables will be provided by One Inc. can be updated in Batch or Real Time
depending on the
Merchant requirements.
Example of the One Inc. Card Range Table at the Merchant
Institution Card Card Range Product One Inc One Inc.
Range End (if (Optional) Primary Route
Secondary
Start required) (alternate)
Route
MasterCard 5118 10 PC Financial 255.255.255.255
255.255.213.200
MasterCard
Credit Card
MasterCard 5178 05 Capital One 255.255.255.255
255.255.213.200
MasterCard
Credit Card
One Inc 1234 56 One Inc Token 1
255.255.255.255 255.255.213.200
Example of Data to be sent to One Inc.
Payment Terminal Merchant Iran ID Tran Tran Unique
Card ID ID Date Time Identifier
Number (Retrieval
Ref
Number)
Using
One Inc One Inc.
Primary Secondary
Route Route
One Inc. may also deploy an application (API) which may integrate with the
Merchant Customized
Software to recognize and route transactions to One Inc. As a precedent,
Moneris offers API's to link
to their system for viewing data or linking to their gateways.
Note: If additional Fields are required, these may be determined during the
detailed design with the
Merchant technical team in order to determine when the fields are populated
and available during
their checkout process. Fields such as terminal ID and Merchant ID are not
dependent upon SKU
items and can be delivered to One Inc. prior to the calculation of the amount.
The Amount is usually the last item which is determined as all of the SKU
items would have to be
scanned and tabulated.
Also, of note is that the Card Number may be encrypted from the source and may
never be exposed
or stored within a non- secure system. PCI rules apply.
Page 54 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Timing:
Usually, the Payment Card is not presented by the Customer until the end of
the checkout and after
the total calculated.
Changes for implementation:
:0- A procedural change would be requested so that there is no additional time
in lane. We
would request that the customer tap the card into the POS system prior to or
during checkout.
fr The Merchant would send the Card Number, Terminal and Merchant ID along
with the
provided routing data.
fr
'00- Merchant Software changes to identify the customer and to send the
transaction
o Load and Maintain the One Inc. IIN and Routing tables at the merchant
O Recognize the tap or swipe of the Payment Card or Token
o Check the One Inc. IIN table
o Retrieve the route
o Create a transaction in an agreed upon format to be sent to One Inc.
O Do a round robin check for an available route
o Log the transaction into a state table which would wait for the response
O Send the transaction with a unique identifier so that the response from
One Inc. can be
matched to the original transaction request
o Log the response
o Interface with the Loyalty system passing the Loyalty number and terminal
data so that
the Points and Balance can be sent to the customer
One Inc. may verify the Merchant, match the Card or token number and respond
with the
Loyalty number using the merchant route stored at the One Inc. Merchant
routing facility.
= The transaction may delivered back to the Merchant Server in adequate
time to enable the
merchant to calculate the points and balance for the customer. One Inc would
also log the
transaction into the One Inc. database so that Reconciliation and Balancing
can be done with
the Merchant.
Page 55 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Example of Data to be sent to the Merchant Server
Loyalty Terminal Merchant Tran Tran Tran Unique
Number ID ID ID Date Time Identifier
to match
the
Merchant
message
(Retrieval
Ref
Number)
Using
Merchant Merchant.
Primary Secondary
Route Route
In order to achieve the recognition and routing, One Inc. may choose to
develop also deploy an
Application Program Interface (API) along with the Card Range and Routing
Tables. The API may
integrate with the Merchant Customized Software to recognize and route
transactions to One Inc.
This software would have to portable and reusable as there are a variety of
POS equipment vendors
and operating systems currently in use on the market.
Hardware
One Inc. could deploy computers into the Merchant Data Center in order to
store encrypted data
enabling the Merchant to recognize One Inc. Numbers or Card Numbers. This may
require a review
of PCI and PIPEDA rules. This equipment would be accessible to One Inc. for
batch and Real Time
updates.
Hardware Security Modules (HSM's) may be required at the Merchant location in
order to decrypt
data encrypted under the One Inc. key system. This process is detailed in the
Cryptography Section
of this document
Network Connectivity
In order to achieve Real Time and Batch Connectivity with Merchants, One Inc.
and the Merchant
may establish.
s;)=. Secure and Encrypted Primary and Alternate routes (e.g. VPN)
Development and Test Route
Managed Secure File Transfer Route
Page 56 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Security
In scenarios where Card or Personal Identifiable Information is exchanged and
stored, Encrypted
and Secure transmissions may be required for information in transit and at
rest. Hardware Security
Modules (HSM) and Secure tunnels are industry standard for this practice. Keys
are exchanged in
strictly supervised Key Ceremonies so that both partners in the exchange are
able to use the
information. Key Ceremonies and Ham's will be addressed in the Cryptography
section of this
Manual.
Performance
Service Level Agreements detailing One Inc and Partner commitments to Request
/ Response
thresholds, Uptime and throughput may be in place.
End to end testing may be required to confirm performance within the Service
Level Agreements and
a monitoring process and reporting may be in place for audit purposes.
Data Storage
Data being stored at One Inc. and partner sites would need to be classified
(rated) and assigned
categories. Usually Data is classified in the following manner:
= Public
= Internal Use
= Confidential
= Restricted
Personal and Financial Data are usually in the Restricted Category
Compliance
The result of the Data Classification exercise may drive the Compliance
requirements.
The Standards are set by the:
Payment Card Industry ¨ PCI
Canadian Government - Personal Information Protection and Electronic Documents
Act (PIPEDA)
Canadian Marketing Association ¨ Privacy Guidelines
Page 57 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Example Implementation Option 2 - Summary and Costs
The costs would be similar to the changes at POS as described in Option 1.
The Merchant POS would have to recognize and route the One Inc number to the
Merchant central
servers and then the servers managing the end-points would route the
transaction to One Inc.
This process may be more under control of the merchants and may leave them
less dependent on
vendors.
Depending upon the detailed design of this option with the Merchant technical
staff, there may be a less
complex recertification required with the acquirer as the routing logic for
routing would reside on the
Merchant host.
The Merchant would be asked to estimate the cost of the Host based routing and
receiving messages.
Page 58 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Example Implementation Option 3 ¨ Routing From Card Association or Issuer /
Processor
For Merchants who are unable to change the POS systems in order to recognize
One Inc. provided
IIN number ranges, or for those who are unable to establish a direct route to
One Inc., the option of
having the transaction transiting the traditional payment path exists.
Upon recognition of the Payment Card, the Card Association or the Issuer /
Processor may be
enabled with the capability to recognize and route the Payment Card Number or
the One Inc. number
so that the Loyalty Number for the customer can be retrieved or authorized
(recognized).
As detailed in the example flows below, the major distinction with this option
is that there are no
direct incoming links from the Merchant or Merchant POS systems.
The Merchants may be required to extract the Loyalty number from the
transaction returned by the
Acquirer or receive a direct communication from One Inc.
Page 59 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Issuer ¨ Card Association Software changes
The Card Association Route would be similar to the Processor Route in that
either could host a Link
Table which may map the Card Number to the One Inc. Number
Link Table - (if One Inc. does not store Card Number).
Card One Wait for
Number Inc. Response
Number flag
The wait for Response Flag is an indicator which can be set up when the
Merchant enrolls
with One Inc.
If the Merchant provides routing information to One Inc. may use this flag to
indicate to the Card
Association or Issuer / Processor that we would not be returning a Loyalty
number for insertion into
the outgoing response message. They do not wait for our response with the
Loyalty Number.
The data passed to One Inc. has to be specific enough so that the Merchant can
match the One Inc.
transaction to the financial transaction.
Upon the arrival of the inbound (from the Acquirer) message, the Card
Association may be asked to
look up the Link Table and to match the Card Number to the One Inc. Number.
They may then be
asked to extract the relevant information from the transaction and send those
to One Inc.
Example of Data to be sent to One Inc. from Issuer/ Processor or Card
Association
One Inc. Terminal Merchant Tran ID Iran Iran Unique
Linked ID ID Date Time Identifier
Number
Using
One Inc One Inc.
Primary Secondary
Route Route
Page 62 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
If One Inc. is returning the Loyalty number back to the Card Association or
Issuer / Processor
Example of Data to be sent to Issuer/Processor or Card Association from One
Inc.
One Inc. Loyalty Merchant Tran ID Tran Tran Unique
Linked Number ID Date Time Identifier
Number (retrieval
or Stan)
Using
Issuer or Issuer or
CA CA
Primary Secondary
Route Route
The direct routing of the Data back to the Merchant Server or Merchant POS
would be the
same as described in the POS and Merchant Server implementation options.
Hardware
The Option is available for One Inc. to deploy a mapping and routing server
and API on the CA or
Processor site in order to facilitate this translation. Any hardware deployed
on Payment Network or
Processor sites may be subject to PCI.
Network Connectivity
In order to achieve Real Time and Batch Connectivity with Payment Networks or
Processors, One
Inc. may establish:
Secure and Encrypted Primary and Alternate routes (e.g. VPN)
Development and Test Route
Managed Secure File Transfer Route
Security
In scenarios where Card or Personal Identifiable Information is exchanged and
stored, Encrypted
and Secure transmissions may be required for information in transit and at
rest. Hardware Security
Modules (HSM) and Secure tunnels are industry standard for this practice. Keys
are exchanged in
strictly supervised Key Ceremonies so that both partners in the exchange are
able to use the
information. Key Ceremonies and HSM's are addressed in the Cryptography
section of this Manual.
Page 63 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Performance
Service Level Agreements detailing One Inc and Partner commitments to Request
/ Response
thresholds, Uptime and throughput may be in place.
End to end testing may be required to confirm performance within the Service
Level Agreements and
a monitoring process and reporting may be in place for audit purposes.
The treatment of the Loyalty number returned to the Payment Network or Issuer
may not negatively
impact the end to end request / response transaction time from POS to ISSUER
and back.
Data Storage
Data being stored at One Inc. and partner sites would need to be classified
(rated) and assigned
categories. Usually Data is classified in the following manner:
= Public
= Internal Use
= Confidential
= Restricted
Personal and Financial Data are usually in the Restricted Category
Compliance
The result of the Data Classification exercise may drive the Compliance
requirements.
The Standards are set by the:
Payment Card Industry ¨ PCI
Canadian Government - Personal Information Protection and Electronic Documents
Act (PIPEDA)
Canadian Marketing Association ¨ Privacy Guidelines
Page 64 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
Universal Recognition for Access
Page 65 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Universal Recognition ¨ Access Control Systems
An access control system determines who is allowed to enter or exit, where
they are allowed to exit or
enter, and when they are allowed to enter or exit
Electronic access control uses computers to solve the limitations of
mechanical locks and keys. A wide
range of tokens can be used to replace mechanical keys. The electronic access
control system grants
access based on the credential presented. When access is granted, the door is
unlocked (or the gate is
opened) for a predetermined time and the transaction is recorded. When access
is refused, the door
remains locked (or the gate remains closed) and the attempted access is
recorded. The system may
also monitor the door (or gate) and alarm if the door (or gate) is forced open
or held open too long after
being unlocked.
ONE INC. may take the complexity out of these numerous credentials and tokens
by enabling
access validation on a single form factor utilizing an existing Card, Loyalty
or One Inc. number.
Page 66 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Access control models
Access control models are sometimes categorized as either discretionary or non-
discretionary. The three most widely recognized models are Discretionary
Access
Control (DAC), Mandatory Access Control (MAC), and Role Based Access Control
(RBAC). MAC and RBAC are both non-discretionary
Attribute-based access control
In attribute-based access control (ABAC), access is granted not based on the
rights of
the subject associated with a user after authentication, but based on
attributes of the
user. The user has to prove so called claims about his attributes to the
access control
engine. An attribute-based access control policy specifies which claims need
to be
satisfied in order to grant access to an object. For instance the claim could
be "older
than 18". One Inc. could provide assistance in enabling Rules based access
control.
Discretionary access control - DAC
Discretionary Access Control (DAC) is an access policy determined by the owner
of an
object. The owner decides who is allowed to access the object and what
privileges they
have. One Inc. could filter eligibility in order to enable DAC.
Role-based access control
Role Based Access Controls (RBAC) is an access policy determined by the
system, not
the owner. RBAC is used in commercial applications and also in military
systems, where
multi-level security requirements may also exist. RBAC differs from DAC in
that DAC
allows users to control access to their resources, while in RBAC; access is
controlled at
the system level, outside of the user's control.
Three primary rules are defined for RBAC:
1. Role assignment: A subject can execute a transaction only if the subject
has
selected or been assigned a role.
2. Role authorization: A subject's active role may be authorized for the
subject. With
rule 1 above, this rule ensures that users can take on only roles for which
they
are authorized.
3. Transaction authorization: A subject can execute a transaction only if the
transaction is authorized for the subject's active role. With rules 1 and 2,
this rule
ensures that users can execute only transactions for which they are
authorized.
Page 68 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Access control system operation
An access control point can be a door, turnstile, parking gate, elevator, or
other physical
barrier where granting access can be electronically controlled. An electronic
access
control point can contain several elements. At its most basic there is a stand-
alone
electric lock. The lock is unlocked by an operator with a switch. To automate
this,
operator intervention is replaced by a reader. The reader could be a keypad
where a
code is entered, it could be a card reader, or it could be a biometric reader.
Access Readers
Access Readers do not usually make an access decision but send a card number
to an access control panel that verifies the number against an access list.
Generally only entry is controlled and exit is uncontrolled. In cases where
exit is also
controlled a second reader is used on the opposite side of the door. In cases
where exit
is not controlled, free exit, a device called a request-to-exit (RTE) is used.
Request-to-
exit devices can be a push-button or a motion detector. When the button is
pushed or
the motion detector detects motion at the door, the door alarm is temporarily
ignored
while the door is opened. Exiting a door without having to electrically unlock
the door is
called mechanical free egress. This may be an important safety feature. In
cases where
the lock may be electrically unlocked on exit, the request-to-exit device also
unlocks the
door.
When a credential is presented to a reader, the reader sends the credential's
information, usually a number, to a control panel, a highly reliable
processor. The
control panel compares the credential's number to an access control list,
grants or
denies the presented request, and sends a transaction log to a database. When
access
is denied based on the access control list, the door remains locked. If there
is a match
between the credential and the access control list, the control panel operates
a relay
that in turn unlocks the door.
Security Considerations and Authentication on Access
The above description illustrates a single factor transaction. Credentials can
be passed
around, thus subverting the access control list. For example, someone has
access
rights to the data center. The credential can be lent or stolen and used
fraudulently. To
prevent this, two factor authentication can be used. In a two factor
transaction, the
presented credential and a second factor are needed for access to be granted;
another
factor can be a PIN, a second credential, operator intervention, or a
biometric input.
There are three types (factors) of authenticating information
= something the user knows, e.g. a password, pass-phrase or PIN
= something the user has, such as smart card
= something the user is, such as fingerprint, verified by biometric
measurement
Page 69 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Access control system components
An access control point, which can be a door, turnstile, parking gate,
elevator, or other
physical barrier where granting access can be electronically controlled.
Typically the
access point is a door. An electronic access control door can contain several
elements.
At its most basic there is a stand-alone electric lock. The lock is unlocked
by an
operator with a switch. To automate this, operator intervention is replaced by
a reader.
One Inc. can integrate with the Host PC in order to authenticate the user.
Example access control topology
'WowIN .
i'
...: o,
111 rei7
li.., ,
.. , ,..,..,
õ.. ,
Page 70 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Appendix A - Universal Recognition ISO 8583 POS Messaging Standard
ISO 8583 defines a message format and a communication flow so that different
systems
can exchange these transaction requests and responses. The vast majority of
transactions made at ATMs use ISO 8583 at some point in the communication
chain, as
do transactions made when a customer uses a card to make a payment in a store
¨
POS. In particular, American Express, MasterCard and Visa networks base their
authorization communications on the ISO 8583 standard, as do many other
institutions
and networks. ISO 8583 has no routing information, so is sometimes used with a
TPDU
header.
Cardholder-originated transactions include purchase, withdrawal, deposit,
refund,
reversal, balance inquiry, payments and inter-account transfers. ISO 8583 also
defines
system-to-system messages for secure key exchanges, reconciliation of totals,
and
other administrative purposes.
Although ISO 8583 defines a common standard, it is not typically used directly
by
systems or networks. It defines many standard fields (data elements) which
remain the
same in all systems or networks, and leaves a few additional fields for
passing network
specific details. These fields are used by each network to adapt the standard
for its own
use with custom fields and custom usages.
The placements of fields in different versions of the standard varies; for
example, the
currency elements of the 1987 and 1993 versions are no longer used in the 2003
version, which holds currency as a sub-element of any financial amount
element. As of
writing, ISO 8583:2003 has yet to achieve wide acceptance. The technology
described
herein may be used with other message formats and communication flows.
Page 71 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
An ISO 8583 message is made of the following parts:
= Message type indicator (MTI)
= One or more bitmaps, indicating which data elements are present
= Data elements, the fields of the message
Message type indicator
This is a 4 digit numeric field which classifies the high level function of
the message. A
message type indicator includes the ISO 8583 version, the Message Class, the
Message Function and the Message Origin, each described briefly in the
following
sections. The following example (MTI 0110) lists what each digit indicates:
Oxxx -> version of ISO 8583 (1987 version)
x1xx -> class of the Message (Authorization Message)
xx1x -> function of the Message (Request Response)
xxx0 -> who began the communication (Acquirer)
ISO 8583 versions
Position one of the MTI specifies the versions of the ISO 8583 standard which
is being
used to transmit the message.
Position Meaning
Oxxx ISO 8583-1:1987 version
1xxx ISO 8583-2:1993 version
2xxx ISO 8583-1:2003 version
9xxx Private usage
Page 72 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Message class
Position two of the MTI specifies the overall purpose of the message.
Position Meaning Usage
A h Determine if funds are available, get an approval but do
xlxx ut not post to account for reconciliation, Dual Message
Messaorization ge
System (DMS), awaits file exchange for posting to account
Determine if funds are available, get an approval and post
x2xx Financial Message directly to the account, Single Message System
(SMS), no
file exchange after this
File Actions
x3xx Used for hot-card, TMS and other exchanges
Message
x4xx Reversal Message Reverses the action of a previous authorization
Reconciliation
x5xx Message Transmits settlement information message
x6xx Administrative Transmits administrative advice. Often used for
failure
Message messages (e.g. message reject or failure to apply)
Fee Collection
x7xx
Message
Network
x8xx anagement
Used for secure key exchange, logon, echo test and other
M
Message network functions
x9xx Reserved by ISO
Page 73 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Message function
Position three of the MTI specifies the message function which defines how the
message may flow within the system. Requests are end-to-end messages (e.g.,
from
acquirer to issuer and back with timeouts and automatic reversals in place),
while
advices are point-to-point messages (e.g., from terminal to acquirer, from
acquirer to
network, from network to issuer, with transmission guaranteed over each link,
but not
necessarily immediately).
Position Meaning
xx0x Request
xxl x Request Response
xx2x Advice
xx3x Advice Response
xx4x Notification
xx8x Response acknowledgment
xx9x Negative acknowledgment
Message origin
Position four of the MTI defines the location of the message source within the
payment
chain.
Position Meaning
xxx0 Acquirer
xxxl Acquirer Repeat
xxx2 Issuer
xxx3 Issuer Repeat
xxx4 Other
xxx5 Other Repeat
Page 74 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Examples
Bearing each of the above four positions in mind, an MTI may completely
specify what a
message may do, and how it is to be transmitted around the network.
Unfortunately, not
all ISO 8583 implementations interpret the meaning of an MTI in the same way.
However, a few MTIs are relatively standard:
MTI Meaning Usage
Request from a point-of-sale terminal for
0100 Authorization request
authorization for a cardholder purchase
0110 Issuer Response Issuer response to a point-of-sale terminal for
authorization for a cardholder purchase
When the Point of Sale device breaks down and you
0120 Authorization Advice
have to sign a voucher
0121 Authorization Advice Repeat if the advice times out
0130 Issuer Response to
Confirmation of receipt of authorization advice
Authorization Advice
0200 Acquirer Financial Request Request for funds, typically from an ATM or
pinned
point-of-sale device
0210 Issuer Response to
Issuer response to request for funds
Financial Request
E.g. Checkout at a hotel. Used to complete
0220 Acquirer Financial Advice
transaction initiated with authorization request
Acquirer Financial Advice
0221 if the advice times out
repeat
Issuer Response to
Confirmation of receipt of financial advice
0230 Financial Advice
0400 Acquirer Reversal Request Reverses a transaction
0420 Acquirer Reversal Advice Advises that a reversal has taken place
Acquirer Reversal Advice
0421 if the reversal times out
Repeat Message
0430 Issuer Reversal Response Confirmation of receipt of reversal advice
Network Management
0800 Echo test, logon, log off etc.
Request
0810 Network Management
Echo test, logon, log off etc.
Response
Network Management
Key change
0820 Advice
Page 75 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Bitmaps
Within ISO 8583, a bitmap is a field or subfield within a message which
indicates which
other data elements or data element subfields may be present elsewhere in a
message.
A message may contain at least one bitmap, called the Primary Bitmap which
indicates
which of Data Elements 1 to 64 are present. A secondary bitmap may also be
present,
generally as data element one and indicates which of data elements 65 to 128
are
present. Similarly, a tertiary, or third, bitmap can be used to indicate the
presence or
absence of fields 129 to 192, although these data elements are rarely used.
The bitmap may be transmitted as 8 bytes of binary data, or as 16 hexadecimal
characters 0-9, A-F in the ASCII or EBCDIC character sets.
A field is present only when the specific bit in the bitmap is true. For
example, byte '82x
is binary '1000 0010' which means fields 1 and 7 are present in the message
and fields
2, 3, 4, 5, 6, and 8 are not present.
Examples
Bitmap Defines presence of
4210001102C04804 Fields 2,7, 12, 28, 32, 39, 41, 42, 50, 53, 62
72340541 Fields 2, 3, 4, 7, 11, 12, 14, 22, 24, 26, 32, 35, 37, 41, 42,
47, 49,
28C28805
53,62,64
8000000000000001 Fields 1, 64
0000000000000003
(secondary Fields 127, 128
bitmap)
Explanation of Bitmap (8 BYTE Primary Bitmap = 64 Bit) field 4210001102C04804
BYTE1 : 01000010 = 42x (counting from the left, the second and seventh bits
are 1,
indicating that fields 2 and 7 are present)
BYTE2 : 00010000 = 10x (field 12 is present)
BYTE3 : 00000000 = 00x (no fields present)
BYTE4 : 00010001 = 11x (fields 28 and 32 are present)
BYTE5 : 00000010 = 02x (field 39 is present)
BYTE6 : 11000000 = COx (fields 41 and 42 are present)
BYTE7 : 01001000 = 48x (fields 50 and 53 are present)
BYTE8 : 00000100 = 04x (field 62 is present)
0 _______ 10 ____ 20 ______ 30 _____ 40 _______ 50 _____ 60_64
1234567890123456789012345678901234567890123456789012345678901234 n-th
bit
Page 76 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
010000100001 00000000000000010001000000101 10000000100100000000100 bit
map
Fields present in the above variable length message record:
2-7-12-28-32-39-41-42-50-53-62
Data elements
Data elements are the individual fields carrying the transaction information.
There are
up to 128 data elements specified in the original ISO 8583:1987 standard, and
up to
192 data elements in later releases. The 1993 revision added new definitions,
deleted
some, while leaving the message format itself unchanged.
While each data element has a specified meaning and format, the standard also
includes some general purpose data elements and system- or country-specific
data
elements which vary enormously in use and form from implementation to
implementation.
Each data element is described in a standard format which defines the
permitted
content of the field (numeric, binary, etc.) and the field length (variable or
fixed),
according to the following table:
Abbreviation Meaning
a Alpha, including blanks
Numeric values only
Special characters only
an Alphanumeric
as Alpha & special characters only
ns Numeric and special characters only
ans Alphabetic, numeric and special characters.
Binary data
Tracks 2 and 3 code set as defined in ISO/IEC 7813 and ISO/IEC 4909
respectively
. Or... or ... Variable field length indicator, each. indicating a digit.
Fixed length of field or maximum length in the case of variable length
x or xx or xxx
fields.
Additionally, each field may be either fixed or variable length. If variable,
the length of
the field may be preceded by a length indicator.
Page 77 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Type Meaning
Fixed no field length used
Where LL < 100, means two leading digits LL specify the
LLVAR or (..xx)
field length of field VAR
Where LLL < 1000, means three leading digits LLL specify
LLLVAR or (...xxx)
the field length of field VAR
LL can be 1 or 2 bytes. For example, if compressed as one
hex byte, '27x means there are 27 VAR bytes to follow. If
ASCII, the two bytes '32x, '37x mean there are 27 bytes to
LL and LLL are hex or
follow. 3 digit field length LLL uses 2 bytes with a leading '0'
ASCII. A VAR field can be
nibble if compressed, or 3 bytes if ASCII. The format of a
compressed or ASCII
VAR data element depends on the data element type. If
depending of the data
numeric it may be compressed, e.g. 87456 may be
element type.
represented by 3 hex bytes '087456x. If ASCII then one
byte for each digit or character is used, e.g. '38x, '37x, '34x,
'35x, '36x.
Page 78 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
iSO 8583 POS Messaging Format
ISO/ ISO Field Data- Length Format Full description
8583 -87 Name type
BIT
Number
Bit Map h 16 Secondary bit map
Extended indicating the presence or
absence of bits in range 65-
128 in the message being
transmitted.
2 Primary n 19 LLVAR Customer PAN, used to route
account messages.
number
pAN)
_
3 Processing n 6 Define the transaction type
code 3x2 digit fields. 1&2=type of
trans, 3&4=type of account,
5&6=to account (zeroes)
4 Amount, n 12 Transaction amount in
transaction (lowest unit local currency)
at the acquirer.
Amount, n 12
Settlement
6 Amount, n 12 Amount in (lowest unit local
cardholder currency) of amount to be
billing debited from the account
held by the issuer.
7 Transmission n 10 mmddhhmmss Message transmission date
date & time and time in GMT. Switch
completes this field.
Amount, n 8
Cardholder
billing fee
9 Conversion n 8
rate,
Settlement _______
Conversion n 8 Conversion rate applied to
rate, Forex txn amount, format
cardholder ABBBBBBB where A is the
billing decimal point position from
the right and B is the
conversion factor which
when multiplied by field 4
gives field 6.
11 Systems trace n 6 Sequence number assigned
audit by message originator. Stays
number Unchanged through txn life.
12 Time, Local n 6 hhmmss Time of the local transaction
transaction
13 Date, Local n 4 mmdd Date of the local transaction
transaction
Page 79 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
14 Date, n 4 yymm Card expiration date
Expiration
15 Date, a 4 mmdd Date of settlement
Settlement
16 Date, a 4 mmdd
conversion
17 Date, capture a 4 mmdd
18 Merchant type n 4 Category code of merchant
acquirer. Auth transactions
only.
19 Acquiring n 3 Country code of acquiring
institution institution
country code
20 PAN Extended, n 3
country code
21 Forwarding n 3
institution.
country code
22 Point of service a 3 PIN/PAN entry mode.
entry mode Format PPN where PP=Pos
entry mode and N=PIN
entry mode.
23 Application a 3 Identifies and differentiates
PAN number cards with the same PAN
24 Network n 3
International
identifier
25 Point of service n 2 Condition under which the
condition code transaction takes place at
POS. Various values.
26 Point of service n 2 Maximum number of PIN
capture code digits supported.
27 Authorizing a 1
identification
response
length
28 Amount, a 8
transaction fee
29 Amount. a 8
settlement fee
30 Amount, n 8
transaction
processing fee
31 Amount, n 8
settlement
processing fee
32 Acquiring a 11 LLVAR Code identifying the
institution acquirer
identification
code
Page 80 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
33 Forwarding n 11 LLVAR
institution
identification
code -- --
34 Primary n 28 LLVAR
account
number,
extended
35 Track 2 data z 37 LLVAR Information encoded on
track 2 of the magstripe
card
36 Track 3 data n 104 LLLVAR
37 Retrieval an 12 Data for matching original
reference txn Julian date+term
number sequence
38 Authorization an 6 Authorization ID assigned
identification by authorizing institution
response
39 Response code an 2 Disposition of message:
Approved, incorrect PIN
etc)
40 Service an 3
restriction code
41 Card acceptor ans 8 Unique code identifying the
terminal terminal at the card
identification acceptor location.
42 Card acceptor ans 15 Code identifying the card
Identification acceptor.
code
43 Card acceptor ans 40 Full terminal address (1-23
name/location address 24-36 City 37-38
State 39-40 Country)
44 Additional an 25 LLVAR Used for P05 referrals,
response data format errors, or VISA
acquired auth responses.
45 Track 1 Data an 76 LLVAR
46 Additional an 999 LLLVAR
data - ISO
47 Additional an 999 ILL VAR
data -
National
48 Additional an 999 LLLVAR
data - Private
49 Currency code, a 3 Code (ISO?) of the local
transaction currency of the acquirer.
50 Currency code, an 3
settlement
Page 81 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
51 Currency code, a 3 Code (ISO?) of the currency
cardholder used for cardholder billing.
billing
52 Personal h 16 Encrypted PIN block
Identification
number data
53 Security n 18
related control
information
54 Additional an 120 Mandatory for txn
amounts response. Contains codes
for account, amount and
currency types and
amounts.
55 ICC CARD ans 999 LLLVAR Chip and Pin specific data
DATA
56 Reserved ISO ans 999 LLLVAR
57 Reserved ans 999 LLLVAR
National
58 Reserved ans 999 LLLVAR
National
59 Reserved for ans 999 LLLVAR
national use
60 Advice/reason an 7 LVAR ICC reason for reversal or
code (private advice.
reserved)
61 Reserved ans 999 LLLVAR
Private
62 Reserved ans 999 LLLVAR
Private
63 Reserved ans 999 LLLVAR
Private
64 Message h 16 MAC check code
authentication
code (MAC)
65 Bit map, h 16 Tertiary bit map indicating
tertiary the presence or absence of
bits in positions 129-192 in
the message being
transmitted.
66 Settlement n 1
code
67 Extended n 2
payment code
68 Receiving n 3
institution
country code
69 Settlement n 3
institution
county code
Page 82 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
70 Network n 3 Network processing info.
management Various 3digit codes for
Information sign on and off, keychange,
code cutover, handshake etc
71 Message n 4
number
72 Message n 4
number, last
73 Date, Action n 6 yymmdd
74 Credits, n 10
number __________
75 Credits, n 10
reversal
number
76 Debits, number n 10
77 Debits, n 10
reversal
number
78 Transfer n 10
number
79 Transfer, n 10
reversal
number
80 Inquiries n 10
number
81 Authorizations, n 10
number
62 Credits, n 12
processing fee
amount
83 Credits, n 12
transaction fee
amount
84 Debits, n 12
processing fee
amount
SS Debits, n 12
transaction fee
amount
86 Credits, n 15
amount
87 Credits, n IS
reversal
amount
SS Debits, n IS
amount
89 Debits, n IS
reversal
amount
Page 83 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
90 Original data is 42 Data elements in a reversal
elements identifying the original txn.
These elements are
formatted specifically.
91 File update an 1 Code indicating type of file
code update operation (1=add
2=change 3=delete
4=enquiry)
92 File security n 2
code
93 Response
indicator
94 Service an 7
Indicator
95 Replacement an 42 Actual amounts dispensed
amounts and settled for partial
reversals. If not partial
both amounts are zero.
96 Message an 8 Password to net
security code management and file
Update. Not currently
validated by LINK
97 Amount, net n 16
settlement
98 Payee ans 25
99 Settlement n 11 LLVAR
institution
identification
code
100 Receiving a 11 LLVAR
Institution
identification
code
101 File name ans 17 Name of file being accessed
for a file update.
102 Account ans 28 LLVAR Identifies the 'from'
identification 1 account in a transfer
103 Account ans 28 LLVAR
identification 2
104 Transaction ans 100 LLVAR
description
105 Reserved for ans 999 LLLVAR
ISO use
106 Reserved for am 999 LLLVAR
ISO use
107 Reserved for ans 999 LLLVAR
ISO use
108 Reserved for ans 999 LLLVAR
ISO use
Page 84 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
ISO use
113 Authorizing n 11 LLVAR Institution approving or
agent denying the transaction.
institution id
code
122 Reserved for ans 999 LLLVAR
private use
123 Reserved for ans 999 LLLVAR
private use
124 Info Text am 255 LLLVAR For file updates,
cardholder
file maint data, for admin
advices the first 255 bytes
in error.
125 Network ans 50 LLLVAR Additional net
management management info: 1-16
information working key,17-20 check
value, 21-50 spaces
126 Issuer trace id ans 6 LLLVAR Used by issuer to label the
txn with his own
transaction id. Unique
within business day.
Unchanged through
transaction life.
127 Reserved for ans 999 LLLVAR
private use
128 Message h 16 MAC check code
Authentication
code
Page 85 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
EMV ¨ Chip and Pin specific data ¨ DE 55 breakdown
E.2 ICC System Related Data Field 66
Field 55 is an LLL VAR field comprising Header and Data Fields.
Request Format
- DIjPcnnit Tag IV Comment -
- -
Header 1 ICC Implementation Name 4(a11) = M Value = AGNS
EBCDIC in EBCDIC character set
Header 2 ICC Implementation Version 2b(I1) - M Value: 0001x
Number
Data I ARQC 8b(an) 9F26 M Application Request
CIYP4togran
Data 2 Issuer Application Data 32b 9F10 M Note
LLVAR
IAD 11 Length 11)(n) = 14 Sub field 1
IAD 12 Derivation Key Index lb(n) - M Sub field 2
(AD 13 Cryptogram Version Number 1b(n) = M Sub field 3
IAD 14 Card Verification Results 4b(an) = M Sub field 4
Data 3 Unpredictable Number 4b(n) 9F37 M
Data 4 Application Transaction Counter 21)(n) 9F36 M
Data 5 Terminal Verification Results 5b(an) 95 M
Data 6 Transaction Date 3b(n) 9A M YVAIMDD
Data 7 Transaction Type 113(n) 9C M
Data 8 Amount, Authorised 6b(n) 9F02 M
Data 9 , Transaction Currency Code 2b(n) 5F2A M Man
Data 10 Terminal Country Code 2b(n) 9F1A M Onno
Data 11 Application Interchange Profile 2b(an) 82 M
Data 12 Amount, Other 6b(n) 9F03 PA Ahvays zero f AMEX issuer
Data 13 Application PAN sequence Number lb(n) 5F34 M
Data 14 Cryptogram information data 114n) 9F27 M
Data 15 Reserved for Future Use = b 0 Reserved data area, to
take
LL VAR the maximum total length up
to the defined length of 255
_ bYtes-
Page 86 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Appendix C ¨ Merchant POS Certification ¨ EMV - PCI
Purpose
This document has been designed by Canadian Acquirers and Payment Brands in
order
to clarify the EMV device compliance process for merchants with integrated
Point of
Sale (POS) systems. Merchants with integrated POS systems and those who own
their
POS hardware are responsible, along with their AcquirerNalue Added Reseller
(VAR),
to ensure that their POS systems are fully EMV compliant. Merchants who rent
or lease
their POS terminals may contact their payment service provider to confirm that
EMV
device compliance requirements may be addressed by the equipment vendor,
Acquirer
or VAR providing the equipment.
This document is targeted at merchants with integrated POS systems. The
objective of
this document is to provide key personnel such as payment experts and project
management resources with a basic level of understanding regarding the EMV
compliance processes across all payment brands. This document is not intended
to
replace any other documents supplied by Acquirers or VARs. Merchants may
contact
their Acquirer for proprietary requirements.
Introduction
Around the world, countries are migrating from magnetic stripe technology to
EMV chip
technology to support card payments.
As Canada migrates to EMV chip from magnetic stripe, integrated merchants may
be
required to upgrade their point of sale solutions to support this new
technology.
The EMV compliance process comprises several stages.
First, the equipment itself may be Type Approved to satisfy EMV requirements.
Next the
payment application software may be validated. Each payment brand may have its
own
terminal application software requirements that need to be met.
After hardware and software validation, the connection between the POS
terminal and
the Acquirer may be validated.
Lastly, the entire chain for transactions may be confirmed. Integrated
merchants may be
required to participate in the application software and the merchant-acquirer
connection
validation phases.
Page 87 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Page 88 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
compliance requires the participation of the terminal manufacturer, Payment
Brands and
Acquirer.
Page 92 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
One Inc.
Universal Recognition
SECTION - Central Processing Platform
Page 93 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Central Processing Platform
One Inc. ¨ Central Processing Platform
One Inc. as part of its Universal Recognition services to Merchants, Loyalty
and Access
partners including individual Customers, may provide a Central platform, where
transaction processing, file serving, database content analysis and Web based
services
are offered.
The One Inc. Platform is an interoperable and versatile platform supporting
the
Enrolment, Processing and Secure File transfer services offered to protect and
process
the Customer and partner data in a compliant and secure environment. The One
Inc.
platform has three major functions;
= Web Services and Authentication
= Real Time Transaction Processing and Linkage Routing
= Secure File Transfers
The One Inc. Central Application Server Hub is a system within the Internet
Cloud
utilizing Universal Resource Locator addresses (URLs). The protection through
the
cloud is a Virtual Private Network for Merchants and Partners and SSL
encrypted web
pages for the Customers.
This Internet and VPN connectivity option would enable a Merchant's POS,
Server or
Access to connect and send messages in order to perform Universal recognition.
The platform features Web Sites at One Inc. or Partner locations accessing web
services which enable individual Customers to enroll and maintain their
information.
The system is available 24x7 supported by firewalls, load balancers, alternate
routing,
guaranteed delivery and encryption devices bolstered by failover, monitoring
and alert
systems housed within a PCI secure data center.
Partners include Merchants, Loyalty Programs, Card Associations and any
organization
requiring the use of One Inc. Universal Recognition services.
The open and interoperable design of the platform permits clients such as
Health Clubs,
Museums and Art Galleries to exchange messages with the One Inc. Application
Platform in an ISO compliant or configurable format.
Page 94 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
The Platform has the capability to initiate or respond to messages in real
time within
industry standard guidelines.
Customers may be able to create or update their information on the One Inc.
website.
The messages generated may trigger the functionality for enrollment in the One
Inc.
program, address changes, updating of Customer demographic data and linkages
to
participating programs offered by One Inc. partners.
Page 95 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Example Transaction Types
Merchant POS - Recognition
This transaction is initiated when a Customer presents the Merchant with a
card at the
POS during a Purchase checkout process. The Merchant's POS sends a message to
the One Inc. Central processing Hub which performs the following;
- Receive the message, and extract the relevant data, including the
Customer's
card number, the Merchant and Terminal ID.
- Look up the Customer Profile Data with the Customer's card number.
- Look up the Merchant Profile with the Merchant's ID and Terminal ID.
- Look for a Program Id in the Customer's Profile that matches a Program Id
in
the Merchant's Profile. (Program Id could be Loyalty Program).
- If a match is found then respond to the Merchant's POS with the
Customer's
Account number in that Program. Otherwise respond with a "not found"
response message.
Note: The Customer's Card number in this case, could be any card that is
linked to the
Customer's Profile including the One Inc. card or a Payment Card.
Page 102 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Enrollment in a Program at POS
This transaction occurs if a Customer is not recognized in a Program sponsored
by a
Merchant.
The Merchant's POS sends an enrollment message to One Inc. with the Program
Identifier and the Customer's Card number.
The Central Application Hub Server may:
- Retrieve the Customer's Profile based on the Card Number.
- Depending on the Program, either forward the enrolment Request message
with the relevant Customer information to the Partner hosting the Program
and forward the response from the Partner onto the POS;
- Optionally, One Inc. could perform the enrollment process on behalf of
the
Partner and advise the Partner hosting the Program at a later point in time.
- On successful completion, the One Inc. Platform may store the
Customer's
newly assigned number and add that Program to the Customer's One Inc.
Profile.
Page 103 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Purchase at POS
This transaction occurs when a Customer purchases product at a Merchant and
presents a Card. The Recognition transaction is forwarded to One Inc. with the
encrypted Card Number.
The Central Application Hub Server may:
- Retrieve the Customer Profile based on the Card Number.
- If the Customer is enrolled with One Inc., The One Inc. platform may
match the Merchant to the appropriate Loyalty Program or Partner.
- If a matching Program between Merchant and Customer is found then,
depending on the Partner hosting the Program, One Inc. may send the
Purchase transaction to the Partner for fulfillment, (e.g. Loyalty Points
issuance, Balance Inquiry, or Redemption). Or One Inc. may perform the
Partner's transaction and advise the Partner at a later time.
Page 104 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Example Partner Initiated Transactions:
Customer Profile Update
A One Inc. Partner Hosting a Program may send a Customer Profile update
transaction
to One Inc., where the Central Application Processing Hub may perform the
following;
(e.g. Cancellation of the Partner Program Card Number for a Customer, and
replace
with a new number)
- Receive the message, parse it and extract the Customer data.
- Update the Customer's record in the One Inc. database.
Page 105 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
File Transfer Batch Transactions
Partners may initiate Secure File Transfers to the Central Application Hub
Server
containing Customer Profile Updates similar to the Real Time Transaction
Types.
One Inc. may transfer files to a Partner, containing Customer Enrollment and
Profile
update data relevant to that Partner.
Page 106 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Data Dictionary
Data Item Description
Acctld Account Id is an internal number that groups related
Card Holders into a single Account in the One Inc.
system.
CardHolderld Card Holder Identifier is an Internal number that
uniquely
identifies an individual registered with the One Inc.
system.
OneCardNum This is the One Inc. number of a Physical (Card, FOB)
medium assigned to an individual registered with the One
Inc. system.
CardStatus This is the Status of a Card, could be 'A'ctive,'
l'nActive ,
'C'ancelled, 'Lost/Stolen
PymtCardNum Payment Card Number, normally this would be a Credit
or Debit Card linked to an individual subscribed to the
One Inc. system. This data is Encrypted.
LoyaltyPGMId Loyalty Program Id is an internal number representing a
Loyalty Program partnered with One Inc.
LoyaltyPointsBal Loyalty Points Balance of an individual's account at a
Loyalty Program.
Merchld Merchant Id is an internal number representing a
Merchant partnered with One Inc.
Storeld Store Id is a number assigned to a Merchant Location,
this number is provided by the Merchant's systems.
Terminalld Terminal Id is a number assigned to a Merchant's POS
(Point of Service) device; this number is provided by the
Merchant's systems.
CardRangeStart Card Number Range start number, this is a One Inc.
assigned BIN start number for a range assigned to a
Merchant and or Loyalty partner.
CardRangeEnd Card Number Range end number, this is a One Inc.
assigned BIN end number for a range assigned to a
Page 108 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Merchant and or Loyalty partner.
Region Region represents a Geographical location that a
Merchant Location is in.
LoyaltyCardNum Loyalty Card Number is a number assigned to an
individual by the Loyalty Program Provider.
AccessPolicy Access Policy, is a representation that determines
whether an individual has access to a specific Merchant
Location (Store and Terminal).
CardHolderName Name of the individual subscriber to One Inc. system.
CardHolderStreetNum Address Street Number of the individual subscribed to
One Inc.
CardHolderStreetName Address Street Name of the individual subscribed to
One
Inc.
CardHolderSuiteNum Address Suite Number of the individual subscribed to
One Inc.
CardHolderCity Address City or Town of the individual subscribed to
One
Inc.
CardHolderProvState Address Province or State of the individual subscribed
to
One Inc.
CardHolderCountry Address Country of the individual subscribed to One
Inc.
CardHolderGender Gender of the individual subscribed to One Inc.
CardHolderBirthYear Birth Year of the individual subscribed to One Inc.
CardHolderAnnualIncome Annual Income of the individual subscribed to One
Inc.
CardHolderWebPassword Encrypted One Inc. website password of an individual.
_
CardHolderSecretQuestionl A question to be asked to the Card Holder to unlock
PIN
and or password.
Page 109 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
Card HolderSecretAnswerl Answer to CardHolderSecretQuestionl.
CardHolderSecretQuestion2 A question to be asked to the CardHolder to unlock
PIN
and or password.
CardHolderSecretAnswer2 Answer to CardHolderSecretQuestion2.
CardHolderSecretQuestion3 A question to be asked to the CardHolder TO unlock
PIN ¨
and or password.
CardHolderSecretAnswer3 Answer to CardHolderSecretQuestion3.
One Inc.CardPINOffset One Inc. Card PIN offset, this is a PIN Verification
Value
(Checksum) assigned to the OneCard.
MerchName Merchant Name
MerchLocStreetNum Merchant Location Street Number
MerchLocStreetName Merchant Location Street Address
MerchLocCity Merchant Location City
MerchLocProvState Merchant Location Province or State
MerchLocCountry Merchant Location Country
MerchLocRegion Merchant Location Region
MerchLocPOSInfo Merchant Location POS Information, Model, vendor,
PINPAD model etc ...
LoyaltyPGMName Loyalty Program Name
LoyaltyPGMStreetNum Loyalty Program Street Number
LoyaltyPGMStreetName Loyalty Program Street Address
LoyaltyPGMCity Loyalty Program City
LoyaltyPGMProvState Loyalty Program Province or State
LoyaltyPGMCountry Loyalty Program Country
Page 110 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
LoyaltyPGMRegion Loyalty Program Region
TransID Transaction ID is an internal number to uniquely
identify a
transaction in the One Inc. system.
TransType Transaction Type could be the following; Loyalty Points
Inquiry, Loyalty Points Redemption, User Authentication,
User Access Request.
TransDate Transaction Date and Time (UTC).
TransAmount Transaction Amount.
TransCurrency Transaction Currency
TransMerchld TransAction MerchantId
TransStorelD TransAction Merchant Store Id.
TransTerminalld Transaction Terminal Id.
TransCardNum Transaction Card Number (Encrypted) .
TransEntryMode Transaction Card Entry Mode, MagStripe, Proximity,
Manual, Chip
TransChipData Transaction Chip Data.
TransUserAuthMode Transaction User Authentication Mode, None, PIN,
Password, Signature.
TransLoyaltyPGMID Transaction Loyalty Program ID, if Trans type was
Loyalty based.
TransLoyaltyCardNum Transaction Loyalty Card / Account Number, if the Trans
was Loyalty based.
TransLoyaltyAmount Transaction Loyalty Amount, if the Trans was Loyalty
based.
REC_CREATE DT Record Create Date and Time stamp for every record in a-
database entity.
Page 111 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
REC CHANGE DT Record
Change Date and Time stamp for every record in
a database entity.
Page 112 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Example Transmission Protocol
The transmission between the One Inc. Application Server and all external
partners may be over the Internet using TCP/IP. The communication channel
may be secured by using either SSL, IPSec tunnel, or in some cases where the
partner is generating large volumes of messages and transactions, then a
dedicated VPN tunnel.
The internal Network of the One Inc. Web and Application Services Server may
be a private LAN behind firewalls with SSL (Secure Socket Layer) encryption to
comply with Payment Card Industry security standards.
Example Database Security Protocol
All sensitive customer data may be encrypted while stored in the One Inc.
database and decrypted as required. Data Security processes may comply with
established industry standards and guidelines. The encryption keys may be
secured and managed as per established industry standards. (Please refer to
the
Encryption Section for further details).
Page 114 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Secure File Transfer Standard
The SFTP standard was developed by the IETF (Internet Engineering Task
Force) as an extension of the second version of the SSH (Secure Shell
Protocol)
in order to be compatible with a myriad of other protocols as well as provide
users with secure file transfer capability. This specialized file transfer
policy has
become the gold standard in the file transferring protocol field in terms of
excellence in service, security, safety, added intuitiveness, ease of use, and
versatility, especially when considering the fact that it's quite usable with
other
protocols too.
The IETF claims that although SFTP is defined in the SSH2 protocol's context,
it's a standard that's actually independent from the rest of the SSH2 protocol
suite (so it's not limited by the SSH2's own concepts and definitions) and is
even
a lot more universal to boot. Because it can virtually be used with most other
existing protocols, it can be applied into a multitude of purposes and
functions,
which may include the transfer of management information in VPN applications
and secure file transfer over TLS (Transport Layer Security).
Whenever you open an SFTP application, you may be required to enter the
name of the SFTP host you want to visit as well as your password and
username. All the authorized members of a given SFTP (a company's staff and
crew or a university's student body and faculty, for example) can download and
exchange files via either the WinSCP SFTP client for Windows PCs or the
MacSFTP client for Macintosh machines.
SFTP assumes by default that it is running on a private and secure channel
(e.g., SSH) wherein the server is authorized and deemed legitimate by the
client.
Moreover, the identity of the client user is accessible to the protocol. Also,
the
graphical equivalent of the SFTP client further abridges and streamlines the
file
transfer process by enabling you to deliver files via the tried-and-true drag
and
drop functions of your mouse; that is, just like in any standard propriety
operating
system, you can now access, copy, move, or paste files between windows using
SFTP.
Each partner may be asked to provide the public encryption transmission key;
this may be saved on One Inc.'s Server, which may then allow the partner's
system to login to the One Inc. Server.
The partner's access to the One Inc. server may be limited to writing a new
file,
they may not be able to delete, read, or overwrite any existing files.
Page 116 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
SECTION - Data Classification and Encryption
(11
,. Inc.
Page 117 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Data and Encryption Overview
There are a significant number of regulations in effect worldwide that relate
to
protection of private and sensitive data. Some are focused on protection of
specific industry information, where others are more concerned with proper
disclosure of data loss incidents and general privacy attributes.
Most of today's standards and compliance regulations are concerned largely
with
the protection of private data at rest, during transactions, and while it
traverses
network connections. Some of these regulations make specific recommendations
or require particular technologies for compliance. For all of them, however,
encryption can be employed to satisfy the protection requirements.
Encryption is the conversion of data into a form, called a ciphertext. Data in
this form cannot be easily understood by unauthorized people. Decryption
is the process of converting encrypted data back into its original form, so it
can be understood.
In order to easily recover the contents of an encrypted signal, the correct
decryption key may be required.
The key is an algorithm that undoes the work of the encryption algorithm.
Alternatively, a computer can be used in an attempt to break the cipher.
The more complex the encryption algorithm, the more difficult it becomes
to eavesdrop on the communications without access to the key.
Strong encryption is an industry term which describes ciphers that are
essentially unbreakable without the decryption keys.
By determining what data you are required to protect, locating the data at
rest
and in transit, and implementing the appropriate encryption technologies, you
can significantly improve your overall security posture while complying with
any
number of data privacy regulations.
The following pages describe the types of data under regulation and describe
example practices for implementing appropriate encryption technologies.
Page 118 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Data Classification
Although there are many distinct types of data of importance to regulators,
most
of them fall into several broad categories:
= Financial data:
The types of financial data are numerous, but commonly include credit card
account numbers and tracking data, bank account numbers and associated
financial information, and a variety of credit-related data on individuals and
businesses. Several regulatory standards, particularly Sarbanes-Oxley in the
Unites States, are concerned with reporting financial data for public
companies.
= Personal health data:
Sensitive patient health data can include insurance related data, actual
medical
information, and personal data about patients, such as social insurance
numbers,
addresses, and other sensitive information, which may not be publicly
available.
= Private individual data:
Such data includes social insurance numbers, addresses and phone numbers,
and other personally identifiable data that could potentially be used for
identity
theft and other illicit activity.
= Military and government data:
Data specific to government programs, particularly those related to military
departments and operations is carefully regulated.
= Confidential/sensitive business data:
Data that has to be kept secret including trade secrets, research and business
intelligence data, management reports, customer information, sales data, etc.
falls into this category.
Data at rest is data that is commonly located on desktops and laptops, in
databases and on file servers. In addition, subsets of data can often be found
in
log files, application files, configuration files, and many other places.
Page 119 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Cryptographic Keys
Cryptographic Keys are strings of bits that are used during the encryption
and/or
decryption process, according to the protocol being employed.
= Keys are measured in length of bits; the longer the keys, the better
security they provide.
= Cryptographic keys are analogous to the keys that secure a lock on a
door. Compromising these keys can have significant consequences on
any cryptosystem.
= These keys are usually stored in a Host Security Module, or as
cryptograms (encrypted keys) in a Host's database.
A key cryptogram is the result of encrypting a clear key value, in other
words,
producing a ciphertext block
Page 121 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Key Life Cycle
Key Life Cycle Events
In order to manage keys, it is critical to first understand the life cycle of
a key.
The life cycle for symmetrical keys may differ from that of asymmetrical keys,
as
symmetrical schemes only use one key, opposed to asymmetrical schemes
which use both a public and a private key pair.
The following essential events form part of the key's life cycle:
Key Generation
= Initial creation of the key
Key Distribution
= Since the key may not necessarily be used within the same system
where it had been generated, it has to be distributed to other systems.
For symmetric keys this is always the case, since the key may be
communicated to at least one other point.
Key Loading
= Once the key has been distributed to the systems that may use it, it may
be loaded. In some cases this is achieved by manually loading/entering
the key into a hardware security module
Key Backup
= It might be a requirement to also backup the key into a secure
environment
Key Usage
= This is where the key may be used in cryptographic algorithms as part of
a
solution.
Key Storage Environment
= While the key is not in use, it may be stored securely. A key can be
stored
on a normal storage medium, or on a cryptographic token, like a smart
card or Hardware Security Module
Key Archive
= Once the key has been decommissioned and is no longer in use, it could
be archived for future reference.
Key Destruction
= A key is deleted or physically destroyed
Page 122 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition - Example Master File Key
The MASTER FILE KEY is a symmetric key, also known as Local Master Key
(LMK), and may be used to encrypt other cryptographic keys which are to be
stored outside of the Hardware Security Module (1-ISM). It is also sometimes
called the Issuer Master Key (IMK)
This is the most significant key in the One Inc. cryptography
scheme as it secures every key in the cryptosystem. It may be
created, entered, audited and controlled as detailed in the Key
Ceremony described in this document.
= The Master Key may be created of triple length to ensure the best
strength
and durability.
= This may be the first key created and entered into the HSM
= For management purposes, if using redundant HSMs, it is recommended
that the same MFK be loaded into all of them. This may ensure
consistency between the hardware devices (uptime and failover
considerations in a Real Time transactional environment).
= Typically the designated Key Custodians for this key type are people
close
to the IT and/or information security departments. These are people that
are closely related to the HSM.
= HSM's are hardware modules that can fail like any other hardware device,
and so the Key Custodians may be readily available to re-create the MFK
in the case of an emergency so as to limit the impact to the production.
Page 123 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Example Key Encryption Key
The KEY ENCRYPTION KEY (KEK) may be used for the secure transport and
storage of other cryptographic keys
= The KEK may be used as a wrapper to ensure that keys are not
compromised during the transport process from one party to another.
= This may be a shared key that is exchanged between two parties using
the Key Custodian method (described on later in this document)
= Once this key is successfully exchanged, it may be used for exchanging
new keys securely in an automated fashion.
Page 124 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Example Base Derivation Key
The BASE DERIVATION KEY (BDK) is used when dynamic generation of new
keys are required. Key derivation allows for the recipient of data to re-
generate
the same key using transaction data and a previously shared key (BDK).
DUKPT ¨ Pronounced "duckput" ¨ Derived Unique Key Per Transaction - is an
encryption standard that is recognized as one secure way of performing debit
transactions
= Some encryption protocols, like the one employed in DUKPT, generate
new keys dynamically
= In DUKPT, a new key is generated by the sender for every transaction,
making it virtually impossible for anyone to attempt to decipher the
information in transit, or even break the key. Dynamic Key Exchange
= Some protocols allow for a new key to be generated every (n) transaction
or every (n) seconds, but the new key may be exchanged securely with
the other party before it can be used. This exchange process may take a
few seconds to complete, and therefore is not suitable for a one key per
transaction protocol like DUKPT.
= The BDK may be shared either via the Key Custodian method, or in the
case of PIN Pad devices, it may be injected into the device prior to being
deployed. On the recipient's side, this BDK may also be installed in order
for the derivation procedure to work.
Page 125 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Example PIN Verification Key
The PIN Verification Key (PVK) may be the result of encrypting the last 12
positions of the Primary Account Number ('PAN') under a key producing a
"natural Pin".
= A 'natural PIN' may be derived and associated with each valid card
number
= The PVK may be static so that for any given PAN, the same natural PIN
may always be calculated
= The HSM calculates the difference between the customer's selected PIN
and the card's natural PIN
= This difference ¨ known as the PIN offset ¨ may be placed on your card
database for subsequent PIN checks.
Page 126 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Example PIN Block
A PIN Block is a cryptogram of a customer-entered PIN during the transaction
initiation process.
= A transaction can be entered at an ATM or at a POS device using a PIN
Pad
= The customer selected PIN is formatted, according to the standard being
employed, then it is encrypted using the 3DES or AES algorithm
= This formatting and encrypting of the PIN produces a 64 bit block of
data.
= This PIN block travels with the transaction and may be verified by the
issuing host in order to continue with the transaction authorization
process.
Page 127 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Data Encryption Standard - DES
Data Encryption Algorithm is a standard used for encrypting data, in which a
private key is shared between one or more parties.
= This key may be used, according to the protocol, to encrypt and decrypt
the information being exchanged.
= The process of sharing the keys is called key exchange, and may be
performed in a very secure manner to prevent key compromise.
Page 128 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Key Exchange
A key exchange is the process of two parties exchanging keys in a secure
manner
= The same keys are used by both parties in order to enable them to
understand the ciphertext being exchanged
= the keys remain secret during the exchange process
= The most common method is the key custodian method, in which key
custodians in each of the organizations is tasked with generating (or
entering) the secret keys into the HSM ¨ Key Ceremony
= Two or more key parts may be generated (typically three parts), and
distributed to two or more key custodians on both organizations.
= This method has proven to be the most secure method as no single
custodian in either organization knows the entire key
= These key parts may be combined at both organizations by their
respective key custodians in order to make up the one secret key required
by the cryptosystem
Page 129 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Example Key Ceremony
One Inc. has a standard for Strong Encryption that may use a 3 part Key. Many
organizations employ 2 part keys and we can accommodate that process:
One Inc. Example Key Ceremony
= Key Custodian 1 for One Inc generates key part 1 using an HSM and
records it. It is recommended that at least a double-length key is
generated.
= Key Custodian 2 for One Inc. generates key part 2 using the same HSM
and records the key.
= Key Custodian 3 for One Inc., generates key part 3 using the same HSM
and records the key.
= Key Custodian 1 for One Inc. sends a copy of key part 1 (Secure
transmission method) to Key Custodian 1 in organization B. Traditionally,
they can be sent in a tamper resistant container using certified mail or
bonded Couriers.
= Key Custodian 2 for One Inc. sends a copy of key part 2 to Key Custodian
2 in organization B.
= Key Custodian 3 for One Inc. sends a copy of key part 3 to Key Custodian
3 in organization B.
= In an audited key entering ceremony, Key Custodian 1 in One Inc. enters
the HSM room, and inputs Part 1 of the key. It is recommended that Key
Custodians 1, 2 and 3 may never enter the HSM room at the same time.
= Key Custodian 1 may record the check digits returned by the HSM.
= In the same audited key entering ceremony, Key Custodian 2, in One Inc.
enters the HSM room, and enters Part 2 of the key. Key Custodian 2 may
record the check digits returned by the HSM for his/her key part.
Page 130 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
= The last custodian participating in the audited key entering ceremony,
Key
Custodian 3, in One Inc. enters the HSM room, and enters Part 3 of the
key. Key Custodian 3 may record the check digits returned by the HSM
for his/her key part. At this point, the HSM may return an 'overall' check
digit value which may also be record by Key Custodian 3.
= In a similar ceremony, Key Custodians 1, 2 and 3 in organization B may
perform the same procedures.
= At the end of the ceremony, the Key Custodians 3 may compare the
overall check digits to ensure that all key parts were entered correctly. If
the overall check digits do not match, this is an indication that one or more
parts were keyed in incorrectly when they were entered into the HSM. If
this is the case, the key custodians may compare the check digits for their
respective keys to identify where the problem might be.
Page 131 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition - Example Cryptography Options
Two example options available for generation and control of One
Inc keys are:
= In-house Cryptography
= Outsourced Cryptography
Page 132 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
CHIP CARD Keys (EMV)
DOW ¨ Dynamic Card Verification value (Visa term)
Description
The DCW is a master key used in the derivation of chip specific unique derived
keys (UDKs) that are used for the authentication of transactions made by that
card. One DCW is generated for the IIN under which One Inc. issues cards.
The keys are double length.
Generation
DCW keys are generated by custodians using the One Inc. key generation
facility.
Storage
Two copies of each DCW are retained after generation and conveyance in clear
component form.
Page 135 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Issuer Private Key
Description
The Issuer private key is used to sign Integrated Chip Card (ICC) public keys
that
are unique to each chip. This signature may later be verified by terminals
processing financial transactions to authenticate the ICC public key. One
Issuer
private key is generated as One Inc. has one IIN. The keys may initially be
1152 bits long and may be replaced every two years (standard banking
practice).
The size of the replacement key may upgraded as the Payment Networks
increase their CA private key length
Generation
Issuer private keys are usually generated by the Service Bureaus (G&D,
Oberthur and Gemalto are the market leaders) and may be securely stored in
their HSM devices.
Payment Systems Environment
In order to have a One Inc. chip card recognized by terminals, an application
ID,
issuer public and chip and terminal software may be created or modified to
establish a Payment System Environment (PSE) and a Proximity Payment
System Environment for contactless transactions (PPSE).
Page 136 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Issuer Public Key
Description
The Issuer public key is used to verify card specific ICC public keys by
terminals
processing financial transactions. The Issuer public key is signed by the
Payment Network CA private key to create the Issuer public key certificate.
One
Issuer public key is generated for each IIN for One Inc.
Generation
Issuer private keys are usually generated by the Service Bureaus (G&D,
Oberthur and Gemalto are the market leaders) and may be securely stored in
their HSM devices.
Storage
Once the Payment Network has signed each Issuer public key, the certificates
are stored One Inc. A copy is also retained by the Service Bureau producing
the
cards.
Conveyance
Once generated by the Service Bureau, Public Keys are sent to One Inc. One
Inc. then sends the keys to the Payment Network. Once the Payment Network
has signed the keys they may be returned to One Inc. in the form of an Issuer
Public Key Certificate which may then be sent to the Service Bureau via secure
courier.
Page 137 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Example Fields on the traditional Payment Chip.
In the table below, the Cardholder available data is presented
Name EMV Tag Max M/O Description - CARDMEMBER DATA
Identifier Length PERSONALIZATION
Application 9F42 02 Optional Indicates the currency in which the
Currency Code account is managed. This is Optional
but
becomes mandatory if Cumulative Total
Transaction Amount checking is used
Application 5F25 03 Mandatory The date from which the Chip
application
Effective Date is activated
Application 5F24 03 Date AFTER which the Chip application
Expiration date Mandatory expires
Application 5A 08 Mandatory One Inc. Card Number
Primary
Account
Number (PAN)
Application 5F34 01 Mandatory Identifies and differentiates Chip
Primary (Applications) with the same PAN
Account
Number (PAN)
Sequence
Number
Cardholder 5F20 26 Optional Indicates the Cardholder Name
according
name to (IS07813).
Cardholder 9FOB Optional In case the Cardholder Name exceeds
Name the 26 characters defined for 5F20.
Extended
Service Code 5F30 02 Optional This is the Service code as defined
on the
mag stripe Track 1 and Track 2 . This is
(also included) in the "Track 2 Equivalent
Data" - tag 57, ** Note** Some issuers
use this Service code to identify
contactiess transactions i.e. - It is
different from the Magstripe service
code
Track 1 9F1F variable Optional Discretionary Data associated
with Track
Discretionary 1 on the Magstripe
data
Track 2 9F20 variable Optional Discretionary Data associated
with
¨ I -
Discretionary Track 2 on the Magstripe. Does not
data seem to be required - Verify with test
team
Verify with Service Bureau - Do they
need any additional cardmember data?
Page 139 of 166

CA 02779774 2012-05-30
ONE INC. ¨ UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Example Data Authentication
Two mechanisms used to ensure that the authorization for a transaction is not
vulnerable to fraud are the CAM and the CVM.
CAM, or Card Authentication Method, is the way that the POS checks if the card
is
cloned and valid.
The CVM or Cardholder Verification Method comprises the smartcard verifying
that
the PIN typed on the POS by the payer is the correct PIN.
There are three types of offline Data Authentication that can be performed,
but the
method to be used depends on the capabilities of the card and terminal. Online-
only
terminals are not required to support data authentication, but all other
terminals may
support both SDA and DDA and may also support CDA.
SDA - Static Data Authentication of the card data (e.g. account number and
expiry
date) to verify that it has not been modified.
DDA - Dynamic Data Authentication of card and terminal data to verify that the
card
application and data are genuine.
CDA - Combined DDA and Application Cryptogram Generation.
Page 140 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Static Data Authentication
STATIC DATA AUTHENTICATION
Key Points ¨
Static Data Authentication is a form of offline authentication in which the
terminal
validates a fixed signature over data elements held within the card to confirm
the
legitimacy of critical chip resident data identified by the AFL and the Static
Data
Authentication Tag List.
This method of authentication detects unauthorized alteration of data on the
chip after
personalization.
During SDA, the Chip is passive and the Terminal is active.
The Chip provides the data to be validated, but the Terminal carries out all
the
computation
The same data and signature is used for every transaction. Hence the term
'Static'
No secret key is stored on card, unlike DDA; hence authentication is done
purely on
the signed data.
The risk is that the chip can be cloned.
One Inc. recommends that the Merchants work with their OEM's to ensure that
their terminals are DDA capable.
Page 141 of 166

ONE INC. - UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Example Static Data Verification Steps
Issuer (Certification Aathonty)
Acqutrer )
Dmlibused te
xy:tte Key Pubbc Key Pek,-..7.te Kiey
Public lioy iltespies m Ten:4a*
St Ps kA PCA
=
c\i
c\i
Cim:r...54-2,
0
r-
r-
C
IC Card
IC Talmital
-4 catnumikatitua Waimea IC Cord aad
Taman' IP.
Card provides to tertroital
- 1 %rs Pt;,, wirify that tba Inures. Pl
-P,mated by Cettifscatiou. Amin*
tt-as cestlfiet! try the C A
-Cant clata talghtlagstal 5goature
- 1%v. P, - ttlt tha dotal aignature
alba card data
Page 142 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Example Dynamic Data Authentication
DYNAMIC DATA AUTHENTICATION ¨ DDA
Key Points ¨
Each chip is equipped with a private key and a public key.
The public key is in a public key certificate signed by the issuer.
At transaction time, the chip signs random data with its private key.
The terminal checks the signature and verifies the certficate chain.
Different data used every time (therefore dynamic).
In order to support CDA, the chip may be required to be RSA capable (needs
additional hardware in the form of a crypto processor).
Definition
RSA is an algorithm for public-key cryptography that is based on the presumed
difficulty of factoring large integers, the factoring problem. RSA stands for
Ron Rivest,
Adi Shamir and Leonard Adleman, who first publicly described it in 1978. A
user of
RSA creates and then publishes the product of two large prime numbers, along
with
an auxiliary value, as their public key.
Page 143 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Combined Data Authentication ¨ Future
COMBINED DATA AUTHENTICATION (ON THE FUTURE ROADMAP)
CDA comprises a dynamic signature generated by the ICC (similar to DDA but
including Application Cryptogram (AC) generation) followed by verification of
the
signature by the terminal.
It is applicable to both the first and second GENERATE AC commands and may
require the retrieval of the relevant public keys
Since the public keys are not required until the CDA signature is verified as
part of
processing the response to the first GENERATE AC, retrieval of the public keys
may
happen any time before verifying the CDA signature
During retrieval of the public keys, errors may result in CDA failure (TVR bit
for 'CDA
failed' is set to 1). These errors include but are not limited to failure of
public key
retrieval and invalid format of records to be authenticated
There are no known implementations of this type of authorization but it is
designed to
prevent a "man in the middle" type of attack.
Page 145 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Example Hardware Security Modules
A hardware security module (often abbreviated to HSM) is a type of secure
crypt
processor targeted at managing digital keys, accelerating crypto processes in
terms of
digital signings/second and for providing strong authentication to access
critical keys
for server applications.
These modules are physical devices that traditionally come in the form of a
plug-in
card or an external TCP/IP security device
The goals of an HSM are
= onboard secure generation
= onboard secure storage
= use of cryptographic and sensitive data material,
= Offloading application servers for complete asymmetric and symmetric
cryptography.
HSMs provide both logical and physical protection of these materials from non-
authorized use and potential adversaries. In short, they protect high-value
cryptographic keys.
The cryptographic material handled by most HSMs are asymmetric key pairs (and
certificates) used in public key cryptography. Some HSMs can also handle
symmetric
keys and other arbitrary data.
Major Vendors ¨ Thales, HP AtaIla, SafeNetInc
Page 146 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
One INC. Universal Recognition ¨ Cloud Cryptography
This is an evolving exercise with theories being developed and models
suggested.
The most promising is Homomorphic Encryption
Homomorphic encryption is a form of encryption where a specific algebraic
operation
performed on the plaintext is equivalent to another (possibly different)
algebraic
operation performed on the ciphertext.
Page 147 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
1 Inc.
.,
SECTION - Card and Token Issuance
Page 148 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Card and Token Issuance - Introduction
The One Inc. Universal Recognition program allows for the recognition of the
Customer using the
One Inc. number at various touch points.
The program is capable of recognizing a variety of form factors in the
contact, contactless (RFID) and
mobile (NEC) environments.
Recognition of a customer ensures that the unique identity of the individual
enrolled in the One Inc.
program may be recognized by the Merchant or Access partner in order to ensure
that the individual
possessing the One Inc. token is eligible for the services offered by that
particular establishment.
Page 149 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Example Steps for production of Cards and Tokens
1). Customer Enrolment
2). Customer Verification
3). Customer Confirmation / Rejection
4). Customer and Form Factor Data Creation (Embossing Files)
5). Form Factor Personalization
6). Form Factor Production and Distribution
7). Form Factor Activation, Usage
8). Reissue and Replacement
Page 150 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Important concepts in Issuance and Enablement of Cards and Tokens
Personalization
The Cardholder Data may be taken from the Cardholder database and sent to a
card production
facility via a secure and encrypted process. Once here, the physical card
itself can be created. In the
case of a pre-existing Mobile device, the Personalization is done via Over the
Air Provisioning (OTA)
where the data is sent through a Trusted Secure Management system directly to
the chip on the
mobile device. .
Embossing
In a Payment environment, Embossing files are usually batch files prepared by
the Issuer Bank with
assistance from the processor and the Card Network and sent to the Service
Bureau for Magnetic
Stripe and Chip Card Issuance.
** This file contains the Personal Identifiable Information and Cryptography
necessary for the
production, mailing and usage of cards (and PINs (if required))**
As a non-financial Issuer One Inc. may not require the involvement of the
processor, however, ISO
standards may need to be followed for the form factor to be used in a shared
Payment Environment.
There are also ISO standards defined for Access Cards and Tokens.
Provisioning
The terminology means "providing something". In the case of cards and chips,
cardholder and
security data is provided in order to accomplish the function of the card or
token.
In Mobile devices, the provisioning is done "Over the Air" (OTA). In the case
of a phone, applications,
data and instructions (lock, unlock, reset) can be sent from the issuer
directly to the device or the
customer can request the same..
Page 152 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Contactless and Mobile Chips
Contactless Cards and Mobile Phones share similar Chip Technology but are
updated and
maintained by different methods. These chips are called Dual Interface chips.
A Dual Interface chip is created and provisioned to Operate in a both a
Contact and Contactless
mode.
Contact ¨ Card is inserted into POS or ATM and parameters can actually be
updated via Scripts sent
from the Processor (Pin required) or Card can be swiped in "fallback" mode.
Contactless ¨ Card or Mobile phone is waved or brought into the proximity area
of a Paywave,
Expresspay or Paypass terminal reader.
It is important to note that there are a few parametric differences between
provisioning the Contact
and Contactless "sides" of the Chip.
Contactless tokens
Contactless tokens form a logical connection to the client computer but do not
require a physical
connection. These keychain tokens or fobs are a popular choice for keyless
entry systems and
electronic payment solutions.
Page 155 of 166

ONE INC. - UNIVERSAL RECOGNITION
Comparison between Magnetic Stripe and Chips
Magnetic Stripe Chip
Magnetic stripe holds basic information about the ), Chip is capable of
storing large
Card member. amounts of data
securely.
= Typically swiped through
a terminal to begin a > Remains in the terminal throughout the
transaction. transaction and
exchanges information with the
terminal.
0
1.)
Can be launched with either PIN or signature as
Signature required for cardholder verification, the method for
cardholder verification.
1.)
0
More secure alternative to magnetic stripe
1.)
0
= Vulnerable to
counterfeit, lost or stolen, and card when used in card-present
transactions.
card not present types of fraud.
0
Embedded computer chip is very difficult to copy.
= Information on magnetic stripe can be easily copied.
Can facilitate additional payment and non-
= Facilitates standard
payment transactions. payment applications (e.g., loyalty programs).
Page 156 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Dual Interface and Hybrid Chips
Two additional categories of cards are dual-interface cards and hybrid cards.
A hybrid card has two chips, one with a contact interface and one with a
contactless interface. The
two chips are not interconnected.
A dual-interface card has a single chip with both contact and contactless
interfaces. With dual-
interface cards, it is possible to access the same chip using either a contact
or contactless interface
with a very high level of security.
The chips used in all of these cards fall into two categories as well:
microcontroller chips and
memory chips. A memory chip is like a small floppy disk with optional
security. Memory chips are
less expensive than microcontrollers but with a corresponding decrease in data
management
security. Cards that use memory chips depend on the security of the card
reader for processing and
are ideal for situations that require low or medium security.
A microcontroller chip can add, delete, and otherwise manipulate information
in its memory. A
microcontroller is like a miniature computer, with an input/output port,
operating system, and hard
disk. Smart cards with an embedded microcontroller have the unique ability to
store large amounts
of data, carry out their own on-card functions (e.g., encryption and digital
signatures) and interact
intelligently with a smart card reader.
Page 157 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Enablement ¨ Chip Cards
Enablement
When a chip is manufactured it does not belong to an issuer and as a
consequence is not configured to
process application loading and deleting. The chip has a unique ID, its
Carrier Device (CD) ID, and a set
of chip specific symmetric transport keys. The chip is said to be in protected
state.
When an issuer purchases chips and wishes to deploy them, they may first be
enabled. This binds the
chip irrevocably to the issuer and allows the issuer only to load and delete
applications.
Enablement Data
The main elements of enablement data may comprise:
= Issuer ID
= Carrier Device (CD) Number
= Product ID
= Communications settings
= Public Key Certificate
The Issuer ID may one of the most important data elements updated during
enablement. During
loads and deletes it may be one of the first elements checked. If the
certificate does not contain
the same value, the load or delete may not take place.
Prior to enablement the chip is identified by the CD ID, but after it is the
CD Number that is
used. This may be important as it may play a role in confidential loads.
The Product ID allows issuers to segregate their card base as they see fit.
This value can also
be used to target certificates at particular products. For example, a gold
card program cardholder
may have access to a special loyalty application. If all gold cards have the
same product ID (or
share a range of ID), then a load certificate can be created that would only
allow those chips to
load the application.
For a contact interface the communication settings are held in the Answer-To-
Reset (ATR) value.
Here the chip announces its preferred transport protocol(s), communications
speed and other
information. Once set at enablement this can not be changed at all during the
lifetime of the
chip.
Page 161 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Another important change that takes place at enablement is the replacing of
the symmetric
transport keys by an asymmetric key pair. The chip's public key is made
available in a certified
format and that key is used during confidential loads.
Enablement Data ¨ encryption
Each card has its own unique set of symmetric transport keys. The key values
are derived from
the chip's CD ID. When enablement data for a chip is generated the KMA system
derives the CD
specific keys and encrypts all the data. Only the target CD can decrypt it and
use it.
Enablement Data ¨ How it is obtained
Enablement data may be requested from the Key Management Authority (KMA) of
the Chip
Manufacturer (e.g. MULTOS)
Page 162 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Embossing File Data
File Data
Record ID - "H" ¨ Indicates that it's a Batch Header Record
File Type - Major Urgency Indicator (Daily, Cycle or Fast)
Date - MMDDYY
Timestamp - Timestamp when the file was generated
Client Number - Client Number used to identify the Issuer (One Inc.)
Request Type - New, Special, Replacement (Depends on Card Product
Decision)
Photo Indicator - Not generally used on Payment Cards but could be used
for Identity Cards
CRV Indicator - If the Card is participating in the CARD RECEIPT
VERIFICATION (CRV)
VISA / MC Ind - Card payment Network Type (Visa / MasterCard)
# Of Applications - Number of applications running on the ICC (Integrated
Circuit Chip).
Pin Data
Pin - PIN encrypted under the PIN ENCRYPTION KEY (PEK) ¨ usually
the
responsibility of Issuer ¨ ISO 4 ¨ 12 digits
PIN Message - Pin Message printed on the Card
Carrier. If
Canada Post, hold for 2 days. If courier sometimes Card and PIN are sent
together
Mailer Indicator - Pin Mailer or No
Pin Message Date - PIN date usually pulled from file date and formatted as
"DD/MM/YYYY" ¨
Service Bureau dependent - Gemalto example
Page 163 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Encryption Key Details
UDK ¨MAC - Unique Message Authentication Code Key - UDK may be
encrypted with
the appropriate Zone Master Keys (ZMK)
UDK ¨ENC - Unique Data Encipherment Key - UDK may be encrypted with the
appropriate Zone Master Keys (ZMK)
UDK ¨AUTH - Unique DEA (ARQC / ARPC) Key - UDK may be encrypted with the
appropriate Zone Master Keys (ZMK)
Production and Delivery Details
Account (Card) Number - The number that may be embossed on the card
Account Identifier - Unique Identifier created when the Cardholder's
application is
approved. It may be the same for Primary, Co-Applicant and
Authorized users. The value never changes throughout the Life
Cycle of the account.
Delivery Codes - Hold Code, Postal Mail, Postal Mail without hold,
Courier
Language Code - Language Preference Indicator
Region Code - Cardholder Geographic region (Residence)
Mailer Details
Credit limit - The Account's Credit Limit. Format is usually whole
dollars,
right justified, zero filled. Message printed based on Language
Code
Card Holder Name - Cardholder's Name printed on the card mailer.
Address Lines 1 - 5 - Cardholder's mailing address
Mailer Message 1-6 - Pin Mailer Messages
Return Address 1 -2 - Return Address
Page 164 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Embossing Details
Embossing Line 1 - Account Number
Embossing Line 2 - Expiry Date
Embossing Line 3 - Cardholder Name (26 digit limitation)
Embossing Line 4 - Based on CARD ID options. E.g. Business Name (limit
of 26
digits)
Deboss Line 1 - Information printed on the signature panel on the
back of the
card ¨ CVV (note Amex CVV is on the front)
Coercivity - Mag Stripe production based on Card ID options . 4
= low
usually
Encoding Track 1 - Data to be encoded on Track 1
Encoding Track 2 - Usually, Account Number, Expiry Date, Service Code
Page 165 of 166

CA 02779774 2012-05-30
ONE INC. - UNIVERSAL RECOGNITION
Matrix of Example Card Technologies and approximate costs
. _________________ :
1 Relative
Data ' Cost of ' Relative
Card Technology Drawbacks Advantages
Storage finished
Security
cards"
I Cost $ 0.36
Bar-Code 104 bits Read-only, Durability, No
average clone-able Security
372 bit Read-only, 7% Infant
s No
Magnetic-Stripe Mortality, Reader Life, Cost $ 0.38
2 tracks Security
Clone-able
2
up 000
Read-Write
to ,
Smart Contact- its Data storage is limited Capability, $ 0.80
Medium
b
Memory Durability Security
Read-Write &
up to Computing
Smart Contact-CPU Cost 1.25
512,000 bits I Capability, $
SeHighcurity
I lDurability, Security,
l Storage
Read-only, High Cost of
No
R.F.I.D. - Prox 36 bits cards, readers and I Durability $
2.60
1 Security
' terminals, clone-able i
R.F.I.D. - IS01443
lup to 64,000 High Cost of cards, l Read-Write
' LOW
Capability,
I bits readers and terminals I, Durability
$ 3.50 ill Security
Page 166 of 166

CA 02779774 2012-05-30
0 /
POS Card Number Capture and Encryption

CA 02779774 2012-05-30
Executive Summary
Merchant Point of Sale integration is a key aspect of having the One Inc.
token and
Payment Card recognized.
Merchant systems are comprised of two distinct components which communicate
and
pass data between each other. The two components are the Main POS and the
Payment Systems.
The Main POS system is responsible for the checkout and Loyalty functions.
Some well
known vendors are Squirrel, Jonas Group, Beanstream and Sweda.
The Payment System acquires Payment transactions from the Payment Terminals
(pinpads) and transmit the encrypted data directly to the Acquirer or via the
Main host
Merchant switch to the Acquirer.
Companies such as AJB Software and Tender Retail perform POS environment
integration in order to ensure communications between the two systems.
One Inc. Universal Recognition aims to minimize the time the customer spends
in the
checkout lane during the recognition process.
Merchant changes required:
= Payment System needs to accept the One Inc. Encryption key. We do not
want
to affect the Acquirer Payment Terminal even though most are capable of
accepting secondary keys.
= Payment System must recognize and encrypt card number and pass it to the
Main POS system for transmission to One Inc.. This requires knowledge of the
One Inc. IIN number ranges.
= Payment System must be able to accept the response from One Inc. and
extract
the Loyalty or Pre-paid card number.
= In the event that the Loyalty Number is returned from the Acquirer in the
ISO
response message, the Payment System will be modified to identify and extract
the number for Merchant action
= If there is a Barcode attached to the Payment Card, the Main POS will
recognize
and route the One Inc. number to the One Inc. Platform
4/11/12 One Inc - POS Design - V.03 Page II.

CA 02779774 2012-05-30
POS - Card Number Data Flow - Direct Connect Merchant to One Inc.
The approach of using the Payment Card Capture Terminal for One Inc. cards and
transactions is to limit
the number of Card capture devices at the POS Lane to one device, as well as
limiting PCI-DSS scope to
the Payment driver module where Payment Card Numbers are used as One Inc.
recognition tokens.
Overview
The driver module of the Payment Terminal will perform the Card Capture,
encrypt the Card Number
and provide the encrypted card data to the Main POS module. The POS module
will then perform the
recognition and routing to One Inc. and will receive and interpret the One
Inc. response based upon a
mutually agreed message format.
Detail Data Flow
Customer ¨ Enters or provides a Card (Form Factor) to a Payment Terminal with
Magstripe swipe, a Chip
validation or a NFC (Near Field Communications) tap.
Terminal Driver ¨The driver module of the Card Capture device will perform the
following;
- If the Card Capture is for a Payment transaction, then proceed with the
payment process, while
routing the card information to the Main POS module with the Card Number
encrypted using the
One Inc. public encryption key provided via a secure and audited Key Ceremony.
- If the Card Capture is for Loyalty or Customer recognition, the terminal
driver will encrypt the Card
Number with the One Inc. public encryption key and send that information to
the Main POS
module.
Main POS module ¨ Receives the One Inc. encrypted Card Number and checks the
Recognition and
routing One Inc. module (or device) for the necessary primary or alternate
routing instructions.
Encryption
One Inc.'s encryption best practices requires the use of Public/Private key
pairs. Data encrypted under
a Public Key can only be decrypted by the corresponding Private Key.
The Payment Terminal driver module will be required to store the One Inc.
public key, encrypt captured
Card Numbers under this key and to provide the encrypted Card Number to the
Main POS module. The
main POS module will then access the One Inc. recognition and routing module.
4/16/12 One Inc - POS Design - V.03 Page 13

CA 02779774 2012-05-30
Key Management
The specific process by which the Keys are to be managed are as follows:
A key version identifier along with the encrypted data will be provided by the
to the Main POS module
by the Terminal Driver
One Inc. will then be able to determine which specific key was used to encrypt
the data at that point in
time.
The Key Versioning methodology provides the capability of using multiple keys
when transitioning to a
new key and is a PCI-DSS compliance requirement.
The Terminal Driver module will be required to periodically check for and
refresh the One Inc. public
key and to provide the key version identifier along with the encrypted data to
be passed through the
Main POS.
This pass through ensures Point to Point encryption and the data can only be
decrypted via One Inc. can
appropriate private key.
The card data is NEVER decrypted at any point in the journey from the secure
Payment terminal
environment to the One Inc. PCI compliant zone.
4/16/12 One Inc - POS Design - V.03 Page 1 4

CA 02779774 2012-05-30
Using the existing Payment infrastructure (Ride the Rails)
The approach of "Ride the Rails: is to use the existing payment infrastructure
of the Payment Network or
Processor to recognize and route a Request to One Inc.
The One Inc. response back to the Payment Network or Processor will be
incorporated into the
Payment response message and sent back along the Payment route to the
Merchant.
Overview
The driver module of the Payment Terminal will perform the Payment process as
it does today when
formatting and sending the message to the Acquirer for treatment by the
Payment Network and Issuer's
processor.
The Terminal Driver needs to be enhanced as the additional processing occurs
when it receives the
response from the Payment Network. The Terminal driver would have to parse the
message (bitmap) to
determine if One Inc. response data exists in the response message. The
additional response data
would then be passed on to the Main POS checkout module under the same
encryption process detailed
earlier.
The proposed additional response data from One Inc. is to be placed in ISO
8583 DE427, which is
defined as a Private Use data element.
Detail Data Flow
Customer - Enters or provides a Card (Form Factor) to a Payment Terminal with
Magstripe swipe, a Chip
validation or a NFC (Near Field Communications) tap.
Terminal Driver - The driver module of the Card Capture device performs the
following:
- Sends the transaction to the Acquirer and receives the response as is
done today.
- Parse and check the Response message for additional data from One Inc.
- If additional One Inc. data is found, provide that data in the response
to the Main POS module.
Main POS module - should expect and process the additional One Inc. response
data if it is present in
the response data from the Terminal module.
4/16/12 One Inc - POS Design - V.03 Page 1 6

CA 02779774 2012-05-30
Encryption
The connection between the Payment Network and One Inc. is a on a VPN and the
additional One Inc.
response data does not contain Payment data, hence no further encryption
process is required by the
Terminal driver module. The DE-127 field will contain the customer Loyalty
number corresponding to
the Merchant s Loyalty program.
Key Management
The existing Key Management is not affected and the Payment data never leaves
control of the Payment
Infrastructure.
4/16/12 One Inc - POS Design - V.03 Page 1 7

CA 02779774 2012-05-30
Ride Rails and Branch to One Inc. and Merchant POS - Card Number Data Flow
The approach of Ride the Rails is to use the existing payment Network to send
a message to One Inc. In
this implementation the connection to One Inc. would be a branch from the
Payment Network or
Processor. One Inc. will continue the branch by responding directly to the
Merchant's Host system
based on the Merchant, Terminal and Device Data provided by the Payment
Network or Processor.
The Payment Network or Processor will receive a "Do not wait" response from
One Inc.
The Payment Network or Processor sends the transaction to One Inc., who would
then process it and
provide the One Inc. data directly to the Merchant's Host system.
The Merchant's Host system would be enhanced to recognize the originating POS
and to communicate
the appropriate response on approved payment transactions.
Overview
The driver module of the Payment Terminal will be unaffected and would perform
the Payment process
as it does currently. No additional changes would be required in this
implementation model.
Detail Data Flow
Customer ¨ Enters or provides a Card (Form Factor) to a Payment Terminal with
Magstripe swipe, a Chip
validation or a NFC (Near Field Communications) tap.
Terminal Driver ¨ The driver module of the Card Capture perfroms the
following:
- Sends the transaction to the Acquirer and Payment Network and receives
the response (business as
usual).
Payment Network / Processor ¨ The network would process the transaction as is
today, it would also
send the transaction to One Inc.
Payment Network / Processor - would receive a "Do not wait" signal back from
One Inc. when the direct
merchant route is identified as the return option.
One Inc. ¨ Once a transaction is received from the Payment Network, One Inc.
would perform the
translation and retrieval function and provide the resulting output data in a
message to the Merchant's
Host system.
4/16/12 One Inc - POS Design - V.03 Page 19

CA 02779774 2012-05-30
Merchant Host System ¨ When this system receives a One Inc. message, it should
perform the existing
Loyalty function using the returned Customer number and route the response to
the appropriate end
point.
Main POS module should expect a message from the Merchant's Host system, with
Loyalty and or
additional processing based on the One Inc. message.
Encryption
The connection between the Payment Network and One Inc. and the Merchant host
system are on
Virtual Private Network. The One Inc. message to the Merchant Host system data
does not contain
Payment data, hence no further encryption process is required. It should be
noted that One Inc. has
encryption capability should the need arise.
Key Management
Current Key Management processes are not affected. One Inc. has encryption and
Key exchange
capability should they be required.
4/16/12 One Inc - POS Design - V.03 Page I 10

CA 02779774 2012-05-30
Overview ¨ Cash Payment
In the case when a Customer pays by Cash and also provides a One Card token
(e.g. Card) , the One Inc.
process will continue as per implementations described in this document, the
Main POS module will be
required to process two separate streams of processing a Payment and a One
Inc. stream.
There is also an opportunity for Direct Connect Merchant to One Inc. to accept
the One Inc. token at the
POS therefore bypassing the Card Payment Terminal.
4/16/12 One Inc - POS Design - V.03 Page I 12

CA 02779774 2012-05-30
in
0 c
ONE INC.
SECURE FILE TRANSFER
ARCHITECTURE
AND
PROCESS

CA 02779774 2012-05-30
ONE INC.
SECURE FILE TRANSFER ARCHITECTURE AND PROCESS
INTRODUCTION ...................................................... 3
TRANSMISSION PROTOCOL ............................................. 3
FILE DATA ENCRYPTION .............................................. 5
FILE DATA INTEGRITY ............................................... 6
One Inc Page 2 of 6

CA 02779774 2012-05-30
ONE INC.
SFTP in computing terms refers to the SSH File Transfer Protocol, otherwise
known as the Secure File
Transfer Protocol, which is a network protocol designed to offer file
management, file transfer, and file
access functionality over any dependable data streams or channels. It's also a
vast improvement from its
predecessor, FTP (File Transfer Protocol), which used to be the standard in
file transference between two
computers during the dialup era and before the broadband era.
The SFTP standard was developed by the IETF (Internet Engineering Task Force)
as an extension of the
second version of the SSH (Secure Shell Protocol) in order to be compatible
with a myriad of other
protocols as well as provide users with secure file transfer capability. This
specialized file transfer policy
has become the gold standard in the file transferring protocol field in terms
of excellence in service,
security, safety, added intuitiveness, ease of use, and versatility,
especially when considering the fact that
it's quite usable with other protocols too.
The IETF claims that although SFTP is defined in the SSH2 protocol's context,
it's a standard that's
actually independent from the rest of the SSH2 protocol suite (so it's not
limited by the SSH2's own
concepts and definitions) and is even a lot more universal to boot. Because it
can virtually be used with
most other existing protocols, it can be applied into a multitude of purposes
and functions, which may
include the transfer of management information in VPN applications and secure
file transfer over TLS
(Transport Layer Security).
Whenever you open an SFTP application, you're required to enter the name of
the SFTP host you want
to visit as well as your password and username. All the authorized members of
a given SFTP (a
company's staff and crew or a university's student body and faculty, for
example) can download and
exchange files via either the WinSCP SFTP client for Windows PCs or the
MacSFTP client for Macintosh
machines.
SFTP assumes by default that it is running on a private and secure channel
(e.g., SSH) wherein the
server is authorized and deemed legitimate by the client. Moreover, the
identity of the client user is
accessible to the protocol. Also, the graphical equivalent of the SFTP client
further abridges and
streamlines the file transfer process by enabling you to deliver files via the
tried-and-true drag and drop
functions of your mouse; that is, just like in any standard propriety
operating system, you can now access,
copy, move, or paste files between windows using SFTP.
Each partner will be asked to provide the public encryption transmission key;
this will be saved on
OneInc's Server, which will then allow the partner's system to login to the
OneInc Server.
The partner's access to the OneInc server will be limited to writing a new
file, they will not be able to
delete, read, or overwrite any existing files.
One Inc Page 4 of 6

CA 02779774 2012-05-30
ONE INC.
FILE DATA INTEGRITY
The Integrity of a transmitted file must be assured, this will can be done by
using MD5 checksum method.
Once the transmitter of a file is assured that the file has been transmitted
successfully, must provide a
MD5 checksum hash of the file. This value is not of cryptographic
significance, it only assures that the
receiver of the file can calculate the MD5 hash and verify this with the MD5
provided by the sender, if
those match then the receiver is assured that the intended file was
transferred successfully by the sender.
The following is a brief description of MD5 checksum;
The MD5 hash also known as checksum for a file is a 128-bit value, something
like a fingerprint of the file.
This feature is useful both for comparing the files and their integrity
control.
All hash values share the following properties:
Non-discoverability
Every pair of nonidentical files will translate into a completely different
hash value, even if the two files
differ only by a single bit. Using today's technology, it is not possible to
discover a pair of files that
translate to the same hash value.
Repeatability
Each time a particular file is hashed using the same algorithm, the exact same
hash value will be
produced.
Irreversibility
All hashing algorithms are one-way. Given a checksum value, it is infeasible
to discover the password. In
fact, none of the properties of the original message can be determined given
the checksum value alone.
One Inc Page 6 of 6

CA 02779774 2012-05-30
RTS is designed on industry standard hardware platforms and communication
systems. This makes
interoperability possible between off-the-shelf components from different
sources, eliminating the
need for custom coding to permit coexistence.
RTS runs on a standard Intel "Server" Class platform.
The RTS and the RTS Pathfinder GUI architecture are built around .NET
framework and are written in
C#. It provides user authentication against the Windows active directory and
user access control.
Each user has unique permissions for which screens can be viewed or changed.
RTS is performance tuned for high transaction volumes and maximum availability
and
reliability from the outset. The system is engineered to maximize available
bandwidth,
without impacting payment authorization transactions.
RTS operating on a single server configuration will support a minimum of 300
(three
hundred) transactions per second (TPS). We have completed internal benchmark
testing at
2000 (two thousand) TPS.
RTS is a very scalable architecture. A..113 customers have achieved a 24X7X365
operation
through the use of multiple production RTS Servers in multiple locations
providing for
redundant authorization capability.

CA 02779774 2012-05-30
Redundancy and load balancing can be achieved with several different
approaches. The RTS
production servers can be placed into a single TCP/IP cluster using either
Windows Network Load
Balancing Service or through the use of an external hardware appliance like a
Cisco Content Switch or
BIG IP. All stores would connect to one IP address at your corporate office.
The load balancing device
would automatically load balance the TCP/IP connections between the multiple
RTS Production
Servers. As store connection messages from the stores are received, the load
balancing device would
determine which RTS gets the next connection.
The RTS systems can be installed in the same site or between two physical
locations.
RTS provides for full replication of applicable data between the RTS systems.
AJB strives to provide its customers with solutions that function in a "lights
out" fashion. The
underlying criteria have always been that the system must function with the
least amount of manual
intervention and only alert users when a problem is detected. In keeping with
this mission statement,
RTS provides user configurable alerting thresholds, and several mechanisms for
generating alerts to
the merchant's support desk personnel including pager, email and NT event log.
RTS uses an "executable" architecture in which each financial processor has an
assigned specific
executable that contains the applicable message format logic. All formatting
is completed for that
processor with the assigned executable. The RTS software uses a bank routing
table to be able to
setup a profile for each store type. Each profile contains a listing of all
supported card types and which
processors they will be sent to. Because each financial processor would have a
unique executable,
when changes are made to one executable, there will not be any impact to other
executables on the
system.
RTS also has a pass-through message format called the "FiPay 300". This
message
structure is used by merchants to define their own message types to service
internal
transaction types with other host bank end applications such as Loyalty, SKU
Locator,
Refund Management and customer lookup. The structure requires a standard
header
format that is used by RTS for routing purposes. The rest of the structure can
be defined by
the merchant and is routed transparently between the POS and backend
processing
interfaces.
RTS includes our Pathfinder network management software. Pathfinder is a user
friendly Graphical
User Interface (GUI) that provides a flexible, easy-to-use method for
defining, accessing, and
managing the RTS and the network. It provides real-time access and into the
status of your network,
stores and financial processor links.
In a dual or multi server RTS configuration, Pathfinder can provide a single
view of both systems.
Pathfinder will update with input from each system. Additionally by double-
clicking on a Node,
Pathfinder will display the log and trace information on the system that the
store is currently
connected to. If a store is in a failed state, it means the store is failed
across all RTS Servers.
RTS Pathfinder provides enhanced monitoring functions to manage your stores
and financial
processors as well as providing enhanced reporting and statistical capability.
The RTS Pathfinder Dashboard tool allows a snapshot view of all current system
status, including TPS
(transactions per second) overall, TPS by specific processor and other key
operational events.
The RTS requires access to Microsoft SQL Server 2005/2008 for reporting, PCI
auditing and
settlement/reconciliation purposes only. RTS does not use SQL for the
authorization function. so if the
SQL database is not available to RTS, there is absolutely no impact on the
authorizations between the
stores, RTS and your financial processors.

CA 02779774 2012-05-30
RTS supports the following application security:
o SSL connectivity from store to RTS
o SSL connectivity from Pathfinder GUI to RTS
o VPN (although inherent to network security) and transparent to AJB
application
o Windows Active Directory for user authentication and permissions
o AES 256 bit encryption which is tied into shared key distribution. No
single user knows the entire
key, only their partial key
o signed files preventing changes to configuration files

CA 02779774 2012-05-30
Universal Recognition Token and Platform (SaaS partner overview)
The Market:
There are several high quality providers of gift / prepaid / loyalty
solutions. These
companies integrate into the retailers (POS / payment terminal) and provide
software as
a service (SaaS) via the 'cloud'. Initially started as gift cards / prepaid
(Stored Value
Solutions - SVS) solutions, they are now expanding into loyalty and other
marketing
services.
These organizations' strengths are the quality of the software solution, the
robustness
of their platform, and quality of service. These services can be provided cost
effectively
and turnkey to the retailer. Additionally, once integrated into a retailer
they are looking
for value add and more ways to upsell the retailer with new products and
services.
Their 'weakness' is that these solutions require a new customer to (I) get and
carry a
new card in order to be recognized (II) fill out an enrollment form either in
store or
online. These two elements pose significant barriers. Retailer must feel
confident that
their customer will accept to carry a new card - not an easy task -and take
the time to
enroll. These barriers are slowing the growth of the providers of SaaS SVS and
loyalty
solution. One Inc's universal recognition platform may eliminate these
barriers.
Registration is key for gift / prepaid cards. Today, customers can use prepaid
(Coffee
Card) with registering. However, this has two significant drawbacks. For the
customer,
if the card is lost ¨they lose all the money on the card ¨just like it is
cash. For the
retailer, an unregistered card means that they get no customer information
contact /
buying behavior that can be used for effective marketing.
The card is not linked to the service.
First take a step back, the card may not be linked to the service. The card
may simply be
a recognition device. The actual service gift / prepaid / loyalty may be
completely
'decoupled' from the card. Once identified, the service provider's system
takes care of
settlement of cash, attribution of points ...so, in fact, the card may simply
be a
'number' or way to identify the customer.
The Opportunity:
Universal Recognition Card (Token) - one is better than many.
The One Universal Recognition Platform may allow providers of gift / prepaid
(SVS) and
loyalty programs the ability to provide their retailers and the final customer
with the
ability to have one card for multiple locations.
So what does One Inc provide? An Interconnect Model:
One inc solution provides an interconnection between various provides that
will allow
for the implementation of a universal recognition token at multiple locations.
This is
similar to Interac allowing one bank card at multiple ATM's or MasterCard
allowing

CA 02779774 2012-05-30
Universal Recognition Token and Platform (SaaS partner overview)
customer to shop at any retailer worldwide.
The interconnect model is based on the following elements
- Universal Recognition card / token(s) that can be accepted at all locations.
- Unique number on every token
- Central real time recognition platform
Universal Recognition Card (Token) - one is better than many.
The starting point may be a card in order to be accepted at ALL locations. The
token
may have the lowest common denominator for technology so that every retailer
may
accept it. For example, this is a card with a mag strip - every retailer has
the ability
either on their POS or payment terminal to read a mag strip. {What about the
phone ..
.see appendix }
Get a new token. Customers who do not hold a one card token may get a new
token
just like they get a new gift / prepaid / loyalty card today at the retailers
point of sale.
The difference is that this token will not be a single store token but the
customer may
be able use it to be recognized at any partner location. These tokens may
branded the
issuing retailer with a 1 logo. For existing customers that already have a non-
one card
they may exchange it at the retailer for a new 1 activate card. Same service
that they
have today, but now with universal recognition.
Use an existing token. Once a customer has a 1 token in their possession they
may not
need to get a new token; they may simply use one that is already in the
wallet.
Third party token issuance: In order to build a membership base and 'park of
One card
tokens, it may be possible to work with third party partner to 'distribute'
tokens to their
customer as a value add ¨ branded ¨ gift. These partners may not be merchants
that
accept the One Inc. universal token, but may issue tokens as a marketing tool.
The idea
is that, by issuing the token, the partner may enhance customer satisfaction
by
providing something of value ¨ that will remain in their wallet. Partners
could be banks
(given to customer of gold bank cards), insurance companies, etc....
Unique Number:
The numbers assigned to the One Inc. universal tokens may be a subset of our
official
BIN number. That way One Inc. may ensure that every number issued is unique.
It may
also allow for 'distributed issuance of numbers. Our interconnect partners may
have a
subset of numbers attributed to them which may allow them to independently
issue
new tokens while ensuring they have a unique number across the coalition.
Universal Recognition Hub
We provide the central hub that may allow customers to use a single token
across

CA 02779774 2012-05-30
Universal Recognition Token and Platform (SaaS partner overview)
multiple retailers - that are not using the same provider (like Interac did
with the banks)
. One Inc. may integrate with the solution providers in order to 'enhance'
their service
offering to the retailers. "Enhance" it by eliminating the need for their
customer to
carry a new card and enroll in a new program. The hub may provide the
following
functionality real time to our partners - and thus their retailers
- New Customer Activation: New (to One Inc. ) / New (to retailer)
- Instant Enroll in new programs: Existing One Inc. members (hold a token) may
instantly enroll in a new program by simply swiping their card. One Inc. may
transmit
the appropriate contact information in their behalf, avoiding the need to
enroll or
register.
- Lost Card replacement: Replace one card, not many
- Update Customer Information: Customer updates once and that information may
be
pushed to all the retail programs that you participate in.
- Change tokens: as new technology arrives (e.g. Smartphone), customer may
seamlessly switch to a new token without having to re register all of their
cards /
programs.
Leverage our partners base.
One Inc. recognition platform may enhance our partners service offering. For
example,
One Inc. may leverage off its partners network for:
- Integration: One Inc. may connect the One Inc. recognition platform to our
partners
SaaS system, which, in turn, connects us to the retailers. This strategy may
allow One
Inc., via this partnership, to provide a universal recognition token to
thousands of
retailers with 'directly' integrating into their POS, as our channel partners
have already
done so. Each new partner integrated may provide the opportunity to instantly
'activate' thousands of new retailers.
- Sales: The Universal recognition token is a value add that may enhance the
service our
partners are already providing. This may be sold as an additional product to
existing
customers or to be used as a key selling feature when pitching new clients.
Thus it is
the partners that (help) sell. As the number of One Inc. tokens in circulation
increases,
this may become a big selling feature for partners.
- Billing: As this is sold though our channel partners, they may bill the
merchants
directly (either as part of the existing service or an additional fee - tbd)
and One Inc.
may share in that revenue stream.

CA 02779774 2012-05-30
Universal Recognition Token and Platform (SaaS partner overview)
Why will the partner loin One Inc. (and not do it on their own) ?
The card is not a strategic advantage - in fact it is a barrier to them
selling - and up
selling - their services.
Why Join.
Their customers may select their solution based on the value of the solution,
not the
fact that they can provide a card. The card is not a strategic advantage. The
retailer
can get all the value of the solution plus without having to 'force' another
card into the
customer wallet.
One Inc. universal solution may also be a preemption against new 'virtual
providers'.
New startups are pitching phone based solutions that do not require a card.
They do
not address the 'all tech' solution of being able to service ALL of a
merchants customer
base ¨ as everyone will not have or want to use a Smartphone. By joining One
Inc., the
providers have a competitive solution to these new 'non card based' providers
of gift /
loyalty programs.
Why not do it on their own?
Beyond Retail. In addition to providing a interconnection to other retail
locations, One
Inc. may expand the recognition platform beyond loyalty to other 'access'
opportunities.
If potential partners go it alone, they cannot provide a token to their
retailers that can
also be used beyond retail for access to museums, health clubs, etc.
Beyond Retail -
In addition to retail, One Inc. may take the same approach - integrating into
channel
partners - in markets beyond retail.
Museums / Galleries: Memberships are another example of a service that need a
recognition token. Similar to gift / loyalty, there are larger SaaS suppliers
of these
solutions to museums / galleries. Working with these suppliers allows you to
get an 'in'
international ticketing companies.
Ticketing: Many venues, transport, etc....have put in place a bar code system
for
tickets. Instead of printing the ticket, customers could attach the ticket to
the One Inc.
card recognition token and use that to enter the event. Many ticketing
supplier are
moving to a semi virtual solution by pushing bar codes via sms or to an app.
An
additional opportunity for the SaaS ticket providers is to connect to the One
Inc.

CA 02779774 2012-05-30
Universal Recognition Token and Platform (SaaS partner overview)
recognition platform and allow their customer to use their One Inc. card as a
ticket.
Health Clubs: Similar to gift / loyalty, there are SaaS providers to the
health / fitness
clubs. One Inc. takes a similar approach to eliminating the need for an
additional card
in the wallet.
Companies providing access systems to ski resorts. For example, the ski pass
is a
contact-less card that provides access at each lift. These cards are not one
time - but
'rechargeable' during the season and season to season. Customers can go
online,
purchase their list ticket (day, week .. ) and 'attach' it to their pass.
There are even
some resorts that have put in place a pay as you go system in which the token
is linked
to a credit card and you are billed for actual usage. This is a big step
forward for the ski
resorts as it reduces lines - and staff - selling tickets and allows for more
sophisticated
direct marketing and optimization of pricing. However for this to work the
customer
may need to have a card issued by the resort.
If One card was integrated into one of these companies, all of their resorts
could offer
this functionality by attaching the ski pass to any One inc universal (contact-
less) token.
The advantages to the resort may be (i) first time customers do not need to
line up to
get a card, they can order tickets in advance and attach to their One card
(ii) eliminate
lost, forgotten (in the other jacket) ..ski card. (iii) automatic photo id.
Passes that are
for more than 2 days require an electronic photo that can be sent directly
from one to
the ski resort (photo is not on the card, but in the system an shows on a
screen ever
time you pass a lift) (iv) Customer data. One Inc. may provide additional
customer data
(name, email, telephone) that the ski resort does not currently receive.

CA 02779774 2012-05-30
Universal Recognition Token and Platform (SaaS partner overview)
Appendix X: What about the phone?
The phone may be a solution in the future but for these services to work they
are based
on a ALL tech solution. The starting point will be a card in order to be
accepted at ALL
locations. It is important to have a token that has the lowest common
denominator for
technology so that every retailer can accept it. For now this is a card with a
mag strip
(every retailer has the ability either on their POS or payment terminal to
read a mag
strip).
So how will One address the smartphone.
One will take an all tech approach to the phone ¨ running 'parallel' options.
There will
(always) be a simple card (mag and maybe enhanced to contact-less). However;
One
will also have implement 'virtual' soltutions.
One App (bar code). One will have a bar code app that will allow members to
have the
same universal recognition token but with a single app. The app will simply be
a 'virtual'
bar code of the one number (that can be scanned). As a customer you can use
one app
instead of having multiple apps ¨ each with a different bar code ¨ that you
need to find,
launch and display on checkout. The challenge with this option is that the
SaaS
providers need to have a solution that can accept a bar code as well as a mag
strip and
the merchants need to have the appropriate hardware, a bar code scanner.
One App (NFC) ¨ When NFC rolls out and sufficient SaaS providers and their
merchants
have the ability to accept this technology, One can seamless 'upgrade'
customer from
their existing One Recognition Token to NFC.

CA 02779774 2012-05-30
The Problem of Recognition
Issuers (collectively defined as loyalty programs, membership to clubs,
transportation pass, car sharing, bike sharing etc.) may require that the
'members' be identified. In order to identify members the issuer may assign a
unique identifier to each member so that each time the member requires access
to the service and benefits they can be identified.
Identifiers
The ideal identifier for an issuer may be one that is universally unique,
permanent and transportable. The most common unique identifier is a new
number issued on a new card. This is the simplest as it ensures that the
number
is unique; however it may require the customer to carry a new card. However,
although the number is unique for that issuer the number is not universally
unique. Other 'alternative' identifiers include the use of email address,
phone
numbers, name, work, etc. but are not optimal because they do not have all the
three criteria of an ideal identifier. For example, a loyalty card number is
unique for the company but may not be universally unique across all loyalty
programs. An email address or phone number is universally unique but may not
be permanent if the user changes work or their provider.
The One Number - The ultimate universal unique identifier
The One number is the optimal identifier for recognition as it is the only
identifier created solely for the purpose of recognition. The one number is
universally unique, permanent and transportable.
The One Universal Token
The one universal token is the ultimate recognition token. It is based on the
universally unique One Number and can take the form, for example, of a card
(mag stripe, bar code, RFID), a Smartphone application, wireless fob ..
The one token may provide the holder with a single token to be recognized at
multiple participating issuers.
How issuers Participate:
Use One numbers. Issuer can request a one number range and use this number
on their tokens. Initially it may work just like an existing loyalty card /
number.
The additional benefit is that the number may be guaranteed to be universally
unique not just unique for the issuer. Thus, in the future, if that issuer
wants to
allow their card to be used at other locations or if the issuer wants to
accept
other issuers' tokens, it is possible without any change to the system or
numbering on their cards.

CA 02779774 2012-05-30
Simple Acceptance: An issuer who wants to accept a universal one token can add
an additional identifier field - the one field - to their system. When a
customer
uses the one token, the system may search on the one field and open their
profile. The rest of the process may be exactly as if they has been identified
with
the issuers token / card / number.
Linked System: An issuer can also be linked to the One Recognition platform
and
can do a real time lookup of any one token. This cloud-based process may have
additional benefits.
Benefits of participating in the one platform may include -
- Interoperability
- Instant Enroll
- Centralized Membership Information Updates
- Switching of tokens
Interoperability -
Current loyalty / membership programs that issue a unique identifier e.g.
loyalty
card / number, may ensure that it is unique for their company. However, they
may not be able to ensure that the number is unique for other programs /
memberships. Thus is it not possible for an issuer to 'partner' with one or
more
issuers allowing members to use one card at multiple locations. E.g. use my
gym
card to get loyalty points at a retail location or vice versa. Since the One
number
is unique, participating locations that accept the one number can allow
members
to use the card at multiple locations as it may be guaranteed to be a unique
identifier across all of those locations.
Instant Enroll -
Enrolment of new members usually requires (i) the creation of a new member
profile (ii) the issuance of a new unique identifier and card (or alternative
token). The One Universal Token may provide for instant membership
enrolment and may eliminate the need for the two steps.
- New member simply 'swipes' their one universal token (mag strip
swipe, bar code read or REID swipe) and a new membership profile
may be created with the one number as the unique identifier.
- One inc. then 'sends' the necessary customer information (name,
address, email ...) to the issuer to complete the profile.
Thus an issuer may secure a new member with one simple swipe of the One
universal token without having to issue a new card nor requiring the customer
to
fill out a new customer profile.
From a customer point of view, they are now part of a new program without
having to carry a new card or fill out any forms.

CA 02779774 2012-05-30
Central Update of Customer Information - Master Data Management
In addition to using the one number for recognition, an additional benefit of
the
one number may be to simplify master data management of member identity
information.
Members may be able to update their information profile (address, phone
number, email address...) once, and that information may be pushed out to all
the connected issuers. Since the issuers all use a unique one number to
indentify
the members, this may eliminate any errors in matching the updated customer
information with the correct customer profile in their database.
Switching of Tokens:
The one number is the key to identification, not the token. Thus a member can
seamlessly switch from one form of a token to another. For example they can
change from a card to a Smartphone application. Since there may be no 'data'
associated with the profile - just the one number - the switch may be simple:
just
enter the one number into the new app and the member may have instant access
at all of the one partner locations. This is a simplified and streamlined
process
compared to current applications in the market that store several loyalty /
member car numbers in one application. A change of phone would mean that all
the data of all the members cards would have to be reentered or synchronized.
With the One system, there is only one number, not multiple numbers.

Representative Drawing

Sorry, the representative drawing for patent document number 2779774 was not found.

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
Inactive: IPC expired	2023-01-01
Application Not Reinstated by Deadline	2014-12-23
Inactive: Dead - Application incomplete	2014-12-23
Deemed Abandoned - Failure to Respond to Maintenance Fee Notice	2014-05-30
Deemed Abandoned - Failure to Respond to Notice Requiring a Translation	2013-12-23
Inactive: Cover page published	2013-12-09
Application Published (Open to Public Inspection)	2013-11-30
Inactive: Incomplete	2013-09-23
Inactive: IPC assigned	2012-09-19
Inactive: First IPC assigned	2012-09-19
Filing Requirements Determined Compliant	2012-06-27
Application Received - Regular National	2012-06-27
Reinstatement Requirements Deemed Compliant for All Abandonment Reasons	2012-06-27
Inactive: Filing certificate - No RFE (English)	2012-06-27
Amendment Received - Voluntary Amendment	2012-05-30

Abandonment History

Abandonment Date	Reason	Reinstatement Date
2014-05-30
2013-12-23

Fee History

Fee Type	Anniversary Year	Due Date	Paid Date
Application fee - standard			2012-05-30

Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
ONE INC.

Past Owners on Record
JEFFREY MOSCOE
MARC LAVINE
SACHA DIAB

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.

Filter

Download Selected in PDF format (Zip Archive)

Download Selected as Single PDF

Document Description	Date (yyyy-mm-dd)	Number of pages	Size of Image (KB)
Claims	2013-11-30	1	3
Abstract	2013-11-30	1	3
Cover Page	2013-12-09	1	17
Description	2012-05-30	151	5,089
Description	2012-05-30	56	6,500
Filing Certificate (English)	2012-06-27	1	166
Reminder of maintenance fee due	2014-02-03	1	111
Courtesy - Abandonment Letter (incomplete)	2014-02-17	1	164
Courtesy - Abandonment Letter (Maintenance Fee)	2014-07-25	1	173
Correspondence	2012-06-27	1	55
Correspondence	2012-07-04	1	24
Correspondence	2012-06-27	1	31
Correspondence	2013-09-23	1	44

Language selection

Menus

Event History

Abandonment History

Fee History

Your request is in progress.

Requested information will be available
in a moment.

Thank you for waiting.

Patent 2779774 Summary

Event History

Abandonment History

Fee History

Your request is in progress.Requested information will be availablein a moment.Thank you for waiting.

Your request is in progress.

Requested information will be available
in a moment.

Thank you for waiting.