Language selection

Search

Patent 2384927 Summary

Third-party information liability

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

Claims and Abstract availability

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

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent Application: (11) CA 2384927
(54) English Title: CASH INITIATED SYSTEM FOR PAYING WEB TRANSACTIONS
(54) French Title: SYSTEME DE PAIEMENT AU COMPTANT DES TRANSACTIONS SUR LE WEB
Status: Dead
Bibliographic Data
(51) International Patent Classification (IPC):
  • H04L 12/16 (2006.01)
  • G06Q 20/28 (2012.01)
  • G07F 7/02 (2006.01)
  • G07F 19/00 (2006.01)
(72) Inventors :
  • ESMAIL, IQBAL (Canada)
(73) Owners :
  • ESMAIL, IQBAL (Canada)
(71) Applicants :
  • ESMAIL, IQBAL (Canada)
(74) Agent:
(74) Associate agent:
(45) Issued:
(22) Filed Date: 2002-05-06
(41) Open to Public Inspection: 2003-11-06
Availability of licence: 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 2384927 were not found.

Claims

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

Sorry, the claims for patent document number 2384927 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.


r
CA 02384927 2002-05-06
TEM File No. 246.1
TITLE: CASH INITIATED SYSTEM FOR PAYING WEB TRANSACTIONS
s FIELD OF THE INVENTION
The present invention relates to electronic commerce on the World Wide
Web (referred to herein as the "Web"), generally, and in particular relates to
the
ability to make cash-based payments on the Web.
1o BACKGROUND OF THE INVENTION
The number of e-commerce transactions is increasing dramatically.
Estimated B2B (Business to Business) transactions in 2001 are just under one
trillion US dollars. By the end of 2004, B2B transactions are expected to
reach
2.5 trillion US dollars annually, and up to 4.3 trillion US dollars annually
by 2005.
is Impressive compound growth of 68%, 91 % and 109% is expected for the USA,
Western Europe and Asia-Pacific, respectively, between 200'1 and 2005. B2C
(Business to Consumer) volume in the US has been estimated at just under
US$50 billion for 2001 and growing.
Currently Web payments are made by a handful of established systems,
2o the predominant one being credit cards. There are about a half dozen other
payment systems which enjoy varying degrees of acceptance by Web merchants
and consumers. The sustainability and growth of such other systems and any
future new systems will depend on their ability to achieve broad acceptance by
- 1-

CA 02384927 2002-05-06
merchants and consumers alike. Credit cards, on the other hand, are the
principal choice of merchants as they are the main choice of consumers because
they have been in existence the longest and vast global coverage has been
built
up over the years.
s Some of the above-noted payment systems are briefly set out below,
together with their advantages and disadvantages.
1. Credit Cards: They are the choice of a vast number of merchants and
consumers on the Web, but both eligible merchants and consumers have to
first qualify from the issuing financial institution to be able to deal in
andlor
io use the cards. A large number of merchants and consumer s do not qualify,
and hence they cannot accept or use credit cards. Additionally, many credit
card holders are apprehensive about using credit cards over' the Internet
because of fears and risks of misuse of information.
2. CyberCash: After sending a credit card or bank account number, the
is consumer is issued an "electronic wallet" with an encryption process giving
the consumer the ability to pay a Web merchant. This system requires a
consumer to have means to transfer funds (credit card, bank account or wire
transfer) to CyberCash, which is an intermediary.
3. DigiCash: This system requires a bank to be part of its system for
accepting
zo cash withdrawn from consumers' bank accounts, and uses software to store
this cash in the consumers' computer hard drives for payment to merchants.
-2-

