Ex Parte Philyaw et al

Board of Patent Appeals and Interferences

Nov 22, 2010

09382426 (B.P.A.I. Nov. 22, 2010)

The two-month time period for filing an appeal or commencing a civil
action, as recited in 37 C.F.R. § 1.304, or for filing a request for rehearing,
as recited in 37 C.F.R. § 41.52, begins to run from the “MAIL DATE”
(paper delivery mode) or the “NOTIFICATION DATE” (electronic delivery
mode) shown on the PTOL-90A cover letter attached to this decision.

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte JEFFRY JOVAN PHILYAW and DAVID KENT MATHEWS
____________

Appeal 2009-003363
Application 09/382,426
Technology Center 3600
____________

Before HUBERT C. LORIN, JOSEPH A. FISCHETTI, and BIBHU R.
MOHANTY, Administrative Patent Judges.

FISCHETTI, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2009-003363
Application 09/382,426

2
STATEMENT OF THE CASE
Appellants seek our review under 35 U.S.C. § 134 of the Examiner’s
final rejection of claims 1-29. We have jurisdiction under 35 U.S.C. § 6(b)
(2002).

SUMMARY OF DECISION
We AFFIRM-IN-PART.

THE INVENTION
Appellants claim a method of facilitating E-commerce and, more
particularly, to an architecture for automatically inserting user profile
information into a vendor payment form by submitting a bar code and/or
unique ID. (Specification 2:5-7).
Claim 1 is representative of the subject matter on appeal.
1. A method of processing profile information of a
user for conducting an on-line transaction between
the user and a vendor, comprising the steps of:
entering profile information of a user into a profile
form at a user location disposed on a network prior
to conduction of an on-line transaction between the
user and the vendor, the vendor disposed at a
vendor location on the network;
issuing to the user a unique code representing
stored profile information of the user in response
to the user transmitting the profile form from the
user location to a second location on the network
for storage thereat, the second location disposed
on the network;
Appeal 2009-003363
Application 09/382,426

3
initiating an on-line transaction by selecting a
product of the vendor at a user location;
after selecting the product, providing to the vendor
location by the user the unique code for purchase
of the product, during the on-line transaction,
which on-line transaction requires the user to view
a vendor payment form at the user location
representing information about the transaction, and
which vendor payment form includes fields that
are associated with information obtainable from
the stored profile information of the user and
which must be viewed by the user prior to
completion of the on-line transaction;
providing the stored profile information from the
second location to the vendor location in response
to the vendor location receiving and processing the
unique code; and
automatically inserting by the vendor at least a
portion of the stored profile information of the user
into the vendor payment form for respective
associated fields therein for presentation to the
user at the user location after such insertion such
that, when the user receives the form for viewing,
such insertion has already occurred, such that the
user has not viewed the form other than with
already populated certain fields prior to reception.

THE REJECTIONS
The Examiner relies upon the following as evidence of
unpatentability:
Wong US 5,956,699 September 21, 1999
Appeal 2009-003363
Application 09/382,426

4
Hartman, et al. US 5,960,411 September 28, 1999
Fortenberry, et al. US 6,005,939 December 21, 1999
Rhoads US 6,311,214 October 30, 2001

The following rejections are before us for review.
The Examiner rejected claims 1-11, 14-17, 19-24, and 27 under 35
U.S.C. 103(a) as being unpatentable over Fortenberry and Hartman.
The Examiner rejected claims 12 and 25 under 35 U.S.C. 103(a) as
being unpatentable over Fortenberry, Hartman, and Official Notice.
The Examiner rejected claims 13, 18, 26, 28, and 29 under 35 U.S.C.
103(a) as being unpatentable over Fortenberry, Hartman, and Rhoads.

