david w. axelrod, osb #750231 email daxelrod ... - magic · david w. axelrod, osb #750231 email...

David W. Axelrod, OSB #750231Email [email protected] E. Mansfield, OSB #05539Email [email protected] E. Tingleaf, OSB #054463Email [email protected], Williamson & Wyatt, P.C.Pacwest Center1211 SW 5th Ave., Suite 1900Portland, OR 97204Telephone 503.222.9981Fax 503.796.2900

Of Attorneys for Defendant, Xap Corporation

IN THE UNITED STATES DISTRICT COURT

FOR THE DISTRICT OF OREGON

COLLEGENET, INC.,

Plaintiff,

vs.

XAP CORPORATION,

Defendant.

No. 03-1229-BR

XAP CORPORATION’S POST-TRIAL PROPOSED FINDINGS OF FACT

Case 3:03-cv-01229-BR Document 808 Filed 07/14/08 of 32 Page ID#: 6842


SCHWABE, WILLIAMSON & WYATT, P.C.Attorneys at LawPacwest Center

1211 SW 5th Ave., Suite 1900Portland, OR 97204

Telephone 503.222.9981

PDX/117132/154237/DWA/2742335.7

Xap Corporation submits the following Post-Trial Proposed Findings of Fact. “Tr_____”

citations are references to the 2008 trial transcript.

I. The Prior Art Systems Made, Used and Sold by CollegeNET.

1. Prior to the Critical Date, CollegeNET sold, offered for sale, or publicly operated

two systems for presenting over the Internet customized forms to users, receiving the user’s

information, and processing that information to provide it to CollegeNET’s customers: the

college applications service referred to as “ApplyWeb” technology, and the Smart Loan™ forms

processing services provided to the Student Loan Marketing Ass’n (“Sallie Mae”).

A. ApplyWeb 1 System and Architecture

2. “ApplyWeb 1” (“AW 1”) means the college application forms processing service,

and the equipment and computer software that provided the service, that was publicly used, sold,

or offered for sale by CollegeNET prior to the Critical Date.

3. Prior to the Critical Date, CollegeNET contracted to provide AW 1 to more than

110 college campuses (DTX 2006) and advertised and touted this system to the public as having

specific functionality (DTX 2018, 2019) and as being the “most advanced network of fully web-

based, electronic admissions applications.” (DTX 2018, at CNA71249).

4. CollegeNET contends that it did not maintain records of the software programs

that implemented the public AW 1 service prior to the Critical Date. CollegeNET’s attorneys

identified by letter (DTX 2070) the best records they claimed were available, which included

software programs maintained in the “aw.test” directory, the directory Mr. Hitchcock described

as being the final staging directory for the launch of “production” versions of the AW 1 software.

Tr. 434. CollegeNET has no record of any so-called “production” code operative during April

and May of 1997 other than as reflected in aw.test/RCS/app.pl,v and aw.test/RCS/mp_app.pl,v.

Tr. 744-51. The best evidence of the software that implemented the pre-Critical Date college

application service is the programs listed as the first entry for each principal program category






PDX/117132/154237/DWA/2742335.7

(app.pl, ques.pl, process.pl, and cndb.pl) in DTX 2141. Tr. 747, 749-51. These programs

include all of the functional components needed to deliver the AW 1 service and are consistent

with CollegeNET’s marketing materials and internal documentation that describe the publicly-

available AW 1 service. Tr. 751.

5. Mr. Hitchcock suggests that the software directory—ns-home— is the

“production” code of AW 1 (Tr. 413, 434). The n-s home directory software cannot be, or

accurately reflect, the versions of the software that implemented the public AW 1 service in the

six months leading up to the Critical Date because it (1) contains only versions of app.pl that

were “last modified” on August 28, 1996 and December 5, 1996; (2) does not contain programs

(ques.pl and process.pl) needed to support the commercial service and which CollegeNET agrees

(7/9/08 Supp. Agreed Facts ¶¶ 3,4) were used in the pre-Critical Date public system, and (3) does

not contain any of the modifications that CollegeNET contends were made to the app.pl and

ques.pl programs after these “last modified” dates, as described in CollegeNET’s own records of

such changes. DTX 2047, PTX 3159.

6. The AW 1 system architecture can be divided into “front” and “back” ends.

7/9/08 Supp. Agreed Facts, ¶2. An important architectural feature of the front-end system was

the separation of the instructions for creating an application form from the software program that

generates the form (DTX 2072, p.2; Tr. 84-87). The forms engine, software programs named

app.pl (including after January 1997, ques.pl), generated HTML code based on instructions

provided by application data files in the form of # directives (“pound directives”) that were read

by the forms engine to generate the specific HTML fields. In AW 1, the application data files

were called “.in files.” Id.; Tr. 79, 91. Mr. Batcheller conceived of this architecture and

recognized its importance in documentation that was provided to Wolfston and studied by

Hitchcock well before the Critical Date. Tr. 75, 84, 86-87, 89, 95-98, 117-22; DTX 2076, 2078,

2182; Tr. 145-46.

“The <school> .in files are the strength of the ApplyWeb system. It permits applications to be built quickly, automatically and most important,






PDX/117132/154237/DWA/2742335.7

consistently. If a change needs to be made for an individual school, the application can be instantly rebuilt without concern that the change resulted in an incompatibility with the database and other applications. The key to the system is that all applications – regardless of how different they may be functionally – can uniformly exchange data with each other. The app.pl and <school> .in file enforces that. . . . The .in file is read by app.pl, which in its most simple incarnation, builds a static .html form representation of the .in contents. It builds text boxes, checkboxes, tables and lists as the .in file demands.” DTX 2072, p. 3 (emphasis supplied).The application engine permits the construction of an html application with a source file [“.in” file] that is typically 20% of the size of the final html application. The end result is that every application can be unique and accurate but requires 1/5 of the effort to create as the actual application, as well as be guaranteed compatible with the database.” DTX 2076, p. 1(emphasis supplied).

7. The front-end functions were performed by software programs (app.pl and later,

ques.pl) (7/9/08 Supp. Agreed Facts, ¶¶ 3, 4) which were different from the programs

(sendbot.pl, key_gen.pl, key_update.pl) that performed the back-end functions. DTX 2072.

Both groups of programs used software routines from process.pl and the cndb.pl library to write

user data to (the front end) and read it from (the back end) the database. Id.; Tr. 750.

8. The .in files list instructions to invoke common or school-specific form fields to

create an individual college application form in HTML. Tr. 79-81, 133-34. The .in file permits

each school to select the fields, and any individualized questions for its form(s), in the order and

lay-out specified by the college. Id. The AW 1 system supported more than 400 common or

shared fields (DTX 2037, lines 748-2852; 2029, 2029 A-D) and additional school-specific fields,

thereby enabling schools to request the information from applicants that the school wanted. Tr.

237-43. AW 1 branded the school’s form with the name of the school and its logo. Tr. 81. The

HTML code was then sent over the Internet to the user’s browser which interprets the code to

render the college application.

9. When a user filled out a form and posted the information back to the forms

engine, the user information was tagged with an attribute name assigned to the form field in the

AW 1 system (e.g., “PERSON_NAME_LAST (1)” for father’s last name). Process.pl and cndb.pl

software routines structured the user data in an alphabetical listing of attribute names and values






PDX/117132/154237/DWA/2742335.7

(name: value pairs) segregated (“delimited”) by semi-colons. Tr. 248-49, 312-13; compare Tr.

737-38. The “name” is metadata used to characterize the user’s data. The data itself is the

“value.” Tr. 91-92, 104, 250. Process.pl saved the user information to the Illustra relational

database. Tr. 79. Data sharing, or the pre-populating of college applications with information

previously received from the same user, occurred in AW 1 whenever the attribute name used to

describe an applicant’s information was the same between applications. Tr. 87-89.

