Ex Parte Michelsen

Board of Patent Appeals and Interferences

Jun 16, 2010

10424562 (B.P.A.I. Jun. 16, 2010)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte MICHAEL J. MICHELSEN
____________

Appeal 2009-012890
Application 10/424,562
Technology Center 3600
____________

Decided: June 16, 2010
____________

Before MURRIEL E. CRAWFORD, HUBERT C. LORIN, and
JOSEPH A. FISCHETTI, Administrative Patent Judges.

LORIN, Administrative Patent Judge.

DECISION ON APPEAL
Appeal 2009-012890
Application 10/424,562

2
STATEMENT OF THE CASE
Appellant(s) seek our review under 35 U.S.C. § 134 of the Examiner’s
final decision rejecting claims 1-20. We have jurisdiction over the appeal
under 35 U.S.C. § 6(b).
SUMMARY OF DECISION1
We REVERSE.
THE INVENTION
The Appellant’s invention relates generally to money transfer
transactions. More specifically, the present invention relates to confirming
the validity of identifications presented by persons involved in money
transfers. (Spec. ¶ 0002).
Claim 1 is illustrative:
1. A method of confirming the validity of an identification presented
by an individual in a financial transaction, comprising:
receiving transaction information at a transaction device that is
usable to perform the financial transaction;
based at least in part on the transaction information,
determining the need for identification information;
receiving identification information at the transaction device,
wherein the identification information is obtained from the
identification presented by the individual and the identification
information has a format;
transmitting the identification information to a host computer
system;

1 Our decision will make reference to the Appellant’s Appeal Brief (“App.
Br.,” filed December 18, 2008) and Reply Brief (“Reply Br.,” filed June 1,
2009), and the Examiner’s Non-Final Rejection (“Non-Final Rej.,” mailed
May 15, 2008), Answer (“Ans.,” mailed April 1, 2009) and the Appellant’s
Specification (“Spec.,” filed April 27, 2006).
Appeal 2009-012890
Application 10/424,562

3
at the host computer system and based at least in part on the
format of the identification information, assessing the validity of the
identification presented by the individual from which the
identification information was obtained.

THE REJECTIONS
The Examiner relies upon the following prior art:
US 5,679,938 Templeton Oct. 21, 1997
US 6,330,546 Gopinathan Dec. 11, 2001
US 6,612,488 Suzuki Sep. 2, 2003
US 2003/0056113 Korosec Mar. 20, 2003

The Appellant is appealing the following rejections:
1. Claims 1-6, 9-12, 14-18, and 20 under 35 U.S.C. § 102(b) as anticipated
by Templeton.
2. Claim 8 under 35 U.S.C. § 103(a) as unpatentable over Templeton.
3. Claims 7, 13, and 19 under 35 U.S.C. § 103(a) as unpatentable over
Templeton and Gopinathan.

ISSUE
Does Templeton describe, expressly or inherently, the claim limitation
“based at least in part on the format of [received] identification information,
assessing the validity of the identification presented ...” (claim 1)?

FACTUAL FINDINGS
The Examiner argues that Templeton expressly and inherently
describes the claim limitation “based at least in part on the format of
[received] identification information, assessing the validity of the
Appeal 2009-012890
Application 10/424,562

4
identification presented ...” (claim 1). Answer 4 and 7-8. The Examiner
relied on the following Templeton passages:
• Col. 4, ll. 22-35:
by the merchant at the point of sale. The
authorization host computer analyzes the first
transaction packet and determines whether to elicit
additional information from the transaction
terminal prior to completing the transaction. If
additional information is desirable, the
authorization host computer communicates a
prompt to the transaction terminal. In response to
the receipt of the prompt, the transaction terminal
displays the prompt to the merchant, which enters
the additional information into the terminal. The
transaction terminal then communicates a second
transaction packet, which contains the additional
information, to the authorization host system.
Based on the additional information, the
authorization host computer then determines
whether to authorize or decline the transaction, and
communicates appropriate authorization indicia to
the transaction terminal.

• Col. 4, ll. 56-64:
In the present invention, transaction data is
selected from the group that includes payment
data, identification data, merchant data and product
data. Some transaction data may be received via a
keypad associated with the transaction terminal.
Other types of transaction data may be received by
electronically reading magnetic ink character
recognition (MICR) data from a check, or by
electronically reading identification data from a
magnetic stripe on an identification card.

• Col. 12, ll. 60-64:
Appeal 2009-012890
Application 10/424,562