ISSUES
Did the Examiner err in rejecting claims 1-11, 14-17, 19-24, and 27
under 35 U.S.C. § 103(a) as being unpatentable over Fortenberry and
Hartman on the grounds that a person with ordinary skill in the art would
understand that since Fortenberry discloses a security key which makes
available profile information contained in an encrypted file sent to a vendor,
that Fortenberry discloses providing the stored profile information from the
second location to the vendor location in response to the vendor location
receiving and processing the unique code?
Did the Examiner err in rejecting claims 4 and 17 under 35 U.S.C.
§ 103(a) as being unpatentable over Fortenberry and Hartman on the
grounds that a person with ordinary skill in the art would understand that
Appeal 2009-003363
Application 09/382,426

5
Fortenberry or Hartman discloses the vendor location receives the profile
information from the second location in response to the vendor location
transmitting the unique code to the second location?

FINDINGS OF FACT
We find the following facts by a preponderance of the evidence:
1. Fortenberry discloses unique codes, each in the form of keys,
and each representing specific information in a user’s profile, because a
“user 208 may have a first key which unlocks confidential user information
in the user passport, a second key which unlocks secret user information in
the user passport and a third key which unlocks top secret user information
in the user passport.” (Col. 6 ll. 40-44).
2. The Specification does not define the term providing within the
context of how the unique code and the profile information gets to the
vendor location.
3. The ordinary and customary definition of the term providing, as
defined by Merriam Webster’s Collegiate Dictionary (10th ed.), is: “to
make something available.”
4. Fortenberry discloses providing stored profile information, in
response to the vendor location receiving and processing the unique code,
since “[w]hen the vendor, i.e. the web server receives passport data from the
passport agent 216, and such user information is encrypted, the public key
Appeal 2009-003363
Application 09/382,426

6
sent by the user is used to unlock and decrypt the passport data, as illustrated
by the decisional block 518 and process block 520.” (Col. 8 ll. 59-64).
5. The Specification does not define the term processing within
the context of how the unique code is handled by the vendor location.
6. The ordinary and customary definition of the term processing,
as defined by Merriam Webster’s Collegiate Dictionary (10th ed.), is: “to
subject to a special process or treatment.”
7. Hartman discloses displaying, to a user, a form containing
information about the user’s purchase transaction, stating:
FIG. 1A illustrates the display of a Web page
describing an item that may be ordered. … This
example Web page contains a summary
description section 101 … a single-action ordering
section 103, and a detailed description section 104.
… The summary description and the detailed
description sections provide information that
identifies and describes the item(s) that may be
ordered.
(Col. 4 ll. 5-19).
8. Hartman discloses that the purchase transaction form presented
to the user includes fields that are associated with shipping address
information which is obtainable from the user’s profile through a link,
because “[i]f the purchaser wants to verify the shipping address, the
purchaser can select the ‘check shipping address’ label.” (Col. 4 ll. 35-50).
Appeal 2009-003363
Application 09/382,426

7
9. Hartman discloses storing user profile information at a vendor’s
server, stating, “[t]he server system also stores purchaser-specific order
information for various potential purchasers.” (Col. 3 ll. 38-40).
10. Hartman discloses automatically inserting stored user profile
information into the vendor payment form presented to the user with the
result that “[t]he purchaser information subsection displays enough
information so that the purchaser can verify that the server system correctly
recognizes the purchaser.” (Col. 4 ll. 35-41).
11. The Specification does not define or describe the term form.
12. The ordinary and customary definition of the term form, as
defined by Merriam Webster’s Collegiate Dictionary (10th ed.), is: “a
printed or typed document with blank spaces for insertion of required or
requested information.”
13. Fortenberry discloses entering profile information of a user into
a profile form, by presenting “to the user a series of queries which may be in
the form of menus, as illustrated by process block 406. In response, the user
enters the requested information such as social security number, driver’s
license number, etc. ….” (Col. 7 ll. 45-49).
14. Hartman discloses a form to gather user profile information in
Figure 8B.

Hartman’s Figure 8B

Appeal 2009-003363
Application 09/382,426

8

Hartman’s Figure 8B showing a user profile form.

