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 martys@ballardspahr.com

Fax: 602-798-5595 talcottj@ballardspahr.com

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 nadeld@ballardspahr.com

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

“nanog@merit.edu” distribution list, and NetSol used the “rs-talk@internic.net”

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 billing@internic.net 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 billing@internic.net 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 martys@ballardspahr.com 999 Peachtree Stree, Suite 1000 Atlanta, GA 30309-3915 Phone: 678-420-9408 Jonathon A. Talcott, Back-up Counsel USPTO Registration No. 71,671 talcottj@ballardspahr.com 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 nadeld@ballardspahr.com 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