10. Data sharing was an operable, tested, and publicly-available service under AW 1.

Tr. 93. CollegeNET advertised the service widely both to attract students to its website and to

market to colleges. DTX 2012-2015; 2019 (CNA 79030); DTX 2022, 2023, 2002; 2028. A

comparison of two applications used by CollegeNET to promote its college application service

(e.g., DTX 2023), Mercer and Virginia Tech universities, illustrates the extent of data sharing

between customized forms that would be implemented by AW 1. DTX 2031 (Mercer), 2033

(VA Tech), 2034 (comparison showing shared fields), DTX 3127 (comparison showing degree

of customization differences). Tr. 244-46.

11. Account/password information, user data, institution data, and application

information was stored in tables in a relational database. Tr. 78-79. After mid-1996, AW 1 used

a commercial database system named Illustra. Id. Account and password information was kept

in the account table, accessible by the user’s ID. The User Data table was also accessible by the

user’s ID. A Log table, again accessible by the user’s ID, recorded the states of the user’s

application, including whether the application was in process, complete or transmitted to the

school. DTX 2035, p. 6; Tr. 102-03. The Institution table stored institution “keys” (list of field

information that an institution wanted for a particular application) and other information. Tr.

253. Data from the Log table was retrieved to enable a user to view the state of his or her

application and to control system processes. Tr. 99, 104; DTX 2072, pp. 2-3.

12. The back-end transfer of user data to the college did not use the app.pl or ques.pl

programs, or the .in files. DTX 2072, p. 3; Tr. 99-101. In the AW 1 system, the following steps






PDX/117132/154237/DWA/2742335.7

were performed to deliver data to an institution: 1) determine the application(s) to be sent; 2)

determine what specific data each institution required; 3) prepare an e-mail to send the

information; 4) retrieve the user’s data and match the institution-required fields against the

applicant data, selecting (pruning) only the field values required by the institution; 5) put the

pruned name:value pairs into the e-mail and send it. DTX 2072, p. 3.

13. When an application was submitted and payment made, an entry was written by

the AW 1 system to a special queue directory. DTX 2072, p. 2. A software program, named

Sendbot, ran periodically to retrieve and process queued applications. Tr. 101. Sendbot

processed the user’s data and information about the application, as follows:

a. Sendbot first retrieved the institution’s “keys” data from the Institution table in

the Illustra database. The keys file (e.g., DTX 2074-B: cmds. keys) lists the specific fields that

the institution asked to receive, together with additional fields to identify the e-mail address and

application fee. Tr. 253-54.

b. Sendbot also invoked cndb.pl database routines to retrieve the corresponding

user’s data file (the BLOB) from the Illustra database. The cndb.pl routines restructure the user

data into an index table or associative array of name:value pairs. Tr. 312-13, 738.

c. In order to prepare the e-mail, Sendbot searches the index table (also referred to

as an associative array) of user data, one key field at a time, using the attribute name of each

field specified in the “keys” file to locate the corresponding field name and data value from the

index table of the user’s data. DTX 2072, p. 3; Tr. 253-54; Tr. 737-38. Once located, each

name:value pair was included in the e-mail, preserving the selection and order specified by the

institution-specific keys file. Id. If the user’s data contained data fields that were not requested

by an institution, those fields would be omitted, aka “pruned.” DTX 2072, p. 3.

14. Every institution application had a “keys” file. Tr. 739. The “keys” file was

created separately from the “front-end” application forms generating programs (app.pl and

ques.pl). Tr. 113-16. An institution’s keys file was created by two programs, keygen.pl and






PDX/117132/154237/DWA/2742335.7

key_update.pl. DTX 2074-E, 2074-F. Both programs were first written by Jon Batcheller. Id.

The creation of every keys file required the institution to select whether the information would

be sent encrypted, with fields for which no information was submitted, and/or with an overriding

SIS (student information system) formatted order and selection of fields. 2074-E, lines 13-21,

257-58, 272-76; Tr. 254.

15. The SIS format option arose from a contract signed by Mr. Wolfston in 1995

between CollegeNET and CMDS, a seller of SIS systems. PTX 3048; Tr. 81-82. CollegeNET

developed and implemented a system for delivering data to CMDS and/or CMDS-affiliated

colleges having a different fields selection and ordering—a different format. Tr. 103-04, 129-30.

The AW 1 software, when creating a keys file, was programmed to look first for the SIS option.

2074-E, lines 257-58; Tr. 253-56. If the option was selected, the keys file is created by first

invoking the SIS user data fields specification and, only after that was selected, adding user data

fields from the .in file. Tr. 103-07; 114-16. The resulting keys file included additional fields for

transmittal to the SIS vendor, and the user data fields were in an order different from the

college’s application data file (the .in file). Tr. 105-07, 255-56.

16. Sendbot’s steps prove that the AW 1 system processed the user’s data to send it

to the college and did not simply send a “flat text file” of the user data. Compare Wolfston

Decl., DTX 2094, ¶ 12. That the keys_update program implements choices (encryption, pruned

empty fields, and SIS option) to create a keys file proves that the AW 1 system provided format

options specified by the institution for every college application. See infra ¶ 48. The SIS option

proves that the AW 1 system included the capability to order user data as may be specified by the

SIS vendor or any other third party, whether a college or another. Tr. 105 (Batcheller) (“We

could modify the order and we could modify the fields.”)

17. CollegeNET maintained the keygen.pl and key_update.pl software programs

(and, in early 1997, updated each to accommodate multi-page capability), and thereby confirmed

both the continuing availability of this option and the patent applicants’ knowledge of the






PDX/117132/154237/DWA/2742335.7

capability. Mr. Hitchcock was involved directly in updating the principal programs that

implement this SIS formatting option and adding multi-page capability to the cndsapp.pl

program. DTX 2074-X, lines 18-21, 37; DTX 2074-Y, lines 213-16, 228-31, 293-95, 549-56.

18. Mr. Batcheller conceived of most, if not all, of the AW 1 architecture described

above, including all of the front-end processes. DTX 2072, 3001, 2035, 2076; Tr. 75, 89, 95-98,

117-22. Mr. Batcheller wrote the original programs for process.pl, app.pl, cndb.pl, sendbot,

ackbot, keygen.pl and key_update.pl. Id. His work is set forth in CollegeNET’s records (DTX

2072, 2076, 2035, 2077) and the source code that he wrote or supervised (including DTX 2011,

2047, 2182, and 2186). Mr. Hitchcock, testified that Mr. Batcheller was “the architect” of AW 1

(Tr. 146) and that CollegeNET retained the functionality of the front-end architecture of AW 1 in

“ApplyWeb 2” (Tr. 446).

B. The Sallie Mae Smart Loan™ Contract

19. The November 22, 1996 Smart Loan™ contract (DTX 2149) details that

CollegeNET will: create a customized form replicating Sallie Mae’s paper Smart Loan™

application; present the form over the Internet; collect user information; verify the user’s data

against required fields and their content as specified by Sallie Mae, when the application is

submitted; receive and store the user’s data; track one or more states of the application; and

provide the user data in a format specified by Sallie Mae. Tr. 171-172. It recites that it will be

implemented with “ApplyWeb technology” and includes specific licensing provisions for

“ApplyWeb technology.” DTX 2149, ¶¶ 1.2, 9, 10.4, 11.2; Tr. 168-70.

20. The only difference between the requirements of the Smart Loan™ service and

‘042 patent claim 1 is a reference in the preamble of claim 1 to more than one college and thus

providing more than one customized form. Compare DTX 2149 to DTX 2098, at 35:2-45. The

subject matter of the Sallie Mae contract is thus highly material to any consideration of the

claims of at least the ‘042 patent and is more material than any of the prior art patent references






PDX/117132/154237/DWA/2742335.7

considered by the Examiner during prosecution of the ‘278 and ‘042 patents. Tr. 171-72; DTX