15. The Specification describes the use of an Internet web browser,
describing that “[t]he PC 112 runs a browser program to facilitate the access
of information on the network, for example, a global communication
network known as the ‘Internet’ or the World-Wide-Web (‘Web’).”
(Specification 13:9-13).
16. Fortenberry discloses the use of Internet web browser
technology when it discloses “a consistent, secure and redundancy free
technique for obtaining and maintaining user information at one or several
sites on a public network is provided. The public network may correspond,
for example, to the Internet and the sites may correspond to web sites on the
Internet.” (Col 1 ll. 56-60).
17. Fortenberry discloses initiating an on-line transaction by
selecting a product of the vendor at a user location where “[f]irst, the user
Appeal 2009-003363
Application 09/382,426

9
requests a transaction with a particular vendor, i.e., web site 210, as
illustrated by process block 502.” (Col. 8 ll. 29-31).
18. Fortenberry discloses a user providing the vendor location with
a unique code for the purchase of a product during an on-line transaction
when, “the user provides a public key to the vendor, as illustrated in process
block 504.” (Col. 8 ll. 31-33).
19. Fortenberry discloses storing credit card information or a social
security number in a profile using user only available encryption. (Col. 6 ll.
52-62).
20. The Specification defines the term “encoded” to mean
“unintelligible to the user” (Specification 54:24).
21. Hartman discloses an example of encoded payment
information, displayed as part of information about an order, in a portion of
Fig. 1C.
Appeal 2009-003363
Application 09/382,426

10
A portion of Hartman’s Figure 1C follows:

Portion of Hartman’s Figure 1C showing encoded payment information.
22. Fortenberry discloses that a central registration server stores
user profile information, since “a passport system includes a single
repository of user information in a single format and a passport access
provider for accessing the user information in the repository and for
providing a user passport to a requestor.” (Col. 1 ll. 51-55).
23. Fortenberry discloses that a passport agent is a server and a
database, stating, “[a]lso coupled to Internet 200 is a passport server 212 and
a passport data base 214. Passport server 212 and passport database 214 may
be collectively referred to as a passport agent 216.” (Col. 5 ll. 62-65).
24. Rhoads discloses a code, entitled “Bedoop data” which “is any
form of digital data encoding recognized by the system 10--data which, in
many embodiments, initiates some action …” (Col. 3 ll. 3-7).
25. Rhoads discloses cards such as “[d]rivers licenses, social
security cards, or other identity documents may be encoded by the issuing
authority with Bedoop data that permits access to the holder's personal
records over the web.” (Col. 22 ll. 24-27).
Appeal 2009-003363
Application 09/382,426

11
26. Rhoads discloses the code hidden on a credit card conveys
profile data or credit card data, so that:
When a consumer visits a commercial web site and
wishes to purchase a displayed product, the
transaction can be speeded simply by presenting a
Bedoop-encoded credit card to a Bedoop sensor on
the user's computer. The Bedoop data on the card
leads to a database entry containing the credit card
number and expiration date.
(Col. 27 ll. 43-48).
27. Rhoads discloses using the code to convey payment profile
information to a vendor, in that “[c]redit card or other customer billing
information, together with mailing address information, can be stored in a
profile on the Bedoop system, and relayed to the transactional web site either
automatically when a purchase action is invoked, or after the user affirms
that such information should be sent ….” (Col 24 ll. 13-18).
28. Hartman discloses a user sending a message to a vendor server
to order a displayed item, in that, “[w]hen the purchaser selects the single-
action ordering button, the client system sends a message to the server
system requesting that the displayed item be ordered.” (Col. 4 ll. 59-61).
29. The Examiner found a rationale to combine Fortenberry and
Hartman is because “this will be more efficient by eliminating a step and the
need for additional software for filling in the web page on the user computer
after sending information to the user and sending the web page to the user
Appeal 2009-003363
Application 09/382,426

