COLLEGENET, INC. v. XAP CORPORATION

Full title: COLLEGENET, INC., a Delaware corporation, Plaintiff, v. XAP CORPORATION, a…

Court: United States District Court, D. Oregon

Date published: Oct 29, 2004

No. CV-03-1229-HU (D. Or. Oct. 29, 2004)

Opinion

No. CV-03-1229-HU.

October 29, 2004

Kristin L. Cleveland, Scott E. Davis, Jared S. Goff, Michael N. Zachary, KLARQUIST SPARKMAN, LLP, Portland, Oregon, Attorneys for Plaintiff.

Alexander C. Johnson, Stephen S. Ford, MARGER, JOHNSON McCOLLUM, P.C., Portland, Oregon, Daniel Johnson, Jr., Henry C. Su, FENWICK WEST LLP, Mountain View, California, Attorneys for Defendant.

FINDINGS RECOMMENDATION

DENNIS HUBEL, Magistrate Judge

Plaintiff CollegeNET, Inc. brings this patent infringement action against defendant XAP Corporation. Plaintiff is the owner of two patents: United States Patent Number 6,345,278 B1 ("the '278 patent), and United States Patent Number 6,460,042 ("the '042 patent). In its Second Amended Complaint, plaintiff brings two claims of patent infringement, one for each of the two patents. Plaintiff also brings a claim for declaratory judgment related to a September 10, 2003 press release published by plaintiff, as well as two claims for unfair competition.

Defendant raises affirmative defenses of noninfringement, invalidity, and unenforceability. Defendant additionally counterclaims for declaratory judgments of noninfringement, invalidity, and unenforceability. Finally, defendant also brings claims for unfair competition.

Presently, the parties seek construction of various terms of the two patents. This Findings Recommendation contains my recommended claim constructions.

This Court has had the opportunity to previously oversee the adjudication of these two patents in two cases, unrelated to the present case, brought by plaintiff against ApplyYourself, Inc. In case number CV-02-484-HU, plaintiff brought infringement claims against ApplyYourself related to the '278 patent. In case number CV-02-1359-HU, plaintiff brought infringement claims against ApplyYourself related to the '042 patent. The cases were consolidated and were tried to a jury in August and September 2003. As part of that litigation, I construed some claims in both patents. CollegeNET v. ApplyYourself, No. CV-02-484-HU, Opinion (D. Or. Dec. 19, 2002) (construing claims in the '278 patent);CollegeNET v. ApplyYourself, Nos. CV-02-484-HU, CV-02-1359-HU, Opinion (D. Or. July 7, 2003) (construing claims in both patents). I refer to my previous constructions as discussed below.

BACKGROUND AND OVERVIEW OF THE INVENTIONS

I. The '278 Patent

As described in the patent itself, students applying to colleges and universities typically complete a separate paper application for each institution to which they seek admission. Exh. A to Sec. Am. Compl. (Col. 1, lines 19-21).¹ The applicant then mails each application to the corresponding institution along with a fee. 1:21-23.

1 References to the '278 patent will be to this exhibit and will be denoted simply by the column and line number referred to, such as 1:19-21.

Many institutions prefer Internet applications. 1:24-25. One problem with such applications, however, is that the student is required to re-enter the same information for each subsequent application to a different institution or to the same institution perhaps for a different academic term. Additionally, the institution cannot change the application form without revising the source code that creates the application form, making changes expensive and inconvenient. 1:26-34.

One way to reduce the redundancy for the applicant would be to allow students to complete a single, generic application form provided by a third party who would then transmit the application to any designated institution. 1:35-38. The drawback to such a system is that the institution cannot customize its application form. 1:38-48.

As described by plaintiff, a typical applicant would use the patented invention by first viewing a college's website and proceeding to the admissions web page. The student would typically be using a personal computer that was running a web browser to access the website. Somewhere in the on-line admissions materials, there is a prompt for applying on line. Clicking on this would lead the student through a series of instruction pages and ultimately to a "log on" page where the student establishes a user ID and a password.

Next, the student would receive a prompt which would say something like "Application" or "Apply Now." When the student clicks on this prompt, the browser on the student's computer sends a request over the Internet to the third party servicer's web server. The forms engine processes the request. The request itself would identify the specific college application form being requested and the student who is requesting it.

The forms engine then creates a copy of the requested application form for the student. The forms engine can create a copy of the college's application form in a variety of ways. The forms engine queries the database to determine whether the particular student has information stored that corresponds to any of the fields in the newly requested application form. If it is that student's first application with the third party servicer's system, there will be no stored information. If the student has previously filled out other application forms, the forms engine will identify the like fields and obtain data from the database. The forms engine will merge the retrieved data into the corresponding form data fields on the application form. The forms engine will then provide the application form to the student, sending it from the web server over the Internet.

The student then enters personal information into the form data fields. When the student clicks "save" or "save and go to next page," the browser will send the information entered by the student and post it to the third party servicer's web server. The forms engine then stores the information into the database.

Once the student has completed the form, the student can hit the "transmit" or "send application to school" prompt. It is then possible for the forms engine to perform a "data validation" check on the application. For example, Lewis Clark College may specify that the "high school attended" and "SAT scores" are required fields and that it will not accept application forms in which those fields are left blank.

In addition, error-checking criteria may be specified, such as the "SAT score" must be between 200 and 800. The forms engine compares the data entered by the student for these fields and determines whether they are filled in and whether any specified criteria are met. If the criteria are met, the data is "valid" and will be further processed. If not, the system will send back to the student, over the Internet, an error-correction form or message that the student must change entries for the fields that did not meet the prescribed criteria.

Once the application is complete, the student can also select a payment method to "e-pay" the school's application fee.

Next, the same student may want to fill out a second application to a different college or university. The student logs on to that school's website and follows the application prompts. The forms engine creates an application form for the student. Assuming both colleges use plaintiff's services, and because the student has previously filled out a form, information regarding that student is already stored in the database. The forms engine will retrieve information required for the second application that the student has already entered on the first application. The forms engine then automatically inserts the previously stored information required by the second application, into the form data fields of the second application form and sends it back to the student over the Internet. . . . The student will fill in the remaining blanks of the form, then "save" it. His or her data will then be sent over the Internet and posted to the web server. The forms engine will then store the data in the database.

II. The '042 Patent

The '042 patent is a continuation patent of the '278 patent. Exh. B to Sec. Am. Compl. (Col. 1, lines 4-5).²

2 References to the '042 patent will be to this exhibit and will be denoted simply by the column and line number referred to, such as 1:4-5.

The abstract of the patent explains the patent as follows:

A forms engine allows data sharing between customizable on-line forms, such as college admissions applications. Before applying, an applicant opens an account with a third party application servicer. After the applicant completes an application for one institution, the data is saved in a data base and automatically populates fields in subsequent application forms. The form for each institution is created from a form description file. Each form is branded for its institution and forms for different institutions differ in appearance and content so that the presence of the third party servicer is transparent to the applicant.

The system is extensible without programming, allowing new applicant attributes to be readily incorporated into the system and allowing the content and appearances of the application to be readily changed by changing the description file. The use of aliases for applicant attributes permits data to be readily shared between forms even though labeled and arranged differently on different forms. Information stored about each attribute allows the specification of data validation rules and data sharing and grouping rules, as well as dependency rules that permit application page content to depend on applicant's responses on a previous page.

Exh. B to Sec. Am. Compl. at p. 1.

The attributes of the '042 patent are fairly consistent across the independent claims and include the following general features: (1) presenting a customized form to an applicant; (2) allowing the applicant to enter user and payment information; (3) receiving the user and payment information; (4) processing the user and payment information; and (5) sending the user information back to the institution in a format specified by the institution.

The dependent claims further define the form in various ways: (1) as having multiple pages, as seen in claims 6, 21, 33, and 43; (2) providing for data validation at the client computer or after each page of the multiple page application is posted, as seen in claims 7, 8, 10, 11, 14, 22, 23, 25, 27, 30, and 33; (3) providing for further data validation at the server level or when the application is completed, as seen in claims 8, 10, 11, 12, 14, 23, 25, 27, 28, 30, 34, and 35; and (4) providing for automatic data population between multiple application forms, as seen in claims 4, 19, 36, 37, and 41.

CLAIM CONSTRUCTION STANDARDS

The first step in any validity or infringement analysis is to construe the claims. See, e.g., Smiths Indus. Med. Sys., Inc. v. Vital Signs, Inc., 183 F.3d 1347, 1353 (Fed. Cir. 1999) ("the first step in any validity analysis is to construe the claims of the invention to determine the subject matter for which patent protection is sought"); Markman v. Westview Instruments, Inc., 52 F.3d 967, 976 (Fed. Cir. 1995) (en banc) (first step in two-step patent infringement analysis is to determine "the meaning and scope of the patent claims asserted to be infringed[, . . .] commonly known as claim construction or interpretation[.]"), aff'd, 517 U.S. 370 (1996). The meaning of a term in a patent claim is a matter of law to be resolved by the court. Markman, 517 U.S. at 389-91.

Claims should be interpreted, when reasonably possible, to preserve their validity. Modine Mfg. Co. v. United States Int'l Trade Comm'n, 75 F.3d 1545, 1556 (Fed. Cir. 1996). In construing a claim, the court should first look to the intrinsic evidence, that is, the claims themselves, the written description portion of the specification, and the prosecution history. Bell Howell Document Mgmt. Prods. Co. v. Altek Sys., 132 F.3d 701, 705 (Fed. Cir. 1997).

Generally, claim construction begins with the words of the claim. K-2 Corp. v. Salomon S.A., 191 F.3d 1356, 1363 (Fed. Cir. 1999).

It is standard practice that in determining the proper construction of an asserted claim, the court looks first to the intrinsic evidence — the patent specification, including of course the written description, and, if in evidence, the prosecution history. Absent an express definition in the specification of a particular claim term, the words are given their ordinary and accustomed meaning; if a term of art, it is given the ordinary and accustomed meaning as understood by those of ordinary skill in the art.

Zelinski v. Brunswick Corp., 185 F.3d 1311, 1315 (Fed. Cir. 1999); see also Georgia-Pacific Corp. v. United States Gypsum Co., 195 F.3d 1322, 1332 (Fed. Cir.) ("The specification of the patent in suit is the best guide to the meaning of a disputed term."), amended, 204 F.3d 1359 (Fed. Cir. 1999).

Terms in a claim are given their ordinary meaning to one skilled in the art unless it appears from the patent and prosecution history that the inventor used them differently. A patentee may be his own lexicographer, but any special definition given to a word must be clearly defined in the specification or file history. Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996).

Additionally, a claim term should generally be read so as not to exclude the inventor's device or the inventor's preferred embodiment. See, e.g., id. at 1581 (claim interpretations excluding the preferred embodiment are heavily disfavored);Modine Mfg., 75 F.3d at 1550 ("[A] claim interpretation that would exclude the inventor's device is rarely the correct interpretation[.]").

While examining the patent specification is appropriate, it is improper to import, or "read in" to a claim, a limitation from the specification's general discussion, embodiments, and examples. See, e.g., Intel Corp. v. United States Int'l Trade Comm'n, 946 F.2d 821, 836 (Fed. Cir. 1991) ("Where a specification does not require a limitation, that limitation should not be read from the specification into the claims.") (internal quotation omitted);Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed. Cir. 1988) ("Although the specification may aid the court in interpreting the meaning of disputed language in the claims, particular embodiments and examples appearing in the specification will not generally be read into the claims.").

It is also improper to eliminate, ignore, or "read out" a claim limitation from a claim in order to extend a patent to subject matter disclosed, but not claimed. See, e.g., Ethicon Endo-Surgery, Inc. v. United States Surgical Corp., 93 F.3d 1572, 1582-83 (Fed. Cir. 1996) (court cannot read a limitation out of a claim); see also Unique Concepts, Inc. v. Brown, 939 F.2d 1558, 1562 (Fed. Cir. 1991) (patentee cannot be allowed to expressly state throughout specification and claims that his invention includes a limitation and then be allowed to avoid that claim limitation in infringement suit by pointing to one part of specification stating an alternative lacking the specification).

Claims are not limited to the preferred embodiment. CVI/Beta Ventures, Inc. v. Tura LP, 112 F.3d 1146, 1158 (Fed. Cir. 1997) ("as a general matter, the claims of a patent are not limited by preferred embodiments."); see also Amhil Enters., Ltd. v. Wawa, Inc., 81 F.3d 1554, 1559 (Fed. Cir. 1996) ("A preferred embodiment . . . is just that, and the scope of a patentee's claims is not necessarily or automatically limited to the preferred embodiment.").

Finally, when intrinsic evidence is unambiguous, it is improper for the court to rely on extrinsic evidence to contradict the meaning of the claims. See Pitney Bowes, Inc., v. Hewlett-Packard Co., 182 F.3d 1298, 1308-9 (Fed. Cir. 1999). If, after considering the intrinsic evidence, a claim term is ambiguous, a court may look to extrinsic evidence to assist in determining the meaning or scope of terms in a claim.Vitronics, 90 F.3d at 1584. Extrinsic evidence includes expert testimony, inventor testimony, and technical treatises or articles. Id. Extrinsic evidence cannot, however, alter the clear meaning of a claim arising from the patent or prosecution history. Id.

DISCUSSION

I. Terms Proposed for Construction by Plaintiff

Plaintiff seeks the construction of three claim terms or phrases: (1) automatically; (2) file; and (3) "processing by the third party forms servicer an electronic payment associated with the form."

A. Automatically

The term "automatically" appears in claims 1, 9, 12, 13, 14, 21, and 32 of the '278 patent, and in claims 4, 19, 36, and 38 of the '042 patent. In each instance, the term modifies one of three functions: populate, insert, or store. The term principally appears as "automatically" and occasionally as "automatic." This different use is immaterial to the construction of the term.

I previously construed the term in the December 19, 2002 Opinion in the ApplyYourself case. Dec. 19, 2002 Op. at pp. 10-29. Plaintiff's proposed construction is the same as the construction I adopted there. I agree with defendant that the constructions adopted in the ApplyYourself case are not controlling here. Texas Instruments, Inc. v. Linear Techs. Corp., 182 F. Supp.2d 580, 586 (E.D. Tex. 2002) (court's claim construction by another judge in same district in prior suit did not collaterally estop unrelated defendant from obtaining new claim construction; independent review of the claims would ensure fairness to all parties).