2087.

21. The Smart Loan™ contract would be important to a reasonable examiner for three

additional reasons. First, it teaches expressly one or more of the specific verification steps

claimed as novel elements by the patent applicants in ‘042 patent claims 6, 8, 10-14, 20-26 and

28-30 and ‘278 patent claims 3, 4, 19, and 28. DTX 2149, Exh. A, p. 2, Attachment 6; Tr. 173-

75; see Tr. 359-60. Second, it states that CollegeNET will provide the user data to Sallie Mae in

a format specified by Sallie Mae that is different from the order of the fields listed in the Smart

Loan™ application, using fixed-length fields and a flat (not structured) text file. DTX 2149,

Exh. A, p. 2, Exh. B, ¶ 7, Attachment 8; Tr. 176-79. Third, the Smart Loan™ service was

implemented as a multi-page form. Tr. 194, 179, 606. Each of these contract specifications

contradicts arguments that CollegeNET made for patentability of all of the ‘042 patent claims,

original and new, during the ‘042 Re-examination. DTX 2093, pp. 4-7; DTX 2133, pp. 17-18.

22. The Smart Loan™ contract and service is prior art under 35 USC 102(b) with

respect to each of the verification, data uploading, and multi-page functions. Tr. 167, 180-81,

185-88, 192-96.

23. The Smart Loan™ contract’s verification steps include: checking for required

fields (DTX 2149, Exh. A, Attachment 6; Tr. 173), and checking to ensure the response meets

criteria specified by Sallie Mae. Tr. 173, 171-174. The verification was implemented with

JavaScript, which in early 1997 was a known method for data checking Internet forms. Tr. 188,

315, 597-98. For this reason, verification was ready for patenting when the Smart Loan™

contract was signed in January 1997. Tr. 180. JavaScript verification is performed at the client

computer. Id.; DTX 2158.

24. Verification in the Smart Loan™ service was reduced to practice prior to the

Critical Date. Tr. 182; 604-06. CollegeNET’s implementing schedule (DTX 2154) calls for the

system to be “online” at the end of May, 1997 (Tr. 185-87), and Mr. Ratliff could not identify in






PDX/117132/154237/DWA/2742335.7

any respect that this logical order was not followed. Tr. 603. The system was online July 3. Tr.

197. Adjusting the schedule for this delay, which is consistent with all of CollegeNET’s

documentation and Mr. Ratliff’s deposition testimony (Tr. 188-96), the scheduled step of testing

the system architecture for its intended purpose—reduction to practice—would have occurred in

or about late April 1997, when “testing on browser/platforms” and “Sallie Mae/UAI test of

information transfer” were scheduled. Tr. 182; DTX 2154. “Testing on browsers and platforms”

and the JavaScript verification programming were admittedly done by May 1997. Tr. 604-06.

CollegeNET did not preserve the only Smart Loan™ software. Tr. 606-07. All that remains is a

series of screen pages with operable supporting code implementing the related verification

conditions; the screens are programmed to display a “page last updated” date of April 29, 1997.

DTX 3066-A through 3066-L; Tr. 191-93; compare Tr. 148 (Hitchcock) (“Date last modified”

means the file code existed as of that date). Mr. Ratliff kept no record of any code changes he

may have made after April 29, 1997. Tr. 607.

25. Multi-page capability was reduced to practice, identified to the Smart Loan™

service, and demonstrated to Sallie Mae before the Critical Date. DTX 3066-C, 2159; Tr. 604-

06. The code that implements verification also implements multi-page capability and is

operable. PTX 3066-B; Tr. 189. CollegeNET’s records show CollegeNET finalizing the details

of the screen pages in May 1997 (DTX 2159) and Sallie Mae reviewing an online system by the

Critical Date. DTX 2164. CollegeNET’s documentation shows that it is in the last scheduled

phases—“final cleanup and testing” and “Sallie Mae ongoing review” —by the Critical Date.

DTX 2154; Tr. 194-96; compare Tr. 598-99, 607.

26. These conclusions are supported by CollegeNET’s objective behavior. Tr. 231-

33. By March 1997, CollegeNET was advertising to prospective college customers the Smart

Loan™ service as an embodiment of its college application service. DTX 2022, 2023. “Sallie

Mae–We provide the same application technology for their smart loan [sic, Smart Loan™].” Id.,

p. 1. In May 1997, Mr. Wolfston prepared a marketing solicitation intended for Stanford






PDX/117132/154237/DWA/2742335.7

University. DTX 2158. The solicitation extols the characteristics of Smart Loan™ verification,

which are described as already developed (“[Sallie Mae’s] form has the ability via Javascript. . .

.) (emphasis added). Id. A July 14, 1997 email to Stanford references the subject matter of DTX

2158 and Stanford’s prior response to a prior offer of the Smart Loan™ verification function for

college applications. DTX 2237, pp. 5-6; Tr. 475-78. These contemporaneous records are

consistent only with the conclusion that the Smart Loan™ verification and related multi-page

functions were reduced to practice in the same code in or about April 1997 (Tr. 233-35), and that

the relevance of the Smart Loan™ service to CollegeNET’s college application services was

readily apparent to CollegeNET and its customers.

27. The Smart Loan™ contract provides that CollegeNET will send the applicant

information to Sallie Mae in a format (flat text file, fixed length, with field information in an

order distinct form that of the application form) specified by Sallie Mae. DTX 2149, ¶ 3 (“Loan

Application Processing”), Exh. B, ¶ 7, Attachment 8; Tr. 176-78; 362-63.

28. CollegeNET has not presented any evidence other than DTX 2153 and 2155

concerning its implementation of user data delivery to Sallie Mae. Tr. 183-85. DTX 2153 and

2155 are correspondence in January and early February 1997 whereby CollegeNET, with Mr.

Wolfston’s participation, offers Sallie Mae alternative methods for transmitting user data in the

format that Sallie Mae has specified in DTX 2149, Attachment 8. Sallie Mae selects one of the

alternatives. DTX 2155; Tr. 181-83. CollegeNET’s implementation schedule, DTX 2154, calls

for the data transfer functions to be tested to confirm that the service will perform its intended

functions by March 1997. DTX 2154 (see “Sallie Mae/UAI test information transfer”). Expert

testimony that the implementation of such a data transfer from the Illustra database would be a

routine function for a web programmer of ordinary skill in the art (Tr. 180-81) is consistent with

CollegeNET’s records. Information transfer in the format specified by Sallie Mae was ready for

patenting when the contract was signed and was reduced to practice by late April 1997 and

certainly before the Critical Date. Id.






PDX/117132/154237/DWA/2742335.7

C. The Patent Applicants and the ‘278 and ‘042 Prosecution Histories

29. James Wolfston is a named inventor and the CEO of CollegeNET. He controlled

the prosecution of the ‘278 and ‘042 patents for all named inventors. DTX 2080. The ‘278

patent was filed as a provisional application on June 4, 1998. A formal application was filed

June 3, 1999. The patent applicants filed an Information Disclosure Statement on October 21,

1999, but did not disclose either the AW 1 or Smart Loan™ systems. DTX 2080, pp.

CNA109821-23.

30. Of the references cited by the patent applicants, the Examiner found the Scharmer

patent (DTX 2090) most pertinent. DTX 2087, pp. 3-6. The patent applicants argued that

Scharmer did not disclose any of the following functions: storing user information in a database,

data sharing to pre-populate a second form, modifying the application form without re-

programming the forms engine, presenting customized forms for multiple institutions, data

validation or verification of any kind, branding the form, multiple-page forms, transmitting user

data to more than one institution, selecting (i.e., pruning) the data sent, administration by a third-

party forms servicer (i.e., CollegeNET), or using metadata to characterize the applicant data

when stored. DTX 2093, pp. 4-7. As described herein, AW 1 and the Smart Loan™ systems