12
separately” and because it “assures the user that the vendor has the order
correct.” (Ans. 4).
30. The Examiner found a rational basis to combine Rhoads with
Fortenberry and Hartman is because “utilizing existing infrastructure, along
with the convenience of having the access code readily available will
provide for increased usage of the system and therefore increased revenue.”
(Ans. 5).
31. The Examiner found a rational basis to combine Official Notice
with the Fortenberry/Hartman combination as it “is a notoriously well
known place to store this type of information and preventing these
companies from participating in the invention of Fortenberry would reduce
the potential sales market and reduce revenues.” (Ans. 5)
32. Fortenberry discloses a vendor requesting that the passport
agent send profile information necessary to complete a transaction identified
by a user-id, since “[t]he vendor requests relevant information contained in
the user environment variables from the passport agent, as illustrated by
process block 508. The request for information is specified in the message as
follows: RELEASE-TYPE TO INTERNET-SITE ON BEHALF OF MY-
USER-ID.” (Col. 8 ll. 37-42).

ANALYSIS
We affirm the rejections of claims 1-3, 5-16, and 18-29. We reverse
the rejections of claims 4 and 17.
Appeal 2009-003363
Application 09/382,426

13
Claims 1 and 14
Initially, we note that the Appellants argue independent claims 1 and
14 together as a group. (App. Br. 35). Correspondingly, we select
representative claim 1 to decide the appeal of these claims, with remaining
claim 14 standing or falling with claim 1.
Appellants argue:
Fortenberry discloses the generation of an
encryption security key, in the form of a public
key, to the user that the user may utilize later when
allowing a vendor to access profile information.
Fortenberry teaches that the public key is used to
‘unlock and decrypt’ the passport data. As such,
the public key, though unique, is not a unique code
representing the stored profile information.
(App. Br. 23-24).
We disagree with Appellants. Fortenberry discloses a unique code, in
the form of a security key, where each particular key represents specific
information at different security levels in the user’s profile (FF 1). Thus,
Fortenberry’s unique security keys meet the claim limitation of a unique
code representing stored profile information of the user because each key
corresponds to specific information stored in a user profile.
Appellants further argue that the Examiner’s reliance on Fortenberry
is in error because “[t]he data is not sent in response to the vendor location
receiving and processing the public key” (App. Br. 27).
We are not persuaded by this argument. First, the argument fails since
it argues limitations not part of the claim, namely, the claim does not require
Appeal 2009-003363
Application 09/382,426

14
that the data be sent, or that the vendor receives data. Rather, the claim only
requires providing the information in response to receiving and processing
the unique code. We find that the term providing as used in the context of
how the vendor gets the unique code and the stored profile information is not
defined in the Specification (FF 2). We thus rely on the ordinary and
customary meaning of “providing,” which is “to make something available”
(FF 3). We find that Fortenberry discloses that the unique code is received
by the vendor from the user (FF 4). The passport data which is analogous to
the claimed profile information is also received at the vendor and is
processed using the received key to unlock and gain access to the profile
data (FF 4). The profile data is provided by the passport agent, analogous to
the claimed second location, to the vendor (FF 4), and thus Fortenberry
meets the claim limitation by making the unique code and the profile
information available to the vendor.
Appellants next argue that “Fortenberry does not teach … that the
vendor processes the public key” because “Fortenberry expressly teaches …
that the vendor uses the public key to decrypt the encrypted data … (Appeal
Br. 27).
We are not persuaded by this argument. We find the term processing
is not defined or described in the Specification (FF 5), and we thus rely on
the ordinary and customary meaning of “processing,” which is “to subject to
a special process or treatment” (FF 6). Since Fortenberry discloses a process
520 for decrypting the profile/passport file with the key (FF 4), the claim
Appeal 2009-003363
Application 09/382,426

15
limitation is met because decryption is a special process to decode
information represented by the key.
Appellants also assert:
[T]he Examiner provides no reference to teach an
‘on-line transaction requires the user to view a
vendor payment form at the user location
representing information about the transaction, and
which vendor payment form includes fields that
are associated with information obtainable from
the stored profile information of the user and
which must be viewed by the user prior to
completion of the on-line transaction’ as required
by the claim.
(App. Br. 24-25).
We are not persuaded by this argument because we find Hartman
discloses a vendor payment form that is transmitted to the user before
completing a purchase (FF 7). We further find that this form contains
information about the transaction, namely, Hartman discloses “information
that identifies and describes the item(s) that may be ordered”. (FF 7).
Hartman further discloses information which is obtainable from the user’s
profile because Hartman discloses a link in the form to the shipping address
(FF 8). Thus, Hartman’s form, and the information it contains, meets the
claim limitations.
Appellants additionally argue that both Fortenberry and Hartman fail
to disclose “inserting released information into a form automatically before
Appeal 2009-003363
Application 09/382,426