Nonetheless, while the previous claim constructions do not have preclusive effect here, to the extent neither party raises new arguments, I defer to the prior claim constructions. KX Indus., L.P. v. PUR Water Purification Prods., Inc., 108 F. Supp. 2d 380, 387 (D. Del. 2000), aff'd, 2001 WL 902507 (Fed. Cir. 2001). Additionally, even in the presence of new arguments, I give "considerable weight" to my previous claim constructions.See Colby v. J.C. Penney Co., 811 F.2d 1119, 1123 (7th Cir. 1987) (under the principles of stare decisis "a court must give considerable weight to [its own previous decisions] unless and until they have been overruled or undermined by the decisions of a higher court, or other supervening developments, such as a statutory overruling").

The construction of "automatically" that I adopted in theApplyYourself case is: "Once initiated, the function is performed by a machine, without the need for manually performing the function." Dec. 19, 2002 Op. at p. 29. Defendant does not oppose this construction, but contends that because the term modifies different functions, the construction of the term must be made specifically in the context of the claim limitation in which it appears.

I disagree. "Automatically" describes how the function is to be performed. There is no suggestion from the claim language that the nature of that performance depends on the particular function being performed. Furthermore, generally, the same meaning is ascribed to the same claim term. Omega Eng'g, Inc. v. Raytek Corp., 334 F.3d 1314, 1334 (Fed. Cir. 2003) ("[W]e presume, unless otherwise compelled, that the same claim term in the same patent or related patents carries the same construed meaning."). Here, there is no compelling reason to construe "automatically" as it appears in each separate claim limitation. Thus, I recommend adoption of the prior construction of "automatically."

B. File

This term appears in claims 30 and 32 of the '278 patent. I previously construed the term to mean "[a]n electronically stored collection of information that has a unique name." Dec. 19, 2002 Op. at pp. 30-32. Plaintiff contends that I should adopt the same construction here.

Defendant states that while it has no objection to this construction, the term should be construed in the context of the claim in which it appears. The term appears in the context of the phrase "application information file," in claim 32 of the '278 patent. But, it appears independently in claim 30 of the '278 patent, and it was separately construed in the ApplyYourself case. Given that it appears independently in at least one claim, it warrants its own independent construction, divorced from the "application information file" phrase. Accordingly, I recommend adoption of the prior construction.

C. "Processing by the Third Party Forms Servicer an Electronic Payment Associated With the Form"

This phrase appears in independent claims 1, 16, and 32 of the '042 patent. In its entirety, the claim phrase reads: "processing by the third party forms servicer an electronic payment associated with the form, the processed payment being from the form user to the one of the multiple institutions to which the form is directed[.]" 35:29-32; 36:45-48; 37:63-67. Both parties seek construction of this phrase, although defendant adds some additional claim phrases related to the "electronic payment function." For efficiency, I address all proposed constructions related to the electronic payment function, here.

The proper construction of this claim phrase was vigorously contested in the ApplyYourself case. After briefing and oral argument, I construed the phrase as follows:

Using the received payment information to facilitate the clearance, settlement, and/or transfer of the electronic payment. The processing function includes, but is not limited to, processing by the business entity hosting the forms engine software and excludes any processing by any public form user or any of the institutions of higher education.

July 7, 2003 Op. at pp. 25, 45-55. Plaintiff argues for the adoption of this previous construction. Plaintiff additionally argues for the adoption of two terms within this claim phrase which I construed in the ApplyYourself case: (1) "electronic payment": "An electronic transfer of funds, such as an electronic check, credit card or debit card payment. The term electronic payment does not include a fee waiver." (2) "form": "A structured document having a collection of fields for entering and containing data. The form may be rendered to a user on a client computer or any web-browser enabled graphical display." Id. at p. 25.

Defendant does not dispute the prior construction of "electronic payment." In the ApplyYourself case, I concluded that the construction of "electronic payment" as "an electronic transfer of funds, such as an electronic check, credit card or debit card payment [and] does not include a fee waiver[,]" was appropriate because it was consistent with the claim language. July 7, 2003 Op. at p. 45. That same reasoning applies here. Accordingly, I recommend adherence to the prior construction for "electronic payment."

Defendant proposes a different construction for "form": "an electronic document having fields for the entry and display of data, which consists of one or more pages." Curiously, while defendant offers this alternative construction, it makes no mention of the previous construction.

Defendant points to two parts of the '278 patent specification in support of its proposed construction of "form." First, defendant notes that the specification states that "[t]he present invention comprises a universal forms engine that permits the creation and processing of customizable electronic forms and selective sharing of information between the customized forms." 2:1-4. Based on this, defendant argues that "form" means an electronic document. Next, defendant points to the specification's statement that "[a] form is considered to be essentially a container for data and implies an associated process." 2:22-23. Then, defendant notes that moreover, several claims of the '278 patent describe a form as having fields for the entry of information. 22:40-41, 22:57-58, 25:7-8, 26:11-13.

Next, because several of the dependent claims in the '278 patent refer to multiple form pages and multiple pages, 24:37-40, 25:53-54, 26:61, 26:64, defendant argues that the construction of "form" should include that the electronic document consists of one or more pages. Thus, defendant's proposal reads: "an electronic document having fields for the entry and display of data, which consists of one or more pages."

I recommend rejecting defendant's proposed construction of "form." The word "electronic" is not necessary because first, it is redundant in that some uses of the word "form" in the patent claims and specification are preceded by "electronic." Second, my previous construction, by discussing how the form may be rendered to the user, implicitly defines "form" as being electronic.

Also, the construction does not need to expressly state that a form is one or more pages because by construing the word without reference to any page limitation, none is suggested. Furthermore, the characteristic of multiple pages is expressed in dependent claims. Cases hold that generally, limitations of dependent claims are not normally read into the independent claim from which they depend. Karlin Tech., Inc. v. Surgical Dynamics, Inc., 177 F.3d 968, 971-72 (Fed. Cir. 1999).

Finally, I agree with plaintiff that there is no support for the inclusion of the word "display" in the construction of form. The specification provides that "a form is considered to be essentially a container for data and implies an associated process." 2:22-23. As such, plaintiff argues that a "display" requirement is not inherent in the meaning of the word form, nor is it required by the specification. I agree with plaintiff that while other claim language may suggest that the "form" is displayed, the term "form" itself does not. Therefore, I recommend rejecting defendant's proposed construction of "form" and adhering to the previous construction.

As to the larger claim phrase at issue, defendant suggests that in addition to the claim phrase quoted above regarding electronic payments, other claim phrases related to the electronic payment function need to be construed. Defendant cites to the following claim language: "receiving by the third party forms servicer over the computer network . . . electronic payment information entered by the user." This phrase appears in claims 1, 16, and 32 of the '042 patent. 35:26-28; 36:42-44; 37:60-62. Defendant also proposes that the slightly different language in claim 38 be construed: "receiving from the form user via the third party form servicer an electronic payment associated with the customized form[.]" 38:54-56.

Defendant offers separate constructions for five subparts of the originally construed phrase quoted at the beginning of this section and the additional phrases quoted in the preceding paragraph. The subparts proposed for construction are: (1) "processing . . . an electronic payment associated with the form"; (2) "receiving . . . electronic payment information"; (3) "by the third party forms servicer"; (4) "via the third party form servicer"; and (5) "entering payment information."

1. "By the Third Party Forms Servicer"

Because the central dispute in regard to this electronic payment phrase concerns the phrase "by third party forms servicer," I start with it. The heart of the dispute regarding this claim phrase in the ApplyYourself case was whether the entire function of processing the electronic payment had to be exclusively performed by the third party forms servicer itself or whether the third party forms servicer could contract with another party to perform the function. July 7, 2003 Op. Ord. at pp. 44-55. I rejected the argument that the function had to be performed exclusively by the third party forms servicer. Thus, my claim construction indicates that the processing function includes processing by the business entity hosting the forms engine software, but that the processing is not limited to that entity. Defendant here contends that my prior construction was in error.

Defendant raises arguments similar to those raised by the defendant in ApplyYourself and which I considered and rejected. For example, defendant points to Figure 15 in the '042 patent as demonstrating that the payment processing occurs inside the forms engine operated by the third party forms servicer. But, as explained in the July 7, 2003 Opinion, this argument "fails to account for the fact that a fourth entity must be involved in the processing of an electronic payment because of the nature of all electronic payments." July 7, 2003 Op. at p. 53. Because the electronic payment function requires a financial intermediary which authenticates credit cards and verifies account balances and two banks, the function necessitates the involvement of entities other than the forms engine host. Id. at pp. 53-54. Even if the business entity hosting the forms engine were to acquire the ability to perform the credit card clearinghouse function, the electronic payment processing function still requires the participation of two banks whose functions cannot be delegated to a non-bank entity. Id. at p. 54. Thus, reliance on Figure 15 is unpersuasive.

In the July 7, 2003 Opinion, I also addressed the defendant's argument that because the claim language provides that the third party forms servicer receives and processes both user information and electronic payment information and because the business entity hosting the forms engine is the third party forms servicer entity which processes the user information, it must be that same entity that processes the payment information. I rejected this argument in favor of plaintiff's argument that because these are "comprising claims," nothing in the claim language precludes another party from taking part in the processing of electronic payments. As I explained:

However, plaintiff notes that these are "comprising" claims which recite required steps and elements, but which do not preclude additional steps or elements. Vehicular Techs. Corp. v. Titan Wheel Int'l, Inc., 212 F.3d 1377, 1382-83 (Fed. Cir. 2000) ("The phrase `consisting of' is a term of art in patent law signifying restriction and exclusion while, in contrast, the term `comprising' indicates an open-ended construction. . . . In simple terms a drafter uses the phrase `consisting of' to mean `I claim what follows and nothing else.' A drafter uses the term `comprising' to mean `I claim at least what follows and potentially more.'") (citations omitted); Georgia-Pacific Corp. v. United States Gypsum Co., 195 F.3d 1322, 1327-28 (Fed. Cir. 1999) (use of the word "comprising" means including the elements that follow, but not excluding additional, recited elements).

Plaintiff argues that because these are "comprising" claims, nothing in the claim language precludes another party from taking part in the processing of electronic payments. Plaintiff contends that as "comprising" claims, the claims merely require that the third party forms servicer include the business entity hosting the forms engine as a party involved in the processing of payments, but not the sole party performing that function.

I agree with plaintiff. Although the claim language noted by defendant requires the "third party forms servicer" to "receive" both user and payment information and then to "process" both user and payment information, it does not, by itself, limit the interpretation of "third party forms servicer" to the forms engine host business entity nor does it preclude that entity from utilizing a fourth party to participate in the "processing." I note that the parties themselves define "processing" to include "facilitation" of the electronic payment. This suggests that the role of the "third party forms servicer" is not restricted to the actual performance of the processing function, but may include a facilitator capacity.

Given the nature of a "comprising" claim, additional elements may be part of the claim. Accordingly, based on the claim language, I interpret the disputed phrase "processing by the third party forms servicer," to mean that the processing function, as previously construed by the parties, includes, but is not limited to, processing by the business entity hosting the forms engine software and excludes any processing by any public form user or any of the institutions of higher education.

July 7, 2003 Op. at pp. 48-49.

Defendant in the present case renews the argument made by the defendant in ApplyYourself and suggests that I misinterpreted the law regarding "comprising" claims. I disagree.

Defendant primarily relies on Moleculon Research Corp. v. CBS, Inc., 793 F.2d 1261 (Fed. Cir. 1986). There, the court rejected Moleculon's argument that "comprising" language opened the patent claim and its individual method steps to additional structural elements in addition to opening the claim to additional steps.Id. at 1271. The court concluded that Moleculon's position was too broad. Id. The court held that while

a transitional term such as "comprising" or, as in the present case, "which comprises," does not exclude additional unrecited elements, or steps (in the case of a method claim), . . . the transitional phrase does not, in the present case, affect the scope of the particular structure recited within the method claim's step.

Id.

Defendant also cites to a 1997 case for the proposition that "`[c]omprising' is a term of art used in claim language which means that the named elements are essential, but other elements may be added and still form a construct within the scope of the claim." Genentech, Inc. v. Chiron Corp., 112 F.3d 495, 501 (Fed. Cir. 1997).

Defendant relies on these cases to argue that the term "comprising" cannot be used to read out the claim limitation's express requirement that processing an electronic payment be performed by a third party forms servicer. Defendant argues that the