disclose every one of these functions and would be more important than the references supplied

by the applicants to a reasonable examiner evaluating the ‘278 and ‘042 patent application.

31. The patent applicants and CollegeNET never disclosed the Smart Loan™ contract

or service. DTX 2080; 7/08/08 Supp. Agreed Facts, ¶ 19. The patent applicants filed an

Information Disclosure Statement in February 2001 (DTX2086) in which AW 1 was mentioned

for the first time. The disclosure suggests that the AW 1 system was made public only for the

purpose of testing in its intended environment, not for commercial use. DTX 2086, p. 2; Tr. 337-

39 (Nusbaum). The February 2, 2001 IDS was “not considered” by the Examiner because it was

not filed in the proper form. DTX 2087, p. 2.






PDX/117132/154237/DWA/2742335.7

32. In response to a June 12, 2001 Office Action (DTX 2087), the patent applicants

submitted amendments, arguments, and the Declaration of James Wolfston. DTX 2092, 2094.

The Wolfston Declaration recites that it was made to disclose the AW 1 system as it existed prior

to the Critical Date “even if it appears that [it] may have been experimental, not involve the

specifically claimed invention, or not encompass a completed invention.” DTX 2094, p. 1.

D. The Wolfston Declaration

1. Hard-coded application forms.

33. Wolfston represented to the Patent Office:

10. [In AW 1,] [e]ach college admission application was “hard-coded” and any changes to an application form required re-writing the program that generated the form. Although the software for the application for each school was written separately, the programs used common modules, such as boxes specifying extra curricular activities. These common modules needed to be identical from form to form for compatibility. DTX 2074.

34. A reasonable examiner, as a person of ordinary skill in the art, would understand

this statement literally: all of the information needed to generate the application form was coded

in the forms engine, the program that generated the form. Tr. 198-201. This is consistent with

the dictionary meaning of “hard-coded.” DTX 2209, 2210. Only with this understanding would

every change (i.e., “any change”) require re-programming the forms engine. Only in this

circumstance would it be true that the software for every aspect of every form was required to be

“written separately.” Tr. 198-200. As represented by Wolfston, AW 1 would not anticipate the

features described (DTX 2079, at 7:51-61, 10:42-64; Tr. 360-62) and claimed in the ‘278 patent,

claim 2. In fact, the college application forms were not hard-coded to the forms engine in the

AW 1 system. Tr. 79, 86-87, 142, 201-02, 360-61. The system described in these citations from

the patent is the AW 1 system.

35. Mr. Wolfston’s assertion that by paragraph 10 of his Declaration, he was

describing the AW 1 architecture simply is not credible. In AW 1, college application forms

were created by a forms engine that read instructions in the form of pound directives from a data

application file (the “.in files”) and rendered HTML code based on those instructions. The






PDX/117132/154237/DWA/2742335.7

HTML code was then delivered to and displayed by the user’s browser. See supra ¶¶ 6,8; Tr.

596. The .in file is not a software program but is a text or data file. Tr. 201-02, 596; DTX 2031,

2033. Because the instructions for creating the form are contained in the .in file, no modification

to appl.pl or to ques.pl is necessary to add or delete an existing common field, to add any school-

specific field, or to change the text of questions. Tr. 86-87, 134-35, 142, 229; see supra ¶ 6.

Modification to the forms engine (app.pl or ques.pl) is only required to add common form fields

that have never previously been used in the system. Id.; DTX 2072. This is the system structure

described as the preferred embodiment of the patent. DTX 2079, at 7:51-61, 8:56-59, 10:42-64;

Tr. 202-03.

36. CollegeNET’s revision control histories for the ques.pl and app.pl, software

programs and the .in data files prior to the Critical Date (DTX 2047, 3159) reveal that 479

changes were made to individual college applications which necessitated fewer than 80 changes

to the forms engine to accommodate school-specific changes. Tr. 229-31. Necessarily, changes

could be made to application forms without re-programming the forms engine.

37. AW 1 also had the capability, implemented for at least select fields, to accept

“arguments” from the application data file (.in file) to override default parameters coded on the

forms engine setting field length, field name, and the number of displayed characters, as

described in the ‘278 patent at 7:51-61 and 10:42-64. Tr. 136-37, 204-08, 220-22, 224-26. Mr.

Hitchcock’s April 17, 1997 architecture document detailing the “ApplyWeb 1.0” system

acknowledges this capability. DTX 2074-T, p. 2. While this capability was not implemented for

every common field by the Critical Date, the capability was reduced to practice and used

publicly prior to the Critical Date with more than one common field. DTX 2037, lines 3021-

3030, 2888-2913, 2263-2267, and 1033-1036; Tr. 142, 224-26. Mr. Wolfston did not disclose

any of this information to the Patent Office, and his affirmative representation is false. Tr. 232.

2. Customized application forms.

38. Mr. Wolfston represented to the Patent Office:






PDX/117132/154237/DWA/2742335.7

6. The ApplyWeb 1 program, though functional, was found to be too inflexible to provide the customized application format and customized data processing uploads required by the participating institutions. We developed the present invention to overcome the limitations of ApplyWeb 1. DTX 2094.

39. “Customized,” with respect to the format and content of application forms, refers

to differences between college applications in (1) the content of requested information, (2) the

order and selection of the fields, and/or (3) branding with the name and/or logo of the institution.

DTX 2079, ‘278 patent, 6:5-9; 7:61-63; (claim 1) 22:34-39; (claim 5) 23:36-39.

40. As of the Critical Date, the AW 1 forms engine supported more than 400 field

options, had the capability to add tailored school-specific fields as required, and had the

capability to incorporate specific questions as requested. See supra ¶¶ 8,10; Tr. 237-39. AW 1

individually branded applications and inserted the logo of the institution into the generated

application form, if requested. Id. Customization was commercially significant and that is how

CollegeNET presented AW 1 to the public. Tr. 240-42:

“[CollegeNET application forms] . . . are fully tailored to the individual specifications of each college client. . . . Each CollegeNET application is fully tailored and branded for the client institution.” DTX 2018, at CNA71250;

“CollegeNET applications are true facsimiles of the forms you now use. When we say we will bring up your application, we will bring up YOUR application, not another ‘standard’ form that might compromise the information you are seeking from your applicants.” DTX 2019, at CNA79029 (emphasis original);

“The electronic application looks as similar to your paper application as possible within the confines of HTML, the Web ‘markup language.’” DTX 2077; see also DTX 2004, DTX 2013.

41. CollegeNET and Wolfston assert that the statement in ¶ 6 of the Wolfston

Declaration refers to an alleged dependency between the ability to customize forms and the

ability to share data or send applicant data to institutions. But there is no such dependency that

could make truthful the clear statement that AW 1 was “too inflexible to provide the customized

application format” that customers required. The forms-engine software programs that create the

HTML code—app.pl and ques.pl—in cooperation with application data files are different from






PDX/117132/154237/DWA/2742335.7

the software programs process.pl, sendbot, cndb.pl, and the keys file used to process and transmit

user data to institutions. See supra ¶¶ 6-7. There is no dependency between customization and

sending applicant data to institutions. Data sharing as claimed in the ‘278 patent, claim 1 (“some

of” the fields) was significant even when the application forms had very different layout and

content, as exemplified by a comparison of the Mercer and Virginia Tech forms used to market

the AW 1 service. See supra ¶ 10.

42. Mr. Wolfston’s representation did not colorably disclose the true customization

capabilities of AW 1 and was false and misleading.

3. Data Sharing.


5. The ApplyWeb 1 program theoretically had the ability to share data between applications to different institutions. Only a relatively small number of applications were processed using ApplyWeb 1, and to the best of my knowledge no student used ApplyWeb 1 to complete more than a single application and no data sharing actually took place. DTX 2094.

44. What Mr. Wolfston did not tell the Patent Office is more telling. AW 1 had data

