Ex Parte Sharma

Board of Patent Appeals and Interferences

Dec 2, 2008

09751265 (B.P.A.I. Dec. 2, 2008)

UNITED STATES PATENT AND TRADEMARK OFFICE 1
___________ 2
3
BEFORE THE BOARD OF PATENT APPEALS 4
AND INTERFERENCES 5
___________ 6
7
Ex parte DUSHYANT SHARMA 8
___________ 9
10
Appeal 2008-3804 11
Application 09/751,265 12
Technology Center 3600 13
___________ 14
15
Decided: December 2, 2008 16
___________ 17
18
Before ANTON W. FETTING, DAVID B. WALKER, and 19
BIBHU R. MOHANTY, Administrative Patent Judges. 20
FETTING, Administrative Patent Judge. 21
22
23
DECISION ON APPEAL 24
25
STATEMENT OF THE CASE 26
Dushyant Sharma (Appellant) seeks review under 35 U.S.C. § 134 of a 27
non-final rejection of claims 1-20, the only claims pending in the application 28
on appeal. 29
We have jurisdiction over the appeal pursuant to 35 U.S.C. § 6(b) 30
(2002). 31
Appeal 2008-3804
Application 09/751,265

2
We AFFIRM. 1
2
The Appellant invented a way for integrated electronic bill presentment 3
and payment among billers, consumers, banks and other financial 4
institutions in electronic commerce (Specification 1:3-7). 5
An understanding of the invention can be derived from a reading of 6
exemplary claim 1, which is reproduced below [bracketed matter and some 7
paragraphing added]. 8
1. An electronic bill presentment and payment system, 9
comprising: 10
[1] a database 11
capable of storing data relating to a plurality of bills 12
sourced from a plurality of billers, and 13
corresponding to a plurality of consumers; 14
[2] a bill data processor coupled to said database, 15
said bill data processor being capable of converting data 16
received from said plurality of billers 17
into a format compatible with said database; 18
[3] a bill report processor coupled to said database, 19
said bill report processor being capable of allowing at 20
least some of said plurality of billers 21
to review and obtain reports in real time from 22
data relating to said billers and 23
the status of said biller's bills stored in said 24
database; 25
[4] a bill security element 26
which prohibits access to said database 27
by any entity not having encrypted access to said 28
database; and 29
Appeal 2008-3804
Application 09/751,265

3
[5] a portal interface element coupled to said database, 1
said portal interface element being capable of supporting 2
a plurality of visual interfaces 3
each associated with a different web portal or bill 4
presentment and payment website, 5
each visual interface being supported by a web 6
portal or bill presentment and payment website 7
different from other of said visual interfaces, 8
each of said visual interfaces allowing a consumer 9
to review and pay said consumer's bills and 10
thereby change information in said database 11
only if said consumer has been authorized 12
access to said database by a credit verifier. 13
This appeal arises from the Examiner’s non-final Rejection, mailed 14
December 27, 2006. The Appellant filed an Appeal Brief in support of the 15
appeal on June 21, 2007. An Examiner’s Answer to the Appeal Brief was 16
mailed on October 4, 2007. A Reply Brief was filed on December 4, 2007. 17
PRIOR ART 18
The Examiner relies upon the following prior art: 19
Kamen US 6,421,067 B1 Jul. 16, 2002
Haseltine US 6,578,015 B1 Jun. 10, 2003
REJECTIONS 20
Claims 1-16 and 18-20 stand rejected under 35 U.S.C. § 102(e) as 21
anticipated by Haseltine. 22
Claim 17 stands rejected under 35 U.S.C. § 103(a) as unpatentable over 23
Haseltine and Kamen. 24
Appeal 2008-3804
Application 09/751,265