CA 02384927 2002-05-06
This again requires the consumers to first make a deposit to the DigiCash
system via credit card or bank account.
4. eCHARGE and iBill: These systems bill the consumer through a 1-900
phone number and are limited to people owning phones, and as well are
s limited in the number of transactions that can be made over a period.
In sum, most prior art systems require a consumer to be <able to make a
transfer of funds to the "paymasters", or the consumer must have a credit card
or
communication device like a telephone or mobile phone on which charges can
be made. Even so, the consumer has to first be assessed as creditworthy by a
1o phone company in order to take a charge. Credit cards, which have the
highest
e-commerce usage, are prone to fraud by hackers and merchants.
What is therefore desired is a novel method and system which overcomes
the limitations and disadvantages of the existing methods and systems.
is SUMMARY OF THE PRESENT INVENTION
The methods and systems of the present invention, sometimes referred to
herein as the "CIT"" payment system", or "CIT"" system", were developed
because
there are many consumers in the world-wide marketplace that do not have
means of Web payment or credit cards, either because they fail to qualify due
to
2o bad credit, or are minors in law who cannot obtain such cards, or do not
have
access to such cards, or simply do not like to use credit cards tin the Web
because of the fear of insecurity or divulging personal details. There are

CA 02384927 2002-05-06
consumers in the third world who have no payment modes in their regions, but a
common aspect with such consumers is that they have money and access to the
Internet (also referred to as the "Net"), whether they are in the middle of
Africa or
the Amazon jungle. Hence, the present invention puts a system in place that
s takes advantage of existing payment-system infrastructures without the need
to
"reinvent the wheel".
BRIEF DESCRIPTION OF THE DRAWING FIGURES
Embodiments of the invention will now be described, by way of example
so only, with reference to the accompanying drawings, wherein:
Figure 1 depicts a voucher employed in the systems and methods
according to a preferred embodiment of the present invention;
Figure 2a depicts a flow chart of the steps performed in one embodiment
of the method of the present invention;
15 Figure 2b depicts an alternate embodiment of the step:; performed in an
alternate embodiment of the method of the present invention;
Figure 3 shows a sample Web page for a user of the present system; and,
Figure 4 shows a table of the estimated users of the Web by global
regions.
2o
_q_

CA 02384927 2002-05-06
LIST OF REFERENCE NUMBERS IN DRAWINGS
20 - The voucher (or its contents) which is dispensed from a point of sale
(POS)
be it a bank counter, automatic teller machine (ATM), on-line terminal or
other
venue.
s 22 - The identification number of the issuer or seller of the voucher. In
the case
of an ATM or on-line terminal the identification number of the owner of the
ATM
or on-line website.
24 - Three fields, each of numeric, alphabetical and alphanumeric code
respectively.
so 26 - The usable or face value for which the voucher has been purchased.
28 - A barcode embodying information 22 and 24.
30 - The user who purchases the voucher, also referred to as the consumer or
customer
32 - The issuer or seller of the voucher.
is 34 - The system server of the issuer or seller of the voucher
36 - The system server of the CI system
38 - The merchant conducting business over the Internet (or Web)
40 -The payment processor, or sometimes referred to as an acquiring processor,
who is an intermediary enabling settlement of transactions between credit card
ao consumers, their issuing financial institutions and the Internet merchant.
42 - The merchant bank is the bank of the Internet merchant 38
-s-

CA 02384927 2002-05-06
44 -The designated account is the account where the issuer or seller of the
voucher deposits the proceds of the sale of vouchers.
50 - A drop-down box enabling the user 30 to choose the type of currency on
the
voucher
s 52 - The blank boxes allowing for multiple voucher usage
54 - A drop-down box giving the user 30 the option to choose the currency in
which he wishes to have the total displayed.
56 - The key or button to commence processing of the transaction

CA 02384927 2002-05-06
DESCRIPTION OF PREFERRED EMBODIMENTS
The method and system of the present invention is a remote, anonymous,
simple, low-risk, versatile and mutt-market targetable Web-payment system that
has the potential of rivalling the dominance of credit cards. In essence the
s invention provides for a voucher to be purchased for a sum of money (from a
seller) which bears identification (ID) codes. The codes correspond to that
sum
of money, and these ID codes are stored on the CI system server along with its
corresponding sum of money . The CI system server is linked to the servers of
other parties who are part of the CI system. Based on the implementing system,
so anyone able to produce the subject ID codes correctly to the CI system and
its
links can have access to that money, be it for Internet purchases, money
transfers or bill payments. This system can be utilised globally under
multiple-
currency platforms as long as electronic linkages are available. This
provision for
multi-currency payment truly gives the CI system global dimensions in that
1s vouchers in any currency issued in any country can be used for purchasing
in
and from any other country.
OVERVIEW
An overview of the present invention is first presented.
zo At a Point of Sale (POS), a user (also referred to herein as a consumer,
purchaser or customer) intending to transact over the Internet purchases a
voucher 20 (as illustrated in fig.1 ) for any denomination of money 26. The