sharing capability that was in public use, tested, and operable from July 1996. Tr. 85, 87-89, 93,

121, 237-38; 225, 245, 246, 444-445; DTX 2034. Mr. Wolfston personally confirmed its use by

applying as a student would. DTX 2234, pp. 39-40. User data in AW 1 is tagged with a unique

attribute name, itself metadata, that characterized the applicant’s data for purposes of storage,

retrieval, and processing. DTX 2072, p. 1-2; Tr. 91-92, 253. Data sharing occurred when the

attribute names for any two fields in different applications were the same. Tr. 85-87. Separation

of the “.in” application data file from the “app.pl” forms engine, a key feature of the AW1

architecture, facilitated data sharing. DTX 2072, p. 2; Tr. 202-03.

45. CollegeNET touted AW 1’s “automatic” data sharing capability to the public:

“Even though each ApplyWeb form is tailored faithfully to the format of the school’s paper form . . ., common data from any of these forms is automatically shared across the others saving the student redundant typing.” DTX 2012. Similar statements appear in DTX 2013, 2014, and 2015.






PDX/117132/154237/DWA/2742335.7

“Most students apply to more than one campus; putting your application on CollegeNET shows them that you are conscientiously attempting to make the overall job of applying much easier. . . . [O]ur precise data mapping permits automatictransfer of common information from one application to another.” DTX 2019, at CNA79030. Similar statements appear in DTX 2002, 2023, and 2028.

46. The patent applicants did not tell the Patent Office that the data sharing capability

was made public, tested on the public system (Tr. 92-93), and widely advertised to encourage

students to use the CollegeNET website. The applicants instead characterized the capability as

“theoretical,” implying that the capability was only conceptual and not proven. Tr. 354-55. Mr.

Wolfston’s statement is false and misleading, concealing the true character of AW 1’s data

sharing and related capabilities.

4. Processing user data and customized data formats.


12. ApplyWeb 1 could not process the applicant information to put it into a form specified by the college. The flat text file of applicant data was sent via electronic mail to the institution to which the application was addressed.

* * *

6. The ApplyWeb 1 program, though functional, was found to be too inflexible to provide the . . . customized data processing uploads required by the participating institutions. We developed the present invention to overcome the limitations of ApplyWeb 1. DTX 2094.

48. Wolfston misrepresented and concealed the capabilities of the AW 1 and the

Smart Loan™ services. An alleged novel feature of both patents, and particularly the ‘042

patent, is processing the user data to provide it to the institution in a “format” specified by the

institution. DTX 2098 at 35:33-38; DTX 2136, pp. 16-17. The patent specifications describe

this claim element broadly, covering any choice made by the institution/customer from two or

more formats offered by the forms servicer. DTX 2079, ‘278 patent, 8:21-31 (“Data may be

transmitted to the institution, for example, as name-value pairs, as fixed records, in EDI, or

printable PDF format”).






PDX/117132/154237/DWA/2742335.7

“The data formats may include 1) comma separated values; 2) tab delimited values; 3) fixed length format; 4) name/value pairs, and 5) EDI 189. For all of these methods, of course, the data is ordered as required (e.g., Social Security number first, last name second, high school name 33rd, etc.). ‘278 patent, 21:1-10.

In the Reexamination of the ‘042 patent, CollegeNET and Mr. Wolfston sought (DTX 2130, pp.

17-18) and obtained (DTX 2133, pp. 43-45) additional claims 50 and 51, specifying that a choice

between any two formats that may differ only in whether a semicolon, comma, or a tab is used to

separate user information, or the order that data is transmitted, or whether the field is a fixed or a

variable length, is sufficient to make the information available “in a format specified by the

institution.” DTX 2136, pp. 17-18.

49. The AW 1 system processed the user’s data prior to sending it to the institution.

Tr. 247-249; Tr. 737-739; see supra ¶¶ 12-16. The AW 1 service did not send the “flat text file

of applicant data” to the institution. “Flat text file” storage was only used by CollegeNET in an

early prototype. Tr. 92. In mid-1996, storage was replaced by the structured BLOB, “a database

concept.” Tr. 248-24; Tr. 278-279. The earliest AW 1 commercial systems processed (Tr. 254,

313) and “pruned” (DTX 2072, 2076; Tr. 251) the applicant’s data record to select only those

fields requested by the college. DTX 2072, 2076; Tr. 251; Tr. 247. In every case, the institution

made formatting selections when setting up the keys file, and the SIS option proved the

capability and offer of alternative ordering of fields—precisely the scope of new claim 51. See

supra ¶¶ 14-15; Tr. 301. Wolfston and CollegeNET simply denied this processing and

formatting capability that had been in public use or sold long before the Critical Date. Tr. 249-

250, 253-256.

50. The Smart Loan™ service exemplifies the very limitation asserted to be novel:

providing the user information to the institution in a format that is specified by the institution.

Attachment 8 of the Smart Loan™ contract provides both fields ordering different from the

corresponding application form, as well as a fixed-length, comma delimited text structure. See






PDX/117132/154237/DWA/2742335.7

supra ¶¶ 27-28. Both of these requirements correspond directly to the new independent claims

50 and 51 that CollegeNET secured during reexamination. Id.

51. Nor did Wolfston or CollegeNET disclose that CollegeNET in 1995 contracted

and commenced steps to deliver user data in the EDI format to Carnegie Mellon University.

DTX 2007, 2008; Tr. 262-263, 301. This undisputed contract of sale was never disclosed to the

Patent Office, even though the EDI format also constitutes an alternate format for purposes of

evaluating the claimed inventions.

52. Against the background of the patent applicants’ duty to disclose the material

information about which they were aware to the Patent Office, Wolfston’s Declaration is false

and misleading with respect to the ability of the prior art CollegeNET systems to process user

data and to provide it to the institution in a format specified by the institution.

5. The “state” of an application.


11. ApplyWeb 1 did not maintain a “state” for an application and could not, therefore, determine whether an application was in process, complete, or transmitted to the school. DTX 2094 (emphasis supplied).

54. This statement is false. Both the front end and the back end of the AW 1 system

maintained records of the transaction operations performed by the system with respect to a user

and a user’s application. DTX 2072; Tr. 99-104, 138-140. “State” was maintained to allow the

student to be notified of the status of an application and enable system programs, like Sendbot, to

take appropriate actions. Id. AW 1 received, stored in a database table (the Log table), and

displayed data inputs representing at least the following “states” of an application: in process

(begun but not complete); complete and saved; paid; sent to the institution; and acknowledged by

the institution. DTX 2035, p.6. Each of these “states” was automatically tracked by the AW I

system. Id. Mr. Batcheller’s system architecture record (DTX 2072) recites:

“A save operation results in the gathering of the users data from the form, a read of the users data from the database, a merge operation, appending on a DATE_SAVED; filed, and then a write to the database. A log entry is made representing the save. [P]rocess.pl also includes a status operation






PDX/117132/154237/DWA/2742335.7

that accesses the Log table for the users (sic, user’s) entries, and displays them.” DTX 2072, p.2.

“A save and send operation performs the save as outlined above, then performs a second operation which consists of creating an Order ID (OID) and then invoking the CyberCash routines. The CC routines, if successful, will create a copy of the user[’]s data in a file for use by the sendbot and then create a Log ‘sent’ entry showing the OID. In addition, a new data field is appended to the data which is DATE_SENT.” Id.

55. While the “acknowledgement” state was triggered by an e-mail from the college

acknowledging receipt of an application, this “acknowledgement” was automatically logged by

the AW 1 system. No claims of either the ‘278 patent or the ‘042 patent require the forms

processing system to automatically record state or to do any specific function because of a

particular state. The AW 1 states are described in CollegeNET’s documentation of the system,

including DTX 2035 (pp. 1, 6), 2072 (pp. 1-3), 2073, 2076, 2184; see also DTX 2197; Tr. 99-