4
ISSUES 1
The issues pertinent to this appeal are 2
• Whether the Appellant has sustained its burden of showing that the 3
Examiner erred in rejecting claims 1-16 and 18-20 under 35 U.S.C. 4
§ 102(e) as anticipated by Haseltine. 5
• Whether the Appellant has sustained its burden of showing that the 6
Examiner erred in rejecting claim 17 under 35 U.S.C. § 103(a) as 7
unpatentable over Haseltine and Kamen. 8
The pertinent issues turn on whether Haseltine describes a system having 9
the capabilities recited in argued claims. 10
FACTS PERTINENT TO THE ISSUES 11
The following enumerated Findings of Fact (FF) are believed to be 12
supported by a preponderance of the evidence. 13
Haseltine 14
01. Haseltine is directed to electronically presenting bills to 15
customers while preserving the billers' corporate identity, as 16
embodied in the "look-and-feel" of the bills presented to 17
customers (Haseltine 2:57-61). 18
02. Haseltine’s billers have the option of transmitting bill data and 19
bill format data to an electronic presentment and payment 20
database. The bill data may include a customer identifier, an 21
amount due and a date due for each of the biller's customers that 22
have opted to pay their bills electronically. The bill data stream 23
may be coded according to any number of formats such as the 24
Appeal 2008-3804
Application 09/751,265

5
Open Financial Exchange (OFX) format, ASCII, eXtensible 1
Markup Language (XML), print streams or other legacy or 2
proprietary formats. The bill format data may include HTML-3
formatted data configured to mimic the "look-and-feel" of the 4
biller's traditional paper bills, when rendered on a display device. 5
Alternatively, or in addition to HTML, the bill format data may 6
include functionality programmed in Extensible Markup 7
Language (XML) (Haseltine 4:53 – 5:29). 8
03. A bill data validation procedure may be carried out to insure the 9
integrity of the bill data 402 transmitted by the biller. This 10
validation procedure may include, for example, verification of the 11
customer's identity, verification of the integrity of the transmitted 12
data and/or verification that all required fields (such as amount 13
and/or date due, for example) have been properly populated 14
(Haseltine 5:43-49). 15
04. Haseltine provides status tables that may be viewed by 16
customers. As the name implies, the status tables track the status 17
of the bills presented to the customers such as whether a 18
customer's bills have been viewed, paid, have been submitted or 19
are pending. Other indicia indicative of the status of the 20
customers' bills may also be included in the status tables 21
(Haseltine 6:10-21). 22
05. Haseltine allows customers to dispute bills by sending a 23
message to a customer service representative. The biller of the 24
disputed bill may then log onto the system and take appropriate 25
action (Haseltine 6:22-26). 26
Appeal 2008-3804
Application 09/751,265

6
06. Haseltine provides a template manager when the customer logs 1
on to view his or her bills. Haseltine describes a template selection 2
rule that compares the system date (i.e., the present date) with the 3
bill due date and causes the template manager to select a biller-4
specific "overdue bill template" when the system date is greater 5
than the bill due date and a "current bill template" otherwise. The 6
template manager may also evaluate Boolean expressions such as 7
AND, OR, etc. to select a template that is appropriate to the bill 8
data (Haseltine 8:28-40). 9
07. Haseltine allows a customer to log onto a Web site of a biller 10
through the Internet via an HTML Secure Sockets Layer (SSL), 11
which is a high-level security protocol that insures security of data 12
transmitted over the Internet, and is well known and used by many 13
commerce servers on the Web. Popular Web Browsers currently 14
support SSL, with varying levels of encryption. In this case, the 15
biller may maintain a database 400 (FIG. 4) in an appropriate 16
server. Alternatively, the biller may have in-house payment 17
processing capabilities, in which case the customer directly logs 18
onto the Web site of the biller to view and/or pay his or her bills 19
for that biller (Haseltine 9:51- 10:10). 20
08. Haseltine describes how bill consolidators exist, which allow 21
customers to electronically log onto a single site on the Web and 22
pay bills originating from a number of individual billers. Such 23
consolidators may be generally categorized as thin consolidators 24
or thick consolidators. Thin consolidators typically carry only bill 25
summaries and refer the customer to the biller's own Web site for 26
Appeal 2008-3804
Application 09/751,265