CA 02384927 2002-05-06
voucher contains thereon an identification number of the POS, or "Issuer" 22,
and preferably three separate fields of numeric, alphabetical and alphanumeric
code 24 and the denominated amount, or "usable value" 26. The data of the
three fields 24 is bar-coded at 28. If the user has a bar-code reader attached
to
s his terminal it provide for easy transcription of code 24 to the merchant's
payment website (described later with reference to Figure 3).
The sale of the voucher 20 to the purchaser is conducted by a human or
automated counter attendant of the issuer receiving the money (by cash,
cheque, bank account, credit card or other) from the purchaser and entering
the
1o required information (to produce a voucher 20 for the amount of money
received)
into the issuer's system network, such as through a keyboard. The voucher is
issued from a printing device which communicates with (i.e. is "connected to")
the issuer's system network.
The issuer's system network is connected to the CI system's server (and
1s identified to the CI system server by its issuer ID no. 22) which generates
the
three codes 24 in fields 1, 2 and 3 and conveys them to the issuer's system to
be
printed on the voucher 20. These codes along with the issuer ID no. are now
inventoried on the CI server and represent the denominated amount or usable
value 26. The same information (codes 24 and monetary value 26) is also
zo inventoried on the issuer's system.
_g_

CA 02384927 2002-05-06
The purchaser of this voucher 20 now has an ability to spend the
denominated amount 26 at the site of any merchant accepting the CI payment
system on its website.
A preferred method of commercially implementing the CI system is to
s licence the CI system to existing Financial Institutions andlor payment
processors (referred to herein collectively as "Fls") that are already issuers
of
credit cards and have an established network of e-commerce merchants.
Hence, unlike some prior art systems, the implementation of the present system
would avoid the effort of signing up merchants from scratch, since such
1o merchant sign-up procedure is resource intensive and time con suming. The
Fls
would in essence use their Information Technology (IT) hardware which is
already in place to connect to the CI system server, and in exchange for money
from a customer would issue to that customer the above-noted voucher bearing
the particulars corresponding to that amount of money. The codes 24 would be
is based on a method of generating random numbers and have three separate
fields of numbers to make fraud and duplication difficult. This voucher can be
purchased over-the-counter at FI locations, at Automated Teller Machines
(ATMs) or through on-line banking for any monetary denomination, with such
codes 24 corresponding to that monetary amount 26. The codes are inventoried
2o on a server which is linked to the Fls system server and now represents a
sum of
money sold to a customer which can be used over the Web for transactions by
means of entering and transmitting the codes on a merchant's website.

CA 02384927 2002-05-06
The amount 26 on the voucher can potentially be spent at any Net
merchant of the FI (i.e. merchants of Fls that are authorized to accept credit
cards over the Net). When the FI opts to be licensed under the CI system, the
FI
will inform its merchants to register for the CI payment system and the FI
will
s send software to the merchants to enable them to accept the CI payment
system. Hence, by licensing the FI, the CI system benefits from an established
network of merchants.
MORE DETAILED EXPLANATION
1o A more detailed example of the CI system of the present invention is now
presented.
1. The method of the present invention is initiated when the coinsumer attends
at an FI's counter (or ATM or on-line terminal ) and proceeds to purchase a
voucher 20 (see fig.1) for, say, $135.00.
is 2. Upon receipt of the $135.00, the FI ~~~~, ~~ r~~~ holds the amount
as a deposit in a designated account and the $135.00 deposit is provided
with a corresponding code 24. With the money in the FI's account, the FI is
now able to meet a payment to a merchant when the customer spends any or
all of the $135.00 amount.
20 3. The code 24 corresponding to the amount of $135.00 is inventoried (i.e.
recorded) on both the CI system server and the FI system server.
- 10-