104 (discussing DTX 2072 and 2035); Tr. 252 (confirming that the AW 1 code implements

processing architecture described in DTX 2072); Tr. 499-501, 487. Similarly, the Sallie Mae

contract required that the Smart Loan system be capable of maintaining the state of the

applications to allow users to resume partly completed applications and to be notified of Sallie

Mae’s receipt of the application. Tr. 170-171; DTX 2149, Exh. A.

56. CollegeNET and Wolfston marketed the acknowledgement and status features of

AW 1 to students, colleges, and potential customers throughout the year prior to the Critical

Date. DTX 2018 at CNA71259-60; 2019 at CNA79030; 2015. The patent applicants described

these features of AW 1 as an aspect of their invention in the specification of the ‘278 and ‘042

patents. DTX 2079, ‘278 patent, 13:64-66 14:26, 32-37; DTX 2098, ‘042 patent, 13:66-14:1

14:28, 35-40.

57. Mr. Wolfston’s statement is clear and unequivocal. By the examples Wolfston

selected, a person of ordinary skill in the art would understand “state” as any of the operations

performed during the processing of an application from the first “save” to acknowledgement by

the college. This is a direct reference to the “transaction operations” referenced in the patent






PDX/117132/154237/DWA/2742335.7

specification description of the preferred embodiment of the invention: “The application state

can be, for example, ‘in progress,’ ‘submitted,’ ‘payment received,’ and ‘acknowledged by the

institution,’ etc.” DTX 2079, ‘278 patent, 13:64-66, 20:8-45. Mr. Wolfston’s denial of the

CollegeNET prior art systems’ capability to track and report the state of an application is false

and misleading.

6. Storing of User Data.


8. After receipt at the server, the applicant data information was stored in a flat text file. In the ApplyWeb 1 program, no applicant data was stored in a relational database. DTX 2094.

59. Wolfston misrepresented and failed to reasonably disclose the capabilities of the

AW 1 system with respect to its ability to store and process applicant data information. A flat

text file without more contains no internal structure. Tr. 248-249. Without specialized software,

the flat text file elements cannot be searched, sorted, retrieved and processed. Id.; Tr. 736-37.

That capability is this Court’s definition of a database. DTX 2096, p.3. But AW 1 processed

applicant data, assigning name attributes (e.g., PERSON_NAME_LAST(1)”), a form of

metadata, Tr. 91-92, 250, to characterize the data and using software routines to place the user

data in a structured BLOB (Tr. 312-13, 736-39) that was stored in the Illustra relational database.

DTX 2072, 2076; Tr. 78-79, 92; Tr. 252-253. The AW 1 system provided extensive processing

functionality that is denied by Wolfston’s incomplete statements that describe only a very

“primitive” system. See supra ¶¶ 12-16; Tr. 249-50.

60. Applicant data information was stored in a number of tables in the Illustra

database. DTX 2072; Tr. 78-79, 252; see supra ¶¶ 11. The User_Data, Account/Password, and

Log tables were all keyed to and accessible by the unique user ID. Id. The records in the various

tables were related or linked by that common key. DTX 2072; Tr. 86-87. This structure of

tables meets this Court’s definition of a relational database, “a database that is organized in a

manner that can link tables or records together as required.” DTX 2096, p. 3.






PDX/117132/154237/DWA/2742335.7

61. Information about the actual capabilities and storage structure of AW 1 would

have been important to a reasonable examiner. Tr. 356. The AW 1 system contained multiple

fields, stored new user data without changing prior applications, and used a commercial

relational database product. See supra ¶¶ 9-10. The applicants made arguments for patentability

contending that the prior art did not disclose storing new applicant data without “having to

reprogram existing forms.” DTX 2093, p. 4. Mr. Wolfston’s description of the AW 1 storage

capability does not accurately describe the AW 1 storage capability and is false and misleading.

Tr. 356.

7. Multiple page forms.


7. In using the ApplyWeb 1 program, a student requested a college application over the Internet form a server. A single page application form was delivered to the student. The ApplyWeb 1 program was not capable of creating and processing multi-page forms. DTX 2094.

63. Paragraph 7 of the Wolfston Declaration is false. CollegeNET’s prior art systems

created and processed multiple-page forms. Mr. Hitchcock testified in deposition and again in

trial in the ApplyYourself lawsuit in 2003 that the AW 1 system had multi-page capability prior

to the Critical Date and as early as February 1997. DTX, 2218, 2219. His first task after

familiarizing himself with the AW 1 code (DTX 2078, 2182) was to work on implementing a

multi-page capability for AW 1. Tr. 146. By January 1997, Mr. Hitchcock was revising and

testing source code revisions needed to implement multi-page capability, both through the app.pl

software program and the “in. file” architecture of AW 1. DTX 2126 lines 97-113, 117-130, 141-

153; 7/9/08 Supp. Agreed Facts, ¶¶ 5, 6.

64. Beginning in March, 1997, CollegeNET was putting “online” multiple page

college application forms. That required support for multi-page capability from the app.pl

program in order to function as a multi-page application. DTX 2063-65; 2059-62, 2054-56,

2051-53; Tr. 153-158; compare DTX 2035, p. 6, detailing procedures for prior customer

approval of “online” forms and conditions to removing “demo” designation. Removal of a






PDX/117132/154237/DWA/2742335.7

“demo” designation cover each of these cases requires prior college approval of the form. DTX

2035, p. 6. Necessarily these multi-page forms were disclosed online to CollegeNET customers

who had already contracted for forms application services.

65. In April, 1997, Mr. Hitchcock authored a system architecture document reciting

that CollegeNET was then operating two app.pl programs, one for multi-page and one for single

page application forms. DTX 2074-T, p. 2. On May 20, 1997, Mr. Hitchcock merged the multi-

page version of app.pl (aw.test/RCS/mp_app.pl) with the single-page version

(aw.test/RCS/app.pl,v). These programs are the only viable candidates for the “production”

software supporting CollegeNET’s commercial system just prior to the Critical Date. Tr. 747-

49, 751-54; DTX 2141. Mr. Hitchcock’s May 20, 1997 comments to the source code revision

that implements the merger of these two programs recites: “Completely new app.pl!!!!!

corresponds to mh_app.pl v1.2, which combines single and multi-page apps, uses a different

ques.pl too mdh 5/20/97.” While Mr. Hitchcock vaguely asserted that these software programs

were on a file labeled “aw.test” so he could not confirm when the programs were used in

production, Tr. 431-434, CollegeNET has no record of any “production” code operative during

April and May of 1997 other than XAPSC04aw.test/RCS/app.pl,v and

XAPSC04/aw.test/RCS/mp_app.pl,v. See DTX 2070 (CollegeNET attorneys identifying best

evidence of pre-Critical Date code); DTX 2141. The only reasonable inference is that multi-page

capability was in public use and offered to institutions prior to the Critical Date.

66. The Sallie Mae Smart Loan™ service was sold, reduced to practice, and disclosed

to Sallie Mae, as a multi-page form, prior to the Critical Date. See supra ¶¶ 22, 25-26.

67. The information set out above in paragraphs 63-66 would have been material to a

reasonable examiner. Tr. 355. Mr. Wolfston’s Declaration denying this capability is false and

misleading.

8. Metadata and Data Checking (or Verification)







PDX/117132/154237/DWA/2742335.7

9. No metadata, that is, information about the data fields, was stored in ApplyWeb 1. Hence, ApplyWeb 1 was incapable of performing data checking.

69. AW 1 used metadata, that is, “information about the data fields” rather than the

data itself, in or before December 1996. Tr. 91-92. AW 1 used metadata in the “.in” files to

affect the formatting and labeling of the fields. Id. The metadata was used to map the

applicant’s data into the correct field in the application to allow data sharing, data retrieval and