7
further detailed bills and/or further customer service, such as to 1
discuss a disputed bill. Thick consolidators typically carry the 2
biller's entire customer data and often act as their own payment 3
processors (Haseltine 2:30-49). Haseltine allows thick and/or thin 4
consolidators to preserve the "look-and-feel" of their billers' bills 5
while providing the customer with a flexible and integrated bill 6
presentment and payment infrastructure (Haseltine 10:11 – 11:22). 7
09. Haseltine’s system allows generating reports to billers and 8
administrators (Haseltine 12:22-25). 9
10. Haseltine describes using input devices, such as a fingerprint 10
reader, a retina scanner and/or other biometric information 11
measuring and/or acquiring devices to assist in the authentication 12
of customers to the electronic bill presentment and payment 13
database (Haseltine 13:15-22). 14
Kamen 15
11. Kamen is directed to a television electronic programming guide 16
(EPG) with a graphic interface (Kamen 1:3-4; 3:12-23). 17
12. Kamen describes a user modifying the surfaces of EPG graphic 18
elements. This alteration of the video surface can be in the form of 19
zooming in on the video surface by changing its position in virtual 20
3D space or changing the color of the video surface by changing 21
specular, ambient, and directional lighting. By altering the various 22
video and data surfaces, the surfaces (including pictograms) can 23
be observed from different perspectives. This facilitates a viewer 24
Appeal 2008-3804
Application 09/751,265

8
zooming in on the various pictograms to better identify what kind 1
of program they represent (Kamen 3:50-67). 2
Facts Related To The Level Of Skill In The Art 3
13. Neither the Examiner nor the Appellant has addressed the level 4
of ordinary skill in the pertinent arts of systems analysis and 5
programming, financial transaction systems, and network 6
communication. We will therefore consider the cited prior art as 7
representative of the level of ordinary skill in the art. See Okajima 8
v. Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001) (“[T]he 9
absence of specific findings on the level of skill in the art does not 10
give rise to reversible error ‘where the prior art itself reflects an 11
appropriate level and a need for testimony is not shown’”) 12
(quoting Litton Indus. Prods., Inc. v. Solid State Sys. Corp., 755 13
F.2d 158, 163 (Fed. Cir. 1985). 14
Facts Related To Secondary Considerations 15
14. There is no evidence on record of secondary considerations of 16
non-obviousness for our consideration. 17
PRINCIPLES OF LAW 18
Claim Construction 19
During examination of a patent application, pending claims are 20
given their broadest reasonable construction consistent with the 21
specification. In re Prater, 415 F.2d 1393, 1404-05 (CCPA 1969); In 22
re Am. Acad. of Sci. Tech Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004). 23
Appeal 2008-3804
Application 09/751,265

9
Limitations appearing in the specification but not recited in the claim are 1
not read into the claim. E-Pass Techs., Inc. v. 3Com Corp., 343 F.3d 1364, 2
1369 (Fed. Cir. 2003) (claims must be interpreted “in view of the 3
specification” without importing limitations from the specification into the 4
claims unnecessarily). 5
Although a patent applicant is entitled to be his or her own lexicographer 6
of patent claim terms, in ex parte prosecution it must be within limits. In re 7
Corr, 347 F.2d 578, 580 (CCPA 1965). The applicant must do so by placing 8
such definitions in the Specification with sufficient clarity to provide a 9
person of ordinary skill in the art with clear and precise notice of the 10
meaning that is to be construed. See In re Paulsen, 30 F.3d 1475, 1480 11
(Fed. Cir. 1994) (although an inventor is free to define the specific terms 12
used to describe the invention, this must be done with reasonable clarity, 13
deliberateness, and precision; where an inventor chooses to give terms 14
uncommon meanings, the inventor must set out any uncommon definition in 15
some manner within the patent disclosure so as to give one of ordinary skill 16
in the art notice of the change). 17
Anticipation 18
"A claim is anticipated only if each and every element as set forth in the 19
claim is found, either expressly or inherently described, in a single prior art 20
reference." Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 21
631 (Fed. Cir. 1987). "When a claim covers several structures or 22
compositions, either generically or as alternatives, the claim is deemed 23
anticipated if any of the structures or compositions within the scope of the 24
claim is known in the prior art." Brown v. 3M, 265 F.3d 1349, 1351 (Fed. 25
Cir. 2001). "The identical invention must be shown in as complete detail as 26
Appeal 2008-3804
Application 09/751,265