16
submittal to a user” because “Hartman teaches, and is limited to teaching, an
information confirmation page.” (App. Br. 29-31).
We disagree with Appellants because we find Hartman teaches, in
addition to a confirmation message, a vendor payment form, into which user
profile information has been automatically inserted, which is transmitted to
the user (FF 7, 9, 10). Thus, Hartman meets the claim limitation with the
purchase transaction form because it contains user profile information
inserted before being sent to the user.
Applicants argue that “Fortenberry does not teach a profile form, at a
user location, for entry of user profile information” (Appeal Br. 22).
We are not persuaded by this argument for the following reasons.
First, we find that the Specification does not define or describe a “form” (FF
11). We thus rely on the ordinary and customary meaning of “form,” which
is “a printed or typed document with blank spaces for insertion of required
or requested information” (FF 12). Although Fortenberry does not
specifically use the term form, we find that Fortenberry’s menus capturing
profile information are forms. That is, Fortenberry presents queries to a user
in blank menus, and requests responses to gather profile information (FF 13)
from data entered into each menu. Additionally, Hartman discloses a user
profile information form at Figure 8B, which, although it is cumulative to
the Fortenberry menus (FF 14), is nevertheless on point.
Appellants further assert that “if a form existed, the form would exist
at the passport agent (216), not the user location.” (App. Br. 22).
Appeal 2009-003363
Application 09/382,426

17
We also are not persuaded by this argument because Fortenberry also
discloses the use of an Internet web browser (FF 16). Since web browsers
copy information at the server and send the copy to the user, we thus find
that Fortenberry’s website-presented menus which gather profile information
meet the claim limitation entering profile information of a user into a profile
form at a user location disposed on a network because a browser also
presents the Fortenberry form/menu to the user location.
Appellants next argue that “Fortenberry contains no disclosure that
the user initiates an on-line transaction by selecting a product of the vendor
at a user location” because “all that Fortenberry discloses is a user's request
to initiate some sort of transaction with a vendor.” (App. Br. 24).
We are not persuaded by this argument, because we find one of
ordinary skill in the art would understand that Fortenberry’s disclosure of a
user initiating a purchase transaction (FF 17) would necessitate the user
selecting a product or service to purchase before completing the transaction.
That is, since the user performs the actions in a web browser (FF 15, 16), the
product is selected at the user’s location, and then the selection is sent to the
vendor server by virtue of the browser operation.
Appellants also argue that “Fortenberry does not disclose ‘after
selecting the product, providing to the vendor location by the user the unique
code for purchase of the product during the online-transaction’ as contended
by the Examiner” because “Fortenberry does not teach a unique code .…”
(App. Br. 25).
Appeal 2009-003363
Application 09/382,426

18
We disagree with Appellants. Since Fortenberry discloses a user
providing a unique code in the form of a security key to the vendor before
completing a purchase transaction (FF 1, 18), Fortenberry meets the claim
limitation because Fortenberry’s public key security code is the unique code
that is provided to the vendor during the purchase.
Claims 5, 6, and 19
Appellants argue that “Fortenberry and Hartman, taken singularly or
in combination fail to teach that the unique code is unique and has a unique
ID number associated therewith” (App. Br. 37).
We are not persuaded by this argument, because Fortenberry discloses
credit card and social security numbers, i.e., unique ID’s, associated with the
encryption security key or unique code (FF 19). Fortenberry discloses that a
social security number is protected by encryption whose key code
corresponds to an ID number and is only available to the user, and thus is
unique.
Claims 7, 8, 20, and 21
Appellants argue that “Fortenberry and Hartman … fail to teach
where the step of inserting causes all, or a portion, of the profile information
to be entered into the vendor payment form as encoded information” because
Hartman operates by “only sending a portion of information.” (App. Br. 39).
We disagree with Appellants, because the meaning of the term
encoded as defined by the Specification is “unintelligible to the user”
(FF 20), and Hartman displays a partially-unintelligible ship-to address and
Appeal 2009-003363
Application 09/382,426