data selection for transmittal to the college. Tr. 92, 250. Data was stored as name:value pairs in

AW 1. The names of the fields in the BLOB in which data was stored are metadata. Tr. 91-92,

250, 253.

70. While AW 1 had a limited capability to require that some data be entered in

certain “required” fields, (DTX 2214 at 1422-24; Tr. 175), the prior art Smart Loan™ contract

and service had precisely the sophisticated verification functions that the patent applicants

described as a novel feature in 18 of the ‘042 patent’s claims: verifying user data at the client

computer; verifying user data when the application is ready to be submitted; verifying user data

against criteria specified by the institution; and verifying data on each of multiple pages. See

DTX 2098, ‘042 patent, claims 5-6, 8-14, 20-26, 28-30; see supra ¶¶ 21, 23-24.

71. Wolfston now seeks to qualify his statement by linking or conditioning his denial

of “data checking” to the use of stored metadata. In other words, Wolfston argues that he

subjectively meant, “No data checking occurred through the use of metadata.” But that is not

what his statement says. Both sentences are presented as flat denials of the presence of

important capabilities in the prior art system(s). Not one of the foregoing 18 patent claims of the

‘042 patent where verification is claimed mentions the word “metadata,” let alone conditions

verification upon the use of metadata. Claims 18 and 20 of the ‘278 patent claim metadata

without regard to verification, including metadata to characterize user data values (claim 20), a

capability admittedly in the AW 1 system. Tr. 91-92, 443. That it was CollegeNET’s prior art

Smart Loan™ contract, not AW 1, that provided sophisticated verification does not make the






PDX/117132/154237/DWA/2742335.7

statement to the Patent Office truthful, in the context of the patent applicants’ duty to disclose all

material information. Such information regarding metadata would have been material to a

reasonable examiner. See Tr. 358.

E. The Failure to Disclose Jon Batcheller’s Role in the Conception and Reduction to Practice of the Claimed Inventions.

72. Jon Batcheller conceived of the architecture of the AW 1 system, including: the

use of application data files with a forms engine that would generate HTML code from the data

file instructions, enabling the system to modify and alter application forms without re-

programming the forms engine to provide improved customization; using metadata attribute

names to characterize stored user data and permit data sharing between applications; and

processing user data to select only those fields that were requested by the institution, and provide

them in the order requested. See supra ¶¶ 6, 18; Tr. 80-81, 86-91, 122, 140-141. His 1996

architecture records and software programs document his contribution and serve as the obvious

template for the ‘278 and ‘042 patent specifications. DTX 2072, 2076, 2077; Tr. 75, 77-79, 84-

85. The patent applicants sought to patent Mr. Batcheller’s AW 1 architecture (Tr. 202-203) not

the specific improvements they now claim may have been developed after Mr. Batcheller left

CollegeNET.

73. Mr. Batcheller was not named as an inventor of the ‘278 or ‘042 patents. His

name was never brought to the Patent Office’s attention during the prosecution of these patents,

and appears nowhere in the original prosecution file histories. See Tr. 650. CollegeNET offers

no plausible explanation for failing to disclose Batcheller’s contribution to the creation of the

system architecture that was later claimed in the ‘278 and ‘042 patents. Mr. Batcheller’s role in

the conception of one or more aspects of the claimed invention is material information that

would be important to a reasonable examiner in evaluating inventorship of the ‘278 and ‘042

patents. Tr. 370-72.






PDX/117132/154237/DWA/2742335.7

F. The Reexamination of the ‘042 patent

74. During reexamination of the ‘042 patent, the Patent Office rejected all of the

original claims of the ‘042 patent in an initial November 2006 Office Action and a June 2007

Final Office Action. DTX 2123, 2133. In response to the June 2007 Office Action, CollegeNET

and Mr. Wolfston argued a single point of novelty for each of the original patent claims:

“processing . . . the user information . . . to make the user information available to the institution

in a format specified by the institution.” DTX 2136, pp. 16-17; DTX 2098, ‘042 patent, claim 1.

75. In support of the original and new claims, CollegeNET and Wolfston gave a

PowerPoint presentation to the Examiners to describe the prior art relevant to patentability. DTX

2129; DTX 2127. In the presentation, Mr. Wolfston represented to the Examiners that the

following excerpt was representative of the prior art systems offered by Xap Corporation.

“The batch data formats for the online, WINDOWS™, Macintosh™, and DOS™ are identical…Mapping is the responsibility of each campus.” DTX 2127, p. 31.

The excerpt is taken from a contract between Xap and the Texas Guaranteed Student Loan Corp.

(GSLC). Mr. Wolfston testified by deposition that he told the Examiners:

I provided to the patent office the sworn testimony from the leader of Embark, from the leaders of Zap (see, Xap), and of course from myself in the declaration, that those systems that were out there prior to June 4th, 1997, entailed the delivery of a single format, a single vendor-defined format, and thus did not meet the limitation of providing data in a format specified by the institution as our patent memorializes it. DTX 2239, 138:14-139:04 (emphasis supplied).

76. Though in his possession, Mr. Wolfston did not provide the Examiners with a

complete copy of the Texas GLSC contract (DTX 2025) excepting what may have been included

in more than 17,000 pages of material that CollegeNET dumped into the Reexamination record.

Two pages before the page from which Mr. Wolfston took the above excerpt, the Texas GSLC

contract expressly recites that Xap offers at least two alternate electronic formats, including EDI

and at least one text file format, in addition to mapping (i.e., converting to another format) these

Xap formats to a customer specific format not otherwise included. Tr. 271-273.






PDX/117132/154237/DWA/2742335.7

77. The excerpt selected and edited by CollegeNET and Wolfston refers to the fact

that each of the Xap platforms—online, WINDOWS™, Macintosh™ and DOS™—will provide

the same format as may be selected by the institutions from the choices above, not to whether

Xap offers more than one format. Tr. 271-272, 274-275.

78. The pre-Critical Date Texas GSLC contract is similar to the prior art “CSU

Mentor” contract (DTX 2009) that was performed in November 1997. The CSU contract details

Xap’s delivery of a choice among multiple “formats” from which the colleges could choose.

Xap also offered “mapping” services that convert a Xap format into additional formats that may

be directly uploaded to more than six different SIS systems then in use at one or more CSU

campuses. Tr. 275-279. Once a format is selected and/or mapped, that format is provided

uniformly to the selecting institution whether the data comes from Xap’s online system or one of