10
is contained in the ... claim." Richardson v. Suzuki Motor Co., 868 F.2d 1
1226, 1236 (Fed. Cir. 1989). The elements must be arranged as required by 2
the claim, but this is not an ipsissimis verbis test, i.e., identity of terminology 3
is not required. In re Bond, 910 F.2d 831, 832 (Fed. Cir. 1990). 4
Obviousness 5
A claimed invention is unpatentable if the differences between it and 6
the prior art are “such that the subject matter as a whole would have been 7
obvious at the time the invention was made to a person having ordinary skill 8
in the art.” 35 U.S.C. § 103(a) (2000); KSR Int’l Co. v. Teleflex Inc., 127 9
S.Ct. 1727, 1729-30 (2007); Graham v. John Deere Co., 383 U.S. 1, 13-14 10
(1966). 11
In Graham, the Court held that that the obviousness analysis is 12
bottomed on several basic factual inquiries: “[(1)] the scope and content of 13
the prior art are to be determined; [(2)] differences between the prior art and 14
the claims at issue are to be ascertained; and [(3)] the level of ordinary skill 15
in the pertinent art resolved.” 383 U.S. at 17. See also KSR, 127 S.Ct. at 16
1734. “The combination of familiar elements according to known methods 17
is likely to be obvious when it does no more than yield predictable results.” 18
Id., at 1739. 19
“When a work is available in one field of endeavor, design incentives 20
and other market forces can prompt variations of it, either in the same field 21
or a different one. If a person of ordinary skill can implement a predictable 22
variation, § 103 likely bars its patentability.” Id. at 1740. 23
“For the same reason, if a technique has been used to improve one 24
device, and a person of ordinary skill in the art would recognize that it would 25
Appeal 2008-3804
Application 09/751,265

11
improve similar devices in the same way, using the technique is obvious 1
unless its actual application is beyond his or her skill.” Id. 2
“Under the correct analysis, any need or problem known in the field 3
of endeavor at the time of invention and addressed by the patent can provide 4
a reason for combining the elements in the manner claimed.” Id. at 1742. 5
ANALYSIS 6
Claims 1-16 and 18-20 rejected under 35 U.S.C. § 102(e) as anticipated by 7
Haseltine. 8
The Appellant argues claims 1, 2, 3, and 5 as a group. 9
Accordingly, we select claim 1 as representative of the group. 10
37 C.F.R. § 41.37(c)(1)(vii) (2007). 11
The Examiner found that Haseltine anticipated claim 1. The Appellant 12
contends that Haseltine fails to describe the report processor, portal interface 13
element, and plural visual interfaces of claim 1 (Br. 8-9). We disagree with 14
the Appellant. 15
Report Processor 16
Claim 1 requires the report processor be capable of allowing at least 17
some of said plurality of billers to review and obtain reports in real time 18
from data relating to said billers and the status of said biller's bills stored in a 19
database. 20
Haseltine’s system allows generating reports to billers and 21
administrators (FF 09). The Appellant argues Haseltine has no teaching as 22
to whether data is for billers or biller status. But having data for billers and 23
biller status in Haseltine’s system and the capacity to generate reports, 24
Appeal 2008-3804
Application 09/751,265

12
Haseltine’s system would be capable of allowing those described reports to 1
access such data. There is no limitation on the manner in which such access 2
is allowed; presence of the required data and the capacity to generate reports 3
based on that data is sufficient to permit such access. 4
Portal Interface Element and Plural Visual Interfaces 5
Claim 1 requires a portal interface element capable of supporting a 6
plurality of visual interfaces, each associated with a different web portal or 7
bill presentment and payment website, each visual interface being supported 8
by a web portal or bill presentment and payment website different from 9
other of said visual interfaces 10
There is no limitation regarding the manner of support. The Appellant 11
argues there is no description of a portal interface element or of different 12
visual interfaces (Br. 9). Visual interfaces per se are not recited as part of 13
the claimed structure, only support for them. 14
Haseltine allows a customer to log onto a Web site of a biller through the 15
Internet via an HTML Secure Sockets Layer (SSL), which is a high-level 16
security protocol that insures security of data transmitted over the Internet, 17
and is well known and used by many commerce servers on the Web (FF 07). 18
Such a logon portion of a web site is inherently a portion of the site’s portal 19
interface, since the code for an entry into a system such as a logon is a 20
portal. Accordingly, Haseltine describes the portal interface element. 21
Haseltine describes different interfaces for thin consolidators and thick 22
consolidators. Haseltine allows thick and/or thin consolidators to preserve 23
the "look-and-feel" of their billers' bills while providing the customer with a 24
flexible and integrated bill presentment and payment infrastructure (FF 08). 25
Appeal 2008-3804
Application 09/751,265