19
payment charge number in a payment field of Figure 1C (FF 21). Although
Hartman’s transaction payment form (FF 21) does not disclose encoded
information, Hartman discloses the encoded payment information in its
confirmation document in Figure 1C. We find that it would have been
obvious to display the payment information in the purchase transaction form,
because the same information, same transaction, and same privacy concerns
are involved. Thus, one of ordinary skill in the art would have known to
apply Hartman’s encoded payment information to those instances in
Hartman where payment information is displayed to a user in a browser
session.
Claims 11 and 24
Appellants argue that neither Fortenberry nor Hartman “teach a
central registration server, of the type required by the claims of the instant
application, having a database of unique codes and unique ID numbers”
because “Fortenberry merely discloses a passport agent that has a database
of profile information encrypted with a private key” (App. Br. 39-40).
We are not persuaded by this argument, because Fortenberry discloses
a central registration server or passport agent server 212 (FF 22, 23) having
a database of unique codes in the form of security keys (FF 1) each key
allowing access to a unique ID, e.g., social security or credit card number
(FF 19). Thus, Fortenberry’s passport agent is a central registration server,
and Fortenberry’s security keys are unique codes which protect the unique
Appeal 2009-003363
Application 09/382,426

20
ID numbers, such as credit card and social security numbers, stored as
information in the server’s database, thus meeting the claim limitations.
Claims 12 and 25
Appellants argue that the Official Notice the Examiner used on claims
12 and 25 “is not proper to cure the deficiency in Hartman” with respect to
claim 11 (that “Hartman does not disclose a second location”, i.e., a central
registration server) (App. Br. 41).
We are not persuaded by this argument for the following reasons.
First, claim 1 recites three locations: user, vendor, and second. Claim 11
further limits the second location to be a central registration server having a
database of the profile information associated with respective unique codes
and unique ID numbers. As found, supra with respect to claims 5, 6, 11, 19
and 24, Fortenberry discloses a central registration server at the passport
server having a database of the profile information associated with
respective unique codes and unique ID numbers. Since we found no
deficiency in the rejection of claim 11, Appellants’ assertions of error to
claim 12 based on that of claim 11 is likewise unpersuasive.
Furthermore, Appellants have not specifically pointed out the
supposed errors in the Examiner's taking of Official Notice, “includ[ing]
stating why the noticed fact is not considered to be common knowledge or
well-known in the art.” See 37 CFR § 1.111(b), MPEP § 2144.03(C). An
adequate traverse must contain adequate information or argument to create
on its face a reasonable doubt regarding the circumstances justifying
Appeal 2009-003363
Application 09/382,426

21
Examiner's notice of what is well known to one of ordinary skill in the art.
In re Boon, 439 F.2d 724, 728 (CCPA 1971). That has not been done here.
When an Appellant does not seasonably traverse a well-known statement
during examination, the object of the well-known statement is taken to be
admitted prior art. In re Chevenard, 139 F.2d 711 (CCPA 1943).
We find Appellants’ assertion that “a reference is required to support
such a rejection” (App. Br. 41) not persuasive because the Examiner
provided Wong, U.S. Pat. No. 5,956,699 (Ans. 10), in support of the Official
Notice taken. In reply, Appellants’ only response to Wong was that
“Appellants note that the Examiner has not provided a response sufficient to
rebut Appellants arguments with respect to the Claims 12 … [and] 25….”
(Reply Br. 24). We thus find that Appellants did not adequately traverse the
taking of Official Notice. However, even if the traverse had been adequate,
the Examiner provided Wong, and correctly applied it, to substantiate the
Official Notice, without challenge by Appellants.
Claims 13 and 26
Appellants argue that “[t]he combination of Fortenberry, Hartman
and Rhoads does not teach ‘a unique code placed on a credit card’,” because
“Fortenberry teaches standard encryption and decryption algorithms,”
“Hartman teaches the use of a ‘cookie’,” and Rhoads “describes the
‘BEDOOP’ code, which is a sound”, using a “digital code that is hidden on
an object and placed in front of a camera to extract.” (App. Br. 44-45).
Appeal 2009-003363
Application 09/382,426