u~ i
CA 02384927 2002-05-06
4. Once the consumer purchases the voucher, the consumer may then visit a
Web merchant's site (which merchant is signed up already by the FI and onto
the CI system) and makes a purchase for, say, $120.00 by entering the
codes 24 from the voucher on the website (see figure 3) as well as any other
s required details of shipping, under a Secure Sockets Layer (SSL) protocol,
or
like secure means. The accepting merchant's website will already have the
option of choosing the CI payment system. After entering the necessary
details, the consumer submits the transaction for processing by clicking the
"submit" button or key on that website.
5. The SSL protocol encrypts the consumer's submitted data, secures it and
sends it over the Internet to the merchant's website. The payment software in
the merchant's web server sends the encrypted data to a processing centre
used by the issuer FI.
6. The Fls processing centre then communicates the transaction amount figures
is ($120, issuer ID 22 and codes 24) to the CI system server and, if a
sufficient
balance exists, the CI system server debits (I.e. charges) that code 24 (I.e.
account) for $120. If an insufficient or no balance exists, then the CI system
server declines the transaction and the consumer is prompted to check his
balance by being directed via a web link to the CI website. The processing
zo centre then communicates the transaction figures ($120, issuer ID 22 and
codes 24) to the FI that issued the voucher (via the issuer ID number 22) and
deducts the amount of $120.00 (corresponding to the code 24) from the
-11-

CA 02384927 2002-05-06
designated account at the FI where it was deposited. The issuing FI will give
an authorization number.
7. The Web merchant's payment is settled through the existing credit card
payment settlement convention already established between the FI,
s processing centre and the merchant.
8. Regardless of the currency used, at the time of payment settlement the
mechanism in place would deal with the conversions. The method would be
the same as credit cards issued in different currencies.
9. Now, continuing with the above scenario, the consumer has X15.00 left to
his
1o credit under the subject codes 24 (since a voucher for $135.00 was bought
and only $120.00 was spent). The consumer may access the CI system
website and, upon entering his code 24 and issuer ID no. 22, can check the
remaining balance on that voucher.
10.The consumer can spend the remaining $15.00 on a subsequent purchase
is and can also combine additional codes from other vouchers to make a
greater amount. The merchants' CI enabled payment site would allow the
option of multiple codes to be used in combination.
FURTHER EXAMPLES OF THE CI SYSTEM
ao Another example of the present system follows, with specific reference to
the flow chart of fig.2a:
12-

CA 02384927 2002-05-06
Step 1: The consumer 30 attends at a voucher issuer 32, which can be a
bank, an ATM (automatic teller machine), on-line bank or any other designated
location to buy a voucher 20 (as shown in fig.1 ). Except for an on-line
voucher
purchase, the consumer will always be issued a physical voucher. In the case
of
s an online voucher purchase, the consumer will get the required data fields
(codes 24 and issuer ID no. 22) on his terminal screen which may be safely
printed or copied. The consumer pays a desired amount, which is deposited in a
designated account 44 by the voucher issuer 32. The amount paid will
correspond to the code generated in step 3 below. At the different venues
where
1o a voucher can be purchased (eg. Bank, ATM, on-line or other), the consumer
will
use the established operating procedure to obtain the voucher. For instance at
a
bank the consumer will likely interact with a human, convey verbal
instructions,
pay the money (or equivalent value in acceptable form) and receive a voucher.
At an ATM he will likely use his usual means of access to the ATM and follow a
is menu-driven screen to request a voucher which is printed by the ATM while
his
bank account is debited by the value of the voucher. At an on-line terminal
the
consumer will log in using his normal procedure and will seek the voucher-
purchase option whereby he will receive the codes 24, issuer ID no. 22 and
value 26 on-screen to be safely copied or printed. Simultaneously his bank
2o account will be debited by the value of the voucher.
Step 2: At the time of the voucher purchase, the consumer's request is
routed to the issuer's system server 34.
-13-