13
Further, Haseltine’s bill data stream may be coded according to any 1
number of formats such as the Open Financial Exchange (OFX) format, 2
ASCII, eXtensible Markup Language (XML), print streams or other legacy 3
or proprietary formats. The bill format data may include HTML-formatted 4
data configured to mimic the "look-and-feel" of the biller's traditional paper 5
bills, when rendered on a display device. Alternatively, or in addition to 6
HTML, the bill format data may include functionality programmed in 7
eXtensible Markup Language (XML) (FF 02). All of these have the capacity 8
to support multiple visual interfaces. Accordingly, Haseltine describes the 9
capacity for supporting such plural visual interfaces. 10
Claims 4, 6, 7, 8, 11, 12, and 18-20 11
The Appellant separately argued claims 4, 6, 7, 8, 11, 12, and 18-20. 12
Claim 4 requires the bill security element be adapted to utilize a third 13
party credit verifier as said credit verifier. The Appellant argues Haseltine 14
has no reference to a third party verifier (Br. 10-11). Claim 4 only requires 15
capacity for a third party verifier, not the actual use of a third party. Such a 16
capacity would require no more than access to Haseltine’s system by a third 17
party, since bill verification itself is one of the functions of Haseltine’s 18
system (FF 03). The logon logic we found described in Haseltine supra 19
would allow any authorized party, including a third party to access the 20
system as a credit verifier to verify Haseltine’s bill data. 21
Claim 6 requires the portal interface element be adapted to employ XML 22
transmissions. The Appellant argues Haseltine describes transmitting 23
HTML, but not XML (Br. 11). Claim 6 requires only the capacity to employ 24
XML transmissions, not the actual transmission of XML. Haseltine’s bill 25
Appeal 2008-3804
Application 09/751,265

14
format data transmissions may include functionality programmed in 1
Extensible Markup Language (XML) (FF 02). Thus, Haseltine describes the 2
capacity to employ XML transmissions. 3
Claim 7 requires each consumer be authorized access to said database by 4
a credit verifier during a particular consumer session on said visual interface 5
only after an interactive session between the electronic bill presentment and 6
payment system and the credit verifier which occurs during that consumer 7
session. The Appellant argues the absence of a credit verifier precludes such 8
an interactive session (Br. 11-12). The Appellant also argues claims 8-10 9
and 13-16 as a group. Beyond the arguments made in support of claim 1, the 10
Appellant argues that Haseltine fails to describe a portal interface element 11
adapted to initiate an interactive session via a bill security element with a 12
credit verifier to obtain authorization for a consumer to have access to 13
information from a database (Br. 12-13). This is essentially the same 14
argument as in support of claim 7. 15
Haseltine describes an interactive session to obtain customer 16
bioinformatic or other data for accessing the system (FF 10). As we found 17
with claim 4 supra, Haseltine has the capacity for using such a third party 18
credit verifier. The third party is not part of the claimed system. Rather 19
claim 7 requires the preclusion from continuing into the system absent the 20
claimed interactive session, which Haseltine’s system access logic provides. 21
Claim 11 requires the bill report processor be adapted to allow a 22
consumer to use one of the visual interfaces on a website to inquire online 23
about the status of at least one bill, where the inquiry is conveyed to the 24
particular biller. Claim 12 requires the bill data processor be adapted to 25
allow the system to establish an interactive session between a consumer and 26
Appeal 2008-3804
Application 09/751,265

