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

Transcription

1 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 1 of 32 Page ID#: 6842 David W. Axelrod, OSB # daxelrod@schwabe.com Johnathan E. Mansfield, OSB # jmansfield@schwabe.com Yvonne E. Tingleaf, OSB # ytingleaf@schwabe.com Schwabe, Williamson & Wyatt, P.C. Fax Of Attorneys for Defendant, Xap Corporation IN THE UNITED STATES DISTRICT COURT FOR THE DISTRICT OF OREGON COLLEGENET, INC., No BR vs. Plaintiff, XAP CORPORATION S POST-TRIAL PROPOSED XAP CORPORATION, Defendant.

2 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 2 of 32 Page ID#: 6843 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 webbased, 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 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 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 Page 1

3 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 3 of 32 Page ID#: 6844 (app.pl, ques.pl, process.pl, and cndb.pl) in DTX Tr. 747, 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 publiclyavailable AW 1 service. Tr 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 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 ). 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, ; DTX 2076, 2078, 2182; Tr The <school>.in files are the strength of the ApplyWeb system. It permits applications to be built quickly, automatically and most important, Page 2

4 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 4 of 32 Page ID#: 6845 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 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 The.in files list instructions to invoke common or school-specific form fields to create an individual college application form in HTML. Tr , 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 ; 2029, 2029 A-D) and additional school-specific fields, thereby enabling schools to request the information from applicants that the school wanted. Tr 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 Page 3

5 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 5 of 32 Page ID#: 6846 (name: value pairs) segregated ( delimited ) by semi-colons. Tr , ; compare Tr The name is metadata used to characterize the user s data. The data itself is the value. Tr , 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 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 ; 2019 (CNA 79030); DTX 2022, 2023, 2002; 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 Account/password information, user data, institution data, and application information was stored in tables in a relational database. Tr 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 The Institution table stored institution keys (list of field information that an institution wanted for a particular application) and other information. Tr 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 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 In the AW 1 system, the following steps Page 4

6 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 6 of 32 Page ID#: 6847 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 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 and send it. DTX 2072, p 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 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 address and application fee. Tr 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 , 738. c. In order to prepare the , 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 ; Tr Once located, each name:value pair was included in the , 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 Every institution application had a keys file. Tr The keys file was created separately from the front-end application forms generating programs (app.pl and ques.pl). Tr An institution s keys file was created by two programs, keygen.pl and Page 5

7 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 7 of 32 Page ID#: 6848 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 E, lines 13-21, , ; Tr 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 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 , The AW 1 software, when creating a keys file, was programmed to look first for the SIS option E, lines ; Tr 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 ; 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 , 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 Page 6

8 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 8 of 32 Page ID#: 6849 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 , , , 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, 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 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 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 Page 7

9 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 9 of 32 Page ID#: 6850 considered by the Examiner during prosecution of the 278 and 042 patents. Tr ; DTX 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, and and 278 patent claims 3, 4, 19, and 28. DTX 2149, Exh. A, p. 2, Attachment 6; Tr ; see Tr 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 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 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, , , 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, The verification was implemented with JavaScript, which in early 1997 was a known method for data checking Internet forms. Tr. 188, 315, For this reason, verification was ready for patenting when the Smart Loan contract was signed in January Tr JavaScript verification is performed at the client computer. Id.; DTX Verification in the Smart Loan service was reduced to practice prior to the Critical Date. Tr. 182; CollegeNET s implementing schedule (DTX 2154) calls for the system to be online at the end of May, 1997 (Tr ), and Mr. Ratliff could not identify in Page 8

10 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 10 of 32 Page ID#: 6851 any respect that this logical order was not followed. Tr The system was online July 3. Tr Adjusting the schedule for this delay, which is consistent with all of CollegeNET s documentation and Mr. Ratliff s deposition testimony (Tr ), 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 Testing on browsers and platforms and the JavaScript verification programming were admittedly done by May Tr CollegeNET did not preserve the only Smart Loan software. Tr 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, DTX 3066-A through 3066-L; Tr ; 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, Tr 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 The code that implements verification also implements multi-page capability and is operable. PTX 3066-B; Tr 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 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 ; compare Tr , These conclusions are supported by CollegeNET s objective behavior. Tr By March 1997, CollegeNET was advertising to prospective college customers the Smart Loan service as an embodiment of its college application service. DTX 2022, 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 Page 9

11 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 11 of 32 Page ID#: 6852 University. DTX 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, 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 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 ), 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 ; CollegeNET has not presented any evidence other than DTX 2153 and 2155 concerning its implementation of user data delivery to Sallie Mae. Tr 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 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 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 ) 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. Page 10

