IN THE UNITED STATES PATENT TRIAL AND APPEAL...
Transcript of IN THE UNITED STATES PATENT TRIAL AND APPEAL...
IN THE UNITED STATES PATENT TRIAL AND APPEAL BOARD
In re Covered Business Method Review of: U.S. Patent No. 5,895,468
Issued: April 20, 1999 Inventor: Wesley W. Whitmyer, Jr. Application No. 08/726,999 Filed: October 7, 1996 For: SYSTEM AUTOMATING DELIVERY OF PROFESSIONAL SERVICES
))))))))))) ) ) ) ) ) ) )
U.S. Class: 707/010; 707/501;
707/513; 705/26; 395/200.47; 395/200.48
Group Art Unit: Confirmation No. Petition filed: January 22, 2015 FILED ELECTRONICALLY PER 37 C.F.R. § 42.6(b)(1)
Mail Stop Patent Board Patent Trial and Appeal Board U.S.P.T.O. P.O. Box 1450 Alexandria, VA 22313-1450
PETITION FOR POST-GRANT COVERED BUSINESS METHOD
PATENT REVIEW OF U.S. PATENT NO. 5,895,468 UNDER 35 U.S.C. § 321 AND § 18 OF THE LEAHY-SMITH AMERICA INVENTS ACT
i
TABLE OF CONTENTS Page
TABLE OF AUTHORITIES ................................................................................... iv
I. MANDATORY NOTICES ............................................................................ 1
II. OVERVIEW OF THE ’468 PATENT ........................................................... 2
III. GROUNDS FOR COVERED BUSINESS METHOD STANDING ............ 4
A. At Least One Challenged Claim is Unpatenable ................................. 4
B. At Least One of The Challenged Claims is Directed to a Covered Business Method. ................................................................... 4
C. The Challenged Claims are Not Directed to a “Technological Invention.” ............................................................................................ 8
D. Petitioner Has Been Sued for Infringement and Is Not Estopped. ............................................................................................ 11
IV. PRECISE RELIEF REQUESTED ............................................................... 11
V. CLAIM CONSTRUCTION ......................................................................... 12
A. Person of Ordinary Skill in the Art of the ’468 Patent ....................... 12
B. Broadest Reasonable Interpretation ................................................... 13
C. Support for Petitioner’s Broadest Reasonable Interpretations ........... 13
VI. CLAIMS 1-4, 9, 13-16, AND 24-27 OF THE ’468 PATENT ARE INVALID UNDER 35 U.S.C. §§ 101, 102, 103, AND 112 ¶¶ 1, 2, 6. ....... 15
A. [Ground 1] Claims 1-4, 9, 13-16, and 24-27 Are Invalid Under 35 U.S.C. § 101 as Being Directed to a Patent-Ineligible Abstract Idea. ...................................................................................... 15
1. The Challenged Claims Are Directed to the Abstract Idea of Recordkeeping And Client Reminders Relating to Deadlines. ................................................................................. 16
2. The claims fail the second step of the Alice analysis. .............. 19
ii
a. The generically claimed computer, software, and database elements are not “inventive concepts.” ........... 19
b. The generic form templates and client reminders add no “inventive concept” to merit patent eligibility. ....................................................................... 22
c. Failure of the Machine-or-Transformation Test. ........... 24
3. The Dependent Claims add no patentable subject matter. ....... 25
B. [Ground 2] Claims 1-4, 9, and 13-16 Are Invalid Functional Claims Under 35 U.S.C. § 112, ¶ 6. ................................................... 26
1. The device claims should be treated as MPF claims. .............. 26
2. The specification does not disclose any algorithm or code. .... 30
C. [Ground 3] Claims 1-4, 9, 13-16 , and 24-27 Are Indefinite Under Section 112, ¶ 2 ....................................................................... 32
D. [Ground 4] Claims 1-4, 9, 13-16 , and 24-27 Are Invalid under 35 U.S.C. § 112, ¶ 1. .......................................................................... 33
E. [Ground 5] Claims 1-4, 24-27 Are Invalid as Anticipated Under 35 U.S.C. § 102 by the Network Solutions Message Ticketing System. ............................................................................................... 34
1. MTS was a publicly known and used prior art system. ........... 35
2. MTS contains each element of claims 1-4 and 24-27. ............. 40
F. [Ground 6] Claims 1-4, 9, 13-16, 24-27Are Invalid as Obvious Under § 103 in View of MTS and Knowledge of One Having Ordinary Skill. .................................................................................... 54
G. [Ground 7] Claims 1-4, 9, 13-16, 24-27 Are Invalid as Obvious Under 35 U.S.C. § 103 in View of PerfectLaw, Alone or in Combination with MTS. ..................................................................... 58
1. PerfectLaw Qualifies as Prior Art. ........................................... 59
2. PerfectLaw Docketing and Document Assembly Software. .................................................................................. 60
iii
3. One of Ordinary Skill Would Be Motivated to Combine PerfectLaw with Common Knowledge or with MTS. ............. 63
a. Combining PerfectLaw with Ordinary Skill.................. 64
b. Combining MTS with PerfectLaw ................................ 67
4. MTS and PerfectLaw Obviousness Claim Charts ................... 68
VII. CONCLUSION ............................................................................................. 78
CERTIFICATE OF SERVICE ............................................................................... 79
iv
TABLE OF AUTHORITIES
Page(s) FEDERAL CASES
3M v. Chemque, Inc., 303 F.3d 1294 (Fed. Cir. 2002) .......................................................................... 59
Accenture Global Servs., GmbH v. Guidewire Software, Inc., 728 F.3d 1336 (Fed. Cir. 2013) .......................................................................... 17
Alice Corp. Pty. Ltd. v. CLS Bank Int’l, 134 S. Ct. 2347 (2014) ................................. 15, 16, 17, 18, 19, 20, 21, 22, 24, 25
Apex Inc. v. Raritan Computer, Inc., 325 F.3d 1364 (Fed. Cir. 2003) .................................................................... 26, 29
Aristocrat Techs. Australia Pty Ltd. v. Int’l Game Tech., 521 F.3d 1328 (Fed. Cir. 2008) .......................................................................... 30
Aspen Eyewear, Inc. v. Altair Eyewear, Inc., 288 Fed. Appx. 697 (Fed. Cir. 2008) .................................................................. 27
Avante Int’l Tech. Corp. v. Premier Election Solns., Inc., No. 4:06cv0978 TCM, 2008 WL 2783237 (E.D. Mo. July 16, 2008) .......................................... 33
Bancorp Servs., L.L.C. v. Sun Life Assurance Co., 687 F.3d 1266 (Fed. Cir. 2012) .......................................................................... 24
Bilski v. Kappos, 561 U.S. 593 (2010) ............................................................................................ 16
Biomedino, LLC v. Waters Techs. Corp., 490 F.3d 946 (Fed. Cir. 2007) ............................................................................ 28
buySAFE, Inc. v. Google, Inc., 765 F.3d 1350 (Fed. Cir. 2014) ....................... 16, 20
CRS Advanced Techs., Inc. v. Frontline Techs., Inc., CBM2012-00005, Paper No. 17 (Dec. to Inst.) (PTAB Jan. 23, 2013) .............................................. 9
CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366 (Fed. Cir. 2011) .......................................................................... 25
v
DealerSocket, Inc. v. AutoAlert, Inc., CBM2014-00146, Paper No. 19 (Dec. to Inst.) (PTAB Dec. 9, 2014) ................. 9, 18, 20-22, 24, 25 Dealertrack, Inc. v. Huber,
674 F.3d 1315 (Fed. Cir. 2012) .................................................................... 18, 25
Ebay, Inc. v. Kelora Sys., No. C10-4947CW, 2012 WL 1835722 (N.D. Cal. May 21, 2012) .................... 57
Eclipse IP LLC v. McKinley Equip. Corp., No. 4-742-GW(AJWx), 2014 WL 4407592 (C.D. Cal. Sept. 4, 2014) ........ 18, 22
Eolas Techs. Inc. v. Microsoft Corp., 399 F.3d 1325 (Fed. Cir. 2005) .......................................................................... 35
ePlus, Inc. v. Lawson Software, Inc., 700 F.3d 509 (Fed. Cir. 2012) ...................................................................... 31, 59
Ex Parte Sung-Sik Jung, No. 2008-005636, 2009 WL 3089021 (BPAI 2009) .......................................... 57
Function Media, LLC v. Google, Inc., 708 F.3d 1310 (Fed. Cir. 2013) .......................................................................... 31
Garmin Int’l, Inc. v. Cuozzo Speed Techs. LLC, IPR2012-00001, Paper 59 (Final Written Decision) (PTAB November 13, 2013) ...................................... 36
In re Clay, 966 F.2d 656 (Fed. Cir. 1992) ............................................................... 67
In re Lister, 583 F.3d 1307 (Fed. Cir. 2009) ........................................................... 58
Interthinx, Inc. v. Corelogic Solns., CBM2012-00007, Paper 16 (Dec. to Inst.) (PTAB Jan. 31, 2013). .................................................. 11 Inventio AG v. ThyssenKrupp Elevator Americas Corp.,
649 F.3d 1350 (Fed. Cir. 2011) .......................................................................... 27
KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398 (2007) ................................................ 62
Liberty Mutual Ins. Co. v. Progressive Casualty Ins.Co., CBM2012-00002, Paper 66 (Final Written Decision) (P.T.A.B. Jan. 23, 2014) ............................. 54
vi
Lighting World, Inc. v. Birchwood Lighting, Inc., 382 F.3d 1354 (Fed. Cir. 2004) .......................................................................... 26
Lockwood v. Am. Airlines, Inc., 107 F.3d 1565 (Fed.Cir.1997) ................................................................ 33, 35, 39
Markem-Imaje Corp. v. Zipher Ltd., No. 07-cv-00006-PB, 2012 WL 3263517 (D. N.H. Aug. 9, 2012) .................... 31
Maurice Mitchell Innovations, L.P. v. Intel Corp., No. 2:04–CV–450, 2006 WL 1751779 (E.D. Tex. June 21, 2006) .................... 29
Medtronic, Inc. v. Cardiac Pacemakers, 721 F.2d 1563 (Fed. Cir. 1983) .......................................................................... 67
Microsoft Corp. v. Surfcast, Inc., IPR2013-00292, et al., Paper 93 (Final Written Decision) (PTAB October 14, 2014) ................................ 36 Muniauction, Inc. v. Thomson Corp.,
532 F.3d 1318 (Fed. Cir. 2008) .................................................................... 20, 56
Nautilus, Inc. v. Biosig Instruments, Inc., 134 S.Ct. 2120 (2013) ................................................................................... 31, 32
Netscape Commnc’ns Corp. v. Konrad, 295 F.3d 1315 (Fed. Cir. 2002) .......................................................................... 35
Noah Sys., Inc. v. Intuit Inc., 675 F.3d 1302 (Fed. Cir. 2012) .......................................................................... 30
Par Pharm., Inc. v. Jazz Pharms., Inc., CBM2014-00149, Paper 11 (Decision) (PTAB Jan. 13, 2015) ................................. 5 Perfect Web Technologies, Inc. v. InfoUSA, Inc.,
587 F.3d 1324 (Fed. Cir. 2009) .......................................................................... 63
Ranpak Corp. v. Storopack, Inc., 168 F.3d 1316 (Fed. Cir. 1998) .......................................................................... 29
Robert Bosch, LLC v. Snap-On Inc., 769 F.3d 1094 (Fed. Cir. 2014) .............................................................. 26, 28, 30
SAP Am., Inc. v. Versata Dev. Grp., Inc.,No. CBM2012-00001,
vii
Paper 36 (Dec. to Inst.) (PTAB Jan. 9, 2013) ......................................... 5, 8, 9, 11 SAP America, Inc. v. Arunachalam, CBM2013-00013, Paper 61 (Final
Written Decision) (PTAB September 18, 2014) ................................................ 32
Sci. Plastic Prods., Inc. v. Biotage AB, 766 F.3d 1355,(Fed. Cir. 2014) .......................................................................... 67 Teva Pharm. Inds. Ltd. v. AstraZeneca Pharms. LP,
661 F.3d 1378 (Fed. Cir. 2011) .......................................................................... 35
Thought, Inc. v. Oracle Corp., No. 12-cv-05601, 2014 WL 5408179 (N.D. Cal. Oct. 22, 2014) ....................... 29
Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709 (Fed. Cir. 2014) .......... 20, 21, 24, 25
Verdegaal Bros., Inc. v. Union Oil Co. of Cal., 814 F.2d 628 (Fed. Cir. 1987) ............................................................................ 40
Versata Software, Inc. v. Internet Brands, Inc., 902 F. Supp. 2d 841 (E.D. Tex. 2012) ................................................................ 57
Visual Networks Operations, Inc. v. Paradyne Corp., No. DKC 2004-0604, 2005 WL 1411578 (D. Md. June 15, 2005) .................... 29
W. L. Gore & Assoc. v.Garlock, Inc., 721 F.2d 1540 (Fed. Cir. 1983) .......................................................................... 34
Walhonde Tools, Inc. v. Wilson Works, Inc., No. 1:09CV48, 2012 WL 1965628 (N.D. W. Va. May 31, 2012) ..................... 29
WhitServe LLC v. CPi, 694 F.3d 10 (Fed. Cir. 2012) ............................................................................ 6, 7
Wyers v. Master Lock Co., 616 F.3d 1231 (Fed. Cir. 2010) .......................................................................... 63
Zenith Elecs. Corp. v. PDI Commnc’s Sys., Inc., 522 F.3d 1348 (Fed. Cir. 2008) .......................................................................... 35
FEDERAL STATUTES
35 U.S.C. § 101 .................................................................................... 1, 8, 11, 15, 23
viii
35 U.S.C. §§ 102 ................................................................... 1, 12, 33, 34, 35, 40, 43
35 U.S.C. § 102(a) ............................................................................................. 34, 40
35 U.S.C. § 102(g)(2)................................................................................... 34, 35, 40
35 U.S.C. § 103 ........................................................................................... 54, 57, 58
35 U.S.C. § 112 ¶ 1 ...................................................................................... 12, 32, 33
35 U.S.C. § 112 ¶ 2 ........................................................................................... 31, 32
35 U.S.C. § 112 ¶ 6 ........................................................................................... 26, 31
35 U.S.C. § 321 ........................................................................................................ 11
35 U.S.C. § 324(a) ..................................................................................................... 4
REGULATIONS
37 C.F.R. § 42.300 ............................................................................................... 1, 13
37 C.F.R. § 42.301 ............................................................................................. 4, 5, 8
37 C.F.R. § 42.302 ................................................................................................... 11
77 Fed. Reg. 48734-35 ........................................................................................... 5, 6
77 Fed. Reg. 48739 .................................................................................................... 7
77 Fed. Reg. 48756, 48763-48764 (Aug. 14, 2012) .................................................. 8
79 Fed. Reg. 74618-32 ............................................................................................ 15
OTHER AUTHORITIES
Manual of Patent Examining Procedure § 2132 ...................................................... 35
Manual of Patent Examining Procedure § 2141 ................................................ 13, 62
Manual of Patent Examining Procedure § 2143 ................................................ 10, 56
Manual of Patent Examining Procedure § 2144.08 ................................................. 58
Manual of Patent Examining Procedure § 2181 ................................................ 30, 31
ix
LIST OF EXHIBITS
Exhibit 1001: U.S. Patent No. 5,895,468
Exhibit 1002: U.S. Patent No. 5,895,468 File History
Exhibit 1003: Declaration of Dr. Ben Goldberg
Exhibit 1004: Foonberg, How to Start and Build a Law Practice (1976)
Exhibit 1005: Ulrich, Appellate Advocacy (1978)
Exhibit 1006: Vertical Marketing Software (1989)
Exhibit 1007: The Internet for Dummies (1993)
Exhibit 1008: Que’s Computer & Internet Dictionary (“web server”) (1995)
Exhibit 1009: New Merriam Webster Dictionary (“software”) (1989)
Exhibit 1010: IBM Dictionary of Computing (“software”) (1994) Exhibit 1011: IEEE Standard Dictionary of EE Terms (“software”)
(1984) Exhibit 1012: Webster New World Dictionary (“FTP”) (1997) Exhibit 1013: Judge Young Markman Orders Exhibit 1014: PerfectLaw Materials (Duncan Dep. & Exs. 4-14) Exhibit 1015: Declaration of Matthew Ho Exhibit 1016: Declaration of Mark Kosters
Pursuant to 35 U.S.C. § 321, Section 18 of the Leahy-Smith America
Invents Act (“AIA)” and 37 C.F.R. § 42.300 et seq., the undersigned Petitioner
respectfully requests a covered business method review of claims 1-4, 9, 13-16,
and 24-27 of U.S. Patent No. 5,895,468 (“the ’468 patent,” Ex. 1001), which was
filed on October 7, 1996 as U.S. Patent Application No. 08/726,999. The ’468
patent issued on April 20, 1999 to patent attorney Wesley W. Whitmyer, Jr, and is
currently assigned to Mr. Whitmyer’s company, WhitServe LLC (“WhitServe” or
“Patent Owner”). Petitioner demonstrates below that claims 1-4, 9, 13-16, and 24-
27 of the ’468 patent (“the Challenged Claims”) are more likely than not patent
ineligible under 35 U.S.C. § 101 and fail the patentability requirements of 35
U.S.C. §§ 102, 103, and 112 ¶¶ 1, 2, and 6.
I. MANDATORY NOTICES
Real Party-in-Interest: GoDaddy.com, LLC (f/k/a GoDaddy.com, Inc.).
Related Matters: WhitServe LLC v. GoDaddy.com, Inc., Civil Action No.
3:11-cv-00948-WGY (D. Conn.) (hereinafter, the “Litigation”).
Lead and Back-Up Counsel and Service Information:
Lead Counsel Scott D. Marty, Ph. D. USPTO Reg. No. 53,277 BALLARD SPAHR LLP 999 Peachtree Stree, Suite 1000 Atlanta, GA 30309-3915 Telephone: 678-420-9408
Back-up Counsel Jonathon A. Talcott USPTO Reg. No. 71,671 BALLARD SPAHR LLP 1 East Washington Street, Suite 2300 Phoenix, AZ 85004-2555 Telephone: 602-798-5485
2
Fax: 678-420-9301 [email protected]
Fax: 602-798-5595 [email protected]
Daniel A. Nadel USPTO Reg. No. 59,655 BALLARD SPAHR LLP 1735 Market Street, 51st Floor Philadelphia, PA 19103-7599 Telephone: 215-864-8844 Fax: 215-864-8999 [email protected]
II. OVERVIEW OF THE ’468 PATENT
The ’468 patent is entitled “System Automating Delivery of Professional
Services.” Ex. 1001. It contains three independent “device” claims, one
independent “method” claim, and twenty-three dependent claims. The Challenged
Claims are directed to automating the delivery of deadline-oriented services using
computers, databases, software, and the Internet. See id. at Abstract, 1:5-8.
As the patent’s background explains, tasks performed by “professionals”
routinely involve actions taken in response to deadlines. Id. at 1:12-26. Those
deadlines naturally trigger a series of events, including: (i) the professional sending
the client reminders pertaining to the deadline through response forms, (ii) the
client taking action in response to those reminders and response forms, (iii) the
professional receiving the client’s reply, (iv) the professional reacting to the
client’s reply, and so forth. See id. at 1:27-53. These events may, in turn,
necessitate communications to third parties such as authorizations to financial
institutions, government agencies, and the like. Id. at 3:46-56. The patent
3
observes that manually monitoring deadlines and handling the responsive actions is
expensive, time-consuming, and risky in terms of human error creeping into the
process. Id. at 1:17-26, 1:46-53. Thus, “[w]hat is desired . . . is an automated
system for obtaining authorizations from clients prior to deadlines which will
improve the speed, efficiency, and reliability of performing professional services
for clients.” Id. at 2:6-9.
However, as the specification concedes, the concept of “automating” these
conventional reminders and deadline-triggered tasks was far from new. Rather,
“[s]everal systems ha[d] been developed for facilitating some of the functions
which professionals must perform.” Id. at 27-28. In fact, the “most common”
prior art automated docketing systems already used a “networked computer” for
automatically “examining a calendar periodically to notice upcoming deadlines”
from “a database of deadlnes” based on “a preset time period before the deadline.”
Id. at 1:27-39. According to the ’468 patent, then, all that was missing was
automating certain remaining steps of the professional services delivery process
identified above (i.e., generating the reminders and response forms and receiving
replies thereto), and exchanging them through “modern computer communications
media, such as the Internet.” Id. at 1:36-2:5; Ex. 1002 at 0116-0118.
As representative claim 1 reveals, the ’468 patent supposedly claims
bridging this automation gap and eliminating prior art manual steps by running
4
software on a computer that automatically (i) queries a database for upcoming
deadlines, (ii) populates reminder template forms using client-specific information
from the database, and then (iii) processes their exchange among the client,
professional, and third parties (as needed) through the Internet. See Ex. 1001 at
6:55-7:8.
The remaining Challenged Claims at issue add little substance to claim 1:
adding a “notice containing a URL” that retrieves the form from a “web server”
when activated (claims 9, 13-16), generating a response based on the client reply
and sending it to a third party (claims 2, 14, 25), updating the database based on
the reply (claims 3, 15, 26), confirming receipt of the reply (claims 4, 16, and 27),
and implementing claim 1 as a “method” instead of a “device” (claim 24). See Ex.
1001. The ’468 patent essentially claims to automate basic, routine activity
undertaken by professionals for decades, if not centuries, hence, this Petition.
III. GROUNDS FOR COVERED BUSINESS METHOD STANDING
A. At Least One Challenged Claim is Unpatenable
For the reasons set forth herein, it is more likely than not that at least one
claim of the ’468 patent is unpatentable. 35 U.S.C. § 324(a).
B. At Least One of The Challenged Claims is Directed to a Covered Business Method.
The ’468 patent is a “covered business method patent” as defined under § 18
of the AIA and 37 C.F.R. § 42.301. Section 18(d)(1) of the AIA identifies a
5
covered business method patent as “a patent that claims a method or corresponding
apparatus for performing data processing or other operations used in the practice,
administration, or management of a financial product or service.” See also 37
C.F.R. § 42.301(a) (reciting similar language). As supported by the legislative
history, the USPTO has indicated that it broadly defines the term “covered
business method patent” to encompass patents claiming activities that are financial
in nature, incidental to a financial activity or complementary to a financial activity.
See 77 Fed. Reg. 48734-35; SAP Am., Inc. v. Versata Dev. Grp., Inc., No.
CBM2012-00001, Paper 36 (Dec. to Inst.), Page 23 (PTAB Jan. 9, 2013) (“SAP”).
Further, the Board analyzes the claim language in light of the embodiments in the
specification to determine whether the claims recite an apparatus or method used in
or incidental to the “practice, administration, or management of a financial product
or service.” Cf. Par Pharm., Inc. v. Jazz Pharms., Inc., CBM2014-00149, Paper
11 (Decision), Pages 15-16 (PTAB Jan. 13, 2015). The ’468 patent plainly
qualifies as a “covered business method patent,” as it involves the movement of
money in providing a professional service such as paying a maintenance fee or
annuity due on an issued patent.
The Challenged Claims are directed to automatically delivering professional
services that are used in (and incidental to) the practice, administration and
management of financial products and services, and for activities that are financial
6
in nature. See Ex. 1001. Specifically, the Challenged Claims encompass
automating the delivery of “professional services” (including financial
professionals) to purportedly “improve[] the speed, efficiency, and reliability of
performing services for clients,” to avoid the client having “to pay enormous late
fees” due to a missed deadline. Id. at 1:17-20, 2:16-19. For example, claims 2, 6,
10, 14, and 25 all recite “generating a response based on the [client’s] reply; and
transmitting the response to a third party.” Ex. 1001 at 7:9-12, 7:54-57, 8:20-23,
8:38-42, 10:26-30. The ’468 Patent specification explicitly states that this claimed
transmission of the client’s response to a third party includes communicating with
a bank to transfer the client’s funds:
The type of action based on the reply 24 depends on the reply 22, and
may include such actions as . . . generating a transfer of funds
authorization and transferring the authorization to a bank[.]
Ex. 1001 at 3:46-54 (emphasis added), 4:46-54, 6:19-28. The ’468 patent does not
limit its scope to automating bank and fund transfer authorizations, as it states this
is only one of the patent’s contemplated financial services. Id. at 4:56-60. See
also Ex. 1003, Goldberg Decl. ¶ 43. Indeed, WhitServe successfully sued
Computer Packages, Inc. (“CPi”) on the ’468 Patent based on CPi’s patent annuity
product that reminds clients of paying upcoming patent or trademark annuity or
maintenance fee deadlines. WhitServe LLC v. CPi, 694 F.3d 10, 17 (Fed. Cir.
2012). This accused facilitation and management of financial transactions makes
7
clear that the ’468 Patent qualifies as a covered business method patent. The ’468
patent is also classified under various data processing sub-categories, most notably
Class 705, Sub-Class 26, which relates to the financial business process of
“electronic shopping (e.g., remote ordering).” Ex. 1001 at 1 [52]. “[P]atents
subject to covered business method patent review are anticipated to be typically
classifiable in Class 705.” 77 Fed. Reg. 48739; see also Travelocity.com L.P. v.
Cronos Techs., LLC, CBM 2014-00082, Paper 10 at 9-11 (Sept. 15, 2014) (finding
that claims covering e-commerce transactions meet the CBM criteria). The
Challenged Claims purportedly cover electronic commerce and banking. For
example, a customer can receive an electronic notification from a credit card
company informing them that payment is due on an account, the credit card
company can receive the shopper’s instructions to pay the account online and it can
then transmit that instruction to a bank for payment. This activity falls directly
within the broad scope of Claims 2, 6, 10, 14, and 25, which at their most basic
level require reminding customers of deadlines and receiving their instructions for
payment. Additionally, during prosecution of the ’468 Patent, the Patent Office
cited United States Patent No. 5,548,753 as prior art, which teaches automation of
electronic mail notification to accounting personnel. Ex. 1002 at 0107 (emphasis
added). This prior treatment by the PTO of the Challenged Claims as covering
electronic commerce and accounting firms further supports the patent’s
8
qualification as a “covered business method patent.”
C. The Challenged Claims are Not Directed to a “Technological
Invention.”
A “covered business method patent” under AIA § 18 does not include
patents for “technological inventions.” AIA § 18(d)(1). A patent claims a
“technological invention” if “the claimed subject matter as a whole recites a
technological feature that is novel and unobvious over the prior art; and solves a
technical problem using a technical solution.” AIA § 18(d)(2); 37 C.F.R. §
42.301(b). However, claim drafting techniques that merely recite (i) known
technologies; (ii) prior art technology to accomplish a process or method; or
(iii) combined prior art structures to achieve the expected result do not render a
patent a “technological invention.” 77 Fed. Reg. 48756, 48763-48764 (Aug. 14,
2012); see SAP at 25.
The Challenged Claims fail to claim any novel or nonobvious technological
feature. As set forth in detail in connection with the § 101 ineligibility analysis,
infra, the only technological features recited in the Challenged Claims are generic
computers, servers, databases, software, and the Internet—all technology that was
well-known in the art before the patent’s October 7, 1996 filing date. Ex. 1003 at
¶¶ 53-64. The ’468 patent claims using this conventional technology only in the
most obvious way: to “automate” the delivery of non-technical services like “the
9
standard docketing system” to “improve[] the speed, efficiency, and reliability of
performing services for clients” (id. at 2:16-19) and “employ[ing] modern
computer communications media, such as the Internet.” Ex. 1001 at 1:12-2:14; Ex.
1003 at ¶¶ 32-35. See SAP at 28; CRS Advanced Techs., Inc. v. Frontline Techs.,
Inc., CBM2012-00005, Paper 17 (Dec. to Inst.), 6-9 (PTAB Jan. 23, 2013). To the
extent the other features recited by the Challenged Claims could conceivably be
considered technological—the “client reminder,” “response form,” and actions
taken in response thereto—the patentee expressly admitted those features were
already in the prior art. See Ex. 1001 at 1:10-53. Certainly “executing” generic
“software” to retrieve or generate the reminders and forms adds nothing
technologically new, nor does “employ[ng] modern communications” like the
Internet or its inherent attendants of email, URLs, and web servers. E.g., Ex. 1001
at 1:55-56, 4:31-36, 5:9-61; Ex. 1003 at ¶¶ 64, 73-78; DealerSocket, Inc. v.
AutoAlert, Inc., CBM2014-00146, Paper No. 19 (Dec. to Inst.) at 11-12 (PTAB
Dec. 9, 2014) (“DealerSocket”).
Nor does the ’468 patent solve a technical problem using a novel or
nonobvious technical solution. It is obvious by law to “improve[] the speed,
efficiency, and reliability” through the automation of a process using known
technology, and this is all the patent’s purported solution accomplishes. Ex. 1001
at 1:36-53, 2:17-19. See DealerSocket at 12-13 (claimed calculation of payments
10
and generation of customer alerts based on retrieved information and conditions
“using known automated tools” was not a technical solution); MPEP § 2143(IV).
Likewise, storing and querying values relating to deadlines as the ’468 patent
claims cannot possibly be a technological invention or solution. To overcome the
prior art, the patentee amended the claims to specifiy that the “client reminder”
entry in the database must contain a certain basic type of information—“a date
field having a value attributed thereto”—which the patentee explained “include[s]
deadlines for the services to be rendered.” Ex. 1002 at 0116-0117, 0127-0128,
0131-0134. As a corollary, the patentee amended the claimed “querying” process
to clarify that the database is queried “by the values attributed to each client
reminder date field.” Id. at 0131-0134. This was to clarify that the querying
process as claimed “means identifying those reminders with impending deadlines
and discarding those without impending deadlines . . . depending on the value of
the field” instead of the prior art’s “presence or absence of data.” Id. at 0117.
To the extent claiming date fields checked by “values” is a “solution” at all
(it is not), it is nowhere near any “technological” advancement over the prior art,
for the patent admits the prior art “examin[ed] a calendar periodically to notice
upcoming deadlines” that were “typically contain[ed in] a database.” Ex. 1001 at
1:27-39; see Ex. 1003 at ¶¶ 16-33. The type of information claimed as the client
reminder and process of querying by values is certainly fundamental data
11
management, exactly like the allegedly novel “hierarchical data structures [for]
organiz[ing] pricing information” held by this Board to be non-technological. SAP
at 28. Accordingly, the ’468 patent claims are not directed to a “technological
invention.”
D. Petitioner Has Been Sued for Infringement and Is Not Estopped.
On June 14, 2011, WhitServe sued Petitioner for infringement of the ’468
patent and related United States Patent No. 6,182,078 in WhitServe LLC v.
GoDaddy.com, Inc., Civil Action No. 3:11-cv-00948-WGY (D. Conn.), and thus
Petitioner meets the requirements of AIA § 18(a)(1)(B) and 37 C.F.R. § 42.302.
Petitioner is not estopped from challenging the ’468 patent on the grounds
identified, per 37 C.F.R. § 42.302(b), because no final judgment has been entered
in the Litigation on the validity of the claims, unpatentability of the claims have
not been litigated under a preponderance of the evidence standard as applied by
this Board, and there is no preclusive effect of any order issued by the district court
regarding invalidity of the claims presented by this Petition. Interthinx, Inc. v.
Corelogic Solns., CBM2012-00007, Paper 16 (Dec. to Inst.), Pages 9-10 (PTAB
Jan. 31, 2013).
IV. PRECISE RELIEF REQUESTED
Petitioner respectfully requests review under 35 U.S.C. § 321 and AIA § 18
of following ’468 patent claims, and their cancellation on the following grounds:
12
Ground 1 (claims 1-4, 9, 13-16, 24-27): Invalid patent-ineligible abstract
idea under 35 U.S.C. § 101.
Ground 2 (claims 1-4, 9, 13-16): Invalid functional claiming under 35
U.S.C. § 112 ¶ 6.
Ground 3 (claims 1-4, 9, 13-16, 24-27): Invalid as indefinite under 35
U.S.C. § 112 ¶ 2.
Ground 4 (claims 1-4, 9, 13-16, 24-27): Invalid as lacking written
description under 35 U.S.C. § 112 ¶ 1.
Ground 5 (claims 1-4, 24-27): Anticipated under 35 U.S.C. § 102 by the
Network Solutions Message Ticketing System (“MTS”).
Ground 6 (claims 1-4, 9, 13-16, 24-27): Obvious under 35 U.S.C. § 103 in
view of MTS.
Ground 7 (claims 1-4, 9, 13-16, 24-27): Obvious under 35 U.S.C. § 103 in
view of PerfectLaw, alone or in combination with MTS.
As described in the Sections below, these grounds are not cumulative and, in fact,
each is based on separate statutory requirements for patentability or patent
eligibility.
V. CLAIM CONSTRUCTION
A. Person of Ordinary Skill in the Art of the ’468 Patent
The ’468 patent is directed to the problem of automating the monitoring and
13
delivery of deadline-based notices and response forms over the Internet. See, e.g.,
Ex. 1001 at Abstract and columns 1-2. To automate the functions as claimed in
computer-implemented software, database, and Internet technology, a person of
ordinary skill (or “POSA”) in the subject matter of the ’468 patent would need to
possess a Bachelor’s degree in computer science or related field, and two to three
years of experience as a programmer in industry or the educational equivalent
thereof (such as a Master’s degree in computer science). See Ex. 1003 at ¶¶ 38-41.
However, since the purported technological features of the ’468 patent involve
only conventional, general computing platforms, no specialized or sophisticated
computer-based or other technical knowledge is required—only general knowledge
of that technology which one would have with the educational and experience level
as noted is needed. Id.; see MPEP § 2141(II)(C).
B. Broadest Reasonable Interpretation
Petitioner submits that the following terms are to be given their broadest
reasonable constructions as stated below and supported by the declaration of Dr.
Benjamin Goldberg (Ex. 1003) at ¶¶ 42-46. 37 C.F.R. § 42.300(b).
C. Support for Petitioner’s Broadest Reasonable Interpretations
Professional services: While the ’468 patent specification provides an
example of the services to be rendered mainly in the context of legal professional
services, the claims are not limited to any particular kind of profession or service,
14
or even any profession at all, since “professional services” is recited only in their
preambles. Ex. 1001 at 1:12-13,1:13-2:14, 6:55-56, 7:66-67, 10:8-9. The district
court in the underlying Litigation did not construe this term as a limitation on the
body of the claims, which is consistent with the view of one having ordinary skill
in the art that the BRI of “professional services” is not limited to any particular
profession or service. Ex. 1003 at ¶¶ 43-44; Ex. 1013.
Client reminder: This term should be construed as a “record containing
information pertinent to an upcoming service for a client.” The specification
describes a “client reminder” as “contain[ing] information pertinent to the
upcoming professional service to be rendered.” Ex. 1001 at 3:25-29. The patent
gives various examples of such information, including a client name, client e-mail
address, type of service to be rendered, deadline for the service to be rendered, an
individual professional responsible for the client, name of the client contact person,
and “others.” Id. at 3:25-29. The patent describes querying a docket database to
retrieve these client reminders on a periodic basis to remind clients of deadlines.
See id. at col. 3, ll.21-23. See Ex. 1013 [Order re “client reminder”]; Ex. 1003 at
¶ 45.
Client response form: The BRI of this term should be construed as a
“template form populated with client reminder information.” The ’468 patent
describes the “client response form,” or “response form” as it is interchangeably
15
abbreviated, as being automatically generated “based on the retrieved client
reminder” and as containing “pertinent information contained in the client
reminder as well as the client’s options regarding the professional service to be
performed.” Ex. 1001 at 3:30-37. Such options include “choices for alternative
professional services or simply whether or not the client authorizes a professional
service.” Id. at 3:37-40. Accordingly, the client response form contains client
reminder information upon which the client may act. Ex. 1003 at ¶ 46.
VI. CLAIMS 1-4, 9, 13-16, AND 24-27 OF THE ’468 PATENT ARE
INVALID UNDER 35 U.S.C. §§ 101, 102, 103, AND 112 ¶¶ 1, 2, 6.
A. [Ground 1] Claims 1-4, 9, 13-16, and 24-27 Are Invalid Under 35
U.S.C. § 101 as Being Directed to a Patent-Ineligible Abstract
Idea.
Under Alice Corp. Pty. Ltd. v. CLS Bank Int’l, 134 S. Ct. 2347 (2014), there
is a two-step framework for determining patent-eligibility for computer-
implemented ideas: (1) determine whether the claims are directed to a law of
nature, natural phenomena, or abstract idea; and (2) if so, determine whether the
claims recite an “inventive concept,” meaning “an element or combination of
elements that is ‘sufficient to ensure that the patent in practice amounts to
significantly more than a patent upon [the ineligible concept] itself.” Alice at
2354-59. See also 79 Fed. Reg. 74618-32 (“USPTO Eligibility Guidance”).
16
As analyzed below, the Challenged Claims cover no more than the abstract
idea of recordkeeping of deadlines, a reminder to clients regarding those deadlines,
and handling responses from clients regarding deadlines using generic computer,
software, and network technology that the Alice Court and its progeny have
rejected as patent eligible.
1. The Challenged Claims Are Directed to the Abstract Idea of
Recordkeeping And Client Reminders Relating to
Deadlines.
Under the first step required by Alice, it is necessary to determine “whether
the claims at issue are directed to a patent-ineligible concept.” Alice at 2355. In
doing so, a court must “consider[] all claim elements, both individually and in
combination” consistent with the general rule that “patent claims ‘must be
considered as a whole.’” Id. at 2355 n.3. An idea can be ineligibly abstract even if
the particular concept is “narrow” or provides a specific solution to a specific
problem. See Bilski v. Kappos, 561 U.S. 593, 599-601 (2010) (highly specific
method of price hedging directed to an ineligible abstract idea); buySAFE, Inc. v.
Google, Inc., 765 F.3d 1350, 1353 (Fed. Cir. 2014) (abstract idea of third party
“transaction performance guaranty”).
The ’468 patent as a whole, and certainly the Challenged Claims, claims the
following abstract idea: keeping a record of client deadlines, providing a form
17
reminder to the client with basic request for instructions on how to proceed, and
acting in accordance with the client’s instructions once the response to the
reminder form is received. Ex. 1003 at ¶ 48. This concept is fundamental to
delivering business services to clients that has been “long prevalent in our system
of commerce” and “taught in any introductory [profession] class” as a “building
block” of practice management. Alice at 2356. Indeed, as explained in detail by
Dr. Goldberg, maintaining file systems for storing client reminders, template
forms, and using calendar “ticklers” for acting on those reminders has been
fundamental to law and other businesses for decades, if not centuries. See Ex.
1003 at ¶¶ 16-30, 49-52. The concepts of tickler systems and using template forms
are also well-documented by the American Bar Association (“ABA”). Id. at ¶¶ 21-
28; Ex. 1004 [Foonberg] at 158, 165-69. Indeed, the “heart” of the legal office
management is the docketing and calendaring system which, similar to the ’468
patent’s client reminders and response forms, includes “checklists for all appellate
filing deadlines and time sequences; status sheets for each appeal; [and] a dockets
file” that is “essential” to avoid missing deadlines.” Ex. [Ulrich] at 32. And it is
“one of [a lawyer’s] most valuable assets” to maintain a “form file” of templates to
be filled in with client-specific information. Ex. [Foonberg] at 166-69. Certainly,
it is axiomatic that lawyers have checked deadlines and reminded clients about the
same in a non-automated fashion or by hand for decades, if not centuries.
18
The concepts found in these longstanding references are no different from
those claimed in the Challenged Claims. When stripped of their generic computer
elements, these claims boil down to the fundamental notion of monitoring
upcoming deadlines and providing clients reminders about basic information
needed to address them. See Ex. 1001, claims 1-4, 9, 13-16, 24-27. This abstract
idea is similar to the claims directed to the “method of exchanging financial
obligations” covering a fundamental intermediated settlement concept in Alice, and
similar to other broadly claimed fundamental business practices that courts and this
Board have found too abstract for patent-eligibility. See, e.g., Accenture Global
Servs., GmbH v. Guidewire Software, Inc., 728, F.3d 1336, 1344 (Fed. Cir. 2013)
(“generating tasks based on rules to be completed upon the occurrence of an event”
as patent-ineligibile); DealerSocket at 4-6, 32-36 (“automatically accessing”
vehicle lease terms from a database, “automatically generating a message,” and
“automatically transmitting the message” covered abstract idea of “providing
vehicle sales opportunities based on loan or lease payements”); Dealertrack, Inc. v.
Huber, 674 F.3d 1315, 1333 (Fed. Cir. 2012) (“processing [credit application]
information through a clearinghouse” by “receiving data . . ., selectively
forwarding the data . . . and forwarding reply data” too abstract for patent
eligibility); Eclipse IP LLC v. McKinley Equip. Corp., No. SACV 14-742-
GW(AJWx), 2014 WL 4407592 (C.D. Cal. Sept. 4, 2014) (“computer-based
19
notification system” with “message[s] requesting a response” held “directed to the
abstract idea of asking someone to do a task, getting an affirmative response, and
then waiting until the task is done.”). The Challenged Claims are likewise directed
to an abstract idea.
2. The claims fail the second step of the Alice analysis.
a. The generically claimed computer, software, and
database elements are not “inventive concepts.”
For the second step under Alice, it is necessary to determine whether the
elements of the claims “contain[] an inventive concept sufficient to transform the
claimed abstract idea into a patent-eligible application.” Alice at 2357. These
claim elements must include “additional features” that add “significantly more” to
the abstract idea. Id. The Alice Court explicitly found claiming abstract ideas
implemented on generic computers, databases, and networks performing their most
basic functions of storing, processing, and transmitting do not meet the criteria for
eligibility. Id. at 2358. But that is all the ’468 patent does when claiming to
“automate” the claimed reminder systems. Applying Alice to the ’468 patent’s
claims, the generic nature of the computer, database, forms, and Internet
limitations leaps out. The claims recite “automatically” performing on “a
computer” the claimed functions of querying and retrieving the client reminder,
generating the client response form, and transmitting and receiving
20
communications relating thereto. E.g., Ex. 1001 (claim 1). But the patent
discloses no specifics on how the claimed “computer” actually “automat[es]” any
of these actions, nor is there any reference to special computer hardware other than
a general purpose computer. See Ex. 1001 at cols. 3-6; Ex. 1003 at ¶¶ 53-64. Alice
held that “function[s] performed by the computer at each step—creating and
maintaining ‘shadow’ accounts, obtaining data, adjusting account balances, and
issuing automated instructions—is ‘[p]urely ‘conventional’” when claimed to be
implemented by a “wholly generic computer.” Alice at 2358. So too here.
The claimed “database” for storing and retrieving client reminders and the
claimed “communications link” for connecting “to the Internet” likewise do not
pass muster under Alice. Alice held that the claimed “data storage unit” for storing
and accessing shadow records “was purely functional and generic” because
“[n]early every computer will include a communications controller’ and a ‘data
storage unit’ capable of performing the basic calculation, storage, and transmission
functions.” Alice, 134 S. Ct. at 2360. To the extent networking a computer
through the Internet added any “inventive concept” before Alice, the Federal
Circuit since has made clear that “claims’ invocation of the Internet also adds no
inventive concept.” Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716 (Fed. Cir.
2014); buySAFE, 765 F.3d at 1355; DealerSocket at 40. Additionally, using a
“URL” to retrieve forms (i.e., webpages) from a “web server” upon activating the
21
URL link is no more than standard Internet architecture that predated the ’468
patent. Ex. 1001 at 5:7-37, claim 9; Ex. 1003 at ¶¶ 62-63. See Muniauction, Inc.
v. Thomson Corp., 532 F.3d 1318, 1326-27 (Fed. Cir. 2008).
So, too, with the generic “software executing” claimed throughout the ’468
patent. Alice held that claims for software, i.e. “automated instructions” or
“program code for performing the method of exchanging obligations” were
ineligible. Alice, 134 S. Ct. at 2353. Here, the “software executing” is simply
claimed and disclosed in the specification to “automatically” perform the general
steps of the abstract idea described above, so there is no special or advanced
programming. See Alice, 134 S. Ct. at 2351-53, 2358-60; see also Ultramercial,
slip op. at 9 ( “eleven steps for displaying an advertisement” did not specially
program a computer); DealerSocket at 37, 41-42 ( “automated computer
processing” steps for “accessing” information, “determining a predictive
condition” based thereon, and “generating a message automatically” failed to
“recite any improved computer technology or advanced programming technique” ).
Indeed, the only references in the specification that refer to any software
(other than repeating the word “software” by itself) are unclaimed features of the
client’s creation through its reply to the response form through a generic “web
browser,” “cgi script 62 running on the server or a java applet, activex control or
the like running on the client computer (not shown),” and “script program.” See
22
Ex. 1001 at 5:38-6:38; cf. id. at claim 1 (omitting step of client creating the reply).
Even if these generic terms were claimed, these terms are synonomous with
generic program code that is silent as to how that code is to be written to perform
the claimed functions. Ex. 1003 at ¶¶ 73-79. As explained in further detail
regarding indefiniteness of the “software executing” terms, infra, the rest of the
patent’s written description and high-level block diagrams are devoid of any
algorithms—whether in prose, code or otherwise—that would further tie down or
provide structure for the “software” as claimed. Id. Thus, the generically claimed
computer, software, and Internet limitations do not add the requisite “significantly
more” to the claimed abstract idea.
b. The generic form templates and client reminders add
no “inventive concept” to merit patent eligibility.
The claimed “automatically” generating and processing of response forms is
no different from the processing of “shadow records” in Alice, the “message
requesting a response” in Eclipse IP, or the “automatically generat[ed] message” or
“alerts to dealers” in DealerSocket—all of which were held as insufficient to add
“significantly more” to the underlying abstract ideas. Alice, 134 S. Ct. 2351-52;
Eclipse IP, 2014 WL 4407592, at *11; DealerSocket at 3-4, 36-42. In fact, the
“shadow records” disclosed and claimed in Alice were far more detailed than those
here. Compare, Ex. 1001, with U.S. Patent 5,970,479 (Alice patent) at Figs. 41-70.
23
The concept of using template forms to be filled in with client-specific event
information is, of course, fundamental to business practices. See Ex. 1004-05.
And while the ’468 patent offers no details on how it “generates” the claimed
forms, software for automatically “merging” information with template forms was
certainly nothing new or inventive—even in the specific context of law office
automation described in the ’468 patent. Ex. 1003 at ¶¶ 30, 59, 67; Ex. 1006
(advertisement published in 1989 describing “PereWriter” application that
“downloads provisions, merges in user token information and prints a formatted
contract” that “can be mailed electronically … for reference or final approval”).
The claimed “client reminder” also adds nothing inventive—it is nothing more
than information stored in a database, organized in a non-inventive way. The
patent shows no actual “client reminder” entry or special database required to
house it. E.g., Ex. 1001 at 3:20-21 (“client reminder (not shown)”), Fig. 1
(database 14), Fig. 2 (databases 14, 38, 42), Fig. 3 (database 14); Ex. 1003 at
¶¶ 57-58. Instead, the patent describes the client reminder only in the most general
way, as containing “information pertinent to the upcoming professional services to
be rendered,” and only generically describes that type of information as client
contact information, the “type of service to be rendered,” the deadline, and matter
ID. Ex. 1001 at 3:23-27, 4:14-17, Fig. 2 at Ref. Desigs. 32, 34, 40, 36 (same).
Such generic information cannot possibly add the “additional features” to render
24
the claims patent eligible. Merely automating a long-standing practice of
communicating with clients about deadlines is very simply not patentable subject
matter.
Patent Owner may argue it amended its claims to overcome prior art by
adding “a client reminder with a date field having a value attributed thereto.” But
this is irrelevant to § 101 as a non-technological improvement, if any, over the art.
See Ultramercial, 772 F.3d at 716 (“That some of the eleven steps were not
previously employed in this art is not enough—standing alone—to confer patent
eligibility . . . .”); id. (Mayer, J., concurring) at 721 n.1 (“[W]hether the ‘concept’
of intermediated settlement is an abstract idea is a wholly different question from
whether the claimed invention provided a useful and innovative application of that
concept.”). Aside from the utter obviousness of storing deadline information by
date or “value[s] attributed thereto,” it is simply “electronic recordkeeping” held
non-inventive and patent ineligible by Alice. 134 S. Ct. at 2359.
c. Failure of the Machine-or-Transformation Test.
While not dispositive of the eligibilty analyis, the machine-or-transformation
test remains a “‘useful clue’ in the second step of the Alice framework.”
Ultramercial, 772 F.3d at 716-17. As Alice emphatically confirmed, claims to
computer-automation of an otherwise patent ineligible idea fail to tie the invention
to a “particular machine” where the claimed automation is merely through a
25
generic computer running unspecified software or over the Internet. Id.; Bancorp
Servs., L.L.C. v. Sun Life Assurance Co., 687 F.3d 1266, 1275-81 (Fed. Cir. 2012);
DealerSocket at 37, 41-42. As stated, the ’468 patent claims are no more than that.
The claims also fail the transformation test. “Any transformation from the use of
computers or the transfer of content between computers is merely what computers
do and does not change the [eligibility] analysis.” Ultramcercial, slip op. at 13.
Patent Owner may argue that the articles transformed are the client reminder data
through retrieving it, generating a response form based on it, and exchanging
correspondence with the client based on the client reminder and forms. Not only is
this simply “transfer of content between computers” expressly rejected by the
Federal Circuit in Ultramercial, but these steps are far less transformative than
similar claims directed to automated processing and exchange of records
previously rejected by the Federal Circuit under pre-Alice standard. See
Dealertrack, Inc. v. Huber, 674 F.3d 1315, 1331-34 (Fed. Cir. 2012); CyberSource
Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1370-71, 1375-76 (Fed. Cir. 2011).
The claims here fail the machine-or-transformation test.
3. The Dependent Claims add no patentable subject matter.
The dependent claims merely continue the automated back-and-forth
communications between the “professional,” “client,” or a “third party” using the
same generic computer components as in the independent claims, and further
26
recordkeeping by sending “confirmations” and “updating [the] database” based on
those communications. Ex. 1001 at claims 2-4, 13-16, 25-27. These are natural
extensions of the core “reminder and take action” concept, and fail to further limit
that idea in any meaningful way. Ex. 1003 at ¶ 51. And while claims 13-16 may
interject a “web server,” that well-known technology certainly added no “inventive
concept” to render the otherwise abstract idea patent eligible. Ex. 1001, claims 13-
16; Ex. 1003 at ¶¶ 62-63, Exs. 1007-1008; DealerSocket at 42. Thus, the
dependent claims are mere “token postsolution components” that fail to render the
otherwise abstract idea of their corresponding independent claims patent-eligible.
Bilski, 561 U.s. at 612 . Thus, claims 1-4, 9, 13-16, and 24-27 of the ’468 patent
are directed to a patent-ineligible abstract idea. Ex. 1003 at ¶¶ 16-30, 47-69.
B. [Ground 2] Claims 1-4, 9, and 13-16 Are Invalid Functional
Claims Under 35 U.S.C. § 112, ¶ 6.
1. The device claims should be treated as MPF claims.
While claims 1-4, 9, and 13-16 lack the term “means,” Section 112, ¶ 6
applies because their purely functional “software . . .for” claim limitations lack any
structure. Apex Inc. v. Raritan Computer, Inc., 325 F.3d 1364, 1375 (Fed. Cir.
2003). Indeed, the Federal Circuit has consistently held that means-plus-function
claiming applies if the claim term “fails to recite sufficiently definite structure or
else recites functions without reciting sufficient structure for performing that
27
function.” Lighting World, Inc. v. Birchwood Lighting, Inc., 382 F.3d 1354, 1358
(Fed. Cir. 2004); see also Robert Bosch, LLC v. Snap-On Inc., 769 F.3d 1094,
1100 (Fed. Cir. 2014) (finding that when language in the specification describing
the claims is “solely functional, one of ordinary skill in the art [cannot] find in the
specification a definition of the terms as referring to a particular structure.”). The
’468 patent claims the following functions to be “automatically” performed by
“software executing on [a] computer”: (1) “querying [a] database by the values
attributed to each client reminder date field to retrieve a client reminder,” (2)
“generating a client response form based on the retrieved client reminder,” (3)
“transmitting the client response form,” (4) “receiving a reply to the response
form,” and (5) “generating a response [or confirmation] based on the reply” and/or
“updating said database based on the reply.” E.g., Ex. 1001 at claims 1-4. The
specification adds no structure to these claimed functions, whether in the form of
code, logic, prose, or otherwise. Instead, the patent exclusively describes any
references to “software” by repeating or mildly rephrasing the functions as
claimed. Ex. 1001 at 3:18-20 (querying), 3:30-34 (generating a response form),
3:46-48 (receiving reply), 4:1-7 (updating database and sending confirmation).
The ’468 Patent also generically describes functionality of unclaimed software on
the unclaimed client computer , not the claimed professional computer. Id. at col.
3, ll.40-45; 5:43-47; 5:58-6:7.
28
In light of this purely functional description in the claims and specification, a
person of ordinary skill in the art in 1996 would not understand there to be
sufficient structure for the “software” limitations. First, the term “software” does
not have a commonly accepted meaning to connote specific structure. Ex. 1003 at
¶¶ 70-72. (discussing the very broad nature of lay and technical dictionary
definitions of “software”) Second, the specification lacks code and algorithms that
could be used to perform the claimed functions on a general purpose computer, and
also lacks any description of how the computer hardware, databases, and web
servers could be programmed. Ex. 1003 at ¶¶ 73-78. See Aspen Eyewear, Inc. v.
Altair Eyewear, Inc., 288 Fed. Appx. 697, 703-04 (Fed. Cir. 2008); see also
Inventio AG v. ThyssenKrupp Elevator Americas Corp., 649 F.3d 1350, 1356-57
(Fed. Cir. 2011) (holding expert evidence is usually helpful “as the litigated issue
often reduces to whether skilled artisans . . . would conclude that a claim limitation
is so devoid of structure that the drafter constructively engaged in means-plus-
function claiming.”). The specification’s simple re-recitation of the functionality
of the software cannot save the claims from means-plus-function treatment.
Robert Bosch, 769 F.3d at 1099-1101. As an example, the ’468 Patent does not
describe how to “generate a client response form based on the retrieved client
reminder.” To show structure, this limitation requires code instructing the
computer how to generate the claimed form based on the client reminder such as
29
what fields to include, what data to pull, how to present it to the client, etc. Such
code is lacking. See Ex. 1003 at ¶¶ 75-77; e.g., Ex. 1001 at 3:23-29; Fig. 1
(depicting “[Generate] Response Form” in a block diagram). See Ex parte
Lakkala, Appeal No. 2011-001526 (Decision on Appeal) at 8-12 (P.T.A.B. March
13, 2013); Ex parte Erol, Appeal No. 2011-001143 (Decision on Appeal) at 13-16
(March 13, 2013).
WhitServe may attempt to rely on conclusory allegations from one of their
experts regarding how a person of ordinary skill in the art would understand the
“software” limitations. However, WhitServe cannot supply the missing structure
with expert testimony. Biomedino, LLC v. Waters Techs. Corp., 490 F.3d 946,
950–53 (Fed. Cir. 2007) WhitServe will also attempt to argue that the presumption
against means-plus-function claiming is strong because of the lack of “means.”
However, GoDaddy need only show by a preponderance of the evidence there is
insufficient structure in order to rebut this presumption. GoDaddy has done so.
Apex Inc. v. Raritan Computer, Inc., 325 F.3d 1364, 1375 (Fed. Cir. 2003);
Walhonde Tools, Inc. v. Wilson Works, Inc., No. 1:09CV48, 2012 WL 1965628, at
*4 (N.D. W. Va. May 31, 2012); Maurice Mitchell Innovations, L.P. v. Intel Corp.,
No. 2:04–CV–450, 2006 WL 1751779, at *4 (E.D. Tex. June 21, 2006). Finally,
district courts and the U.S. Patent Office have made clear that means-plus-function
treatment is appropriate for software-related claim terms, such as these, that are
30
devoid of structure. E.g., Ranpak Corp. v. Storopack, Inc., 168 F.3d 1316 (Fed.
Cir. 1998) (“module”); Ex parte Lakkala, Appeal 2011-001526 (Decision on
Appeal) (P.T.A.B. March 13, 2013) (“processor . . . configured with [a] program to
. . .”); Ex parte Erol, Appeal No. 2011-001143 (Decision on Appeal) (March 13,
2013) (“a processor adapted to”); Thought, Inc. v. Oracle Corp., No. 12-cv-05601,
2014 WL 5408179, at *19-*25 (N.D. Cal. Oct. 22, 2014) (“computer logic capable
of” and “sub-routine or sub-module for comparing”); Visual Networks Operations,
Inc. v. Paradyne Corp., No. DKC 2004-0604, 2005 WL 1411578, at *28 (D. Md.
June 15, 2005) (“logic”). Additionally, the MPEP provides clear guidance that the
means-plus-function inquiry should be done on a case-by-case basis when
analyzing “generic placeholders” such as those above, including by proper resort to
the specification and extrinsic evidence—here, “software . . . for” performing
functions is simply used as a generic placeholder. See MPEP § 2181 (I.A.) (9th Ed.
Rev. March 2014).
2. The specification does not disclose any algorithm or code.
For means-plus-function claims requiring a computer as the structure, the
Federal Circuit has consistently required that the computer be “more than simply a
general purpose computer or microprocessor.” Noah Sys., Inc. v. Intuit Inc., 675
F.3d 1302, 1312 (Fed. Cir. 2012). Additionally, a patentee’s “[m]ere reference . . .
to ‘software’ without providing detail about the means to accomplish the software
31
function, is not an adequate disclosure” for means-plus-function claiming. Ex
Parte Emigh, Appeal 2012-005145, 2013 WL 1450915, *6 (P.T.A.B.) To meet the
structure requirement, a patentee may express the requisite algorithm to be
employed by the general purpose computer as a mathematical formula, in prose, or
through a flow chart. Finisar Corp. v. DirecTV Group, Inc., 523 F.3d 1323, 1340
(Fed. Cir. 2008). Simply parroting the claimed function in the specification is
insufficient. Robert Bosch, 769 F.3d at 1100. Notably, the disclosure in the
specification must be evaluated from the perspective of a person of ordinary skill.
Aristocrat Techs. Australia Pty Ltd. v. Int’l Game Tech., 521 F.3d 1328, 1337-38
(Fed. Cir. 2008). As discussed supra, the ’468 Patent simply parrots the claimed
functions in the specification and claims “software” on a general purpose
computer. The patents do not contain any algorithm or code to perform the
functions. The patents provide only a block diagram with numerous generic “black
box “components that do not provide structure. E.g., ’468 Patent, Figure 1; Ex.
1003 at ¶ 77. This depiction fails as a mater of law to satisfy the algorithm
requirement. Function Media, LLC v. Google, Inc., 708 F.3d 1310, 1318-19 (Fed.
Cir. 2013); ePlus, Inc. v. Lawson Software, Inc., 700 F.3d 509, 518-19 (Fed. Cir.
2012). Accordingly, the functional limitations are indefinite means-plus-function
terms.
32
C. [Ground 3] Claims 1-4, 9, 13-16 , and 24-27 Are Indefinite Under
Section 112, ¶ 2
Even if the Board disagrees that Section 112, ¶ 6 applies here, all of the
device and method claims must still pass muster under Section 112, ¶ 2. Nautilus,
Inc. v. Biosig Instruments, Inc., 134 S.Ct. 2120, 2124 (2013); see also MPEP §
2181, Section II.A (9th ed. March 2014) (“The invocation of 35 U.S.C. 112(f) or
pre-AIA 35 U.S.C. 112, sixth paragraph, does not exempt an applicant from
compliance with 35 U.S.C. 112(a) and 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112,
first and second paragraphs.”) Indeed, a court or agency may find that the
presumption aginst means-plus-function is not rebutted, but that the lack of
sufficient structure still renders the claims indefinite under Section 112, ¶ 2. See
Markem-Imaje Corp. v. Zipher Ltd., No. 07-cv-00006-PB, 2012 WL 3263517, *7-
9 (D. N.H. Aug. 9, 2012) (finding claims reciting “controllers” for performing
functions to be indefinite under Section 112, ¶ 2 after declining to invalidate the
claims as means-plus-function claims, because there were no algorithms). Indeed,
under the Supreme Court’s opinion in Nautilus, a claim is indefinite if when
viewed in light of the specification and prosecution history, it fails to “inform those
skilled in the art about the scope of the invention with reasonable certainty.”
Nautilus, Inc. v. Biosig Instruments, Inc., 134 S.Ct. 2120, 2124 (2013); SAP
America, Inc. v. Arunachalam, CBM2013-00013, Paper 61 (Final Written
33
Decision), Pages 18-20 (PTAB September 18, 2014) (finding as indefinite the
phrase “routed transactional data structure” because the specification contained no
description of “data structure” or how it was routed or transmitted over a network).
Here, as discussed above, a person of ordinary skill is not informed about the scope
of the claimed “software . . . for” device limitations and “querying,” “generating,”
“transmitting”, and “receiving” method steps with reasonable certainty. See Ex.
1003 at ¶¶ 73-79. Accordingly, the Board should institute trial on claims 1-4, 9,
13-16 , 24-27 as indefinite under 35 U.S.C. § 112, ¶ 2.
D. [Ground 4] Claims 1-4, 9, 13-16 , and 24-27 Are Invalid under 35
U.S.C. § 112, ¶ 1.
Similarly, the PTAB should institute trial under the related but separate
ground of lack of written description under 35 U.S.C. § 112, ¶ 1. The patentee
here failed provide sufficient descriptions for the claimed functions in the patent
application, and patentee cannot rely on the obviousness of claim to satisfy 35
U.S.C. § 112, ¶ 1. Lockwood v. Am. Airlines, Inc., 107 F.3d 1565, 1572
(Fed.Cir.1997); Avante Int’l Tech. Corp. v. Premier Election Solns., Inc., No.
4:06cv0978 TCM, 2008 WL 2783237 , *9-13 (E.D. Mo. July 16, 2008). The
Board should institute trial under Section 112, ¶ 1 for claims 1-4, 9, 13-16 , 24-27.
\ \ \
\ \ \
34
E. [Ground 5] Claims 1-4, 24-27 Are Invalid as Anticipated Under 35
U.S.C. § 102 by the Network Solutions Message Ticketing System.
Network Solutions, Inc. (“NetSol”) was formed in the United States in 1979
to service the early infrastructure of the Internet. Ex. 1016 (“Kosters Decl.”) ¶¶ 1-
56; Ex. 1015 (“Ho Decl.”) ¶¶ 1-32. In September of 1991, NetSol became the sole
operator (i.e., “registrar” and “registry”) of the domain name system (DNS)
registry for managing Internet domain names. Kosters Decl. ¶ 7. In 1993, the
National Science Foundation created the Internet Network Information Center
(“InterNIC”) to provide domain name registration services for non-military
Internet networks, awarding NetSol the contract to manage InterNIC’s registration
services as the sole registrar for the most common and popular domain names,
including “.com,” “.net” and “.org.” Kosters Decl. ¶ 8. In March 1993, to manage
these popular domains, NetSol began to develop an automated, email-based
domain name registration system, called the Message Ticketing System (“MTS”).
Kosters Decl. ¶ 9. By September 14, 1995, NetSol required customer registrants to
make an initial payment after first registering a domain, and then a renewal
payment to maintain the registration. Id. As detailed below and in the declaration
of Mark Kosters—NetSol’s chief software engineer responsible for developing the
MTS system—at least as of August 1996, the MTS system automatically reminded
customers of deadlines for initial registration and renewal payments, and
35
automatically processed email-based template registration forms completed and
returned by customers in response to the reminders, as claimed in the ’468 patent.
Kosters Decl. ¶¶ 10, 1-56; Ho Decl. ¶¶ 10-13; Ex. 1003 at ¶¶ 81-83.
1. MTS was a publicly known and used prior art system.
Because the relevant features of the MTS system were all known or used in
this country by the public over the Internet before the ’468 patent’s filing date of
October 7, 1996, MTS qualifies as prior art under 35 U.S.C. § 102(a) (pre-AIA).
And because MTS was not “abandoned, suppressed, or concealed,” it also qualifies
as prior art under 35 U.S.C. §102(g)(2) (pre-AIA). “Known or used by others”
means knowledge or use which is accessible to the public. Carellav. Starlight
Archery, 804 F.2d 135 (Fed. Cir. 1986); W. L. Gore & Assoc. v.Garlock, Inc., 721
F.2d 1540 (Fed. Cir. 1983) (secret use of a process still constitutes invalidating
public use if public could learn of the claimed process from article produced by the
secret process); MPEP § 2132 (same). The amount of public disclosure required
for a prior art “public use” is low. Netscape Commnc’ns Corp. v. Konrad, 295
F.3d 1315, 1320 (Fed. Cir. 2002) (“any use of [the claimed] invention” by
someone “under no limitation, restriction or obligation of secrecy” constitutes
public use); Eolas Techs. Inc. v. Microsoft Corp., 399 F.3d 1325, 1334 (Fed. Cir.
2005) (finding public use of web browser demonstrated by inventor to two
engineers “under no confidentiality obligation”). And the use of a software-based
36
system can be public even where it does not enable a person of skill in the art to
make the invention. See Zenith Elecs. Corp. v. PDI Commnc’s Sys., Inc., 522 F.3d
1348, 1356 (Fed. Cir. 2008). Rather, the inquiry is merely “whether the public use
related to a device that embodied the invention.” Id. (emphasis added); Lockwood
v. American Airlines, Inc., 107 F.3d 1565, 1568 (Fed. Cir. 1997) (prior art software
for “automated interactive sales terminals” whose “critical aspects” and “essential
algorithms” were confidential trade secrets still held to be in public use because
public used the system’s “high-level aspects”). Further, under 35 U.S.C. §
102(g)(2), the MTS system need only have been invented before October 7, 1996
in the United States and not have been “abandoned, suppressed, or concealed.”
Teva Pharm. Inds. Ltd. v. AstraZeneca Pharms. LP, 661 F.3d 1378, 1382-86 (Fed.
Cir. 2011). The patentee may attempt to show an earlier conception date.
However, it cannot legally do so. In, short the documents patentee relied upon in
the Litigation do not independently corroborate an earlier conception date of the
claim limitations. Microsoft Corp. v. Surfcast, Inc., IPR2013-00292, et al., Paper
93 (Final Written Decision), pp. 15-17 (PTAB October 14, 2014); Garmin Int’l,
Inc. v. Cuozzo Speed Techs. LLC, IPR2012-00001 Paper 59 (Final Written
Decision), p. 21 (PTAB November 13, 2013).
The features of MTS as claimed in the ’468 patent were all publicly
accessible before October 7, 1996 at least through InterNIC’s website, NetSol’s
37
contractually required annual reports to the NSF, presentations at Internet
technology conferences, in online email discussion forums, and through MTS
emails to customers containing the template forms. Kosters Decl. ¶¶ 32-56; Ho
Del. ¶¶ 5-13, ;27-30 Ex. 1003 at ¶¶ 81-83. These publically available materials
were disseminated without any restrictions. See id. In March 1993, NetSol issued
a public “Request for Comments: 1400” (“RFC1400”) that disclosed the automated
processing of MTS template domain registration forms, stating that “[e]ffective
April 1, 1993,” requests for new registrations needed to use a new “autoreg
template” that customers were to fill in and email to InterNIC’s “[a]utomated
Internet registration services” for “parsing” by the InterNIC host software.
Kosters. Decl., Ex. 5 at NET316-322; Ho Decl., Ex. B (same). The MTS system
was being used publically as of March 1993 and was continuously used and
improved upon since then such that by August 30, 1996, InterNIC reported to a
publicy agency, NSF, that “[t]he ticketing system is in place and operating” and
that “[d]omain name registration and update templates are available and in use on
the web.” Kosters Decl., Ex. 2 at 2; Goldberg Decl. ¶¶ 80-84.
InterNIC’s website also published features of MTS before October 7, 1996,
including instructions for customers on how to complete the template registration
forms, email them to InterNIC for automatic processing, and for how to respond to
the automatically generated email reminder from InterNIC to either make payment
38
on the registration or modify or delete the registration. See Kosters Decl. ¶¶ 32-56,
Exs. 1 (showing form available at ftp://rs.internic.net/templates/domain-
template.txt), 3 (noting for “Maintenance Fee[s] Due” that “[t]he Registrar will not
attempt to notify the contacts by any means other than email.”), 4 (same), 8
(“Registration Process Overview” flow chart showing “[r]equest is automatically
acknowledged” and “[t]emplate is automatically checked for errors”).
Public discussion of MTS also occurred before October 7, 1996. In May
1996, Mr. Kosters presented the progress of the MTS services at that year’s North
American Network Operator’s Group (“NANOG”) convention open to the
interested public, confirming that the MTS “autoreg” initial registration services
were implemented in June of 1995. Kosters Decl., Exs. 6, 7 (slide 14). MTS was
clearly auto-processing emails by then, as “80% of new submissions” and “50% of
modifications” to registrations were “never seen by a human.” Id., Ex. 7 (slide 14).
Mr. Kosters also publicly announced that “60 day notices [were] being sent as of 1
May, 1996 on a regular basis” for “Billing - Renewals.” Id. (slide 18); see also id.,
Ex. 8 (“InterNIC sends renewal notice to registrant 60 days before the 2yr
anniversary of the initial registration”). Members of the public interested in
Internet domain names also publicly discussed MTS features via the NANOG
“[email protected]” distribution list, and NetSol used the “[email protected]”
customer email list to explain the automatic registration process and respond to
39
“frequently asked questions” about MTS. Kosters Decl., Exs. 9, 11.
The MTS automated features were also directly disclosed to the public
before October 7, 1996 through email exchanges between MTS and NetSol
customers—including exchanges with the named inventor of the ’468 patent, Mr.
Whitymer, regarding his domain registration for his law firm domain (ssjr.com)
and personal domain (whitmyer.org). Kosters Decl. ¶¶ 32-56, Exs. 10, 12-16, 18-
23; Ho Decl. ¶¶ 15-30, Exs. C-F; Goldberg Decl. ¶¶ 80-83. These documents
show that email “notices” coming from MTS were automatically generated
periodically based on dates of the customer’s initial registration record in order to
remind them of an upcoming “maintenance fee,” and that MTS automatically
processed the customer’s reply emails and sent auto-reply confirmations
acknowledging receipt. See, e.g., Kosters Decl., Ex. 18 ll. 28-32 (“The purpose of
this notice is . . . 1) to inform you that your annual $50 maintenance fee will be due
in approximately 60 days, and 2) to give you an opportunity to update any
information on your domain registration template”), id. ll. 655-58 (“This is an
automatic reply to acknowledge that your message has been received”), Ex. 19
(same); Ex. 1003 at ¶¶ 81-83.
Patent Owner may argue that the MTS database containing domain
registration records was not disclosed as being auto-queried by the MTS system in
order to trigger the MTS reminder emails. However, particularly because the ’468
40
patent itself discloses no code and only generically claims functions, it is not the
code itself that must be publicly discernible, but rather the high-level functions
(such as the querying function) as claimed by the patent. See Lockwood, 107 F.3d
at 1568. The publicly available materials expressly disclose that MTS utilized a
“registration services database,” that the emails were periodically sent out by MTS
based on registration dates, and that the system “depends on valid information
from the template registration that [the customers] fill out so that [the MTS]
database will generate correct email and postal invoices and notices.” Kosters
Decl., Exs. 3-4, 9, 13. MTS customers could even automatically query the
registration database themselves and notice that initial and renewal registration
dates were stored by MTS. Id., Ex. A at 0021, Ex. B at 0046-48 (fqmts query).
Given the extensive automatic nature of the MTS system as evidenced by the
publically available materials, one of ordinary skill would have readily concluded
that the MTS system was automatically querying a database by the registration
activation or renewal date so as to achieve the purpose of the system—i.e., to
remind customers to pay for and thus keep their domains active. See Goldberg
Decl ¶¶ 81-82. MTS constitutes prior art under § 102(a) and/or § 102(g)(2).
2. MTS contains each element of claims 1-4 and 24-27.
A claim is anticipated if each and every element as set forth in the claim is
found, either expressly or inherently, in a single prior art reference. Verdegaal
41
Bros., Inc. v. Union Oil Co. of Cal., 814 F.2d 628, 631 (Fed. Cir. 1987). Prior to
October 7, 1996, the MTS software operated on a clustered set of computers at
NetSol running the UNIX operating system and using a central filestore, called the
Ingres database, which contained domain name registration records. Kosters Decl.
¶ 12. These computers were connected to the Internet, and communications sent
by and to the MTS system were via Internet-based email. Id. As Mr. Kosters
explains and as authenticated by NetSol’s records custodian, Matthew Ho, all of
the programs and files contained in NSI-SOURCECODE_000001 to NSI-
SOURCECODE_003220 were used in the operation of MTS as of the dates
reflected in their “SCCS” repository timestamps shown in the code, all of which
are no later than July of 1996. Kosters Decl. ¶¶ 13-14; Ho Decl. ¶¶ 15-26.
Initial Invoicing. Prior to October 7, 1996, there were two types of
automatic processes that MTS performed. Kosters Decl. ¶¶ 17-24. In response to
a NetSol customer sending InterNIC an email containing a filled out registration
template selecting a “NEW” domain, MTS automatically parsed the email to create
a new record in NetSol’s registration records “Ingres” database. Id. A custom
Ingres application called “igen” automatically queried the registration database
daily, determining which records were “NEW” by selecting records with
“activation dates” falling on the query date and in need of an initial invoice. Id.
For each record requiring an initial invoice, the igen program automatically
42
created an email populated with initial invoice and payment instructions specific to
that customer, both in the body of the email and in its header. Id. MTS then
automatically transmitted that email to the customer and stored a copy within the
MTS ticketing system. Id. The customer responded to that email and MTS
automatically received, processed, and stored two types of customer responses to
the initial invoice email. Id. First, a customer could fill in a registration template
email selecting the “DELETE” or “MODIFY” option and email it back to
InterNIC, which would automatically parse that email and update the Ingres
registration database records accordingly. Id. The customer receiving the invoice
email could have either revised his previous email containing the registration form,
or obtained a new form through the InterNIC FTP server (residing at
rs.internic.net) by using the URL link in the MTS email. Id. The InterNIC FTP
server processed Internet-based requests from the MTS customer clicking on the
URL in the MTS email, and sent the requested information (here, the domain
registration template) back to the MTS customer for revision. Id.; Ex. 1003 ¶ 82.
Second, per the instructions contained in the initial invoice email, a customer
could respond by emailing MTS at [email protected] to ask questions related to
the invoice. Kosters Decl. ¶ 22. For either type of response, MTS would auto-
parse the customer’s email to determine whether it contained information that
needed to be passed along to the billing department. Id. ¶¶ 21-23. If so, MTS
43
would automatically transmit the information contained in the customer’s response
to a separate billing department for further processing. Id., Ex. A; Ho. Decl. ¶¶ 13-
18; Goldberg Decl. ¶¶ 80-83.
Renewal Reminders. Also on a daily basis, MTS software automatically
queried the same Ingres database to determine whether a customer’s domain
registration was soon expiring and in need of renewal payment. Kosters Decl. ¶¶
25-31. The MTS software queried records for domain registrations that had
“activation” dates within a preset date range in advance of their expiration, such as
in the next 60 days. Id. For each selected record, a custom application called
“rereg” automatically created renewal notice emails with template forms filled in
with customer-specific information coming from the queried record. Id. These
emails included a URL link that the customer could use to access the latest
registration template from InterNIC’s FTP server residing at rs.internic.net. Id.
MTS automatically transmitted and stored copies of these renewal notice emails to
the customers, and the customers could respond to the email by filling in
information in the form within the email body, such as by entering updated contact
information or modifying other registration information, or deleting the
registration. Id.
Once the customer emailed back the completed form, MTS software auto-
parsed the email, sent an auto-confirmation email with a ticket ID number to the
44
customer, and then parsed the filled-in template information to update the Ingres
database with any new or modified information. Id. ¶ 29. MTS also automatically
parsed any payment or billing information contained in the customer’s email, and
transmitted that information by email to a separate billing department for further
processing. Id.; Kosters Decl., Ex. B (detailed source code citations for renewals
process); Ho Decl. ¶¶ 19-25; Goldberg Decl. ¶¶ 80-83. The following claim chart
demonstrates that MTS discloses each and every element of the claims 1-4 of the
’468 patent. Ex. 1003 at ¶ 82. Claims 24-27 are quite literally the “methods” of
claims 1-4 and therefore are rendered anticipated by MTS in the same way. Id.
’468 Claims § 102 – MTS [1P] A device for automatically delivering professional services to a client comprising:
Kosters Decl., Exhibit 5 (RFC1400, NET000318).
[1A] a computer;
Initial & renewal processes – MTS software operated on computers at Network Solutions running the UNIX operating system and connected to a central filestore containing customers’ domain registration records. Kosters Decl. ¶ 12-16. See also Ho Decl. ¶¶ 1-33.
[1B.1] a database containing a plurality of client
Initial & renewal processes – MTS stored domain registration records in a database called “Ingress,” referred to in the code as the “id” database. Kosters Decl. ¶ 17-19. For each domain record, “activation_date” attributes were maintained, indicating the start of the pre-set registration period for a given domain name. Id. The source code provided a library of C structs which mapped directly to
45
’468 Claims § 102 – MTS reminders, the database schema’s table structures. The contents of this file
represented the database schema for the id_domain table in the id database, as shown here:
Kosters Decl. Ex. A at 0023, Ex. B at 0047; id. Ex. 17, NET000383 (highlights added). Evidence of the INGRES (“id”) database as storing domain registration information was also found in the MTS code for processing customer “finger” query requests to be able to obtain status of MTS’s processing of the customer’s renewal form. Kosters Decl., Ex. 5 at NET000319. Renewal process – The “rereg” program processed renewals. The rereg program connected to the database in rereg/db_mail.sc at line 164-175: printf("\nConnecting to database..."); if( !db_connect ("id")) ... else { printf("\nConnected to the database..."); connected = TRUE; } Kosters Decl., Ex. B at 0048, NSI-SOURCECODE_772 lines 164-75.
[1B.2] each of the client reminders
Initial & renewal processes – The domain registration records in the INGRES database contained fields showing the NetSol customer’s domain “activation date.” Kosters Decl. ¶¶ 17-31, Ex. A at 0023, Ex.
46
’468 Claims § 102 – MTS comprising a date field having a value attributed thereto;
B at 0047. Initial process – Based on the date and number of days, a date range was constructed by the code and the code selected domain registration records (“select_domain”) with a particular date:
{ fprintf (stderr, "selecting new domains |%s|\n", date); if (!select_period (inv_date, due_date, atoi(period), "days")) { ... } dtptr = select_new_domains (date, ticket_date, dtptr); fprintf (stderr, "ticket date |%s|\n", ticket_date); days--; if (days > 0) format_next_date (date); } while (days > 0);
Kosters Decl., Ex. A at 0024 (NSI-SOURCECODE_34 at lines 161-73). Renewal process – The Lgen program was called using the registration date, list of days to query, etc.: lgen(act_date, days, ticket_date, dtptr,mts_config, log_on, period, fudge);
Kosters Decl., Ex. B at 0049 (NSI-SOURCECODE-772 at line 230).
The program then looped around based on the registration or activation date of the listed domains (lines 111-138 of lgen.c): /* Select dates 60 days from the activation date given. */ if(!select_period(act_date, search_act_date, atoi(lperiod))) ... format_search_date(search_act_date); do { ... if (!select_period (inv_date, due_date, atoi(lperiod))) ... strcpy(global_due_date, search_act_date); select_new_domains (search_act_date, ticket_date, mts_config, log_on, fudge); ... days--; int_period++; itoa(int_period, lperiod);
47
’468 Claims § 102 – MTS printf("\nDAYS: %i\n", days); if (days > 0) format_next_date (search_act_date); act_date = &search_act_date[0]; }while (days > 0);
Kosters Decl., Ex. B at 0050 (NSI-SOURCECODE-889 lines 11-138).
[1C] software executing on said computer for automatically querying said database by the values attributed to each client reminder date field to retrieve a client reminder;
On a daily or periodic basis using scheduled system jobs on UNIX called cronjobs, MTS would query the Ingres database to determine which domains were recently registered to determine which customers needed invoices emailed to them (initial process), and to determine which domains were expiring and thus required renewal emails (renewals process). Kosters Decl. ¶ 18, 26. Initial process – Based on the date value passed into select_new_domains, the sql query code selected domain registration records that matched the selected “activation_date” and added it to a linked list for further processing: llist_struct *select_new_domains (activation_date, tracking_no, llistptr) EXEC SQL BEGIN DECLARE SECTION; char *activation_date; char *tracking_no; EXEC SQL END DECLARE SECTION; llist_struct *llistptr;
. . .
EXEC SQL SELECT handle, domainame, admincontact, techcontact, parentdom INTO :domrec.handle, :domrec.domainame, :domrec.admincontact, :domrec.techcontact, :domrec.parentdom FROM id_domain WHERE activation_date = :activation_date and parentdom != 'RSVD';
Kosters Decl., Ex. B at 0025 (NSI-SOURCECODE-10 at lines 78-83, 91-95). Renewals process – Based on the date value passed into select_new_domains, the sql called domains that matched the registration date against the date selected “activation_date” and added it to a linked list for further processing:
48
’468 Claims § 102 – MTS llist_struct *select_new_domains (activation_date, tracking_no, llistptr) EXEC SQL BEGIN DECLARE SECTION; char *activation_date; char *tracking_no; EXEC SQL END DECLARE SECTION; llist_struct *llistptr;
Kosters Decl., Ex. B at 0049-53, Ex. A (same). The select loop starts on line 91 that builds a list of domains that match that activation date. Kosters Decl., Exhibit 11 at lines 44-69.
[1D] software executing on said computer for automatically generating a client response form based on the retrieved client reminder;
Initial process – MTS software automatically generated initial invoices emails using the “igen” program. Kosters Decl. ¶ 18-22. For the initial process, the client response form is considered the initial invoice email containing instructions on how to email NetSol with billing questions /or to complete a template to delete the registration:
Kosters Decl. Exhibit 21. Renewal process – MTS software automatically generated renewal reminder emails using the “igen” program. Kosters Decl. ¶ _. At the end of the select loop listed in claim 1 step 1C, the system sent a linked list via a procedure called use_db_entries (db.sc line 156) that used a linked list of domains to build a template (db.sc lines 345-355): /* PRINT THE TEMPLATE TO THE FILE "mail_template.txt" */ fill_template_error = fill_template_struc_v3(handle_in); if(fill_template_error == FALSE) ... print_template_error = print_template_v3("mail_template.txt");
Kosters Decl., Ex. B at 0025. This code called print_template_v3 that was a filled in registration template to the listed contacts. Id. at 0052-54. The client response form is considered the MTS email containing
49
’468 Claims § 102 – MTS the template form to be filled out by the customer directly in the email, or to download the latest form and include it as filled out in the email. Kosters Decl. ¶ 25-31. For example:
Kosters Decl. ¶ 29, Exhibit 12 at ARIN73; see also id. at Exs. 18-19 (renewal email exchanges); id. at Ex. 18 (ARIN1-17), Ex. 19 (ARIN0018-46), Ex. 12 and Ex. 16.
[1E] a communication link between said computer and the Internet;
Initial & renewals processes – MTS was connected to the Internet and it sent and received the MTS ticket emails over the Internet as described in the Kosters Declaration. Kosters Decl. ¶ 12; see also id., Ex. 5 at NET318 (InterNIC’s MTS was a “new Internet registration service” that “will be connected to SureNET via T1 around March 10, 1993”). Kosters Decl. ¶ 38.
Additionally, the code shown in the Kosters Declaration for the step for “automatically transmitting the client response form” (step 1F) shows that MTS was connected to the Internet using the address in the ip address range of 198.41.0.0/22. E.g., Kosters Decl. Exhibit A at 0027.
[1F] software executing on
Initial process – MTS software automatically transmitted the invoice reminder email, which was automatically populated with customer-
50
’468 Claims § 102 – MTS said computer for automatically transmitting the client response form to the client through said communication link; and,
specific information pulled from the Ingres database query in claim element 1[C]. Kosters Decl. ¶¶ 17-31. The .snd files generated in print_invoice used a process called sendit that sent the invoice files. Id. Sendit took a list of files and invoked the sendmail agent via the open_mail_agent. (lines 62-77 of sendit.c). Id. The open_mail_agent called the operating system’s sendmail agent that sent the email that comprises the invoice to the listed contacts: /**************************************************************************** opens the mailer via popen ****************************************************************************/ FILE *open_mail_agent() { FILE *fp; fp = popen (MAIL_AGENT, "w+"); return fp;
Kosters Decl., Ex. A at 0027-30. Renewals process – MTS automatically transmitted an email template form to each customer whose registration “activation date” was within a certain time of expiration, starting with a reminder period of 60 days in advance of expiration. Kosters Decl. ¶¶ 25-31. The system called Function mail_POC that would send the resultant template to the points of contact (POCs) listed on the domain: strcpy(dom, domain); act_date_file = fopen("act_date.txt", "wt"); fprintf(act_date_file,"\n\n\n ---- Domain Name Registration Renewal Notice ----"); fprintf(act_date_file,"\n\nYour Anniversary Date is: %s", ad); fprintf(act_date_file,"\nDomain: %s\n\n", dom); fclose(act_date_file); out = fopen(NICout_file, "w"); setbuf(out, (char *)NULL); append_file(out, "temp_header.txt"); append_file(out, "act_date.txt"); append_file(out, bill_text); append_file(out, "mail_template.txt"); append_file(out, "/home/role/rereg/dom_template_inst.txt"); fclose(out);
51
’468 Claims § 102 – MTS Kosters Decl., Ex. B at 0053-54. Each template was stored in a file called “NICout,” which was uniquely called by the make_inc_filename that stored each rereg template in a directory constructed from filenaming.c (lines 63-79). Id. At the end of the run, a program called “sendit” would email the template file to the contacts from a listing of files in that directory: # for (i=optind; i< argc; i++) { filename = argv[i]; fprintf (stderr, "filename |%s|\n", filename); fp = open_mail_agent(); if (!cat_file_to_fp (filename, fp, log_on)) { ... else { log (0, log_on, "email_reply: mail sent!"); close_mail_agent(fp); unlink (filename);
Id. at 0054-55.
As with the initial invoicing process, the program open_mail_agent was found in mts/reply.c at lines 151-159 that called the operating system’s sendmail agent, which sent the email that comprises the invoice to the listed contacts. Id. at 0055-57.
[1G] software executing on said computer for automatically receiving a reply to the response form from the client through said communication link.
Initial process – After a customer received the initial invoice email from MTS, the customer could reply by email to [email protected] or by filling in an email “delete” or “modify” template found at rs.internic.net (as described in the email to the customer). See, e.g., Kosters Decl., Ex. 10. Either of these emails sent back to MTS from the customer in response to the MTS initial invoice email was automatically received and processed by the MTS “sendmail” program. Kosters Decl. ¶¶ 17-24.. MTS code would accept an email automatically from the operating system’s sendmail agent through a spooling process, which would then process the file with the name of the file as a timestamp, and store it as a file for further processing. Id. Renewal process – After a customer received the renewal reminder email from MTS, the customer could reply by email by completing the template registration form contained in the MTS renewal reminder email. Kosters Decl. ¶ 25-31.The customer could select new, delete, or modify and revise registration contact information as needed. Id. The MTS code would accept an email automatically from the operating system through the sendmail program, process the
52
’468 Claims § 102 – MTS file with the name of the file as a timestamp, and store it as a file for further processing. Kosters Decl. Ex. B. at 0056-57 (Spool_mail.c lines 92-103).
Claim 2 The device of claim 1 further comprising software executing on said computer for automatically generating a response based on the reply, and for automatically transmitting the response to a third party.
Initial & renewals processes – While parsing an email received from a customer, MTS would automatically determine what information sent by the customer (in response to the email from MTS) needed to be sent to a separate billing department, and MTS would then automatically pass that information along to the billing department. Kosters Decl. ¶¶ 17-31. This information went to the billing department on a daily basis into its Microsoft Access (“msaccess”) billing application. Id. The igen.c program took a linked list of domains queried in claim step 1C (the automatic querying step), generated a list of invoices (line 185 of brpt.c) and called a function to create an upload document for the distinct billing system to ingest, and then print to the file. The following code shows the generated list of invoices in brpt.c: iptr = gen_invoice (dtptr, ctptr, inv_date, mts_config, log_on);
Kosters Decl. Ex. A at 0026-0032. The relevant portion of the function print_msaccess_invoice was a csv file to be loaded into a 3rd party Microsoft Access billing application through a linked list of invoices (itpr) on lines 331 -335 of igen.c : while (iptr != NULL) { i = iptr->datum; fprintf (fp, "%s,%s\n", i->invoice, due_date); iptr = iptr->nxt; }
Id.
Claim 3
53
’468 Claims § 102 – MTS The device of claim 2 further comprising software executing on said computer for automatically updating said database based on the reply.
Initial & renewal processes – In response to the MTS email, a NetSol customer could ask to delete or modify the domain registration. Kosters Decl. ¶¶ 17-31. This email was received by the Spool_mail program as shown and described in claim step 1G (automatic receipt of customer’s reply), above, and automatically acknowledged by MTS using the reply_mail program as described in claim 4. Id. The output of the reply_mail program was sent to the db_mail program’s queue to be placed into the MTS ticket system. Db_mail was called to open the ingres database and process a list of files. Id. The store_mail program then updated the ticket in the INGRES database based on the customer’s reply: do { EXEC SQL EXECUTE PROCEDURE update_ticket ( ticket_no = :ticket_no, status = :status, priority = :priority, initial = :initial, received = :received, sent = :sent, type = :type, mode = :mode, csr = :csr, updated = :updated ) INTO :rval; ... } while (rval !=1 && sqlca.sqlcode == DEADLOCKED); EXEC SQL COMMIT; 1 && sqlca.sqlcode == DEADLOCKED); EXEC SQL COMMIT;
Kosters Decl. Ex. A at 0033-34, Ex. B at 0060-61. ’468 Claim 4 The device of claim 3 further comprising software executing on said computer for automatically generating a confirmation based on the reply, and for
Initial & renewal processes – Upon receipt of the customer’s email in response to either the MTS initial invoice email or renewal reminder email, the MTS reply_mail program would automatically send a confirmation email back to the sender from a list of files generated by spool_mail.c. Kosters Decl. ¶¶ 17-31. The main program took a list of files generated by spool_mail, read the headers, and sent back the confirmation reply. Id. The process_reply in reply_mail was then called. It determined there was ticket information contained in the customer’s email, and it sent it to autoreply in reply.c, which called the open_mail_agent to send the confirmation email (seen at bottom of claim step 1F). Kosters
54
’468 Claims § 102 – MTS automatically transmitting the confirmation to the client through said communication link.
Decl. Exs. A-B. The database was updated to reflect that the confirmation email was sent. The function Store_mail (to further claim 3) called do_action in the code to invoke a registration program called domreg – store_mail.c, lines 180-187, to send the confirmation. Id. For example:
Kosters Decl. at ARIN0044. Other examples can be found at Exhibit 14 (NET000519), Exhibit 15 (NET000529). RFC1400 also described the MTS automatic email responses that confirmed receipt and verified registration form processing:
Id., Exhibit 5 (NET000318-319).
F. [Ground 6] Claims 1-4, 9, 13-16, 24-27Are Invalid as Obvious
Under § 103 in View of MTS and Knowledge of One Having
Ordinary Skill.
As set forth above, each feature of claims 1-4 and 24-27 of the ’468 patent
was found in the MTS prior art system. However, to the extent the Board
determines that Petitioner has not met its burden on showing MTS publicly
disclosed automatically performing the ’468 patent’s automatic “querying,”
55
“generating,” or “transmitting” limitations, those functions would have been
obvious based on information indisputably publicly disclosed in the MTS ticket
emails, RFC1400, and “rs-talk” email discussion forum. Claims 9 and 13-16
merely replace the MTS FTP server with a generic and well-known “web server,”
which would likewise have been obvious to implement based on the operation of
MTS.
When considering obviousness, “it is proper to take into account not only
specific teachings of the reference but also the inferences which one skilled in the
art would reasonably be expected to draw therefrom.” Liberty Mutual Ins. Co. v.
Progressive Casualty Ins. Co., CBM2012-00002, Paper 66 (Final Written
Decision), 19-20 (P.T.A.B. Jan. 23, 2014); see 35 U.S.C. § 103. Here, one of
ordinary skill would be educated in computer science and have experience in
computer programming. See Section V.A, supra. As Dr. Goldberg explains, this
would encompass knowledge of fundamental software functions of querying a
database based on date field values, and automatically generating forms based on
information stored in a database. Ex. 1003 at ¶ 85. One of ordinary skill would
use these skills with information contained in the MTS tickets or MTS description
in RFC1400 to arrive at the ’468 patent claims. There would have been to
motivation to perform these functions. Ex. 1003 at ¶¶ 86-87. The entire goal of
MTS was to automate as many functions of Internet domain name registration as
56
possible. See Kosters Decl., Ex. 5 at NET316-22 (RFC1400). RFC1400 was
entitled “Transition and Modernization of the Internet Registration Services,” and
described how the “new autoreg templates” were designed “to facilitate automatic
processing.” Id. at NET316-17. RFC1400 further characterized the new MTS
system as “[a]utomated Internet registration services” designed to solve the same
efficiency problem in the art identified by the ’468 patent. Compare id. at NET318
(“This new automated system will allow more accurate and timely processing of
registration requests.”), with Ex. 1001 at 2:6-9 (“What is desired, therefore, is an
automated system . . . which will improve the speed, efficiency, and reliability of
performing professional services for clients.”).
One of ordinary skill would therefore use basic programming to achieve this
efficiency through any further automation of the MTS system, by creating software
to automatically query a database to find expiring registrations. Indeed, the MTS
emails and RFC1400 even referred to MTS’s use of a database. NET510
(referencing MTS “InterNIC database” as storing “domain name records.”);
NET321 (showing “[c]onnecting to the rs Database” as part of customer processing
for querying status of MTS ticket processing). And since the automatic receipt and
“parsing” of the customer’s reply was expressly referenced in RFC1400 and the
MTS ticket emails, automating the remaining steps of generating the MTS ticket
email and sending it out would have been obvious. Ex. 1003 at ¶¶ 85-87.
57
To the extent Patent Owner argues that MTS does not disclose using a “web
server” to transmit the forms as in claims 9 and 13-16 of the ’468 patent, that too
would have been well within the abilities and motivation of one having ordinary
skill in the art. Ex. 1003 at ¶¶ 88-91. A web server is fundamental to the world
wide web architecture, so well known that it was published in “Internet for
Dummies” at least as of 1993, and thus would have been well within the computer
science knowledge of one having ordinary skill. Id. ¶¶ 88-90; Exs. 1007-1008; See
Muniauction, Inc. v. Thomson Corp., 532 F.3d 1318, 1326-27 (Fed. Cir. 2008)
(finding incorporation of “web browser technology” obvious and noting the
Internet, web, and browsers were well-known before October 1996); MPEP §
2143(I)(B) (Example 7). Motivation to use these standard web features can be
found in the MTS ticket emails themselves, which transmitted the templates to the
customer through the Internet from an FTP server the same way as a web server
would have, only using a different comunications protocol (HTTP instead of FTP).
Ex. 1003 at ¶¶ 88-91; Kosters Decl., Exs. 13-16, 18-23.
The transition from FTP to HTTP protocol would have been trivial and well
within the capability of a person of ordinary skill. See Ex. 1003 at ¶¶ 88-90;
Versata Software, Inc. v. Internet Brands, Inc., 902 F. Supp. 2d 841, 850 (E.D.
Tex. 2012) (upholding obviousness finding based on expert testimony that “many
software products were being adapted to work on the Internet, and it therefore
58
would have been obvious to put ‘any of th[e] functionality . . . on a second
computer like a web server’”); Ebay, Inc. v. Kelora Sys., No. C10-4947CW, 2012
WL 1835722, at *13-14 (N.D. Cal. May 21, 2012) (concluding as a matter of law
that “client-server systems were known at the time of the invention . . . , [and] were
obvious to try and were taught by prior art”); Ex Parte Sung-Sik Jung, No. 2008-
005636, 2009 WL 3089021, at *4 (BPAI 2009) (“In the latter part of the last
century, data distribution by web servers, for World Wide Web and Internet access,
became commonplace.”). Indeed, NetSol already had launched an InterNIC
website that it used in connection with the registration system—it just had not
gotten around to incorporating the web into MTS, likely due to the unexpected
rapid influx of automated registrations through the Internet email-based MTS.
Kosters Decl. ¶¶ 32-56, Exs. 1-4; Ho. Decl. ¶¶ 5-9, 27-30, Exs. C-F.
G. [Ground 7] Claims 1-4, 9, 13-16, 24-27 Are Invalid as Obvious
Under 35 U.S.C. § 103 in View of PerfectLaw, Alone or in
Combination with MTS.
“PerfectLaw” refers to the suite of legal docketing and document assembly
software sold by Executive Data Solutions, Inc. (“EDSi”), a company founded by a
former computer science professor at the University of Miami named John
Duncan. Ex. 1014 (“Duncan Dep.”) at 48:11-42, 51:10-56:24, 119-122, 136-39,
cover letters; id., Ex. 10 at WS27635. PerfectLaw was widely distributed to
59
several large law firms throughout the country well before the filing date of the
’468 patent. See id. There are at least two relevant software applications that
EDSi sold together and documented in manuals prior to the filing date of the ’468
patent: (1) the “PerfectLaw Docket” software; and (2) the “PerfectLaw Document
Assembly” software. See id. EDSi referred to these as “front office” applications,
and installed and customized them with PerfectLaw “back office” applications like
timekeeping and billing. Id., Ex. 10 at WS27635-39.
1. PerfectLaw Qualifies as Prior Art.
PerfectLaw constitutes § 103 prior art because (i) its documentation
constitutes a prior art printed publication under § 102(a), and (ii) because it was a
prior system known or used in the United States more than a year before the ’468
patent filing date under § 102(a)-(b). MPEP § 2144.08(II)(A)(1). To qualify as a
“printed publication,” a reference does not literally need to be published on printed
on paper—software, and software manuals can be “printed publications” so long as
they are “disseminated or otherwise made available to the extent that persons
interested and ordinarily skilled” can access it exercising reasonable diligence. In
re Lister, 583 F.3d 1307, 1311 (Fed. Cir. 2009); Ex Parte ePlus, Inc., Decision on
App. in Reexam. Control No. 90/008,104 at 14-18 (BPAI May 18, 2011) (non-
precedential). The PerfectLaw manuals and brochures cited here were provided to
dozens (if not hundreds) of EDSi customers that licensed the software before
60
October 7, 1995. Duncan Dep. at 48:11-42, 51:10-56:24, 119-122, 136-39; id., Ex.
4 (sold to SSJR in Feb. 1994), Ex. 10 at WS27660-61 (brochure extensively
describing the PerfectLaw software distributed in 1993 at Arizona trade show
called “LAWNET ’93”). Similar to ePlus, there were no restrictions on who could
purchase PerfectLaw, so anyone could obtain the PerfectLaw manuals and
brochures documentation—and many law firms did. While Patent Owner may
argue that the distribution dates of certain PerfectLaw manuals are uncertain, the
dates stated on their covers and elsewhere within them are corroborated by Mr.
Duncan’s testimony that PerfectLaw in fact contained their disclosed functionality
well before October 7, 1996. See, e.g., Duncan Dep. at 77:23-25; 78:25-80:12;
84:7-86:19; 173:16-174:6. With far more detail than the ’468 patent, a POSA
would have been able to practice the claims based on the PerfectLaw
documentation without undue experimentation. Goldberg Decl. ¶¶ 59, 108-119;
see 3M v. Chemque, Inc., 303 F.3d 1294, 1306 (Fed. Cir. 2002). Thus,
PerfectLaw qualifies as prior art for obviousness.
2. PerfectLaw Docketing and Document Assembly Software.
As with other docketing systems admitted as prior art by the ’468 patent,
PerfectLaw “contain[ed] a database of deadlines,” automatically “notifie[d] the
professional of each upcoming deadline a preset time period before the deadline”
through a “networked computer.” Duncan Dep. at 64:18-66:23, 77:5-80:19, 98:19-
61
102:17, 173:16-174:6; id., Exs. 4-9, Ex. 10 at WS27638-39, Ex. 11, Ex. 12
(EDSI000521-25), Ex. 13 (WS27334, WS27344). But this was not the only
functionality of PerfectLaw available before the ’468 patent’s filing date. Rather,
PerfectLaw automated many more steps of the claimed “professional services”
delivery process. EDSi packaged together its automated docketing and document
assembly software, integrating it with computers throughout a particular law office
through a centralized database and local area, intranet (or “LAN”) network. (Id. at
WS27660.) Packaging this software together into what EDSi variously marketed
as “Total PerfectLaw System,” “Attorney Information Management” (AIM), or
“Novell PerfectLaw Sofwtare Portfolio” (among others), EDSi championed itself
as a “one-stop automation shop.” (Id. at WS27635-36, WS27660.) Ex. 1003 at
¶¶ 93-103.
The PerfectLaw Docket software (also referenced as PerfectLaw
“Docket/Calendar” and “Docket II” or “Docket 2.0”) contained all the features of
the ’468 patent’s “database,” “client reminders,” and “querying” thereof—
amounting to an automated “tickler” for tracking important dates and displaying
status reports and reminders for important upcoming deadlines. Duncan Dep., Ex.
10 at WS27640. This software monitored a centralized “table” database that stored
“client reminders” in the form of “master files” having “rule-based appointments”
with multiple fields, including a “due date” field, client, matter, and event codes.
62
Id. at WS27640; Duncan Dep. at 64:18-66:23, 77:5-80:19, Ex. 12 at EDSI000521-
25. The rule-based software automatically calculated reminder dates for events
based on an initial “key date,” such as the filing of a complaint. Duncan Dep. at
173:16-174:6; id., Ex. 12 at EDSI000552-557 (configurable “Sequence, Interval,
and Relative” fields triggered period for future deadline reminder); id. Ex. 10 at
WS27639 (characterizing this feature as implemented with “query software”). The
reminder would be displayed on a networked law office computer in a number of
different ways, including as an appointment slip, calendar, or master list showing
the upcoming deadlines and reminder information. Duncan Dep., Ex. 10 at
WS27640 (showing tickler on June 15, 1993 to “[p]repare reply to interrogatories”
due five days thereafter). Goldberg Decl. ¶¶ 101-07. EDSi marketed the
PerfectLaw Docket software as “keep[ing] clients better informed by producing
case status reports [which] increases the chance for future business.” Duncan Dep.
Ex. 10 at WS27640.
In conjunction with the docketing software, the Document Assembly
software automatically merged client or event-specific data with template forms to
create what the ’468 patent claims as a “client response form.” Document
Assembly tapped into form documents that were created using a Microsoft
WordPerfect word processor, which were shared across the LAN network.
(Duncan Dep. At 64:14-66:23, 79:16-2, 82:22-89:16, 93:6-94:7; Duncan Ex. 10 at
63
WS27642.) The forms were compatible with a database management system
called “dBASE,” which facilitated the Document Assembly software function of
automatically merging client/matter and event-specific information with the
WordPerfect template forms to assemble documents. E.g., Duncan Ex. 10 at
WS27642-43 (template answer pleading populated with specific client/matter
information like party name, attorney contact information, and date). EDSi
marketed the assembled forms as “[p]rovid[ing] a more accurate and timely
document to the client or court.” See id. at WS27642; Ex. 1003 at ¶¶ 104-105.
What PerfectLaw did not appear to have at the time was a connection to the
Internet to transmit its reminders and forms outside of the law office in which
PerfectLaw was installed. See Ex. 1003 at ¶¶ 106-107. It also apparently did not
use a web server. Id.
3. One of Ordinary Skill Would Be Motivated to Combine
PerfectLaw with Common Knowledge or with MTS.
Under the Supreme Court’s ruling in KSR Int’l Co. v. Teleflex Inc., 550 U.S.
398 (2007), the USPTO need not identify an express teaching, motivation, or other
“specific hint or suggestion in a particular reference” in order to combine prior art
to arrive at the claimed invention. Perfect Web Technologies, Inc. v. InfoUSA,
Inc., 587 F.3d 1324, 1329 (Fed. Cir. 2009) (citations omitted); MPEP § 2141.
Instead, the obviousness analysis should employ the “common sense” of one
64
having ordinary skill in the art, with “a reasoned explanation” supporting the
proposed combination and a reasonable likelihood of success. See id; see also
Wyers v. Master Lock Co., 616 F.3d 1231, 1238-45 (Fed. Cir. 2010) (finding it was
common sense to combine prior art references to arrive at the claimed invention).
Here, one of ordinary skill in the art would have combined common sense or
features of MTS to arrive at automatically transmitting, receiving, and processing
the PerfectLaw document assembly response forms and notices in order to arrive at
claims 1-4, 9, 13-16, and 24-27 of the ’468 patent. This would have simply been
applying modern technology to further automate the PerfectLaw system.
a. Combining PerfectLaw with Ordinary Skill
EDSi installed the PerfectLaw software to operate on computers networked
together inside a law firm, but it is unclear whether those networks were connected
to the Internet or used URLs or websites to convey the response forms generated
by Document Assembly. Nevertheless, it would have been routine and trivial for
one having ordinary skill in the art of the ’468 patent to connect the PerfectLaw
software to the Internet to exchange communications regarding the forms, and to a
web server for transmitting the form through the Internet upon activation of a
URL. Ex. 1003 at ¶¶ 108-114. It was well within the knowledge of persons in the
software, computing, and networking industry before October 1996 that the
Internet and websites hosting forms on web servers were modern communication
65
standards and the wave of the future. See Ex. 1003 at ¶¶ 112-114. PerfectLaw
itself was compatible with the Internet, expressly including hardware and software
infrastructure suitable for the Novell LAN intranert, which itself was compatible
with an Internet connection simply through the use of a modem and the telephone
lines for internal LAN network. See Duncan Dep. Exs. 4-5 at EDSI000728-732
(EDSi brochure sent to SSJR listing proposed hardware of “External Modem” and
“Novell Asynchronous Communications Server” and software applications of
“Electronic Mail” and “Novell Netware”; Duncan Dep. at 57:14-59:20, 71:1-73:9;
80:3-81:25, 102:1-103:11, 104:22-105:2, 106:1-4, 107:3-5, 125:3-7.). In fact,
EDSi already offered various “on-line” services in connection with the PerfectLaw
software. Duncan Dep., Ex. 10 at WS27638-39.
The PerfectLaw materials showed general motivation to modify the
PerfectLaw software to make its response forms available over the Internet. For
example, in addition to all of the Internet-compatible and webserver-compatible
hardware and software already deployed by EDSi to install PerfectLaw, the overall
mission of EDSi as the “one-stop automation” shop that “focus[ed] all [its]
energies on automating law offices” would be motivated to implement a
connection to external clients through the Internet as part of a natural expansion of
technological capabilities to meet the “automation” mission. (Duncan Ex. 10 at
WS27635-36; Ex. 1003 at ¶ 111. One would also have been motivated to combine
66
the Internet and webservers to solve the common problems of both PerfectLaw and
the ’468 patent of “automation,” “reduc[ing] attorney preparation and reading time,
as well as the secretarial cost of document production,” and “provid[ing] a more
accurate and timely document to the client or court” (Duncan Ex. 10 at WS27642)
—i.e., to “improve the speed, efficiency, and reliability of performing services for
clients.” ’468 patent at 2:16-19; Ex. 1003 at ¶ 112). Indeed, Mr. Duncan testified
that market demand required EDSi to integrate their PerfectLaw system with email
for automatic reminder reports. Duncan Dep. at 80:3-81:45.
There would also be a high likelihood of success when combining
PerfectLaw with modern communications technology like the Internet and
webservers. EDSi’s emphasis on “high quality, industry standard components” of
“the highest quality available” were reportedly highly compatible with state of the
art technology, having “greater flexibility” to adapt to new technologies like the
Internet—which was available before October 1996. Duncan Dep. Ex. 10 at
WS27660. Further, Mr. Duncan testified that PerfectLaw was compatible with
being used over the Internet. Duncan Dep. at 73:4-9, 102:24-103:11. Adapting the
PerfectLaw software by transmitting its client response form outside law firms
through the Internet, instead of within the law firm through the Novell intranet, is
only consistent with EDSi’s stated purpose of providing systems and networks to
offer “one total solution to law office automation.” Id., Ex. 10 at WS27660.)
67
b. Combining MTS with PerfectLaw
As explained above, MTS automatically transmitted a response form and
automatically received and processed replies to the forms through the Internet, and
also used URLs to send the forms through a webserver. With the same motivation
for using common knowledge or the express teachings of the PerfectLaw materials,
one of ordinary skill could have simply added those corresponding communication
features found in MTS to PerfectLaw according to well-known networking
techniques. In fact, those networking techniques had already been deployed for
PerfectLaw but using an internal, Novell intranet network.
While the MTS system was deployed in the domain name registration and
renewal industry, the problem of improving client services through increased speed
and efficiency was common to MTS and PerfectLaw. Duncan Ex. 10 at WS27642;
see Ex. 1003 at ¶¶ 115-118. As such, someone working to automate sending client
reminders to provide services, would almost certainly focus attention on not only
automated attorney docketing systems like PerfectLaw, but also automated domain
name renewal reminder systems such as MTS. Sci. Plastic Prods., Inc. v. Biotage
AB, 766 F.3d 1355, 1360-61 (Fed. Cir. 2014) (problem of preventing plastic screw-
on cap leakage for low pressure liquid cartridges for chromatography could be
solved using soda bottlecap solution). When confronting the problem of the ’468
patent—extending the automated services of PerfectLaw outside the four walls of a
68
law office—one of ordinary skill would naturally consider MTS’s use of the
Internet to extend the automated delivery of others services such as domain
renewals. In re Clay, 966 F.2d 656 (Fed. Cir. 1992); Medtronic, Inc. v. Cardiac
Pacemakers, 721 F.2d 1563 (Fed. Cir. 1983) (electronic circuit device references
solving high frequency power problem held analgous art for patent directed to
medical pacemaker device solving similar power problem). Moreover, the result
from combining PerfectLaw with MTS (or common knowledge) would also have
been predictable and successful, for the technology apparently missing from
PerfectLaw—the Internet, webserver, and URL activated to send the forms—was
(and is) conventional without any specifics unique to the ’468 patent’s claims. See
discussion above, Section VI.A. In sum, adding to PerfectLaw the conventional
Internet and web features claimed in the ’468 patent would have been a minor and
routine modification, whether based on common knowledge of one having
ordinary skill or in combination with the specific MTS Internet and webserver
connectivity features.
4. MTS and PerfectLaw Obviousness Claim Charts
The following charts summarize where each element of the asserted claims
is found in the PerfectLaw and MTS references, as well as where knowledge of
one having ordinary skill in the art would be combined. Ex. 1003 at ¶ 119.
’468 Claims § 103 – PerfectLaw, MTS and/or Ordinary Skill [1P] A device for EDSI sold PerfectLaw to dozens of law firms between 1994
69
’468 Claims § 103 – PerfectLaw, MTS and/or Ordinary Skill automatically delivering professional services to a client comprising:
and 1995, which was software that automatically delivered billing, accounting, case and document management services. E.g., Ex. 1014, Duncan Dep. at 48:11-42, 51:10-56:24, 119-122, 136-39; id., Ex. 4 (sold to SSJR in Feb. 1994), Ex. 10 at WS27660-61.
[1A] a computer; PerfectLaw was that operated on a computer, typically on one or more computers within a law office. E.g., Duncan Dep. at 98:19-102:17, 173:16-174:6; id., Exs. 4-5, Ex. 10 (WS27638). See citations to MTS § 102 Chart, claim 1 element [1A].
[1B] a database containing a plurality of client reminders, each of the client reminders comprising a date field having a value attributed thereto;
PerfectLaw “Docket” software monitored a centralized docketing database that stored “client reminders” in the form of “master files” or “rule-based appointments” containing multiple fields, the fields including a date field, client, matter, and event codes. Duncan Dep. at 64:18-66:23, 77:5-80:19 (since 1994, PerfectLaw used “table database” with “due dates” entered and “data to link” a “form document that was stored in the system” to manage events which were “a task having a data, a deadline, and appointment”); id., Exs. 5-9, Ex. 10 at WS27639 (“database editing”), Ex. 11, Ex. 12 (EDSI000521-25), Ex. 13 (WS27334, WS27344).
Id., Ex. 10 at WS27640 (automated “tickler” reminders). The client reminders stored in the database comprised a date field having a value attributed thereto:
70
’468 Claims § 103 – PerfectLaw, MTS and/or Ordinary Skill
Duncan Ex. 12 at EDSI522-23; see also id., Ex. 12 at EDSI516-21 (“Entering Rule-Based Events and Deadlines” that “automatically sets dates based on rules” stored in a “database”) EDSI552-65, EDSI80-82, Ex. 13 at EDSI495-502 (“tickers”); Duncan Dep. at 173:16-174:6. See citations to MTS § 102 Chart, claim 1 element [1B].
[1C] software executing on said computer for automatically querying said database by the values attributed to each client reminder date field to retrieve a client reminder;
PerfectLaw automatically queried a docketing database by a date and/or date range to retrieve reminders pertaining to client/matter records. Duncan Dep. at 64:18-66:23, 79:16-2 (“The basis of case management, as PerfectLaw defines it, is appointment tasked to do event functionality so it manages events, contract management functionality, document management functionality, and forms functionality. . . . an event is a task having a date, a deadline, and appointment.”)
Duncan Ex. 10 at WS27639; see also id. at WS27640-41,
71
’468 Claims § 103 – PerfectLaw, MTS and/or Ordinary Skill WS27643; Duncan Ex. 12 at EDSI000552 (“Entering Rule-Based Events and Deadlines”).
Id., Ex. 12 at EDSI000556; see also id., Ex. 5 at EDSI731 (“[c]ritical date management”); DuncanDep. at 173:16-174:6. See citations to MTS § 102 Chart, claim 1 [1C].
[1D] software executing on said computer for automatically generating a client response form based on the retrieved client reminder;
PerfectLaw “Document Assembly” software stored template legal forms in a “Word” database, and the software automatically populated those forms by “merging” them with information retrieved from the client/matter information stored in the docketing database. Duncan Dep. at 64:14-66:22), 82:22-89:16, 93:6-94:7; Duncan Ex. 5 at EDSI731 (“PerfectLaw Document Assembly – Merges WordPerfect & Case Database Records” received by SSJR Feb. 4, 1994), Ex. 10 at WS27642.
Duncan Ex. 10 at WS27643; see also id., Ex. 14 at WS27334, WS2744, WS27354, WS27355-57, WS27370-
72
’468 Claims § 103 – PerfectLaw, MTS and/or Ordinary Skill 72. To the extent PerfectLaw does not disclose that the completed template forms were created based on the client/matter reminder information in the docketing database, a POSA would have combined these PerfectLaw features together to do so, alone or in combination with the MTS functionality of creating emails with customer-specific template registration forms based on upcoming registration deadlines. see citations to MTS § 102 Chart, claim 1 element [1D].
[1E] a communication link between said computer and the Internet;
PerfectLaw used a local area network (LAN) intranet to communicate intra-office, connected to a shared database. Duncan Dep. at 96:12-101:25; id., Exs. 4-5 at EDSI000728-732, Ex. 10 at WS27638-39, WS27635-36, WS27642, WS27660; ’468 patent at 2:16-19. EDSi used telephone lines to communicate with clients, but the hardware that EDSI installed, including modems, could be used to connect to the Internet and transmit the reminders and template forms over email. See id. at 57:14-59:20, 71:1-73:9; 80:3-81:25, 102:1-103:11, 104:22-105:2, 106:1-4, 107:3-5, 125:3-7. A POSA would have combined PerfectLaw with conventional Internet technology or the use of the Internet as taught by NetSol’s MTS message ticketing system in order to arrive at this limitation. see citations to MTS § 102 Chart, claim 1 element [1E].
[1F] software executing on said computer for automatically transmitting the client response form to the client through said communication link; and,
PerfectLaw used a telephone line to communicate with other computers, and its client reminders and auto-populated template response forms could be emailed out to clients. Duncan Dep. at 57:14-59:20, 71:1-73:9; 80:3-81:25, 96:12-101:25, 102:1-103:11, 104:22-105:2, 106:1-4, 107:3-5, 125:3-7,; id., Exs. 4-5, 10. A POSA would have combined PerfectLaw with conventional Internet technology or the use of the Internet or email as taught by NetSol’s MTS message ticketing system and its automatic transmission of domain registration
73
’468 Claims § 103 – PerfectLaw, MTS and/or Ordinary Skill emails containing forms sent to customers. see citations to MTS § 102 Chart, claim 1 element [1F].
[1G] software executing on said computer for automatically receiving a reply to the response form from the client through said communication link.
PerfectLaw “Docket” software stored client/matter information in a centralized database, and PerfectLaw “Document Assembly” software stored template legal forms in a “Word” database, which the software automatically populated those forms by “merging” them with information retrieved from the docketing database. Duncan Dep. at 64:14-66:23, 79:16-2, 82:22-89:16, 93:6-94:7; Duncan Ex. 5 at EDSI731 (“PerfectLaw Document Assembly – Merges WordPerfect & Case Database Records” received by SSJR Feb. 4, 1994), Ex. 10 at WS27639, WS27640-43, Ex. 12 at EDSI000552-56, Ex. 14 at WS27334, WS2744, WS27354, WS27355-57, WS27370-72. A POSA would have combined PerfectLaw with conventional Internet or forms processing technology, or the use of the Internet-email based auto-parsing of forms functionality taught by MTS in order to automatically receive the client’s reply to the PerfectLaw merged form. see citations to MTS § 102 Chart, claim 1 element [1G].
2. The device of claim 1 further . . . generating a response based on the reply, and for automatically transmitting the response to a third party.
A POSA would have combined PerfectLaw with conventional Internet or forms processing technology, or the use of the Internet-email based auto-parsing of forms functionality taught by MTS in order to further generate a response to the client’s reply, and to send the response to a third party similar to NetSol sending billing information to third party billing departments. see citations to MTS § 102 Chart, claim 2.
3. The device of claim 2 further . . . updating said database based on the reply.
A POSA would have combined PerfectLaw with conventional Internet or forms processing technology, or the use of the Internet-email based auto-parsing of forms functionality taught by MTS in order to update the PerfectLaw docket database with updated client/matter information based on the client’s reply to the merged form. see citations to MTS § 102 Chart, cl. 3.
4. The device of claim 3 further
A POSA would have combined PerfectLaw with conventional Internet or forms processing technology, or the
74
’468 Claims § 103 – PerfectLaw, MTS and/or Ordinary Skill comprising . . . generating a confirmation based on the reply, and for automatically transmitting the confirmation to the client . . . .
use of the Internet-email based auto-confirmation reply feature taught by MTS in order to generate a confirmation communication sent to the client as in this element. see citations to MTS § 102 Chart, cl. 4.
’468 claim 9 § 103 – PerfectLaw, MTS or Common Knowledge[9A-C] A device for . . . reminder;
See citations to corresponding limitations in claim 1, above, incorporated here by reference. Goldberg Decl. ¶¶ 108-118.
[9D] software executing on said computer for automatically generating a client response form and a notice based on the retrieved client reminder, the notice containing a URL;
See citations to corresponding limitations in claim 1, above, incorporated here by reference. MTS initial & renewal processes – The initial invoice MTS email and renewal reminder MTS email transmitted to customers contained language that notified the customer that payment was due on the domain registration, and further contained a template domain registration form as described above. Kosters Decl. ¶¶ 12-31. The emails here are the claimed “notice based on the retrieved client reminder,” and the claimed “client response form” is the domain registration template. Id. These email notices contained a URL (rs.internic.net/templates/domain-template.txt). Id., Exhibit 10; see also id., Exhibits 14-15, Ex. 18 (ARIN0049), Ex. 21 (ARIN0055). Renewal process –MTS transmitted to customers emails that notified customers that the registration would be expiring, and further contained a template domain registration form as described above:
Id., Ex. 18 (ARIN0001). The MTS renewal reminder emails
75
’468 Claims § 103 – PerfectLaw, MTS and/or Ordinary Skill also contained a URL:
Id., Ex. 18 (ARIN0013 at lines 665-72); see also id., Exhibit 16 (NET000541), Ex. 18 (ARIN0036). PerfectLaw used automated merge form software and automated “tickler” reminders stored in databases. See citations to claim 1, elements [1B]-[1B]. A POSA would have combined these features of PerfectLaw with conventional Internet-based email, forms, and URL technology, or their use as taught by MTS in order to automatically generate a notice containing a URL as well as the response form. see citations to MTS § 102 Chart, claim 2. Goldberg Decl. ¶¶ 108-118.
[9E] a web server; Initial & renewal processes – The MTS system stored the latest domain registration forms on an FTP server accessible through the rs.internic.net website. Exhibit 10; Exhibits 14-15; ARIN0049; ARIN0055; Kosters Decl. ¶ _, Ex. 18 (ARIN0013 at lines 665-72); see also id., Exhibit 16 (NET000541), Ex. 18 (ARIN0036). The InterNIC FTP server was discussed on the InterNIC’s website “Accessing Our Other Online Services” page along with reference to an InterNIC website having a “web interface” at least as of March 26, 1996. Kosters Decl., Ex. 1. A web server was conventional world wide web technology before the filing date of the ’468 patent. Ex. 1007-1008; Duncan Dep. at 19:14-24:13, 31:21-33:2, 34:22-35:25. An FTP server is functionally similar to a web server but uses a different communication protocols (a web server uses HTTP requests). Exs. 1007-1008, 1012. A POSA would have converted the PerfectLaw LAN server or NetSol FTP server into a web server as of the filing date of the ’468 patent
76
’468 Claims § 103 – PerfectLaw, MTS and/or Ordinary Skill using well-known techniques. Goldberg Decl. ¶¶ 108-118.
[9F] software executing on said computer for automatically transmitting the client response form to said web server and for automatically transmitting the notice to the client; and
Initial & renewal processes – The MTS initial invoice and renewal reminder emails, which were notices to the customer of payment due and expiring registration (respectively), were automatically sent to the customer as described above in claim 1. Kosters Decl., Exhibit 10; Exhibits 14-15; ARIN0049; ARIN0055; Kosters Decl., Exhibit 1. The MTS system also electronically stored the template domain registration form at the InterNIC FTP server located at rs.internic.net. Id.
Kosters Decl., Ex. 2; id., Exhibit 2 at page 2 (8/30/1996 status report to NSF of 1995 InterNIC objectives). PerfectLaw used a telephone line to communicate with clients, but its client reminders and auto-populated template response forms could be emailed out to clients. Duncan Dep. at 57:14-59:20, 71:1-73:9; 80:3-81:25, 96:12-101:25, 102:1-103:11, 104:22-105:2, 106:1-4, 107:3-5, 125:3-7,; id., Exs. 4-5, 10. A POSA would have combined PerfectLaw or MTS with conventional web server technology to automatically transmit either the PerfectLaw merged forms or the MTS template domain registration forms to a web server and, as MTS already did, transmit an email containing a notice with a URL to the client. Goldberg Decl. ¶¶ 108-118. see citations to MTS § 102 Chart, claim 1 element [1F].
[9G] software executing on said web server for automatically transmitting the response form to
Initial & renewal processes – When the MTS customer clicked on the ftp://rs.internic.net/templates/domain-template.tx URL contained within the MTS email (described above), software executing on the InterNIC FTP server would automatically transmit the template domain registration form to the client through the Internet. Kosters ,
77
’468 Claims § 103 – PerfectLaw, MTS and/or Ordinary Skill the client when the URL is activated and for automatically receiving a reply to the response form from the client.
Ex. 23; id., Ex. 13. The InterNIC FTP server was discussed on the InterNIC’s website “Accessing Our Other Online Services” page along with reference to an InterNIC website having a “web interface” at least as of March 26, 1996. Kosters Decl., Ex. 1, Ex. 3. See also citations to § 102 MTS chart, claim 1 step 1G. A POSA would have combined PerfectLaw or MTS with conventional web server technology to use a web server to automatically transmit the PerfectLaw merged forms or the MTS template domain registration forms to the client when the URL is activated (as MTS did through an FTP server just using a different communications protocol), and to use a web server to receive a reply to either of those forms. Goldberg Decl. ¶¶ 108-118; see citations to MTS § 102 Chart, claim 1 element [1F]; Duncan Dep. at 57:14-59:20, 71:1-73:9; 80:3-81:25, 96:12-101:25, 102:1-103:11, 104:22-105:2, 106:1-4, 107:3-5, 125:3-7; id., Exs. 4-14.
13. The device of claim 9 further comprising software executing on said web server for automatically generating a notice of reply based on the reply, and for automatically transmitting the notice of reply to said computer, and software executing on said computer for automatically receiving the notice of reply from said web server.
Initial & renewal processes – As described in relation to claim 1, MTS server software automatically identified whether a customer’s email contained a reply filling in the template registration form and created a notice of receipt of that customer’s reply, and MTS automatically parsed the email and notified the rest of the MTS system, including updating the database. Citations to § 103 chart claim 1, element [1G] and claims 3-4 are incorporated here by reference. A POSA would have incorporated a web server into either MTS or PerfectLaw as described in claim 9 in order to process a notice of the client’s reply, and for automatically receiving the reply as the MTS system did with all emails received from customers. Goldberg Decl. ¶¶ 108-118.
14. The device of Citations to § 103 chart claim 2 are incorporated here by
78
’468 Claims § 103 – PerfectLaw, MTS and/or Ordinary Skill claim 13 further comprising . . . generating a response based on the notice of reply, and . . . transmitting the response to a third party.
reference. MTS automatically generated a response based on notice of the customer’s reply to the template domain registration form, as shown in citations for claim 2. MTS automatically transmitted billing information contained in the customer’s response to a separate billing department as shown in the code for claim 2. Kosters Decl. ¶¶ 23, 30. A POSA would have incorporated a web server into either MTS or PerfectLaw as in claim 9 in order to generate a response based on notice of the client’s reply and transmit the response to a third party as the MTS system did with all emails received from customers. Goldberg Decl. ¶¶ 108-118.
15. The device of claim 14 further comprising . . . updating said database based on the notice of reply.
Citations to § 103 chart claim 3 are incorporated here by reference. MTS automatically updated the INGRES database based on notice of the customer’s reply as shown in the citations for § 102 MTS Chart claim 3, incorporated here by reference. PerfectLaw utilized an automatic database. See citations to § 103 Chart elements [1B]-[1D]. A POSA would have combined PerfectLaw or MTS with a web server to further update either of their databases based on notice of the client’s reply. Goldberg Decl. ¶¶ 108-118.
16. The device of claim 15 further comprising . . . generating a confirmation based on the notice of reply, and . . . transmitting the confirmation to the client.
Citations to § 103 chart claim 4 are incorporated here by reference. MTS automatically generated a confirmation email based on the notice of the customer’s reply and transmitted that confirmation to the customer by email, as shown in the citations for claim 4, incorporated by reference. Kosters Decl. ¶¶ 21-31. PerfectLaw utilized tickler reminders. See citations to § 103 Chart elements [1B]-[1D]. A POSA would have combined PerfectLaw or MTS with a web server to further generate and send the client a confirmation based on the notice of a reply, as MTS already did. Goldberg Decl. ¶¶ 108-118.
VII. CONCLUSION
Petitioner therefore requests that a Covered Business Method Post-Grant
Review of these claims be instituted. The undersigned attorneys welcome a
79
telephone call should the Office have any requests or questions. If there are any
additional fees due in connection with the filing of this paper, please charge the
required fees to our Deposit Account No. 14-0629.
Respectfully submitted, this 22nd day of January, 2015.
BALLARD SPAHR LLP
/ Scott D. Marty, Ph.D., Reg. No. 53,277/ Scott D. Marty, Ph.D., Lead Counsel USPTO Registration No. 53,277 [email protected] 999 Peachtree Stree, Suite 1000 Atlanta, GA 30309-3915 Phone: 678-420-9408 Jonathon A. Talcott, Back-up Counsel USPTO Registration No. 71,671 [email protected] 1 East Washington Street, Suite 2300 Phoenix, AZ 85004-2555 Phone: 602-798-5485 Daniel A. Nadel, Back-up Counsel USPTO Registration No. 59,655 [email protected] 1735 Market Street, 51st Floor Philadelphia, PA 19103-7599 Phone: 215-864-8844 Attorneys for Petitioner GoDaddy.com, LLC
CERTIFICATE OF SERVICE
Pursuant to 37 C.F.R. §§ 42.6(e) and 42.105(a), this is to certify that I
caused to be served a true and correct copy of the foregoing PETITION FOR
80
POST-GRANT REVIEW OF U.S. PATENT NO. 5,895,468 UNDER 35 U.S.C. §
321 AND § 18 OF THE LEAHY-SMITH AMERICA INVENTS ACT by United
States Express Priority Mail, on this 22nd day of January, 2015, on the Patent
Owner at the correspondence address of the Patent Owner as follows:
Wesley Whitmyer, Jr., Esq. David Hwang, Esq.
St. Onge Steward Johnston & Reens LLC 986 Bedford Street
Stamford, Connecticut 06905-5619 Dated this 22nd day of January, 2015.
/Jonathon A. Talcott/ Jonathon A. Talcott USPTO Reg. No. 71,671 Attorney for Petitioner GoDaddy.com, LLC