15
the particular biller. The Appellant argues that Haseltine does not describe 1
these limitations (Br. 13-14). 2
Haseltine allows customers to dispute bills by sending a message to a 3
customer service representative. The biller of the disputed bill may then log 4
onto the system and take appropriate action (FF 05). A customer service rep 5
is associated with a biller. A message is adapted to allow any inquiry, 6
including a status inquiry. The claim only requires the capacity for such an 7
inquiry. We find that Haseltine thus describes such a capacity. 8
Claim 18 requires the bill report processor be adapted to allow a 9
consumer to select for review bills coming due on a certain date. Claim 19 10
requires the bill report processor be adapted to allow a consumer to select for 11
review bills overdue. The Appellant argues these features are not described 12
by Haseltine (Br. 14-15). 13
Haseltine describes a template selection rule that compares the system 14
date (i.e., the present date) with the bill due date and cause the template 15
manager to select a biller-specific "overdue bill template" when the system 16
date is greater than the bill due date and a "current bill template" otherwise. 17
The template manager may also evaluate Boolean expressions such as AND, 18
OR, etc. to select a template that is appropriate to the bill data (FF 06). 19
Thus, Haseltine explicitly describes allowing review of overdue bills and 20
describes the tools necessary to allow a consumer to select for review bills 21
coming due on a certain date. 22
Claim 20 requires the portal interface element be adapted to allow a 23
consumer to pay bills from a plurality of different visual interfaces, each on 24
a different site. The Appellant argues Haseltine fails to describe this (Br. 15-25
Appeal 2008-3804
Application 09/751,265

16
16). We found that Haseltine described the capacity to use a plurality of 1
different visual interfaces and a portal to access different sites in our analysis 2
of claim 1 supra. 3
The Appellant has not sustained its burden of showing that the Examiner 4
erred in rejecting claims 1-16 and 18-20 under 35 U.S.C. § 102(e) as 5
anticipated by Haseltine. 6
Claim 17 rejected under 35 U.S.C. § 103(a) as unpatentable over Haseltine 7
and Kamen. 8
Claim 17 requires the portal interface element be adapted to allow a 9
consumer to modify, online, the format in which a bill is presented on a 10
visual interface. The Examiner found that Kamen described allowing a user 11
to so modify graphics (Answer 13-14). The Appellant argues that Kamen 12
does not use bills or report processors (Br. 16-17). 13
The Appellant responds to the rejection by attacking the references 14
separately, even though the rejection is based on the combined teachings of 15
the references. Nonobviousness cannot be established by attacking the 16
references individually when the rejection is predicated upon a combination 17
of prior art disclosures. See In re Merck & Co. Inc., 800 F.2d 1091, 1097 18
(Fed. Cir. 1986). 19
The Appellant has not sustained its burden of showing that the Examiner 20
erred in rejecting claim 17 under 35 U.S.C. § 103(a) as unpatentable over 21
Haseltine and Kamen. 22
Appeal 2008-3804
Application 09/751,265

17
CONCLUSIONS OF LAW 1
The Appellant has not sustained its burden of showing that the Examiner 2
erred in rejecting claims 1-16 and 18-20 under 35 U.S.C. § 102(e) as 3
anticipated by Haseltine, or in rejecting claim 17 under 35 U.S.C. § 103(a) 4
as unpatentable over the prior art. 5
DECISION 6
To summarize, our decision is as follows: 7
• The rejection of claims 1-16 and 18-20 under 35 U.S.C. § 102(e) as 8
anticipated by Haseltine is sustained. 9
• The rejection of claim 17 under 35 U.S.C. § 103(a) as unpatentable 10
over Haseltine and Kamen is sustained. 11
No time period for taking any subsequent action in connection with this 12
appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv). 13
14
AFFIRMED 15
16
17
vsh 18
19
REINHART BOERNER VAN DEUREN S.C. 20
ATTN: LINDA KASULKE, DOCKET COORDINATOR 21
1000 NORTH WATER STREET 22
SUITE 2100 23
MILWAUKEE WI 53202 24