open-ended "comprising" term permits the inclusion of additional steps, which may or may not be performed by additional actors, but it cannot alter or abrogate the express requirement that the third party forms servicer, i.e., the same entity responsible for processing the forms, actually perform the payment processing step.

Deft's Op. Cl. Constr. Brief at p. 29.

What defendant fails to recognize is that the prior construction requires the business entity hosting the forms engine to retain responsibility for processing the electronic payment. The construction mandates processing by the business entity hosting the form (e.g., the third party forms servicer that also processes the user information) but allows some processing steps related to electronic payments to be performed by another entity, except the public form user or any of the institutions of higher education. Thus, the prior interpretation is consistent with the law regarding "comprising" claims because it keeps the "named element" of having the third party forms servicer that also processes the user information, process the electronic payment information, but it allows the extra step of a fourth entity participating in such processing along with that third party forms servicer. I fundamentally disagree with defendant's argument that all of the electronic payment function process must be performed by the host of the forms engine. That entity must perform some, but not all, of the electronic payment function. Accordingly, I recommend adhering to the prior construction for the reasons initially explained in the July 7, 2003 Opinion and expressed herein.

2. "Via the Third Party Forms Servicer"

This phrase appears in claim 38 of the '042 patent. Defendant proposes the following construction: "[t]he institution taking possession of funds in its account through an electronic transfer of those funds from the form user, where the funds that are being transferred to the institution from the user have come by way of or by means of the third party form servicer." To the extent this phrase requires construction at all, I construe it consistently with my previous construction in the ApplyYourself case and consistently with the construction for "by the third party forms servicer" discussed in the preceding section. That is, the third party forms servicer, because it is required to be involved in the processing function as described above, may ultimately transfer the funds from the user to the institution, but other portions of the payment processing function may have been performed by a separate entity so long as it is not the user/applicant or the institution.

3. "Processing . . . an Electronic Payment Associated with The Form"

Defendant proposes the following construction for this claim phrase: "[s]ubjecting an electronic payment associated with the form to[,] or handling an electronic payment associated with the form through[,] an established and routine set of procedures for effecting an electronic transfer of funds, including procedures for authorization, clearance and settlement."

Since "electronic payment" and "form" have already been addressed, the only remaining term in this phrase actually needing construction is "processing." Plaintiff proposes that "processing" in the context of the payment function be construed as "the manipulation of data within a computer system." Defendant argues that the term means "`to subject to a special process or treatment (as in the course of manufacture'" or "`to subject to or handle through an established usu. routine set of procedures[.]'" Deft's Op. Cl. Constr. Brief at pp. 25-26 (quoting Merriam Webster's Collegiate Dictionary 929 (10th ed. 1994)). Thus, defendant's proposed construction for this claim phrase uses the terms "subjecting . . . to[,] or handling . . . through[,] an established and routine set of procedures[.]"

Defendant contends that because the claim specifies that the third party forms servicer processes an electronic payment rather than electronic payment information as recited in the previous limitation regarding the receipt by the third party forms servicer of electronic payment information entered by the user, the term "processing" as used in the phrase "processing by the third party forms servicer an electronic payment associated with the form," means something more than "processing" information or data. Defendant also contends that if "processing" means only the manipulation of data within a computer system, then the stated and claimed goal in the subsequent claim limitation which recites "relieving the institution of the administrative burden of processing forms and payments," would not be achieved.

I disagree with defendant. First, the distinction between "electronic payment" and "electronic payment information" does not support defendant's construction. Under the claim language, an "electronic payment" gets "processed" while "electronic payment information" gets "received." Thus, there is no basis to conclude that the term "processing" when used with "electronic payment" means anything more than "the manipulation of data within a computer system." The previous function is restricted to receiving information which requires no manipulation of data.

Second, I reject defendant's argument that "manipulation of data within a computer system" is insufficient to relieve the institution of processing forms and payments. "Manipulation" is a broad term and is not confined, in this construction, to a narrow task.

Accordingly, I recommend that plaintiff's proposed construction for "processing" be adopted.

4. "Receiving by the Third Party Forms Servicer Over the Computer Network User Information and Electronic Information Entered by the User"

Defendant proposes the following construction: "[t]he third party forms servicer takes possession of the electronic payment information entered by the user, but need not do anything with it." Defendant notes that the act of "receiving" is passive and stands in contrast to "processing" which requires the third party forms servicer to do something.

I agree with defendant and conclude that this proposed construction is supported by the claim language. I also note that defendant's argument in regard to this phrase underscores my reasoning in regard to the construction of the term "processing." I recommend that defendant's proposed construction of the "receiving" phrase be adopted.

5. "Entering Payment Information Onto the Form"

Dependent claims 2 and 17 of the '042 patent provide a limitation in which the payment information entered by a user is entered onto the form. Defendant contends that the claims refer, as their antecedent basis, to the form claimed in independent claims 1 and 16, respectively. Thus, defendant argues, entering the payment information onto the form must mean "entering the payment information in some designated data field(s) of the form generated by the forms engine program and customized in its appearance and content in accordance with the preferences of the institution." I agree with defendant that this construction is a fair interpretation of the claim language and I recommend that it be adopted.

II. Terms Proposed for Construction by Defendant

Defendant groups its constructions into six different functions performed by the invention covered by the two patents. One of these groups addresses all of the claim limitations directed at the "electronic payment function." As noted above, the preceding discussion of plaintiff's proposed construction of "processing by the third party forms servicer an electronic payment associated with the form," includes a discussion of defendant's proposed constructions for the "electronic payment function" and there is no need to further address those constructions.

The remaining five functions are: (1) forms engine; (2) user information database; (3) no rewriting of code; (4) forms processing; and (5) relief from administrative burden. In addition, defendant proposes constructions for two miscellaneous terms: (1) metadata; and (2) relational database.

A. Forms Engine Function

1. "Application Form" and "Application"

"Application" appears in claims 1 and 32 of the '278 patent and in claim 26 of the '042 patent. "Application form" appears in claims 1 and 32 of the '278 patent and in claim 39 of the '042 patent. Defendant proposes slightly different constructions for each term.

Defendant argues that "application form" should be construed as "a form representing an application for admission to a higher education institution." Defendant bases its proposal on the preamble to claim 1 of the '278 patent which recites: "[a] method of creating and processing over a computer network forms representing applications to different higher education institutions[.]" 22:34-36. Defendant argues that because the preamble indicates that claim 1 is directed to a method that results in application forms to "higher education institutions," the construction of "application form" must include a reference to such institutions.

In contrast, defendant proposes the following for the construction of "application": "[a] form representing an application to an institution." Defendant notes that because the preamble of claim 32 of the '278 patent refers only to "applications to institutions" and not "forms" for "applications" to "institutions of different higher education institutions," "application" must be construed more broadly to refer to all "institutions."

Plaintiff argues that neither of these terms need to be construed because they carry only their ordinary meaning and not a technical or special meaning. In such cases, construction is not necessary. Defendant suggests that the district court must construe every term proposed for construction by a party. Defendant's cited authority does not support this proposition. InSulzer Textil A.G. v. Picanol N.V., 358 F.3d 1356, 1366 (Fed. Cir. 2004), the court held that "the district court must instruct the jury on the meanings to be attributed to all disputed terms used in the claims in suit so that the jury will be able to intelligently determine the questions presented." Id. (internal quotation omitted). That statement, however, was made in the context of resolving the question of whether a district court must instruct the jury on all the constructions it actually rendered. Id. at 1365-66. The court did not consider the question of whether a claim term which appears to be used in its ordinary sense, and not in any particular technical or scientific sense, must be construed simply because one party requests its construction.