CA 02384927 2002-05-06
Step 3: The issuer's server 34 connects to the CI server 36. The server 36
generates the random sequence code 24 for the amount of money requested by
the consumer.
Step 4: The CI server 36 inventories this issued code 24 and the issuer ID
s no. 22 with the corresponding monetary value and conveys this data to the
issuer's server 34, which inventories the data in the same manner. This data
will
be accessed later at the time of payment steps 8-11 below.
Step 5: A voucher 20 is then printed bearing this data and other details (as
shown on the sample voucher of fig.1 ) and issued to the consumer 30.
1o Step 6: The consumer 30 visits the Web merchant's site 38, which is
enabled to process transactions via the CI payment system, to purchase the
merchant's product or service at the merchant's selling price. The consumer
enters the data from the voucher according to the required format and submits
the transaction for processing through a secure server, which encrypts this
data.
is One example of a CI payment system Web page the consumer may be
prompted to use when paying at the merchant's site is shown in fig. 3. The
information entered on this site is codes 24, issuer ID no. 22 and amount 26.
A
drop-down box 50 prompts the consumer to choose the type of currency, and in
this example it is the US$. This Web page is designed to accept multiple
2o vouchers 52 in combination made up of any currency 50 in which they are
issued. The consumer simply selects the currency pertaining to the particular
voucher. After all vouchers are entered, the consumer is further prompted to
14-

CA 02384927 2002-05-06
choose the currency in which he wishes to view his total amount 54 (this
currency will most likely be the currency acceptable to the merchant). At that
point all the data pertaining to amount and currency is transmitted to the
payment processor's server where a currency conversion takes place to the
s consumers desired choice of currency and the amount is relayed back to the
consumer. Once the consumer is satisfied with the total amount he presses the
"submit" key 56 on the Web page to process the transaction.
Step 7: The merchant's payment software sends this encrypted data to a
payment processor 40 for authorization.
1o Step 8: The payment processor 40 connects to the CI server 36 to
determine the validity and authenticity of the data. There may be several
vouchers and additionally different voucher issuers so the validity and
authenticity of all is checked.
Step 9: If the data is validated by the CI server 36, then a signal is sent to
is the payment processor 40 to proceed with the transaction. If the data is
not
validated, the transaction is declined by the CI server. Data would result in
non-
validation if any of the information is discrepant such as no funds,
inadequate
funds or non-corresponding fields.
Step 10: If the transaction data is validated, the payment processor 40
zo connects to the issuer's server 34 for authorization. If multiple vouchers
are used
and more than one issuer is noted then all such issuers are contacted for
authorization.
-15-

CA 02384927 2002-05-06
Step 11: The issuer's server 34 will then transmit to the payment processor
40 an authorization number after deducting the requested transaction amount
(i.e. the merchant's selling price or in the case of multiple vouchers the
amount
on the voucher pertaining to the particular issuer) from the designated
account
s 44 in step 1 above.
Step 11 a: Using the authorization number in step 11 above as recorded
evidence the payment processor will debit (charge or reduce) the codes on CI
server 36 for the amount.
Step 12: The payment processor 40 will authorize the transaction to the
1a merchant 38.
Step 13: The merchant 38 ships, digitally conveys or otherwise provides the
goods or services to the consumer 30.
Step 14: The merchant's account is credited at his merchant bank 42.
Step 15: The merchant 38 has access to the cashlfunds at the merchant
is bank 42.
In an alternative embodiment of the GI system shown in fig. 2b, steps 8
and 9 which are described in the fig.2a embodiment above are eliminated and
the process is as follows:
Steps 1-7 are the same as shown above.
zo Steps 8 and 9 are eliminated.
Step 10: The payment processor 40 connects directly to the FI server 34 to
determine the validity and authenticity of the data. Applicant notes that
there
- 16-
~.=~°....~. u,"_...~....,......... ~.-.. _....--.~. ~... ~...--.--.-_~
__._ _~...,- .. _.~.