22
We are not persuaded by this argument because Rhoads discloses the
claimed limitation. In particular, Rhoads discloses digitally encoded data,
i.e., a code that is recognized on an object to initiate an action (FF 24). The
code, called Bedoop data, may be placed on cards to provide access to
profile information (FF 25), and that the code may be placed on a credit card
to convey credit card information (FF 26), or profile information (FF 27).
Thus, we find Rhoads’ unique code, i.e., Bedoop data, is placed on a credit
card to provide access to user profile information, and thus meets the claim
limitation.
Claims 28 and 29
Appellants argue that “Fortenberry, Hartman and Rhoads … do not
teach that the populated form [is] transmitted to a vendor to complete an on-
line transaction.” (App. Br. 46).
We disagree with Appellants because Hartman discloses an order
message containing information necessary to order the product, retrieved
from the form displayed to the user (FF 7-9), and sent to the vendor’s server
(FF 28). We therefore find that Hartman meets the claim limitation
transmitting the populated form to the vendor location to complete the on-
line transaction, because the order message includes the data derived from
the profile information form displayed to the user.
Additionally, Appellants generally argue that the Examiner’s
rejections are “conclusory” and “based on hindsight” (App. Br. 19).
Appeal 2009-003363
Application 09/382,426

23
Appellants also argue that “merely ignoring Appellants’ arguments
regarding the TSM test is not sufficient.” (Reply Br. 7).
We are not persuaded by these arguments. First, the Examiner found
and articulated reasoning for each of the combinations relied upon in the
obviousness rejections (FF 29-31). Second, the Fortenberry, Hartman,
Rhoads, and Official Notice references are from the same field of endeavor,
in that each addresses purchase transactions over the Internet. The rejections
were thus not conclusory, because the articulated reasoning for each
combination was reasonable, based on the common field of endeavor and the
common problems associated with the same field.
As to the question of hindsight, we are not persuaded of error because
the Examiner’s reconstruction of references is based on a valid explanation
(FF 29-31). Finally, to the extent Appellants seek an explicit suggestion or
motivation in the reference itself, this is no longer the law in view of the
Supreme Court’s recent holding in KSR Int’l Co. v. Teleflex Inc., 550 U.S.
398, 421 (2007).
We also affirm the rejections of dependent claims 2, 3, 9, 10, 15, 16,
17, 22, 23, and 27 since Appellant has not challenged such with any
reasonable specificity (see In re Nielson, 816 F.2d 1567, 1572 (Fed. Cir.
1987)).
Claims 4 and 17
Claims 4 and 17 each contain similar versions of the limitation
wherein the vendor location receives the profile information from the second
Appeal 2009-003363
Application 09/382,426

24
location in response to the vendor location transmitting the unique code to
the second location. Appellants argue “Fortenberry and Hartman, taken
singularly or in combination, fail to teach” this claim limitation (App. Br.
37).
We agree with Appellants. Although Fortenberry discloses a process
where the vendor requests profile information from the passport
agent/second location (FF 32), the unique code/security key although
provided, is not received from the vendor to the second location/passport
agent. We thus do not sustain the rejection of claims 4 and 17.
CONCLUSIONS OF LAW
We conclude that the Examiner erred in rejecting claims 1-3, 5-16,
and 18-29.
We conclude that the Examiner erred in rejecting claims 4 and 17.

Appeal 2009-003363
Application 09/382,426

25
DECISION
The decision of the Examiner to reject claims 1-3, 5-16, and 18-29 is
affirmed. The decision of the Examiner to reject claims 4 and 17 is
reversed.

AFFIRMED-IN-PART

MP

HOWISON & ARNOTT, L.L.P
P.O. BOX 741715
DALLAS TX 75374-1715