12 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 12 of 32 Page ID#: 6853 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 The 278 patent was filed as a provisional application on June 4, A formal application was filed June 3, 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. CNA Of the references cited by the patent applicants, the Examiner found the Scharmer patent (DTX 2090) most pertinent. DTX 2087, pp 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 reprogramming 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 thirdparty forms servicer (i.e., CollegeNET), or using metadata to characterize the applicant data when stored. DTX 2093, pp 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 (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. Page 11

13 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 13 of 32 Page ID#: 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, 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 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 This is consistent with the dictionary meaning of hard-coded. DTX 2209, 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 As represented by Wolfston, AW 1 would not anticipate the features described (DTX 2079, at 7:51-61, 10:42-64; Tr ) 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, , 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 Page 12

14 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 14 of 32 Page ID#: 6855 HTML code was then delivered to and displayed by the user s browser. See supra 6,8; Tr The.in file is not a software program but is a text or data file. Tr , 596; DTX 2031, 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 schoolspecific field, or to change the text of questions. Tr , , 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 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 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 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: Tr , , , 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 , , , and ; Tr. 142, Mr. Wolfston did not disclose any of this information to the Patent Office, and his affirmative representation is false. Tr Customized application forms. 38. Mr. Wolfston represented to the Patent Office: Page 13

15 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 15 of 32 Page ID#: 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 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: 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 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 : [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 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 Page 14

16 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 16 of 32 Page ID#: 6857 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 Mr. Wolfston s representation did not colorably disclose the true customization capabilities of AW 1 and was false and misleading. 3. Data Sharing. 43. Mr. Wolfston represented to the Patent Office: 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 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 Tr. 85, 87-89, 93, 121, ; 225, 245, 246, ; DTX Mr. Wolfston personally confirmed its use by applying as a student would. DTX 2234, pp 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 , 253. Data sharing occurred when the attribute names for any two fields in different applications were the same. Tr 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 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 Similar statements appear in DTX 2013, 2014, and Page 15

17 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 17 of 32 Page ID#: 6858 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 automatic transfer of common information from one application to another. DTX 2019, at CNA Similar statements appear in DTX 2002, 2023, and The patent applicants did not tell the Patent Office that the data sharing capability was made public, tested on the public system (Tr ), 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 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. 47. Mr. Wolfston represented to the Patent Office: 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 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 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 ). Page 16

18 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 18 of 32 Page ID#: 6859 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 33 rd, etc.). 278 patent, 21:1-10. In the Reexamination of the 042 patent, CollegeNET and Mr. Wolfston sought (DTX 2130, pp ) and obtained (DTX 2133, pp ) 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 The AW 1 system processed the user s data prior to sending it to the institution. Tr ; Tr ; see supra 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 ; Tr 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 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 Wolfston and CollegeNET simply denied this processing and formatting capability that had been in public use or sold long before the Critical Date. Tr , 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 Page 17

19 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 19 of 32 Page ID#: 6860 supra 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 , 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. 53. Mr. Wolfston represented to the Patent Office: 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 , 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 Page 18

20 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 20 of 32 Page ID#: 6861 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 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 (discussing DTX 2072 and 2035); Tr. 252 (confirming that the AW 1 code implements processing architecture described in DTX 2072); Tr , 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 ; 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 CNA ; 2019 at CNA79030; 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: :26, 32-37; DTX 2098, 042 patent, 13:66-14:1 14:28, 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 Page 19

21 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 21 of 32 Page ID#: 6862 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. 58. Mr. Wolfston represented to the Patent Office: 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 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 Without specialized software, the flat text file elements cannot be searched, sorted, retrieved and processed. Id.; Tr 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 , 250, to characterize the data and using software routines to place the user data in a structured BLOB (Tr , ) that was stored in the Illustra relational database. DTX 2072, 2076; Tr , 92; Tr 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 Applicant data information was stored in a number of tables in the Illustra database. DTX 2072; Tr , 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 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. Page 20

22 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 22 of 32 Page ID#: Information about the actual capabilities and storage structure of AW 1 would have been important to a reasonable examiner. Tr The AW 1 system contained multiple fields, stored new user data without changing prior applications, and used a commercial relational database product. See supra 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 Multiple page forms. 62. Mr. Wolfston represented to the Patent Office: 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 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 DTX, 2218, 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 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 , , ; 7/9/08 Supp. Agreed Facts, 5, 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 ; , , ; Tr ; compare DTX 2035, p. 6, detailing procedures for prior customer approval of online forms and conditions to removing demo designation. Removal of a Page 21

23 Case 3:03-cv BR Document 808 Filed 07/14/08 Page 23 of 32 Page ID#: 6864 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 multipage 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 , ; DTX 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 , 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 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, The information set out above in paragraphs would have been material to a reasonable examiner. Tr Mr. Wolfston s Declaration denying this capability is false and misleading. 8. Metadata and Data Checking (or Verification) 68. Mr. Wolfston represented to the Patent Office: Page 22