CA 02384927 2002-05-06
may be several vouchers and additionally different voucher issuers, and so the
validity and authenticity of all vouchers is checked at the various FI servers
which
have issued the different vouchers. If the data is validated by the FI server
34,
then the transaction proceeds and the amount pertaining to codes 24, which is
s held in the designated account 44, is debited (charged or reduced). An
authorization number is generated by the FI server upon debiting the amount.
If
the data is not validated, the transaction is declined by the FI server. Non-
validation would result if any of the information is discrepant such as no
funds,
inadequate funds or non-corresponding fields.
1o Step 11: The issuer's server 34 will then transmit to the payment:
processor 40
the authorization number generated in the preceding step after deducting the
requested transaction amount (i.e. the merchant's selling price or in the case
of
multiple vouchers the amount on the voucher pertaining to the particular
issuer)
from the designated account 44 in step 1 above. The authorization number
is serves as evidence that the voucher has been charged.
Step 11a: Using the authorization number in step 11 above as recorded
evidence the payment processor will debit (charge or reduce) the codes on CI
server 36 for the amount so that the information held at both the FI and CI
server
is the same.
2o Steps 12-15 are the same as shown above.
- 17-

CA 02384927 2002-05-06
GENERAL DISCUSSION
The operation and many advantages of the present invention may now be
better understood, with particular reference to the figures.
Why is this system aimed at Financial Institutions ?
Internet-based payment systems currently require the signing up of Web
merchants. This is an enormous task in terms of resources, finances and time.
However, without Web merchants accepting a system there cannot be
customers using that system of payment and vice versa.
1o The Fls have their established base of credit card merchants who are
already captive and can easily be brought on stream to subscribe to a new form
of payment. They also have an existing mechanism of payment settlement.
Therefore, the CI system merely piggybacks on what is already in place, but it
works for cash-initiated vouchers rather than credit cards.
1s The participating FI receives payment instantaneously and funds are
available for immediate settlement, and so unlike credit cards there is less
risk.
Essentially, then, the FI is always covered for its outstanding voucher
liabilities.
The FI, together with its branches, ATMs and on-line platforms, forms a
huge dispensing arm to CI system customers.
-18-

CA 02384927 2002-05-06
Why would financial institutions be interested in the CI system?
1. The CI system is within the line and range of financial products currently
offered by Fls.
2. The CI system creates a new source of revenue for Fls. Such revenue
s may be derived from:
merchant sign up fees for adopting the CI system option;
merchant monthly fees for using the CI system;
per transaction fee when using the CI system;
percentage fee of transaction value on the CI system equivalent to current
credit
io card regimes;
service fee from the consumer at time of his voucher purchase; and,
currency exchange commissions.
3. The start-up investment should not be significant compared to the
expected volume of transactions as established IT hardware can be used.
1s 4. There should be the prospect of a new customer base to which existing
products could be targeted.
5. The possibility of fraud and loss should be substantially lower using the
CI
system than using credit cards. Unlike credit cards, any fraud would be
limited
only to the amount issued for the voucher, and so would be no more than the
2o risk associated with a person carrying cash.
19-

CA 02384927 2002-05-06
6. Those merchants who do not qualify from their merchant banks for selling
over the Web using credit cards may, nonetheless, be rated as second tier and
qualify for CI system transactions.
7. By adopting the CI system, the Fls should remain revenue-neutral even if
s there were to be substitution between CI system vouchers and credit cards.
Benefits to the owner of the CI system
Revenue may be derived from licensing fees which would be based on a
percentage of gross revenues of the Fls from adopting the CI system.
so Advertising on the CI system's website should be beneficial as the website
would be expected to have numerous hits from consumers visiting to check their
balances.
Unclaimed voucher balances after three months of first using the voucher
could be subject to service charges so as to deplete the unused balances.
Other attributes of the CI system
No prior deposit or prepayment of funds is required.
There is no Personal Identification Number (PIN) to remember.
No user name appears on a voucher nor is it required for a transaction.
2o No swipe cards are employed.
Anyone may use the system as there is no age or other limit on the user.
There are no eligibility or credit checks required, as for credit cards.
-zo-