the computer-supported operating systems (e.g., WINDOWS™ OR Macintosh™. DTX 2009,

pp. CSU000513, -554, -557, -559, -563, -590 through 592.

79. CollegeNET and Wolfston were well aware of the CSU contract terms. The

contract is public, and the full CSU proposal and contract with Xap was in evidence at the 2006

trial as a CollegeNET exhibit, PTX 1134. Dr. Tansey, a CSU officer, testified at the 2006 trial

about the CSU-Xap system. Wolfston and CollegeNET were present. Dr. Tansey confirmed

that Xap offered and delivered to the CSU institutions a choice among two or more formats for

the receipt of user information.

“One was the old fix[ed length] format record. . . . There were actually two versions of a delimited file that could be accepted, and then there was the TS 189. . . So if Sonoma chose a tab-delimited format and someone else chose a fix[ed length] record format and somebody else chose TS 189, that was no problem. When their files came down . . . they were already in the format that they expected to see . . . .” 2006 Trial Tr. 1346-47.

CollegeNET and Wolfston did not disclose Dr. Tansey’s testimony to the Patent Office

examiners, except by a general reference to the transcript of the jury trial contained in the 17,000

pages of documents dumped into the Reexamination record.






PDX/117132/154237/DWA/2742335.7

80. Similarly, CollegeNET and Wolfston misrepresented and failed to disclose the

2006 trial testimony of Young Shin. DTX 2127 at CN 120079-81. Wolfston represented that

Shin’s company, College-Edge, offered only one “format” prior to the Critical Date (DTX 2127,

pp. 28-30; 2239), when it is clear from Mr. Shin’s trial testimony, DTX 2226-27, that

CollegeEdge offered customers a choice of two or more electronic formats—precisely the scope

of new claim 51. Wolfston was present at trial for and had Shin’s complete testimony but did

not call to the attention of the Examiners those portions that defeated CollegeNET’s contentions.

81. At the interview with the Patent Office Examiner(s), Wolfston and CollegeNET

repeated their description of AW 1, as follows:

“ApplyWeb 1 could not process the applicant information to put it into a form specified by the college. The flat text file of applicant data was sent via electronic mail to the institution to which the application was addressed.” DTX 2127, p. 32.

82. Paragraph 12 of the Wolfston Declaration was false when first presented in 2001

and is false when presented in 2006, Tr. 280, for the same reasons stated in supra ¶¶ 16-22, 49-

51.

83. CollegeNET’s and Wolfston’s representations about the prior art CollegeNET

services of College Edge and Xap were false and misleading. See Tr. 368. The true state of the

prior art was highly material information that defeated the claims of patentability then made by

CollegeNET and would have barred all of the new patent claims sought in Reexamination.

II. Materiality

84. Each of the foregoing representations is false and concealed important

information about the AW 1 and Smart Loan™ prior art systems, information that would be

important to a reasonable examiner. Each misrepresentation and each concealed or undisclosed

information was directed to elements for which separate patentability was sought and/or to key

arguments for patentability that were proffered by the patent applicants. As such, each is of the

highest materiality and importance to a reasonable examiner. See also ¶¶ 16, 21, 30 34, 39, 41,

48, 61, 71, 73, 83.






PDX/117132/154237/DWA/2742335.7

III. Intent

85. Messrs. Wolfston and Hitchcock were the only named inventors who participated

in the patent prosecution. DTX 2080. Mr. Wolfston was fully knowledgeable of the AW 1

system. He participated in CollegeNET engineering meetings and received the architectural

reports from Mr. Batcheller and Mr. Hitchcock. Tr. 73-74; see supra ¶ 6. He was responsible for

all CollegeNET marketing literature and solicitations. He negotiated and signed the Smart

Loan™, Carnegie Mellon, CMDS, and other prior art contracts. See supra ¶¶ 6, 15, 26, 28; DTX

2149, 2007, 2008, 3048.

86. Mr. Hitchcock was intimately familiar with the capabilities of AW 1. He studied

Batcheller’s architecture, making detailed comments on the document. DTX 2078; 2182. He

upgraded and modified the key software programs that implemented the multi-page capability

throughout AW 1, including: app.pl, ques.pl, process.pl, cndb.pl. keygen.pl, and key_update.pl.

See supra ¶¶ 6, 65. While he acknowledged Mr. Batcheller as the architect of AW 1, Tr. 146, he

offered no reason for Mr. Batcheller’s omission from the patent applications.

87. Wolfston had a special motivation to mislead the Patent Office: to sue competitors

based on patents he hoped to obtain from applications that he had yet to file. DTX 2008, p. 3.

88. There is no evidence that Wolfston or Hitchcock, Tr. 163, reviewed any

documents before submitting their description of the technical capabilities of a system, then four

years past. The contrast between the architectural records and documents created by Batcheller

as well as by Hitchcock (DTX 2072, 2076, 2077, 2074T), on the one hand, and the

representations made to the Patent Office, on the other, is stark. None of the documented and

undisputed capabilities of AW 1 described above was disclosed to the Patent Office.

89. Wolfston and CollegeNET breached their duty of candor by failing to accurately

disclose the trial testimony of Dr. Tansey and Mr. Shin, and by the careful excerpting of

admittedly misleading1 snippets from a Xap Corporation contract proposal. CollegeNET failed

1 CollegeNET now argues that one of the 49 pages of materials left with the Patent Office contradicts the representation presented directly to the Examiners and evidences lack of intent to






PDX/117132/154237/DWA/2742335.7

to disclose obviously material information that was harmful to CollegeNET’s claims for

patentability only ten weeks after Dr. Tansey and Mr. Shin testified and a jury found invalid all

claims-in-suit of the ‘042 patent.

90. These facts confirm what is apparent from the scale of the misrepresentations in

this case and the very high materiality of the information withheld. Virtually every statement

made to the Patent Office was inaccurate, served to conceal an important prior art capability, or

was simply false and unsupportable. Considered collectively, the evidence that the patent

applicants intended to deceive the Examiners is clear and convincing.

IV. Balancing of Intent and Materiality

91. Neither Wolfston nor CollegeNET offer evidence of good faith, other than denials

of wrongdoing. The arguments made for the re-interpretation of the Wolfston Declaration make

clear that these are post hoc excuses, for if the re-interpretation were the original intent, the

Wolfston Declaration would never have been submitted using the clear, simple denials of Exhibit

2094. Good faith in that context requires full disclosure of the prior art systems and a clear

delineation of the scope of the improvement to which the later inventor may be entitled.

CollegeNET and Wolfston did none of this. Instead, they claimed the prior art system as their

invention, and that is not good faith.

V. Prosecution History Estoppel

92. During prosecution of the ‘278 patent, CollegeNET distinguished its database

structure from that of U.S. Patent No. 5,640,577 (“Scharmer”), which was the basis of an

obviousness rejection. Scharmer discloses a system that generates online computer forms,

accesses data stored in a database, and uses the data previously stored in the database to populate

fields of electronic forms. Scharmer, Claim 1, 8:19 – 9:6 (“and a plurality of databases, said

mislead. On the contrary; it shows actual knowledge that the snippet was false and a belief that the Patent Office would ignore the 49 pages.






PDX/117132/154237/DWA/2742335.7

plurality of databases including client data”); see also id. at 7:45-51; Tr., 282 (Frederiksen). The

‘278 patent examiner agreed. DTX 2087, pp. 3-4.

93. A person of ordinary skill in the art reading the objective record of the

amendments made to claim 21 of the ‘278 patent would have understood the importance of the

structural field and records limitations in distinguishing one database from another, and,

therefore, the amendments to be directly related to the patent applicants’ purpose in

distinguishing the ‘278 database structure from Scharmer’s database structure. Tr. 732-733

(Maier); DTX 2235 at 115:3-10, 117:15 – 118:2; Tr. 282-283, 284–285; Tr. 283–284 (the

amendments define the structure that achieves alleged utility of the invention) (Frederiksen).

There is no other objective reason to have added the records and fields limitations.

94. Xap’s accused database structure does not “add new records” with “each record

capable of storing information corresponding to each of the database fields.” DTX 2230, at

1600:11 – 1601:4, 1601:12 – 1603:13. That was the issue submitted to the jury. This different

“records” structure is necessarily directly related to the reason for the amendment. Tr., 285-286.

95. A person of ordinary skill in the art would conclude that the rationale for these

amendments is thus directly related to any alleged equivalent that does not have the fields and

records structure added by amendment to distinguish Scharmer from the claimed invention of the

‘278 patent. Tr. 282-84. Therefore, Xap’s accused database structure is directly related to the

reason for the amendments because Xap’s accused database structure does not store applicant

data by adding records capable of storing information corresponding to each of the database

fields.






PDX/117132/154237/DWA/2742335.7

Dated this 14th day of July, 2008.

Respectfully submitted,

Schwabe, Williamson & Wyatt, P.C.

By: s/ David W. AxelrodDavid W. Axelrod, OSB #750231Johnathan E. Mansfield, OSB #05539Yvonne E. Tingleaf, OSB #054463Telephone 503.222.9981Of Attorneys for Defendant, Xap Corporation


david w. axelrod, osb #750231 email daxelrod ... - magic · david w. axelrod, osb #750231 email...

Documents