|
Safety-Zones®
Providing
the Ways to Information & Identity Theft
Protection*
Safety-Zones
Explained in More Detail
Safety-Zones
simply inserts new controls in the form
of "permission gates" into each account
that are controlled by the account holder.
Each
permission gate is controlled by a "supervisory
instruction". These gates remain open (disconnected)
until the function each serves is satisfied
by information requirements selected by
the account holder during a transaction.
The
supervisory instructions to control each
permission gate for all accounts used by
one individual or corporate entity could
be located in one secure and encrypted
location, such as the account holder's personal
computer digital wallet; other locations
are also possible. The only necessary criteria
is that the instructions be presented in
a form that are quick and easy for the account
holder to change. A PDA with menu selections
communicating with a server would provide
for portable use.
This
means that a simple set of logic functions
can be programmed to permit or deny a request
for use of each account for each transaction;
we call them gatekeepers. The gatekeepers
'ask' a set of simple 'questions' to allow
or deny a bank, credit card, or information
transaction, and this is all done in one
query for each transaction.
What follows is a typical set of gatekeeper
questions asked in one query for one transaction.
But for ease of explanation they are written
separately.
A
is to select How
the transaction is to take place,
either in a store (Brick & Mortar) or over
the Internet, but not in one realm (domain
or division of use) in place of the other.
The transaction controller (electronic transfer
agent corporation responsible for the verifications)
will check this. So how is each valid
account to be used? A typical gatekeeper
query upon request for a Brick & Mortar
selected transaction will be: "Scan to see
if this account number is currently valid
and selected for use in a Brick & Mortar
application, not Internet." If it's not
authorized for a selected Brick & Mortar
application right now, the transaction is
rejected. This instantly prevents unauthorized
use. Having a digital wallet window that
allows the account user to preset account
uses in the realms of Internet or Brick
& Mortar will do this, and will enhance
the goals of the SET and SSL protocols.
When selecting to use Internet we are ensuring
that no Brick & Mortar transaction is authorized
at that time, and vice versa.
B
is to verify that the personal information
that you are providing confirms your identity,
as the transaction provider matches the
information held in their care. Safety-Zones
allows you to place personal information,
known only to you and the transaction provider,
in a secure electronic location on a computer,
PDA, server or other location of your choice.
You can change this personal information
at any time.
Personal
Identification check - Prove to me Who
you are. In more detail:
Current protocols compare account information
to the user's reported information but they
do not verify if the user is actually the
account holder. When you go to the store
to buy something with a credit card you
are usually, but not always, required to
show identification along with your credit
card as proof of identity (a driver's license
is commonly used for verification). But
if someone is really impersonating you s/he
would have a solution to this too.
When
you buy something on the Internet the only
identification that you are currently required
to provide is the name and billing address
of the account holder. This means anyone
who has a copy of your card number, its
expiration date, and your name and address
can transact credit card business in your
name. Many other forms of identity theft
are also possible. (See Links).
To solve these problems we propose some
form of account holder identity matching
as proof. In any electronic protocol involving
the customer this could be done by ensuring
that no transaction is processed, or no
digital certificate is inserted into a cardholder's
electronic wallet as proof of identity,
until some form of proof positive identification
is provided by the actual person named in
the account. There is more discussion on
this subject with a proposed solution under
Proof of Identity.
C
is to select Which
account you intend to use,
for example, which credit card. The transaction
controller (the electronic transfer agent
corporation responsible for the verifications)
will verify this as they do now. Safety-Zones
enables you to choose the account to be
verified.
In more detail: Which card or account
opened in the account holder's name has
the account holder's permission to be used?
A typical gatekeeper query upon request
for a transaction is: "Scan to verify (compare)
that this account number is valid for this
account holder." If it's not, it is rejected,
preventing the use of unauthorized accounts.
To enable this gatekeeper, the account holder
inserts one account number (or a list of
valid account numbers) to use for verification.
The transaction service then checks (compares)
the account number submitted to the valid
account number(s) you have provided, insuring
that an attempt at an unauthorized transaction
is rejected, and that a digital certificate
is not placed in a wrong digital wallet
in the account holder's name. Which,
sorts out bogus accounts by rejecting those
that don't match, and prevents improper
use of valid accounts because they are protected
by this and other functions.
This feature in a mature form could be used
to 'find' thieves and 'close' invalid accounts.
D
is Where the
transaction is to take place.
It can be used for any definable and selectable
location. It can be used for a country code,
like the United States, or for a specific
Area or Zip Code; it could even be used
down to the level of a store code. The transaction
controller can check this by using location
codes. This feature will solve a large part
of the theft problem because many credit
card numbers are stolen in one country and
then used in another.
In more detail: Where is the valid
account to be used? A typical gatekeeper
query upon request for a transaction is:
"Scan to see (compare) if this account number
is valid, and accessible right now in telephone
Area Code 361 (large area-Corpus Christi,
Texas), or Postal Zip 78404 (smaller area-a
section of Corpus Christi)." If it's not,
the transaction is rejected. This prevents
unauthorized use outside of the selected
user boundaries, the safety zone.
For this function to work we need passive
"intelligence" from the retail or business
end of a transaction in the form of some
type of location ID (i.e., Country Code,
telephone Area Code, Zip Code, etc.) to
compare the actual location to the location
selected.
E
is the Financial
Limit of the
transaction. You can set
a 'not to exceed' amount for one purchase
transaction or multiple payment purchases.
The transaction controller can check this.
In more detail: What is the Financial Limit
of this transaction? Or, if more than one
transaction, how many? A typical
gatekeeper query upon request for a transaction
is: "Scan to see if the $ Limit provided
is not exceeded right now.'" If it is exceeded,
the transaction is rejected. This blocks
purchases beyond your unauthorized set limit.
We have all heard of the story about someone
misplacing a decimal point or putting in
the wrong amount; this function will save
you from these errors.
F
is When.
It's simply a 'Go' button.
'Make the transaction right now (because
I just pushed the 'go' button) then turn
off''. Actually this is what some engineers
call a momentary normally-open switch; it
just closes to make the connection then
opens again. The transaction controller
allows a transaction to take place during
a short period of time but only if all the
other 'gates' or conditions are satisfied.
In more detail: When is each valid
account to be used? A typical gatekeeper
query upon request for a transaction is:
"Scan to see if this account number is valid
and all choices or selected functions are
satisfied right now.'" If they are not,
the transaction is rejected. This prevents
unauthorized use during any period of time
that the account holder does not want the
account used. Allowing the account holder
an account "on-off switch" somewhere convenient
would achieve this. A link to the desktop
at specified times would also be acceptable.
Having other forms of account on-off switches,
tethered or wireless, would also be acceptable
provided that they are properly protected
against misuse.
Conclusion
to this Point
This
might seem a little complicated, but by
adding a few more windows in a computer
browser's preferences and expanding the
use of the digital wallet, or a menu on
a PDA, we can provide simple and easy
methods for the account holder to enter
information that defines the use parameters
for each account. How will define
the intended use the account holder enters
under the heading Brick & Mortar or Internet.
Who will prove who you are. Which
will enable an automatic scan of the account
number or codes entered by the account
holder to reject bogus accounts or attempts
at fraudulent use of valid accounts. Where
will be a window that lets the account
holder select which safety zone
(Country, Area Code, Zip Code, retailers,
etc.) that the chosen account can be used
in. How much and how
many will define the financial
limit of the transaction. When
will simply be an on-off switch. And of
course, there can also be a master on-off
switch (controlled by both the provider
and account holder) that bypasses all
of these features, so that users of Safety-Zones
and service providers can continue to
do business as usual until the use of
these features are adopted by both the
service provider and the account holder.
In
both SET2 and SSL protocols
one way to add these permission gates
might be to add them in conjunction with
the digital certificate3
authorizations in the account holder's
'digital wallet'4.
Note 2: SET is a SETCo protocol, and SETCo
is Secure Electronic Transaction LLC 1999,
whose members include Visa, MasterCard
and VeriSign. SSL is Secure Socket Layer,
the most commonly used secure transaction
protocol, but the least protective of
the two when not requiring an exchange
of digital ID's.
Note
3: (From the on-line dictionary at whatis.techtarget.com)
"A
digital certificate is an electronic "credit
card" that establishes your credentials
when doing business or other transactions
on the Web. It is issued by a certification
authority (CA). It contains your name,
a serial number, expiration dates, a copy
of the certificate holder's public key
(used for encrypting messages and digital
signatures), and the digital signature
of the certificate-issuing authority so
that a recipient can verify that the certificate
is real. Some digital certificates conform
to a standard, X.509. Digital certificates
can be kept in registries so that authenticating
users can look up other users' public
keys."
Note
4: A digital wallet is software that stores
a user's personal information (name, address,
credit card number, etc.) so that it can
be recalled when an online or electronic
purchase is desired. One of the
problems with the current digital wallet
system is that many vendors that you have
ordered from have your personal information
stored in a digital wallet in their computer
systems, which multiples the number of
opportunities that your private information
can be stolen or misused.
For the detail oriented - it
is not necessary to know this level of detail
to use Safety-Zones®
Sample
Brick & Mortar (Home Page) User Display
|
B&M
|
Internet
|
Qty
|
1
|
$100.00
|
USA
|
|
-
Safety-Zones®
-
|
On
|
Off
|
Zip
Code
|
Area
Code
|
|
Your Credit Card
|
•
|
.
|
.
|
773
|
|
|
|
|
|
|
|
Your
Gas Station
|
|
|
x
|
.
|
773
|
|
Your
Favorite Store
|
|
|
x
|
.
|
773
|
|
Your
Supermarket
|
•
|
.
|
.
|
773
|
|
Your
Pharmacy
|
.
|
x
|
.
|
773
|
|
Other
|
.
|
x
|
.
|
773
|
|
Safety-Zones®
Process Details for
Using Credit Card(s) Safely in the above
display
|
|
.
|
.
|
Step
2 - Customer-side
|
.
|
Step
1 - Server-side
|
|
.
|
Function
|
Shopper (Account Holder) selects information
from simple menus when ready to purchase
something when shopping
|
Compare
|
Account Holder (Shopper) uses simple
menus to preset and store information
in advance
|
|
A
|
B&M
or Internet? |
Brick
& Mortar (Not Internet) |
Compare
How to: |
B&M
(Not Internet) |
|
B
|
Proof
of Identity |
It's
me - "It's me" |
Compare
ID to: |
It's
me - "It's me" |
|
C
|
Which
CC? |
1234-0000-4567-00001 |
Compare
Which to: |
1234-0000-4567-0000 |
|
D
|
Where? |
Country
|
Area
Code
|
Zip
Code
|
-
|
.
|
Country
|
Area
Code
|
Zip
Code
|
-
|
|
D/E
|
Geo-
Location |
USA
|
733
|
-
|
$Spent
|
Compare
Where to
|
USA
|
733
|
-
|
$Limit
|
|
D/E
|
Your
Gas Station |
"
|
"
|
-
|
$47
|
Your
Gas Station |
"
|
"
|
-
|
$60
|
|
D/E
|
Your
Favorite Store |
"
|
"
|
-
|
$69
|
Your
Favorite Store |
"
|
"
|
-
|
$100
|
|
D/E
|
Your
Supermarket |
"
|
"
|
-
|
$89
|
Your
Supermarket |
"
|
"
|
-
|
$100
|
|
D/E
|
Your
Pharmacy |
"
|
"
|
-
|
$37
|
Your
Pharmacy |
"
|
"
|
-
|
$50
|
|
D/E
|
Other |
"
|
"
|
-
|
$27
|
Other |
"
|
"
|
-
|
$100
|
|
E
|
Financial
Limit? |
$
Actually spent: |
$269
|
Compare
$ Limit to: |
$
Permitted up to: |
$410
|
|
E
|
Quantity
Limit? |
Qty
Limit/Location |
1
|
.
|
Qty
Limit/Location |
1
|
|
F
|
When? |
Now!
(Then disconnect) |
Compare
When to: |
When
I say so! |
| |
|
|
|
|
This
chart shows the presets (Step 1) the
Safety-Zones®
process permits each accountholder (shopper)
to make, that must be met when Brick &
Mortar shopping, for each transaction
to take place. The 'controlling contacts'
to permit or deny a transaction would be most
probably located in the Store-Merchant's payment
gateway.
Note
1:
The actual CC# does not show on the User Display.
Sample
Internet (About Page Exhibit B) User Display
|
B&M
|
Internet
|
.
|
Qty
|
1
|
$45.00
|
USA
|
|
-
Safety-Zones®
-
|
.
|
On
|
Off
|
Zip
Code
|
Area
Code
|
|
Your
Bank
|
1
|
.
|
x
|
02139
|
617
|
|
Your
Credit Card #1
|
2
|
.
|
x
|
02139
|
617
|
|
Your
Credit Card #2
|
4
|
•
|
.
|
02139
|
617
|
|
|
|
|
|
|
|
Barnes
& Nobles
|
8
|
|
|
x
|
10011
|
212
|
|
eBay
|
9
|
|
|
x
|
95125
|
408
|
|
Amazon.com
|
10
|
•
|
.
|
98144
|
206
|
|
Safety-Zones®
Process Details for
Using Credit Card(s) Safely in the above
display
|
|
.
|
.
|
Step
2 - Customer-side
|
.
|
Step
1 - Server-side
|
|
.
|
Function
|
Shopper (Account Holder) selects information
from simple menus when ready to purchase
something when shopping
|
Compare
|
Account Holder (Shopper) uses simple
menus to preset and store information
in advance
|
|
A
|
B&M
or Internet? |
Brick
& Mortar (Not Internet) |
Compare
How to: |
B&M
(Not Internet) |
|
B
|
Proof
of Identity |
It's
me - "It's me" |
Compare
ID to: |
It's
me - "It's me" |
|
C
|
Which
CC? |
1235-0000-5679-0000
(CC#1) |
Compare
Which to: |
1234-0000-5678-0000
(CC#1) |
|
C
|
Which
CC? |
4567-0000-1234-0000
(CC#2) |
Compare
Which to: |
4567-0000-1234-0000
(CC#2) |
|
D
|
From Where? |
Country
|
Area
Code
|
Zip
Code
|
-
|
.
|
Country
|
Area
Code
|
Zip
Code
|
-
|
|
D
|
Geo-
Location |
USA
|
617
|
02139
|
$Spent
|
Compare
Where to
|
USA
|
617
|
02139
|
$Limit
|
|
D
|
To Where? |
Country
|
Area
Code
|
Zip
Code
|
-
|
.
|
Country
|
Area
Code
|
Zip
Code
|
-
|
|
D/E
|
Barnes
& Noble |
USA
|
212
|
10011
|
$35
|
Barnes
& Noble |
USA
|
212
|
10011
|
$50
|
|
D/E
|
eBay |
USA
|
408
|
95125
|
$40
|
eBay |
USA
|
408
|
95125
|
$50
|
|
D/E
|
Amazon.com |
USA
|
206
|
98144
|
$42
|
Amazon.com |
USA
|
206
|
98144
|
$45
|
|
E
|
Financial
Limit? |
$
Actually spent: |
$117
|
Compare
$ Limit to: |
$
Permitted up to: |
$145
|
|
E
|
Quantity
Limit? |
Qty
Limit/Location |
1
|
.
|
Qty
Limit/Location |
1
|
|
F
|
When? |
Now!
(Then disconnect) |
Compare
When to: |
When
I say so! |
| |
|
|
|
|
This
chart shows the presets (Step 1) the
Safety-Zones®
process permits each accountholder (shopper)
to make, that must be met when shopping via
the Internet, for each transaction
to take place. The 'controlling contacts'
to permit or deny a transaction would be most
probably located in the Store-Merchant's payment
gateway.
To
see where the Payment Gateway is located in
the typical purchase and payment process refer to the
chart at Budget-Master.com.
For
chart simplicity the store codes or IP addresses
are not shown because they would not normally
be selected by the user of Safety-Zones®,
although they would be part of the process.
For
fraud protection, when using credit/debit
cards, echecks, etc., Safety-Zones®
would insert a set of contacts or a permission
gate into the Payment Gateway.
For securing Information Processes (medical
records, private documents, voting information,
etc.) against fraud Safety-Zones®
would insert the 'controlling contacts' somewhere
in the 'client/customer' interface.
|