CA 02384927 2002-05-06
One cannot overspend as usable value on the voucher is set.
No account, whether with a bank or otherwise, need be set up.
No account loading as with other intermediary-based systems.
There is no disclosure of the user's personal information.
s There is no future risk of fraud as the risk is limited to the face value of
the
voucher.
The voucher is transferable, and so may be provided to a third party as a
gift, for instance.
The present system has the potential of global applicability for retail Net
1o commerce (B2C), for money transfers, for B2B commerce, for bill payments to
businesses and utilities, and for payments to governments (fees, licences,
tickets, taxes, fines etc).
Security Issues
is As in any financial system there are security issues to be addressed.
Regarding the CI system, the principal risks are that the consumer could lose
a
voucher, or that someone might try to replicate the codes at a Web merchant's
site. By virtue of its inherent character and make-up, a consumer would likely
have no remedy for a lost voucher, just as there is usually no remedy for lost
zo cash, unless it is found. If a computer "hacker" should try to run the
codes on a
merchant's site, server-based software should be provided to block that
particular code for a time period, say for four hours, and deem it delinquent.
After
-21-

CA 02384927 2002-05-06
four hours the block would be removed and a fresh attempt can be made. The
code would be determined to be delinquent when two of the three fields are
entered as correct with three attempts made to find the third code.
Furthermore
cracking a voucher code would not be a very productive undertaking for a
hacker
s because: each voucher number is different; all three fields have 1:o match;
the
three field must correspond with the issuer ID no.; and, an erroneous
insertion
would block the hacker's attempt for four hours so that the whole exercise
would
be discouraging.
1o Target market of users for the CI system
1. Credit card users
2. People unable to get credit cards
3. The under 18s (minors)
4. Populations in emerging markets e.g. South East Asia, China, India, Latin
is America, Middle East, North and South Africa
5. Businesses
Market potential of the CI system
Aside from the markets of North America, Western Europe and Asia-
zo Pacific, new markets of consumers from less-developed and under-developed
countries may come on stream via the CI system as these countries have
populations with money to spend as well as Net access but no currently
workable
-z2-

CA 02384927 2002-05-06
system of payment. The banking networks in such countries are ideally suited
to
host the system of the present invention. Consumers in those countries would
be able to access Web merchant services, which are of an on-line digital type
but which do not necessarily entail a shipment of goods, such as news
services,
s on-line gambling, adult industry services and many others.
The expected growth may be explosive. Vast populations are expected to
come onto the Net in Asia. China apparently has only about 2% of its current
population on the Net. India only has an estimated 0.5% of its population on
the
Net compared to developed countries in which upwards of 30-60% of the
so population has Net access. The worldwide figure is estimated to be under
9%.
A table showing an estimate of the number of people with Net access as of
August 2001 is shown in fig.4.
The above description is intended in an illustrative rather than a restrictive
sense, and variations to the specific configurations described may be apparent
15 to skilled persons in adapting the present invention to other specific
applications.
Such variations are intended to form part of the present invention insofar as
they
are within the spirit and scope of the claims below. For instance, in another
alternate embodiment of the present invention, the CI system may be employed
in non-FI type outlets. The CI system may also process (as in fig. 3) single
ao vouchers in a single currency rather than multiple vouchers in different
currencies or any combination thereof.
-23-

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

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 , Administrative Status , Maintenance Fee  and Payment History  should be consulted.

Administrative Status

Title Date
Forecasted Issue Date Unavailable
(22) Filed 2002-05-06
(41) Open to Public Inspection 2003-11-06
Dead Application 2005-01-24

Abandonment History

Abandonment Date Reason Reinstatement Date
2004-01-26 FAILURE TO COMPLETE
2004-05-06 FAILURE TO PAY APPLICATION MAINTENANCE FEE

Payment History

Fee Type Anniversary Year Due Date Amount Paid Paid Date
Application Fee $150.00 2002-05-06
Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
ESMAIL, IQBAL
Past Owners on Record
None
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



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

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

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


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Drawings 2002-05-06 5 128
Representative Drawing 2002-11-07 1 19
Cover Page 2003-10-17 1 36
Description 2002-05-06 23 925
Abstract 2003-11-06 1 1
Claims 2003-11-06 1 1
Correspondence 2002-06-14 1 14
Assignment 2002-05-06 2 98
Correspondence 2003-10-23 1 19