5
accept real-time check activity. The authorization
host computer also has access to a validation file
95, which includes resources that may be used to
validate information received from the check
writer. Merchant related parameters are provided
in a merchant file 100, and billing files and
transaction logs are maintained in an
administrative file 102.

• Col. 14, ll. 28-43:
In some cases, the authorization host computer will
attempt to validate the data provided prior to
authorizing the transaction. This is accomplished
using the validation file 95. The validation file 95
includes data that has little or no statistical
significance in terms of determining the likelihood
that a check will be bad. However, the validation
file 95 includes other information that may be
indicative that the customer is who he or she
claims to be, and that the check will be collectable.
For example, the check acceptance service may
ask the merchant to provide the customer's home
telephone number and attempt to verify that the
number is billable. This may be accomplished by
checking files available from the telephone
companies. In addition, the customer's mother's
maiden name and state drivers license records, if
available, may be used to confirm data

• Col. 30, ll. 50-53:
algorithm and result in an approved transaction.
For validation, the authorization host computer
may request a variety of information, including
telephone number, social security number,
mother's maiden name, etc.

Appeal 2009-012890
Application 10/424,562

6
ANALYSIS
The Appellant argues that Templeton does not describe assessing the
validity of information based on its format. We agree.
None of the Templeton passages (see supra) relied upon in making
the anticipation rejection describe assessing the validity of information based
on its format. Templeton describes validating based on the content of
information requested, e.g., a telephone number, but not on its format.
In support of the rejection, the Examiner explains that
each [of Templeton’s] validation/identification information
(telephone number, driver’s license number and social security
number) inherently has its own format and relates to the
individual tendering the identification. For example, the format
for a telephone number is (XXX)-XXX-XXXX (10 digits); that
of the social security number is YYY-YY-YYYY (9 digits) and
that of driver's license is alphanumeric. Presenting a telephone
number (10 digits) where a social security number (9 digits) is
required (or vice versa) would ultimately lead to rejection of the
identification since the formats are different (this is just an
example and not an assumption as alleged by the Appellant (see
Appeal Brief, pages 7)). In rejecting such identification, the
system inherently compares the wrong identification format
received with the expected identification format. Similarly,
presenting a telephone number (a correct identification format
(10 digits)) when it is required and verifying such number
inherently means that the format of the identification received is
in conformance with the specific identification type requested.
Answer 7-8.
The difficulty with the Examiner’s reasoning is that it assumes the
information that Templeton validates is necessarily in a particular format.
However, the information Templeton requests are not necessarily in any
particular format. Nor does Templeton require the information to be in any
particular format prior to validation.
Appeal 2009-012890
Application 10/424,562

7
For example, the Examiner states that the format for a telephone
number is (XXX)-XXX-XXXX. Such a format consists of 14 characters.
But telephone numbers come in other well known formats, depending on
style, whether a country code is included, the convention used in a (foreign)
country or community, etc. For example, telephone numbers are known to
be formatted as 1-(XXX)-XXX-XXXX (16 characters); XXXXXXXXXX
(10 characters); XXX-XXX-XXXX (12 characters), and XXX-XXXX (8
characters). Accordingly, telephone numbers, which Templeton might use
for validation, are not inherently in a particular format.
And Templeton does not further limit the format in which the
information must be entered into the system. The Templeton system appears
to be open to entering information in any known format. For example,
Templeton does not restrict inputting the telephone number to the format the
Examiner suggests. The Templeton system appears to be open to entering a
telephone number in any of the known formats mentioned above.
The Examiner finds “the [Templeton] system inherently compares the
wrong identification format received with the expected identification
format.” Answer 8. But given that the information Templeton requests is
not necessarily in any particular format and that Templeton does not require
the information to be in any particular format prior to validation, we find
that the evidence more strongly supports the Appellant’s position. That is,
the [Templeton] system does not inherently compare the wrong
identification format received with the expected identification format.
All the claims require assessing the validity of information based at
least in part on the format of the information. The Examiner has taken the
position that Templeton describes this. However, for the foregoing reasons,
Appeal 2009-012890
Application 10/424,562

8
we find that Templeton does not. Accordingly, we do not find that a prima
facie case of anticipation and obviousness have been established in the first
instance.

DECISION
We reverse the Examiner’s § 102 and § 103 rejections.

ORDER
REVERSED

mev

TOWNSEND AND TOWNSEND AND CREW, LLP
TWO EMBARCADERO CENTER
EIGHTH FLOOR
SAN FRANCISCO CA 94111-3834