While claim terms "must be construed as they would be understood by a person of ordinary skill in the art to which the invention pertains," and thus, "[w]hat the claim terms would mean to laymen is irrelevant[,]" Searfoss v. Pioneer Consol. Corp., 374 F.3d 1142, 1149 (Fed. Cir. 2004), if a person of ordinary skill in the art would understand the term in its ordinary, everyday sense, there is no need to construe the term. E.g., Biotec Biologische Naturverpackungen GmbH Co. KG v. Biocorp, Inc., 249 F.3d 1341, 1349 (Fed. Cir. 2001) (district court did not err when it declined to construe "melting" when the meaning of "melting" did not depart from its ordinary meaning or otherwise require construction); Appelra Corp. v. MicrosMass, UK, Ltd., 186 F. Supp. 2d 487, 524, 526 (D. Del. 2002) (court declined to construe terms "maintain," "maintaining," and a "whereby" clause because they were clear on their face and the meaning was "self-evident"); Zip Dee, Inc. v. Dometic Corp., 63 F. Supp. 2d 868, 872 (N.D. Ill. 1998) (rejecting defendant's "artificial construct" of the term "tension" because no construction beyond the "ordinary English language meaning of the term" was required and thus, the patent's "references to `tension'" [would] go to the jury without the interposition of any judicial gloss.").

Both "application" and "application form" are easily understood terms which the patents use in their ordinary sense. Neither the claim language nor the specification suggests that the meaning is anything other than the form used to apply to an institution or an institution of higher education. To the extent any construction is needed, I agree with plaintiff that it should be limited to "a form corresponding to an application."

I further conclude that only the term "application" needs the construction. "Application form" needs no further construction because it already clearly communicates its ordinary, everyday meaning in its own words. To apply the construction for "application" to "application form" would be an exercise in redundancy.

Additionally, there is no support in the claim language to restrict "application form" to an admissions application. The term "admissions" is not used to modify "application form" in claim 1 of the '278 patent. The specification of the '042 patent indicates that although the preferred embodiment of the invention is directed toward admissions forms, the invention may be used for "processing many different types of forms." 9:25.

Finally, I reject defendant's suggestion that "application form" is restricted to applications to "institutions of higher education" while "application" corresponds to the broader "institutions." The only reference to institutions of higher education is in the preamble to claim 1 of the '278 patent. It does not appear anywhere else in that claim and it does not appear in claim 32 of the '278 patent or in claim 39 of the '042 patent, claims which also refer to "application form." Generally, "[l]anguage in a preamble limits a claim where it breathes life and meaning into the claim, . . . but not where it merely recites a purpose or intended use of the invention." Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1118 (Fed. Cir. 2004) (citation omitted). In this case, the reference to "institutions of higher education" in the preamble is only a recitation of a purpose or intended use and adds no separate meaning to the claim.

Accordingly, I recommend that plaintiff's proposed construction of "a form corresponding to an application," be adopted for the term "application."

2. "Institution"

This term appears in claims 1, 21, and 32 of the '278 patent and in claims 1, 16, 32, and 38 of the '042 patent. Defendant proposes it be construed as "an established organization or corporation." Defendant's construction is based on a definition from Merriam Webster's Collegiate Dictionary 606 (10th ed. 1994).

Plaintiff argues that the term needs no construction because it is used only in its ordinary meaning. I agree with plaintiff that because the term is used only in its plain, customary meaning and there is no technical or scientific meaning ascribed to it, providing a construction for the term simply adds unnecessary complexity.

3. "Creating" or "Generating"

One or both of these terms appear in claims 1, 2, 21, and 32 of the '278 patent, and in claim 1 of the '042 patent. Defendant again relies on Merriam Webster's Collegiate Dictionary to construe the terms as "bringing into existence." I agree with plaintiff that because these terms are used only in their ordinary, everyday sense, there is no need to construe them.

4. "In Response to a Request"

This term appears in claims 1, 21, and 32 of the '278 patent and claims 1, 19, and 36 of the '042 patent. Defendant states that both "response" and "request" have their common, everyday meanings. Nonetheless, defendant proposes that the phrase be construed as "in reaction of an instance of a user asking for that form." Plaintiff argues that the phrase needs no construction as it is readily understandable without further elaboration. I agree with plaintiff that the phrase need not be construed because even as defendant notes, the words are used in their ordinary, plain meaning.

5. "Providing" and "Transmitting"

"Providing" is seen in claims 1 and 32 of the '278 patent and in claims 1, 16, 32, and 38 in the '042 patent. For example, in claim 1 of the '278 patent, it is used as follows: "providing to the applicant over a computer network the first application form[.]" 22:42-43. "Transmitting" appears in claims 6, 27, and 32 of the '278 patent. For example, in claim 32, it is used as follows: "transmitting the customized application over a computer network to a requesting applicant[.]" 26:17-18.

For "providing," defendant seeks the following construction: "making the generated form available to the user." For "transmitting," defendant proposes: "sending the generated form to the user." Defendant relies on Merriam Webster's Collegiate Dictionary for its proposed constructions.

Plaintiff argues that the terms "providing" and "transmitting" are everyday words used in their ordinary, everyday sense and thus, they need no construction. I agree with plaintiff. I further agree with plaintiff that neither the claim language nor the specification requires the construction to include the object of the action, e.g. "the generated form", or to whom it is directed, e.g. "the user." For example, if defendant's construction of "transmitting" were used, the claim phrase "transmitting the customized application over a computer network to a requesting applicant" in claim 32 of the '278 patent, would read: "`sending the generated form to the user' the customized application over a computer network to a requesting applicant." I agree with plaintiff that this makes the claim limitation unreadable.

6. "Forms Engine Program" and "Forms Generator"

Claim 21 of the '278 patent and claim 1 of the '042 patent refer to the software program that generates a response to a request from a user. Claim 21 of the '278 patent provides: "a forms engine program operating on the server computer for generating a form from the form description information[.]" 25:3-5. Claim 1 of the '042 patent states: ". . . the form being generated by a forms generator that generates multiple forms corresponding to multiple institutions of higher education, the forms generator generating forms that are . . ." 35:11-14.

Defendant proposes one construction for both phrases: "a software program responsible for performing, among other tasks, the creation or generation of multiple forms corresponding to multiple institutions." Plaintiff proposes separate, but simpler phrases: "A software program that can be used to generate a form" for the term "forms engine program" and "a software program that can be used to generate forms" for the term "forms generator."

Both parties' proposals incorporate the phrase "a software program." I agree with the parties that the phrase "forms engine" is used in the technical, computing sense to mean "a software program." I further agree, as is seen in both parties' proposals, that the phrase "forms engine program" can generally be understood as a software program that creates or generates forms.

Plaintiff contends that defendant's proposal inappropriately inserts "among other tasks" which suggests that the forms engine program and forms generator are required to perform unspecified other tasks, other than generating forms. I agree with plaintiff that the claim language and specification does not support a construction suggesting that the forms engine program or forms generator must be able to perform other tasks. While the forms engine program or forms generator may actually be able to do so, the claims do not mandate the performance of other tasks. The disclosed function for forms engine program and forms generator appears limited to generating forms.

I agree with defendant that the construction for both terms properly includes the reference to "multiple forms corresponding to multiple institutions." Plaintiff notes that in claim 21, the term "forms engine program" is used only in conjunction with the generation of a form, in the singular, not multiple forms. Dependent claim 23 in the '278 patent discusses a forms engine program that can generate more than one form. But, plaintiff argues, the requirement that it generate more than one form does not derive from the phrase "forms engine program" itself, but from additional language in the claim.

I disagree with plaintiff. The preamble to claim 21 provides for "[a] system for creating an processing customized forms for unrelated institutions." 24:52-53. This establishes that the purpose of the claim is to create more than one form. Each step in the claim discusses "form" in the singular because the system generates only one form at a time. But, the invention, to fulfill its purpose, must include a forms generator or forms engine program that generates multiple forms. The whole point of the invention is that a single forms generator or forms engine program can generate forms for multiple institutions and populate subsequent forms with data stored from earlier forms. A construction of "forms generator" and "forms engine program" without the requirement of generating multiple forms for multiple institutions would exclude the invention.

This distinguishes this reference to the preamble from the one discussed above in connection with the terms "application" and "application form." There, the preamble's reference to "institutions of higher education" was not a separate claim limitation because it merely recited a purpose of the invention. Here, while the use of the plural "forms" also indicates a purpose of the forms engine program, the plural term is required for the forms generator and forms engine program to have any meaning which comports with the invention.

Notably, defendant's proposed construction does not require that the forms engine program or the forms generator generate multiple forms simultaneously. The requirement is only that the forms engine program or forms generator be able to generate more than one form, not that it do so at the same time.

Thus, I recommend that the terms "forms engine program" and "forms generator" both initially be construed to mean "a software program which creates or generates multiple forms corresponding to multiple institutions."

Finally, although perhaps not obvious in the proposed constructions of these phrases, the briefing reveals that the parties dispute whether "a software program" as used in the construction of "forms generator" and "forms engine program" is a single program or multiple programs. Defendant contends that the "forms engine program" or "forms generator" is a single program that generates multiple forms corresponding to multiple institutions. Defendant relies on a reference in claim 1 of the '042 patent to "a forms generator" in the singular, "that generates multiple forms . . ." 35:12-14 (emphasis added). Defendant also notes that the prosecution history reveals that one of the named inventors differentiated the invention disclosed in the '278 patent from an earlier version of the system called "ApplyWeb I," by noting that ApplyWeb I required a separate software program for each application form for each school. Exh. A to Deft's Op. Cl. Constr. Brief.³ Thus, defendant contends, the invention disclosed in the patents in suit must be to a single program.

3 I request that in the future, defendant paginate all exhibits and refer to specific pages of an exhibit when citing to it.

Plaintiff counters this argument by noting that the word "a", as used in defendant's proposed construction "a software program" is typically understood to mean "one or more" in patent claims.Tate Access Floors, Inc. v. Interface Architectural Resources, Inc., 279 F.3d 1357, 1370 (Fed. Cir. 2002). Thus, by using "a software program," the construction means one or more programs. Plaintiff also notes that it is common for a "program" to include other "code," which may also be considered a "program," or to call upon other "programs," containing certain functions, with the "programs" working together to create a desired result.

Plaintiff argues that as long as the "forms engine program" or "forms generator" is involved in the generation process, the claim language is satisfied. Plaintiff also contends that nothing in the plain language of the claim deviates from this typical understanding or requires the "forms engine program" or "forms generator" to be the only software included in the form generation.

Plaintiff argues that as long as the "forms engine program" or "forms generator" is involved in the generation process, the claim language is satisfied. Plaintiff also contends that nothing in the plain language of the claim deviates from this typical understanding or requires the "forms engine program" or "forms generator" to be the only software included in the form generation.

Furthermore, plaintiff argues, the intrinsic evidence contradicts defendant's position. In the preferred embodiment, the "forms engine" operates in concert with other software such as the web server software and the database management system software. Plaintiff argues that while the specification states that the "preferred implementation of the invention comprises a single forms engine program . . .", this statement is limited to the preferred implementation and implies that implementations using more than one forms engine are possible.

I agree with plaintiff. Because the forms generator or forms engine program may use other code or programs to actually generate the form, and because it generates the form only in tandem with the web server and the database management software, it cannot be restricted to a single program. While it could be just a single software program that generates the forms, it should not be confined to a single program. Thus, I recommend that the following construction be adopted for "forms generator" and "forms engine program": "a software program, which, with or without additional software programs, creates or generates multiple forms corresponding to multiple institutions."

7. "Form Description Information," "Application Description Information," and "Application Information File"

While defendant proposes different constructions for these three terms, I consider them together because they are related. "Form description information" appears in claim 21 of the '278 patent as follows: "first data storage in communication with the server computer and including form description information specifying the content and appearance of each customized form[.]" 24:59-62. The phrase appears again in that claim: "a forms engine program operating on the server computer for generating a form from the form description information in response to a request for the form transmitted . . ." 25:3-5.

"Application description information" appears in dependent claim 2 of the '278 patent: "[t]he method of claim 1 in which creating a first application form customized in accordance with the preferences of the first institution includes generating a first application in accordance with stored application description information . . ." 23:16-20.

Defendant proposes parallel constructions for these two terms. First, for the "form description information" phrase, defendant proposes the following construction: "information describing a form that is sufficient to enable the forms engine program to generate the described form." For "application description information," defendant proposes: "information describing an application form that is sufficient to enable the forms engine program to generate the described application form." Defendant notes that the '278 patent specification uses "form information" and "application information" interchangeably to describe the information stored in the application data file. 5:61-63; 6:19-22. Accordingly, defendant contends that the two phrases should be similarly construed.

Plaintiff does not disagree that "form description information" and "application description information" should receive parallel constructions. But, plaintiff contends that there is no reason not to adopt the construction I gave "form description information" in the ApplyYourself case and then use that as the basis for the parallel construction of "application description information."

The construction I rendered in the ApplyYourself case for "form description information" was "the information used to customize a form." July 7, 2003 Op. at pp. 38-43. My analysis of the meaning of the term rendered in the ApplyYourself case is equally applicable here. The construction adopted there is consistent with the ordinary meanings of the terms in the phrase. Additionally, I am reluctant to adopt a construction that incorporates another construed phrase as defendant proposes here. Defendant's proposed construction uses "forms engine program." Thus, the jury will have to cross-reference the construction for "forms engine program" to understand the meaning of "form description information." Because the construction from theApplyYourself case sufficiently explains the phrase while avoiding this cross-referencing problem, I recommend that that construction be adopted in this case for the term "form description information." I also recommend that "application description information" be construed to mean "the information used to customize an application."

The phrase "application information file" appears in the following step of claim 32 of the '278 patent: "providing at least two application information files, each describing a customized application for an institution[.]" 25:64-65. It also appears again in a following step: "generating a customized application in response to a request over a computer network from an applicant, the application form and content being specified by one of the at least two application information files, . . ." 26:8-11.

In the ApplyYourself case, I construed "application information file" as "a file that stores information that includes a description of a distinct application form. The file describes the form itself, not the user data (e.g., student specific information) that may ultimately be entered into a particular copy of the form." Dec. 19, 2002 Op. at p. 30.

Defendant concedes that the previous construction is generally correct, but defendant argues that more specificity is required. Without citing to any part of the patent specification, defendant contends that both the specification and the claim language suggest that "application information file" should be construed to mean "a uniquely named text or template file that contains the instructions and pattern descriptions that enables the forms engine program to create a distinct application form that is customized in its appearance and content."

Plaintiff contends that defendant's proposal introduces new phrases without any support, such as "pattern description," that are confusing and undefined. As such, and because defendant concedes that it does not disagree with our prior construction, plaintiff argues that I should adopt my prior construction.

I agree with plaintiff. Defendant's proposal unnecessarily adds new, undefined phrases which will only lead to increased complexity in the claims construction process.

Furthermore, with a separate definition of "file" as rendered above, ("an electronically stored collection of information that has a unique name"), there is no need to construe "application information file" as something "uniquely named." I do agree with defendant that the addition of the words "text or template" to modify "file" is warranted by the claim language. In the discussion of the construction of "application information file" in the December 2002 Claims Construction Opinion on the '278 Patent, I noted that the use of the word "file" in that claim phrase was a "text, or perhaps template, file that stores the directions to produce the customized form for each institution." Dec. 19, 2002 Op. at p. 31. While this reference to "text, or perhaps template," did not make it into the final claim construction of the phrase, I conclude that the term "application information file" should be construed with that modification of "file." Thus, I recommend that the following construction of "application information file" be adopted: "A text or template file that stores information that includes a description of a distinct application form. The file describes the form itself, not user data (e.g., student specific information) that may ultimately be entered into a particular copy of the form."

B. User Information Database Function

This function is initially seen in the following language from the three independent claims of the '278 patent:

storing the posted applicant information in a database having a database field structure defined by multiple database fields, the database including multiple records, each record capable of storing information corresponding to each of the database fields[.]

22:49-52; 24:55-67; 26:4-7.

The following claim language from claim 1 of the '278 patent also encompasses the "user information database function":

automatically storing the applicant information entered into the second form data fields into the database by adding new records to the database, the automatic storing of the applicant information not altering the database field structure, thereby allowing new form data fields corresponding to applicant information not previously requested to be added to an application form without requiring alterations of existing application forms or of programs that access the database, whereby customized applications to different institutions share data through common, extensible data storage.

23:5-15. The other independent claims express a similar function. 25:16-23; 26:25-33.

Defendant also points to dependent claim 11 and this particular language as being relevant to the user information database function:

The method of claim 1 in which storing the posted applicant information in a database having a database field structure defined by multiple database fields includes parsing the applicant information within a [sic] into data elements, the data elements being separately stored and identified, thereby allowing the data elements to be separately retrieved and rearranged in subsequent applications.

23:66-67-24:1-5.

From these claim limitations, defendant proposes constructions for: (1) database; (2) database field structure; (3) defined by multiple database fields; (4) multiple records; (5) record; (6) data element; (7) by adding new records to the database without altering the database field structure; and (8) extensible.

The claim language at issue here, unlike other words or terms in the claims, is not used in its ordinary, customary sense, and is used in a technical sense. Thus, construction is required.

In regard to this function, one of the fundamental issues is whether the database storage is exclusively in a format, or structure, that is based on the concept of tables as one ordinarily thinks of a table for organizing information, a combination of rows and columns. While a table-based structure appears to be what is expressed in the preferred embodiment,see 3:48 (noting that the preferred embodiment uses "relational databases" (discussed below in section entitled "Miscellaneous Terms"); 9:13-14 (noting use of "transactions database table" and "transactions operations table" in preferred embodiment); 9:28 (section describing "Attribute Table"); 9:67 (section describing "User Attribute Sent Table), the specification also expressly states that the "invention is not limited . . . to . . . the use of any particular . . . database," 3:49-51, and it further discloses the use of Extensible Markup Language (XML) as an alternative method of storing user information. 21:13-67-22:1-19.

Accordingly, while the following discussion examines the claim terms at issue in this "user information database" function in the context of the preferred embodiment, I recognize that the claim terms are not limited to that embodiment both by the express statements in the written description and under general precepts of claim construction law. CVI/Beta Ventures, 112 F.3d at 1158 ("the claims of a patent are not limited by preferred embodiments.").

1. "Database"

Defendant proposes the following construction: "an organized collection of information that can be searched, retrieved, changed, and sorted using a collection of programs known as a database management system." Plaintiff proposes: "an organized collection of information that can be searched, retrieved, changed, and sorted using software." The point of contention is in whether the database uses "a collection of programs known as a database management system" or uses "software."

Defendant's proposal is the definition of "database" given in the 1995 edition of the Dictionary of Computer Words 61 (1995 rev. ed.) (relevant page found in Exh. B to Deft's Op. Cl. Constr. Brief). Defendant contends that the '278 patent specification does not indicate that the term "database" is used in any way other than this ordinary technical meaning.

Plaintiff argues against defendant's "database management system" limitation as unduly narrow. Plaintiff notes that the specification states that information can be stored in "tables" or in "XML files." 9:29-10:40, 21:14-19. Plaintiff further notes that while a database management system is often associated with accessing data stored in "tables," persons in the field and skilled in the art might not refer to the software that works with XML files as a "database management system." Accordingly, plaintiff argues, the claim language should not be limited to a "database management system."

I agree with plaintiff. From the written specification, the parties' briefing, the expert declarations, and the arguments presented in the case, it appears that one skilled in the art of database systems would initially understand the ordinary, customary use of the term "database" to refer to tables. But, the written specification, the briefing, the expert declarations, and the arguments presented in the case also show that XML is at least one other "format" available in which to store data. To avoid limiting the term "database" to the concept of storage of data in tables, I recommend rejecting defendant's proposed construction with its inclusion of "database management system" which one of ordinary skill in the art could use to infer that the database at issue in the patent is restricted to one using tables. Thus, I recommend that "database" be construed as "an organized collection of information that can be searched, retrieved, changed, and sorted using software."

2. "Database Field Structure"

Defendant proposes this construction: "the structure of database fields, i.e. relations and the attributes or fields that define the columns the relations contain." Plaintiff proposes: "the grouping and organization of database fields."

To understand defendant's proposed construction, it is necessary to define some of the terms defendant uses. According to one authority, a "relation" is "a two-dimensional table in which data are arranged." Hector Garcia-Molina, et al., Database Systems — The Complete Book 61-62 (2002) (relevant page found in Exh. B to Deft's Op. Brief). An "attribute" is a name describing the meaning of an entry in a column of a relation. Id. at p. 62 (showing diagram of two-dimensional table with headings for four columns and noting that the "attribute describes the meaning of entries in the column below."). In the context of the patents in suit, an attribute in a two-dimensional table could be something like "first name," or "street address" or "user identification."

A "field" is the portion of the database that stores a data value for a particular attribute. See Pltf's Initial Cl. Constr. Brief at pp. 9-10. Another definition for field is "a space reserved for a specified piece of information in a data record." Bryan Pfaffenberger, Ph.D., Que's Computer Internet Dictionary 133 (6th ed. 1995) (relevant page found in Exh. B. to Deft's Op. Cl. Constr. Brief). In this sense, a "field" refers to the location in the database in which a particular type of data is stored. See Pltf's Exh. 1 to Sept. 9, 2004 Oral Arg. at p. 4 (Claim Construction Statement showing construction of "field" as "a location in a record in which a particular type of data is stored. For example, EMPLOYEE-RECORD might contain fields to store Last-Name, First-Name, etc.").

With these definitions, defendant's proposed construction can be read as: "the structure of database fields, i.e., tables and the attributes or spaces that define the columns the tables contain." One of the problems with defendant's proposed construction is its reliance on technical terms to define the claim phrase "database field structure." Defendant's proposal requires several additional definitions or interpretations to be understood, unnecessarily complicating the claim construction.

The more fundamental problem, however, is that once the technical terms used by defendant are defined, it is obvious that defendant's proposed construction limits the database field structure to a structure based on tables. As explained above, the patent's preferred embodiment of "database" may be tables, but it is error to so limit it.

The meaning of "database field structure" is not apparent from the claims themselves. To the extent the claims themselves give some definition to the term, it is limited to the modifying phrase immediately following "database field structure" which reads "defined by multiple database fields[.]" Thus, the claims disclose only that the "database field structure," whatever it is, must have "multiple database fields." Defendant represents that there is no mention in any part of the specification of "database field structure." Plaintiff does not dispute this representation and my independent review of the specification has revealed no reference to the exact term. The only relevant specification reference I found was to the following similar phrase: "As described in more detail below, information about the applicants is maintained as a set of attributes, each attribute corresponding to database fields." 7:29-31.

Given the lack of information in the claims themselves and in the specification, defendant relies on testimony from its expert Jeffrey Ullman, Ph.D., who explains that although "database field structure" is not a term that would be readily recognized by one of ordinary skill in the art of database systems, such a person would understand the phrase to refer to a "specification of the fields used in some single relation or file of records." Aug. 15, 2004 Ullman Declr. at ¶ 7. By referring to "relation," Ullman's explanation, which provides the foundation for defendant's proposed construction, inappropriately restricts the definition of "database field structure" to tables.

Consequently, I recommend that the phrase "database field structure" be interpreted to mean "the grouping and organization of database fields" with the understanding that "database field" refers to "the space reserved in the database for storage of a particular type of data."

3. "Defined by Multiple Database Fields"

Defendant proposes that this phrase be interpreted as "a set of attributes of a single relation intended to hold information about the applicants or users, as the case may be." As indicated above, the phrase "defined by multiple database fields," modifies it predecessor phrase "database field structure." Defendant construes "database fields" as the attributes of a single two-dimensional table. Based on this reasoning, defendant contends that one skilled in the art would understand the phrase "defined by multiple database fields" to refer to the structure or schema of a table and not to the structure or schema of the database itself. Defendant uses "applicants or users" because claims 1 and 32 refer to the storage of application information and claim 12 refers to the storage of user information.

As noted above, while the specification reveals the use of a table-based database, it does not limit the type of database to one using a single table or multiple tables. As seen in plaintiff's September 9, 2004 oral argument presentation, there are several different database structures familiar to those skilled in the art. Pltf's Exh. 2 to Sept. 9, 2004 Or. Arg. at pp. 21-23. The patent claim language and specification disclose an invention which may employ any number of database structures to satisfy the "storing" claim limitation.

Defendant's proposal would limit the claim language to the preferred embodiment which describes the use of a three-column database structure headed by fields for "user identification," "attribute identification," and "data value." Id. at p. 24;see also Pltf's Exh. 5 to Oct. 6, 2004 Or. Arg. at pp. 9, 15 (showing preferred embodiment as single two-dimensional table with columns for "applicant identifier," "characteristic identifier," and "value"). For the reasons discussed above, a construction limiting the term to the preferred embodiment is unduly narrow and is contradicted by the specification's express disclosure that a table-based database is not the only method of storing user information data.

Thus, I recommend construing "defined by multiple database fields" as "multiple spaces for the storage of multiple types of data." Accordingly, the entire claim phrase "database field structure defined by multiple database fields" would mean "the grouping and organization of multiple spaces in the database reserved for the storage of particular types of data."

4. "Multiple Records and Each Record Capable of Storing Information Corresponding to Each of the Database Fields"

Defendant argues that "multiple records" means "the rows of a single relation" and that "record" in the phrase "each record capable of storing information corresponding to each of the database fields," means "a complete unit of related data items stored in named data fields." Defendant's proposals are based on the following definition of "record":

In a database management program, a complete unit of related data items stored in named data fields. In a database, data record is synonymous with row.

A data record contains all the information related to the item the database is tracking. Most programs display data records in two ways: as data-entry forms and as data tables. In a table-oriented relational database management system, the data records are displayed as horizontal rows and each data field is a column.

Que's Computer Internet Dictionary 124 (found in Exh. B to Deft's Op. Brief).

While it may not be readily apparent from defendant's proposed construction of "record," the underpinning of defendant's interpretation is that a "record" is limited to one "row" of a single two-dimensional table. Thus, "multiple records" means multiple rows of such a table.

In contrast, plaintiff construes "record" as a "collection of related data treated as a unit." Plaintiff explains that in the context of online admissions applications, a record might consist of all the data for a particular applicant's application such as name, address, high school attended, etc. Plaintiff contends that this application data may be organized in several different ways in a database with each carrying a different concept of "record":

(1) as multiple tables, with different tables storing different parts of the data, all tables being linked together by the applicant's identification number or some other linking principle. In that case, the "record" is the collection of linked data. See Pltf's Exh. 5 to Oct. 6, 2004 Or. Arg. at p. 11.

(2) all data for a single applicant are stored in a single row of a single table. In that case, the "record" is the data on that row. Id. at p. 7.

(3) as multiple rows of a single table, in which case the rows, together, would constitute the "record." Id. at pp. 9, 15.

(4) stored as a related set of XML data, in which case a record is the set of values that are linked to a "document."

Because, plaintiff's argument goes, some of the various database structures contemplated by the patent carry a meaning of "record" that encompasses more than one "row," or, in the case of XML data, no "row" at all, defendant's proposed construction of "multiple records," which is premised on its definition of "record" as a single row of a two-dimensional table, must be rejected. And, plaintiff continues, its proposal is superior because it captures all of the possible concepts of "record" suggested by the various database structures plaintiff describes.

Plaintiff contends that its invention encompasses all of the database structures it describes and that its construction of "record" is broad enough to take on different meanings of "record" in different steps of the claims. For example, in a multiple table model, id. at p. 11, or a model expressed by the preferred embodiment where there is one table with three columns and each row contains a user identification, an attribute identifier, and a value, the "record," according to plaintiff, is a collection of all of the rows containing information about a single applicant. Because each row in the multiple table model or in the three-column structure described in the preferred embodiment contains information about one of the applicant's attributes, the "record" should be thought of as all of those rows put together.

In support of this concept, plaintiff cites to a particular part of the specification. In describing a "User Attribute Sent Table," the specification refers to the previously described "User Attribute Table," which stores the values assigned to attributes for individual applicants. 9:45-46. The "User Attribute Table" is configured, in the preferred embodiment, as a single table with three columns, one for user identification, one for attribute identification number, and one for data value.⁴ 9:45-48. Each row of the table contains the information related to one attribute for one applicant.

4 The preferred embodiment actually discloses four columns with the additional column for attribute identification number sequence which would be used to assign a relative sequence to the attributes. Because the visual aides shown by the parties omit that fourth column, I do not use it here.

The "User Attribute Sent Table," rather than storing the user information by attribute, stores the information contained in a completed application as a "snapshot of the completed application." 10:1-5. The specification further provides that:

[t]he structure of the User Attribute Sent Table is very similar to that of the User Attribute Table. The primary key of the User Attribute Table is a user identifier (the users log-on name), whereas the primary key of the User Attribute Sent Table is a Transaction Identifier, which identifies a unique combination of user, application, and application terms. Thus, there can be multiple records for a single user in the User Attribute Sent Table if the user has submitted multiple applications or the same application for different application terms.

10:5-14 (emphasis added). I understand plaintiff's argument to be that (1) this description of the "User Attribute Sent Table" suggests that multiple records equates with multiple applications; (2) one application contains more than one attribute; (3) the structure of the User Attribute Table requires multiple rows for multiple attributes; (4) the User Attribute Sent Table, because it is the same or similar to the User Attribute Table, would also store its attributes on multiple rows of the table; and (5) therefore, the User Attribute Table's reference to "multiple records" implies that "record" consists of the collection of information from several rows related to one applicant.

I disagree with plaintiff that this portion of the specification supports its construction of "record" as all of the information related to one applicant. Rather, although the specification indicates that the User Attribute Sent Table uses a similar structure to that described in connection with the User Attribute Table, meaning a single two-dimensional table with columns and rows, it does not suggest that each "record" comprises multiple rows of information related to one applicant. In the User Attribute Sent Table, it appears possible that a "record" is a single row. Given that the User Attribute Sent Table apparently stores user information as it appears in a single application, each row could include just the transaction identifier and all of the information contained in one application. Thus, one row is one completed application containing all of the user attributes sent. As such, there would be "multiple records" for "multiple applications" with "record" referring to one "row." Thus, the quoted portion of the specification does not confirm that the proper interpretation of "record" in the context of the storing step, means all of the information from all rows relating to one applicant.

The other problem with plaintiff's argument is that to satisfy additional claim limitations, plaintiff must offer a different interpretation of "record." This is contrary to claim construction standards which ordinarily require the same term in a claim to be interpreted consistently. Omega Engineering, 334 F.3d at 1334.

The automatically storing step provides, in relevant part, that the invention

automatically stor[es] the applicant information entered into the second form data fields into the database by adding new records to the database, the automatic storing of the applicant information not altering the database field structure . . .

23:5-9; see also 25:16-10; 26:25-29. Because this step addresses an applicant's second application, the applicant already has user information stored in the database. If "record" is defined as all of the information pertaining to one applicant, it does not fit within this claim step because the invention would not be adding a "new record" for the applicant. An old record, e.g. all of the information pertaining to one applicant, already exists. The only interpretation of "record" that satisfies this claim limitation is one that considers "record" to be a single "row," at least in the table-based data storage model.

Given this problem, plaintiff argued at the October 6, 2004 oral argument, that "record" must be interpreted in two different ways in claim 1 of the '278 patent. It must initially be considered as all of the information pertaining to one applicant for the first storing step, but then only as a single row for the automatically storing step. I recognize that plaintiff's proposed construction for "record" is broad enough to encompass both meanings because different groupings of "related data" can each be thought of as a "unit," but I cannot accept that even within the preferred embodiment's three-column two dimensional table, plaintiff must rely on two different meanings of the term "record." I conclude that this is inherently inconsistent with basic precepts of claim construction law.

On the other hand, defendant's premise that a "record" is a single row works with all steps of the preferred embodiment, as well as with a structure using multiple tables, and with XML. With the preferred embodiment, a "record," when considered a "row," is consistent with the use of "record" in both the first storing step as well as the automatic storing step which refers to the information from the second application.

In the storing step, the database includes "multiple records, each record capable of storing information corresponding to each of the database fields." In the three-column table expressed by the preferred embodiment, there are multiple rows, and thus, multiple records, and each row is capable of storing information corresponding to each of the database fields.

In the automatic storing step, the invention stores the applicant information entered in the second application's data fields in the database by adding new records to the database. With record meaning row, this limitation is easily satisfied by adding new rows to the database. This makes sense in that in the preferred embodiment, each attribute receives its own row in the three-column structure. With the first application storage of information expressed in the storage step, the applicant will have several rows stored in a table (again, this is in the context of the preferred embodiment), each row corresponding to a particular attribute. With record meaning row, the new attributes from the second application, e.g. the attributes not part of the first application, will be stored as a new record, that is, a new row.

Because defendant's proposal for "multiple records" ("the rows of a single relation") implies that a record is a row in the context of a table-based database structure, and such a construction is consistent with the use of "record" in the storing claim limitation as well as the use of the "record" in the automatic storing claim limitation, in the context of the preferred embodiment, I recommend concluding that in the preferred embodiment, record should be understood as a single row in the table.

I reject, however, defendant's actual proposal for "multiple records" as "the rows of a single relation" because, again, this proposal restricts the term to the two-dimensional table expressed in the preferred embodiment which is inconsistent with the specification and claim construction standards. Rather, I recommend construing "record" to be "a collection of related data items stored in named data fields" and "multiple records" to mean "multiple collections of related data items stored in named data fields." In the preferred embodiment, this construction includes the understanding that one record is one row. In other embodiments, however, the restriction of record to one row may not be workable. For example, with XML, there is no traditional "row."

As seen in plaintiff's hearing exhibits, there are data items and data fields in a database structure using XML. Pltf's Exh. 5 to Oct. 6, 2004 Or. Arg. at p. 14. The data fields are any of the spaces where information will be stored, such as the spaces between the symbols or the space between the symbols.Id. The data items are, for example "username" and "872."Id. A collection of related data items stored in named data fields could be "username" and "872." That would comprise the record in the XML system.

This understanding meets both the storing and automatically storing claim limitations. Each record is capable of storing information related to each of the database fields and a new record is added to the database from the second form data fields. Accordingly, I recommend that "record" be construed as "a collection of related data items stored in named data fields."

5. "Data Element"

Dependent claim 11 of the '278 patent provides for

[t]he method of claim 1 in which storing the posted applicant information in a database having a database field structure defined by multiple database fields includes parsing the applicant information . . . into data elements, the data elements being separately stored and identified, thereby allowing the data elements to be separately retrieved and rearranged in subsequent applications.

23:66-67-24:1-5. Defendant proposes the following construction of "data element": "the smallest, indivisible unit of data stored in the database, which in the context of a relation, is a single component of a row, corresponding to a particular attribute."

Defendant contends that based on the specification, "data element" should be understood to refer to the smallest, indivisible unit of data stored in the database. The specification notes that "[t]o avoid having applicants enter data more than once to accommodate changes in format, the information is preferably stored in simpler data elements, and then combined during second stage validation into the format requested by the institution." 15:36-40. Additionally, each "data element" maps to a unique attribute having "a unique identifier or alias." 7:39-49. Defendant argues that in the field of database design, one would understand a "data element" to mean a single component of a row, corresponding to a particular attribute.

Plaintiff proposes the following construction: "the smallest unit of data defined for use by a system. By way of example, a form may provide a single field for `full name,' which can be defined to contain the data elements `first name,' `middle name,' and `last name.'" I recommend the adoption of plaintiff's proposal. Defendant's proposal expresses the construction in the context of the preferred embodiment two-dimensional table. Plaintiff's proposal is more easily adapted to other database structures.

6. "By Adding New Records to the Database Without Altering the Database Field Structure"

As stated above, this is part of the "automatic storing" function related to information obtained from the second application, seen in independent claims 1, 21, and 32 of the '278 patent. 23:5-9; 25:16-20; 26:25-29. Defendant proposes that this claim language be construed to mean "the addition of new records, or rows, to a relation does not alter the structure or schema of the relation."

I recommend that this claim phrase not be further construed. First, defendant again ties its proposal to a two-dimensional database structure. For the reasons previously explained, this is inappropriate. Second, I have already construed the individual terms "record," "database," and "database field structure." The only additional words are "adding," "new," "without," and "altering," none of which are used in any sense but their ordinary, customary meaning. Accordingly, there is no need to further construe this phrase.

7. "Extensible"

Defendant also proposes to construe the word extensible which appears at the end of the "automatic storing" function. The entire claim phrase reads:

automatically storing the applicant information entered into the second form data fields into the database by adding new records to the database, the automatic storing of the applicant information not altering the database field structure, thereby allowing new form data fields corresponding to applicant information not previously requested to be added to an application form without requiring alterations of existing application forms or of programs that access the database, whereby customized applications to different institutions share data through common, extensible data storage.

23:5-14; see also 25:16-23; 26:25-33.

Defendant proposes that "extensible" be construed as having the ordinary and customary meaning of "capable of being extended." Defendant contends this is supported by the specification. 7:31-37 ("If an institution chooses to include in its application a request for an applicant attribute that does not correspond to one included in the database, the database is easily extended to include the new applicant attributes without reprogramming the forms engine."). Defendant contends that construction is necessary, despite the term possessing its ordinary and customary meaning, to make clear that the term does not refer to a technical meaning of "extensible" in the field of database design. As defendant explains, at least one technical Internet dictionary refers to an "extensible database" as a database management system that allows access to data from remote sources as if the remote data were part of that database. Deft's Op. Cl. Constr. Brief at p. 17 n. 11 (citing to www.hyperdictionary.com).

I agree with defendant. As explained above, ordinarily, when a claim term is used only in its common, customary sense with no particular technical or scientific meaning, it is not necessary to construe the claim. However, here, to prevent the jury from mistakenly assuming, or the parties arguing, that in this context "extensible" refers to a technical concept in the field of database structuring, it is necessary to construe the claim. I recommend adopting defendant's construction.

C. No Rewriting of Code Function

The function at issue here is found in claims 1, 21, and 32 of the '278 patent. The relevant language is as follows:

automatically storing the applicant information entered into the second form data fields into the database by adding new records to the database, the automatic storing of the applicant information not altering the database field structure, thereby allowing new form data fields corresponding to applicant information not previously requested to be added to an application form without requiring alterations of existing application forms or of programs that access the database, whereby customized applications to different institutions share data through common, extensible data storage.

23:5-14 (claim 1) (emphasis added); see also 25:20-23 (similar language in claim 21); 26:25-33 (similar language in claim 32).

Also relevant to this function is language from dependent claim 2 of the '278 patent:

The method of claim 1 in which creating a first application form customized in accordance with the preferences of the first institution includes generating a first application in accordance with stored application description information and in which a modified first application can be generated by modifying the application description information without rewriting the computer program that creates the first application.

23:15-22 (emphasis added). Additionally, language from dependent claim 34 is relevant:

The method of claim 32 in which providing a database for storing information includes providing a database that is extensible without reprogramming the program for generating the customized application, thereby allowing an institution to readily request and store new information previously stored.

26:38-43 (emphasis added).

Defendant proposes constructions for the following terms appearing in these claims: (1) "alterations"; (2) "without requiring alterations of existing application forms or programs that access the database"; (3) "without rewriting the computer program that creates the first application"; and (4) "without reprogramming the program for generating the customized application[.]"

1. "Alterations"

Defendant proposes that "alterations" be construed as "making different in some particular, as in size, style, course, or the like; modification." Defendant bases this construction on the definition of "alter" from Webster's Encyclopedic Unabridged Dictionary of the English Language 43 (1994). Plaintiff argues that the term "alterations" is used in its plain, ordinary meaning and needs no construction. I agree with plaintiff.

2. "Without Requiring Alterations of Existing Application Forms or of Programs that Access the Database"

Defendant seeks separate constructions for "without requiring alterations of existing applications" and "without requiring alterations of . . . programs that access the database." As to the former, defendant proposes the following construction: "no programs for creating forms have to be rewritten, revised or reprogrammed and no forms have to be recreated or regenerated from rewritten or revised programs in order to add new form data fields to a form." For the latter, defendant proposes the following construction: "no program such as the forms engine that sends and retrieves user data to and from a database needs to be rewritten or reprogrammed in order to add new form data fields to a form."

I agree with defendant that the prosecution history shows that the patent applicants distinguished their invention from the prior art by describing a system with a "flexible forms engine that can be readily extended to handle new data fields without reprogramming the database or recreating existing forms." Exh. A to Deft's Op. Cl. Constr. Brief. Based on the distinction, the '278 patent disclosed an invention in which existing forms do not have to be altered because the forms themselves are not "hard-coded" programs that have to be rewritten. See 1:30-34 (noting that in prior incarnations of internet application forms, "if the institution wishes to change the application form, the institution must typically revise the source code that creates the application form, thereby making changes to the application form expensive and inconvenient.").

The problem with defendant's proposals, however, is that I see no reason not to apply my previous construction of the phrase at issue. In the ApplyYourself case, I construed the following phrase: "thereby allowing new form data fields corresponding to applicant information not previously requested to be added to an application form without requiring alterations of existing application forms or of programs that access the database[.]" The construction I gave the phrase was: "[n]ew form data fields corresponding to application information not previously requested could be added to an application form without altering existing application forms or programs that access the database." I also separately construed the limited phrase "programs that access the database," as "the computer software programs that retrieve user data from the database and send user data to the database." Dec. 19, 2002 Op. at pp. 34-35.

The previous constructions make clear that existing application forms and programs that access the database are not altered when new form data fields are added to the application form. This construction addresses the distinction made over the prior art in the prosecution history. Furthermore, defendant's proposed construction is cumbersome and unnecessarily wordy. The claim language itself is fairly straightforward and the prior constructions adequately define the claim limitations.

3. "Without Rewriting the Computer Program That Creates the First Application"

This claim phrase is taken from dependent claim 2 of the '278 patent, quoted above. Defendant proposes the following construction: "the code for the forms engine program does not have to be rewritten or reprogrammed because one has only to change the application description information that the forms engine uses to generate the application form."

Defendant cites to the specification of the '278 patent in support of its argument that "the computer program that creates the first application" is the forms engine program described elsewhere. The relevant excerpt is:

[t]he applicant database can be extended to include new attributes without making any changes to the forms engine program or to the application files of institutions that chose not to include the new data. The forms engine automatically uses the application data file to produce the requested application in HTML format for display on the applicant's browser. The application description file can be easily modified, for example, to change labels or to add additional fields. The appearance of the application for each institution can be changed by changing its application description file, without reprogramming the forms engine.

8:60-67-9:1-3.

Plaintiff contends that the phrase "without rewriting the computer program that creates the first application" need not be construed because it is not imbued with any scientific or technical meaning and all of the words in the phrase are used in their plain, ordinary, everyday sense. Plaintiff also disputes that aspect of defendant's construction that essentially equates the "computer program" with the "forms engine program."

Plaintiff contends that defendant inappropriately imports language from the specification into the proposed claim construction to create a limitation not seen in the claim language itself. Liebel-Flarsheim Co. v. Medrad, Inc., 358 F.3d 898, 904 (Fed. Cir. 2004) (noting impropriety of reading a limitation from the specification into the claims). Reference to the specification is not an improper claim construction tool, because it is permissible to read the claims in light of the specification. Id. Thus, to the extent the specification is used as a way to confirm the apparent meaning of the claim language, the use of the specification is acceptable. Here, the use of the specification only confirms the claim language's obvious meaning that "computer program" means the forms engine program.

I start with the language of claim 2 of the '278 patent, quoted in its entirety:

The method of claim 1 in which creating a first application form customized in accordance with the preferences of the first institution includes generating a first application in accordance with stored application description information and in which a modified first application can be generated by modifying the application description information without rewriting the computer program that creates the first application.

23:16-23. The "computer program that creates the first application" clearly refers to the first part of this claim which describes the creation of the first application form which has been customized in accordance with the preferences of the first institution. This in turn refers to a method expressed in claim 1.

In claim 1, the language provides that the method allows for the creation of, in response to a request from an applicant for an application to a first institution, a first application form customized in accordance with the preferences of the first institution. 22:37-40.

Because claim 1 discloses no further information regarding what part of the system actually creates the application to a first institution, it is necessary to examine claim 21 which describes the system used for creating and processing the forms previously disclosed in independent claim 1 and subsequent dependent claims. Claim 21 discloses a system which relies on a "forms engine program" to generate a form from the form description information. Read together, claims 21, 1, and 2 provide for the creation, by a forms engine program, of a first application form customized in accordance with the preferences of the first institution. Thus, the claim language itself supports equating the meaning of "computer program" with "forms engine program."

Accordingly, while I conclude that the remaining words in this phrase do not need construction because the words "without," "rewriting," and "the first application" are used only in their non-technical ordinary sense, I agree with defendant that "computer program" should be construed to mean forms engine program. I recognize that recommending a construction that incorporates another construed term will require the cross-referencing which I described above as unnecessarily complicating a construction. However, in this instance, the construction which relies on "forms engine program" is required because unlike the other constructions discussed above, the jury could easily apply the wrong meaning to the disputed phrase in this instance. Therefore, I recommend that the phrase "without rewriting the computer program that creates the first application" be construed as "without rewriting the forms engine program that creates the first application."

4. "Without Reprogramming the Program for Generating the Customized Application"

This claim phrase is taken from dependent claim 34 of the '278 patent, quoted above. Defendant proposes the same construction for this phrase as for the previous phrase: "the code for the forms engine program does not have to be rewritten or reprogrammed because one has only to change the application description information that the forms engine uses to generate the application form."

As with the previous phrase, defendant contends that the "program for generating the customized application" must refer to the forms engine program. In addition to the plain meaning of the claim language, defendant notes that the specification of the '278 patent indicates that the database for storing user information can be extended to include new user attributes that do not correspond to ones already in the database and that this extension does not require reprogramming the forms engine program. 7:29-35; 8:60-67-9:1-3.

Claim 34 refers to the method of claim 32 which in turn, discloses a method which includes generating a customized application. Claim 34, however, does not itself disclose what actually generates that customized form. Again, it is necessary to examine claim 21 for that information. As discussed above, claim 21 discloses that the function is performed by the forms engine program. Thus, I agree with defendant that the reference to "the program for generating the customized application" in claim 34 refers to the forms engine program. This is confirmed by the specification as indicated in the previous paragraph.

I recommend that the phrase "without reprogramming the program for generating the customized application" be construed to mean "without reprogramming the forms engine program for generating the customized application."

D. Forms Processing Function

This function is expressed by the following language in claim 1 of the '042 patent:

processing by the third party forms servicer the user information in accordance with the preferences of the institution of higher education to which the form is directed to make the user information available to the institution in a format specified by the institution, the third party forms servicer thereby providing to public users customized forms identified with institution[s] of higher education and providing to the institutions custom-formatted data, while relieving the institution of the administrative burden of processing forms and payments.

35:34-44; see also 36:49-57 (nearly identical language in claim 16); 38:1-9 (nearly identical language in claim 32).

In addition, in the preamble to claim 1, the patent states:

A method of processing over a computer network forms directed by multiple public forms users to multiple institutions of higher education, the forms being processed by a third party forms servicer that is neither one of the institutions of higher education nor one of the public forms users, . . .

35:2-6. This language is more or less repeated in the preambles to the other independent claims of the '042 patent. 36:32-36 (claim 16); 37:46-50 (claim 32); 38:38-42 (claim 38).

Defendant proposes constructions for the following terms: (1) processing; (2) providing; (3) by the third party forms servicer; and (4) in a format specified by the institution.

One of the most contentious issues in the ApplyYourself case was the construction of the first part of the language quoted above from claim 1:

processing by a third party forms servicer the user information in accordance with the preferences of the institution of higher education to which the form is directed to make the information available to the institution in a format specified by the institution.

I first construed this in the July 2003 summary judgment opinion, then in a subsequent August 20, 2003 Order on plaintiff's motion for reconsideration, and then again during trial in a September 3, 2003 Opinion. I finally instructed the jury that the entire phrase was to be construed as follows:

User information provided to the institution by the servicer is available in an unlimited number of formats and is processed wholly by the third party forms servicer and not the institution. That is, the function is one of providing limitless formats for the transfer of user information from the servicer to the institution with no additional formatting or mapping performed by the institution.

This construction does not preclude formatting, mapping, or other manipulation of the user information data by the institution once it is received by the institution in a format the institution specified.

Any reference to "unlimited number of formats" and "limitless formats" should be interpreted to mean that the third party forms servicer provides the user information to the institution in any format specified by the institution.

"in a format specified by the institution" means in any file format, and it may include any other type of format, specified by the institution.

Final Jury Instructions at p. 14 (dkt #323). This claim construction is one of several issues from the ApplyYourself case currently on appeal before the Federal Circuit. Keeping this prior construction in mind, I turn to defendant's proposals.

1. "Processing"

Defendant first contends that references to "processing" in the preambles to the independent claims to "processing over a computer network forms directed by . . ." and "the forms being processed by a third party forms servicer" should be construed to mean processing of the user information captured by a form rather than the form itself. I agree that the plain language of the claims supports this interpretation.

Defendant next argues that as to processing user information, the term "process" should mean "to subject to a special process or treatment (as in the course of manufacture)." Then, defendant continues, because the claim language refers to processing the user information to make it available in a format specified by the institution, the construction of "processing" must include a reference to making the information available in a format specified by the institution.

Thus, defendant argues that as it relates to forms, "processing" includes the step of "subjecting the user information to a special process or treatment so as to make it available to an institution in a format specified by the institution."

I reject this proposal. Defendant's proposed construction invites confusion by referring to "special process or treatment" because such terms would themselves likely require additional construction. Furthermore, I do not agree that the verb "processing" must be construed by incorporating the phrase "making it available to an institution in a format specified by the institution." That limitation is obvious from the claim language itself. While that may be the end result of the action of "processing," it is not required as part of the construction of "processing."

I have already construed the term "processing" in the context of the electronic payment function. I see no need to adopt a different construction here in the context of processing user information. Nothing in the claim language or specification indicates that the term carries different meanings in the two separate functions. Moreover, as noted above, ordinarily the same term in a claim is to be interpreted consistently. Omega Engineering, 334 F.3d at 1334. Thus, I propose that "process" or "processing" in the context of forms processing, be construed as "the manipulation of data within a computer system."

2. "Providing"

Defendant suggests that the term "providing" in independent claims 16, 32, and 38 of the '042 patent implies the "processing" function expressly claimed in claim 1 because these other independent claims call for the user information to be provided by the third party forms servicer to the institution in a format specified by the institution. Defendant states that the ordinary definition of provide, from Merriam Webster's Collegiate Dictionary 940 (10th ed. 1994), means "to supply or make available." Defendant contends that this definition is consistent with the language of claim 1, stating that the processing step, which defendant argues is implied by "providing" in the other independent claims, is intended to "make the user information available to the institution in a format specified by the institution." Thus, defendant proposes that as it relates touser information, "providing" means "to make available."

Plaintiff contends that because "provide" is used only in its everyday, ordinary sense with no technical meaning having been ascribed to it, no construction is required. I agree with plaintiff.

3. "By the Third Party Forms Servicer"

The claims require the "processing" to be performed by the "third party forms servicer." The preamble for each claim recites that the "third party forms servicer" is "neither one of the multiple institutions nor one of the public form users[.]" 35:5-6; 36:36-37; 37:49-50; 38:41-42.

Defendant argues that I must construe "third party forms servicer" consistently throughout each claim because "the same word appearing in the same claim should be interpreted consistently." Digital Biometrics, 149 F.3d at 1345. Accordingly, defendant proposes that I adopt the same construction for "third party forms servicer," whether it be in the context of processing forms or payments. In defendant's opinion, as discussed above, the third party forms servicer which processes electronic payments is limited to the business entity hosting the forms engine software. Thus, according to defendant, the third party forms servicer which processes forms must also be limited to that same business entity hosting the forms engine software.

I do not dispute defendant's premise that the same word appearing in the same claim should be interpreted consistently. I believe that I have done that by referring to the "third party forms servicer" as the business entity hosting the forms engine software in both the electronic payment context and in the forms processing context. My construction of "third party forms servicer" as that entity remains constant throughout the claim.

What is different, however, is that the function of electronic payment processing inherently requires the participation of an outside entity in the process. As explained above, at a minimum, financial institutions play a role in the processing function. Thus, while "third party forms servicer" means the business entity hosting the forms engine software, the function of processing of electronic payment information requires the participation of the third party forms servicer while contemplating the participation of an additional party.

The forms processing function does not present the same issue. There is no reason why the third party forms servicer cannot be the exclusive processor of user information. Accordingly, the third party forms servicer, when it comes to processing user information, is the sole entity involved in the process.

Thus, I recommend that the term "third party forms servicer" be construed to mean "the business entity hosting the forms engine software" no matter which function (electronic payment or forms processing) is being considered. However, I further recommend, as discussed above, that the processing of electronic payments not be limited to that entity while the processing of user information should be limited to that entity. Additionally, as before, the institution and the user/applicant are not involved in either function.

4. "Format" and "In a Format Specified by the Institution"

Given plaintiff's appeal of the prior claim construction of these phrases in the ApplyYourself case, plaintiff requests I defer claim construction of these phrases in this case pending the resolution of that appeal by the Federal Circuit. Acceding to plaintiff's request could unnecessarily prolong the length of this case. The case schedule for this case has, hopefully, allowed time for a decision from the Federal Circuit before trial. There is no need to defer consideration of the construction here.

Defendant states that it does not take issue with my prior construction. But, in the briefing, defendant appears to suggest that I add additional language. Defendant states that the forms processing steps, including the final step of processing the user information to make it available to an institution in a format specified by the institution, "must be construed as leaving nothing that the institution would have to do by way of processing before it can make use of the user information."

I reject the proposed construction because I think it adds nothing to the previous construction and simply uses different words to express the same meaning. When the claim limitation as I have construed it, is met, there is, by definition, nothing that the institution must do by way of processing before it can make use of the user information. That is the whole point of providing it in any format requested by the institution. The prior construction gives a more complete explanation of the concepts expressed by the claim limitation, including the concept of the institution not having to do anything related to processing, while allowing for the institution to choose to retain parts of the processing function if it desires to do so.

E. No Administrative Burden Function

Independent claims 1, 16, 32, and 38 of the '042 patent refer to "relieving the institution of the administrative burden of processing forms and payments." 35:42-44; 36:55-57; 38:7-9; 38:60-61. Defendant proposes constructions for: (1) "relieving"; (2) "administrative burden"; and (3) the entire phrase "while relieving the institution of the administrative burden of processing forms and payments."

1. "Relieving"

Defendant argues that the addition of the "relieving" clause, read in the context of the claims limitations, creates a limitation on the nature and extent of the processing that a third party forms servicer must do. Defendant contends that the third party forms servicer must provide processing sufficient toeliminate the need for the institution to engage in processing. Defendant accurately notes that I have previously recognized that the clause creates a limiting effect in the prior construction of the phrase "in a format specified by the institution." Sept. 3, 2003 Opinion at p. 9.

Citing Merriam Webster's Collegiate Dictionary 988 (10th ed 1994) (def. 1(a)), defendant argues that "relieving" means "to free from a burden." Based on this, and on defendant's contention that this ordinary meaning is consistent with the patent specification, defendant proposes to construe "relieving" as "freeing from a burden."

Plaintiff objects to the implication that "freeing" is synonymous with eliminating. Plaintiff cites the American Heritage Dictionary for the proposition that the ordinary meaning of "relieving" is to "lessen," not eliminate. Pltf's Resp. Brief at p. 30 (citing American Heritage Dictionary 1474 (4th ed. 2000) (defining "relieving" as: "To cause a lessening or alleviation of."). Plaintiff argues that while relieving can include eliminating or "freeing from a burden," relieving should not be limited to that meaning. Plaintiff cites to Texas Digital, 308 F.3d at 1202, for the proposition that "if more than one dictionary definition is consistent with the use of the words in the intrinsic record, the claim terms may be construed to encompass all such consistent meanings."

I conclude that defendant's proposal is more consistent with the interpretation of "in a format requested by the institution" than plaintiff's proposal. I start with the idea, as expressed in the September 2, 2003 Opinion in the ApplyYourself case, that the "thereby" clause containing the phrase "relieving the institution of the administrative burden of processing forms and payments," "acts as a summary of the function of the claim [limitation] and indicates that by providing the processed user information to the institution as custom-formatted data in a format specified by the institution, the claim will relieve the institution's burden of processing forms." Sept. 3, 2003 Op. at p. 9. I noted that the "thereby" clause was "critical to my construction" of the "in a format requested by the institution" claim phrase because "it is the relief of the burden of the institution that instruct[ed] my reading of the term `format.'"Id.

"Relieving," then, should properly be understood to mean the elimination of anything the institution must do to use the data. If there are limitations on the abilities of the third party forms servicer to provide limitless file formats and thus, a limit on its ability to provide the user information in a format specified by the institution, then the burden of processing the user information is not eliminated and thus, not relieved, because the institution then must do some processing to make use of the data.

While the institution may choose to do any level of "processing" whether electronic or physical, to the data received from the third party forms servicer, it cannot be required to do so by the inabilities of the third party forms servicer to provide the data in the format requested by the institution. The "relieving" claim term and the "in a format specified by the institution" claim phrase, are, in effect, two sides of the same coin. "Relieving," when read in the context of the claim construction for the entire "processing of user information" claim limitation, including the phrase "in a format specified by the institution," means eliminating.

This interpretation does not negate the part of the prior construction of the "processing of user information" limitation which provides that the construction "does not preclude formatting, mapping, or other manipulation of the user information data by the institution once it is received by the institution in a format the institution specified." The construction assumes that the burden on the institution of processing user information is eliminated once it receives the user information in a format it specified. The fact that the institution may choose to do additional formatting, mapping, or manipulation after that point does not suggest that the burden is not eliminated, or that by construing "relieving" as eliminating is inconsistent with this interpretation.

2. "Administrative Burden"

Defendant states that the term "administrative burden" requires no formal definition, but then it proposes the following construction: "the administrative tasks typically associated with the processing of forms such as admissions applications and any payments associated with the forms." I recommend that this term not be construed as it is used in its ordinary, customary fashion with no technical or scientific meaning revealed by the claims or the specification.

3. "While Relieving the Institution of the Administrative Burden of Processing Forms and Payments"

Based on its constructions for "relieving" and "administrative burden," defendant proposes the following construction for the entire phrase at issue:

the institution is freed from the administrative burden of processing the relevant forms and associated payments. With respect to the processing of forms, the institution must be able to receive the user or applicant information in whatever file and other format it has specified, such that no further formatting or mapping has to be done to the data. With respect to the processing of payments, the institution must be able to receive an electronic payment credited to its account and matched to the form with which the payment is associated so that the institution is freed from the administrative burden of handling any aspect of the payment process, from verification of credit card numbers to settlement to reconciliation.

Deft's Op. Brief at pp. A-3-A-4.

I recommend that this construction not be adopted. I conclude that given that the operative terms in the claim phrase have already been construed or need no construction, any additional construction is unnecessary.

G. Miscellaneous Terms

Defendant proposes constructions for two terms it refers to as "miscellaneous terms": (1) metadata; and (2) relational database.

1. "Metadata"

The term metadata appears in claims 19, 20, 36, and 37 of the '278 patent:

19. The method of claim 18 in which the metadata includes validation rules for the data.

20. The method of claim 18 in which the metadata specifies the sharing between applications or the accessibility of the data.

36. The method of claim 32 in which the database stores metadata describing the data.

37. The method of claim 36 in which the metadata describes permissible values for the data and further comprising comparing the applicant data in the completed form data fields with the permissible values.

24:47-51; 26-47-52.

Defendant cites to the following definition of "metadata" from the specification of the '278 patent: "Metadata, that is, information that characterizes the applicant data is also stored." 2:27-28. Defendant argues that metadata may describe various characteristics of the user attributes that are being stored in the database. Defendant contends that these characteristics include the properties of the fields and the relation in which the user data are arranged. Based on these arguments, defendant offers the following construction for "metadata": "information that describes user data including the properties of the fields and the relation in which user data are arranged."

Plaintiff takes issue with defendant's proposal. In contrast to defendant's proposal, plaintiff offers the following: "information that describes data." As plaintiff notes, the parties agree that metadata is information that describes data.

Plaintiff opposes defendant's inclusion of "user data." Plaintiff states that the limitation of "user data" is not in the claim. Plaintiff indicates that the specification makes clear that metadata can be used to describe parameters, such as validation criteria for data, rather than describing user data. Plaintiff cites to the following part of the specification:

Metadata, that is, information that characterizes the applicant data is also stored. For example, in one embodiment, an attribute table describes characteristics, such as permissible values and accessibility to various institution personnel, of applicant attribute data. In another embodiment, such properties of the applicant attributes are stored in XML files. Storing metadata provides greater control over the data validation, sharing between forms, grouping, and access.

2:30-37. Based on this reference, plaintiff argues that defendant's restriction to user data is inconsistent with the ordinary meaning and is contrary to the intrinsic evidence. Furthermore, plaintiff contends that defendant's proposal that the "user data" must also include "properties of the field" and "the relation in which user data are arranged," is not required.

I agree with plaintiff. As to "user data," even claim 19 itself seems to contradict defendant's proposal by stating that the "metadata includes validation rules for the data." Additionally, the specification reference cited by plaintiff suggests that while metadata indeed includes information characterizing the applicant data, the "characteristics" include "permissible values" and "accessibility to various institution personnel." These encompass more than "user data." Thus, "metadata" it is not restricted to "user data."

Another problem is defendant's references to "field" and "relation" which suggest that "metadata" is information about data as it exists in a two-dimensional table. For the reasons described above, this is inconsistent with the patent's specification and basic claim construction standards which caution against limiting a claim term to its preferred embodiment. Accordingly, I recommend that plaintiff's proposal for "metadata" be adopted.

2. "Relational Database"

The term appears in claims 17, 31, and 39 of the '278 patent:

17. The method of claim 1 in which the database includes a relational database or XML data.

31. The system of claim 21 in which the first or second data storage comprises one or more relational database tables stored on a computer readable medium.

39. The method of claim 32 in which the database includes a relational database.

24:43-44; 25:58-60; 26:56-57.

Defendant proposes the following construction for the term: "a database organization method that links files together as required." Plaintiff proposes the following construction: "a database that is organized in a manner than can link tables or records together as required."

Obviously, the two proposals are similar. Plaintiff argues that its alternative uses the terminology "tables or records" instead of "files" because that is grammatically consistent with the claim language and is more accepted in the industry. I agree with plaintiff and recommend that plaintiff's proposal be adopted.

H. Performance of Method Claims in Order Recited

Defendant argues that the method claims of both patents (independent claims 1 and 32 of the '278 patent and independent claims 1, 16, and 38 of the '042 patent), should be construed to require that the steps set forth be performed in the order in which they are recited. Plaintiff asserts that it would be technologically possible to achieve the purpose of the claims even if many of the claim steps were performed in a sequence different than that recited in the claims.

"Unless the steps of a method actually recite an order, the steps are not ordinarily construed to require one." Interactive Gift Express, Inc. v. Compuserve Inc., 256 F.3d 1323, 1342 (Fed. Cir. 2001). However, requiring the performance of the steps of a method in the order recited may "ensue when the method steps implicitly require that they be performed in the written order."Id.

A two-part test is used for "determining if the steps of a method claim that do not otherwise recite an order, must nonetheless be performed in the order in which they are written."Altiris, Inc. v. Symantec Corp., 318 F.3d 1363, 1369 (Fed. Cir. 2003). First, the court looks to the "claim language to determine if, as a matter of logic or grammar, they must be performed in the order written." Id. "If not, we next look to the rest of the specification to determine whether it directly or implicitly requires such a narrow construction." Id. at 1370 (internal quotation omitted). "If not, the sequence in which such steps are written is not a requirement." Id.

1. Claim 1 of the '278 Patent

This claim discloses the following steps, listed in the order they are recited in the claim:

(1) creating a first application form to a first institution in response to a request from an applicant, the form customized to the preferences of the first institution and including first form data fields for entering applicant information;

(2) presenting this first application form to the applicant over a computer network;

(3) entering applicant information in the first form data fields;

(4) posting the applicant information entered in the first form data fields to a server;

(5) storing the posted applicant information in a database (with more info about the database disclosed);

(6) creating a second application form to a second institution in response to a request from "the" applicant (as opposed to "a" applicant disclosed in the first step addressing the first application form), the form customized to the preferences of the first institution and including second form data fields for entering applicant information, at least one which corresponds to applicant information not entered into the first form data fields;

(7) automatically inserting into some of the second form data fields applicant information from the database;

(8) providing the second application form to the applicant over a computer network;

(9) entering applicant information into the second form data fields into which information was not inserted from the data storage or into which the data inserted from the data storage is to be changed;

(10) posting the applicant information entered into the second form data fields to the server; and

(11) automatically storing the applicant information entered into the second form data fields into the database.

I conclude that as a matter of logic, the steps of this claim implicitly require that they be performed in the written order. The invention cannot provide the first application to the applicant in step (2) without first creating the first application in step (1). The applicant cannot enter the applicant information in the first application form data fields in step (3), without having been provided the first application in step (2). The applicant information in the first form data fields cannot be posted to the server in step (4), unless it has been entered in step (3). The applicant information cannot be stored in the database in step (5), unless it has been posted in step (4).

A second application form disclosed in step (6) cannot be a "second" application form unless there has already been a "first" application form recited in steps (1)-(5). Additionally, the reference in step (6) is to "the" applicant, with the antecedent basis clearly being the applicant who has filled out the first application form data fields in steps (1)-(5). For the server to recognize "the" applicant, "the" applicant's information from the first form must have been stored in the database in step (5).

The next step (7) discusses the automatic populating of data stored in the database as a result of steps (1)-(5), into the data fields in the second application created in step (6). Thus, because the second application needs to be created in step (6) before this automatic populating of data into that second application form, and because the first application data has to have been stored in the database as a result of steps (1) through (5), then logically, steps (1) through (5) must occur before step (6) and (6) must occur before (7).

Step (7) must occur before step (8). The automatic population of the second form data fields must occur before the second form is provided to the applicant because if the second form data fields were not automatically populated before the applicant received the second form, one of the main purposes of the invention would be defeated, and because if the second form is provided to the applicant before the automatic population of the second form data fields, there appears to be no step to trigger the automatic insertion of this data. Accordingly, steps (1) through (8) must occur in sequence.

Next, step (8), which provides the second application form, must occur before step (9) which is where the applicant enters applicant information onto the second form. Then, step (9), entering the new applicant information into the second form, must occur before the posting of the entered applicant information to the server in step (10), and the posting in step (10) must occur before the information is stored in the database in step (11).

Thus, as for claim 1 of the '278 patent, I recommend concluding that the steps must be performed in the order recited.

2. Claim 32 of the '278 Patent

This claim discloses the following steps, listed in the order they are recited in the claim:

(1) providing at least two application information files, each describing a customized application for an institution;

(2) providing a database for storing applicant information entered on an application and for providing applicant information for inserting into subsequent applications;

(3) generating a customized application in response to a request over a computer network from an applicant, the application form and content being specified by one of the at least two application information files, the application including multiple form data fields for entering applicant information;

(4) populating the form data fields of the customized data fields of the customized application using applicant information from the database;

(5) transmitting the customized application over a computer network to a requesting applicant;

(6) completing form data fields of the application that were not populated with applicant information from the database; and

(7) automatically storing the applicant information from the database.

Here, I disagree with defendant that all of the steps in this claim must be performed in the order recited. I conclude that this method claim could start with either step (1), providing at least two application information files, or step (2), providing a database for storing applicant information. The claim language and specification suggest no reason why either one of these steps must precede the other.

However, the claim language makes clear that step (1), providing at least two application information files, must occur before step (3) which requires the generation of a customized application based on the specifics in one of the at least two application information files.

The claim language also makes clear that step (4), regarding populating the form data fields of the customized application with applicant information in the database, must occur after both steps (2) and (3). Step (4) requires the information contained in the database outlined in step (2) and it also requires the customized application recited in step (3).

For the reasons explained above in the context of steps (7) and (8) of claim 1 of the '278 patent, step (4), addressing the population of the data fields using applicant information in the database, must precede step (5) in which the customized application is transmitted to a requesting applicant.

Steps (1) through (5) must precede step (6) because step 6 requires the applicant to enter information into the data fields of the customized application that were not automatically populated with information stored in the database. And, step (7) must be preceded by step (6) because it requires storing the information that was entered in step (6).

Thus, I recommend concluding that while steps (1) and (2) must precede step (3) and steps (3) through (7) must occur in the order recited, step (1) and step (2) could be performed with either one preceding the other.

3. Claim 1 of the '042 Patent

This claim discloses the following steps, listed in the order they are recited in the claim:

(1) presenting to a form user over a computer network by a third party forms servicer in response to a request by the form user, a form directed to one of multiple institutions of higher education, the form being generated by a forms generator that generates multiple customized forms;

(2) entering user information onto the form;

(3) entering payment information;

(4) the third party forms servicer receiving user information and electronic payment information entered by the user;

(5) processing of an electronic payment by the third party forms servicer; and

(6) processing the user information by the third party forms servicer.

I recommend concluding that the claim language of this claim logically requires the steps to be performed in the sequence in which they are recited except that step (3) could be performed before or after step (2), and steps (5) and (6) could precede each other as long as they follow step (4).

4. Claim 16 of the '042 Patent

This claim discloses the following steps, listed in the order they are recited in the claim:

(1) presenting to a form user over a computer network by a third party forms servicer a form directed to one of the multiple institutions, the forms including fields for the forms user to enter information;

(2) receiving by the third party forms servicer over the computer network user information and electronic payment information entered by the user;

(3) processing by the third party forms servicer an electronic payment associated with the form;

(4) providing by the third party forms servicer the user information to the institution to which the form is directed in a format specified by the institution.

Here, step (1) has to precede step (2) because the presentation of the form to the user has to occur before the third party forms servicer can receive any user information or electronic payment information entered by the user. Because step (2) contains the receipt of both the user information and the electronic payment information, there is no way to separate those functions in this claim and it seems clear that the receipt of the information in step (2) must occur before the third party forms servicer can either process the electronic payment information as stated in step (3) or before it can provide the user information to the institution in step (4).

This, I recommend concluding that the steps in claim 16 must be performed in the order in which they are recited.

5. Claim 28 of the '042 Patent

This claim discloses the following steps, listed in the order they are recited in the claim:

(1) receiving by an institution from a third party forms servicer user information in format . . ., the user information being derived from a form customized for the institution, . . .;

(2) receiving from the form user via the third party form servicer an electronic payment associated with the customized form; and

(3) thereby providing to the form user a customized form identified with the institution and providing the institution with custom formatted data and electronic payment.

Clearly, steps (1) and (2) have to occur before step (3). However, step (1) does not necessarily need to precede step (2) as they both involve the institution receiving either user information or an electronic payment from or via the third party forms servicer. These could happen simultaneously for example.

While step (1) and step (2) must precede step (3), because (1) and (2) could occur simultaneously, I recommend concluding that the steps in claim 38 do not need to be performed in the order in which they are recited.

CONCLUSION

I recommend construing the claims as discussed in this Findings Recommendations and concluding that the steps in claim 1 of the '278 patent and the steps in claim 16 of the '042 patent must be performed in the order recited.

SCHEDULING ORDER

The above Findings and Recommendation will be referred to a United States District Judge for review. Objections, if any, are due November 19, 2004. If no objections are filed, review of the Findings and Recommendation will go under advisement on that date.

If objections are filed, a response to the objections is due December 3, 2004, and the review of the Findings and Recommendation will go under advisement on that date.

IT IS SO ORDERED.