Full opinion text
MEMORANDUM OF DECISION AND ORDER SPATT, District Judge. In this patent infringement case, the plaintiff Luciano F. Paone alleges that the defendant Microsoft Corporation (“Microsoft”) has infringed United States Patent 6,259,789 (“the '789 Patent”), which Paone holds. Pursuant to the Supreme Court’s decision in Markman v. Westview Instruments, Inc., 517 U.S. 370, 116 S.Ct. 1384, 134 L.Ed.2d 577 (1996), the Court now construes the disputed claim terms of the '789 Patent. I. BACKGROUND A. Background of the Invention The United States Patent and Trademark Office (“PTO”) issued the '789 Patent, entitled “Computer Implemented Secret Object Key Block Cipher Encryption and Digital Signature Device and Method”, to the plaintiff Luciano F. Paone on July 10, 2001. The '789 Patent describes a method of translating (or “encrypting”) ordinary data (called “plaintext”) into encoded data (called “ciphertext”), so that the plaintext may not be viewed by an unintended reader. In cryptography, which is the science of encryption, such a method is called a “cipher”. Generally, encrypted ciphertext is later decoded, or “decrypted”, into plaintext, so that the data is again usable. The cipher described in the '789 Patent is a computer based “symmetric key cipher.” By way of background, a very simple cipher (that is, method) used to encrypt a message sent in English might be to replace each letter in the plaintext with the character that directly follows that letter in the alphabet. Using that method, each “a” in the message would be replaced with a “b”, each “b” in the message would be replaced with a “c”, each “c” would be replaced with a “d”, and so forth. Each “z” would be replaced with an “a”. Using this cipher, the message “Hello there” becomes “Ifmmp uifsf.” A person who knows the method of encryption — -that is, who knows the cipher — can easily decode the message and read it. A cipher that uses a “symmetric key” requires the person encrypting and the person decrypting to know an additional piece of information to use the cipher. For example, we might have a cipher that calls for the replacement of each letter of plaintext with a character that follows that letter some number of letters later in the alphabet. This type of cipher establishes a pattern, but it doesn’t provide all of the information needed to encrypt or decrypt data. Here, the pattern is that each letter of the plaintext will be replaced a letter that appears a given number of characters later on in the alphabet. The key is how many letters later in the alphabet will be found each letter’s replacement. The following is an example of the operation of this cipher: Under this system, a person who knows just the cipher (that is, who knows that letters in the message will be replaced with characters appearing some number of letters later in the alphabet) cannot decrypt the ciphertext, because that person doesn’t know the key. But a person who knows both the cipher and the key can easily decode the message. Of course, this example is a very simple symmetric key cypher, and a person without knowledge of either the cipher or the key could probably guess an encoded message if given time. Thus, to defend against this, cryptologists use far more complicated methods of encryption. Moreover, with the advent of the computer, the ability — and the need — to encrypt with great sophistication has increased dramatically. In keeping with this trend, the '789 Patent focuses on computer-based encryption of data. Generally, when computers encrypt data, they do not directly encrypt English language text, as in the example above. Rather, text is first translated into a long stream of l’s and 0’s — each 1 or 0 being called a “bit”, and eight bits being called a “byte” — which can later be changed back into text. Other types of computer data, such as images or spreadsheets, are also translated into l’s and 0’s before encryption. Generally, the binary code (that is, the l’s and 0’s) that represents readable data is insecure before encryption, because any computer with the correct software could translate these bits back into the original text, image, or spreadsheet. Therefore, if a person wants to send or store sensitive data without fear of it being compromised, the stream of l’s and 0’s must be altered to prevent the files from being viewed by unintended readers. There are several ways to encrypt computer data, but the '789 Patent deals exclusively with “symmetric key” encryption of computer data, which as noted above, requires that the eneryptor and decryptor share knowledge of both a cipher and a key. Computer based symmetric key ciphers divide roughly into two types: block ciphers and stream ciphers. As the distinction between these two types of ciphers forms a major ground for dispute between the parties, the Court discusses this issue in much greater detail below. However, as a general matter, a stream cipher employs its key to encrypt data one bit at a time, while a block cipher employs its key to encrypt bits in groups. The '789 patent describes a block cipher. Computer implemented block ciphers have been in wide use in the United States since at least 1976, when a block cipher called the “Data Encryption Standard” or “DES” was adopted by the United States government for general use. As of 1997, when Paone filed his patent application, dozens of additional block encryption algorithms had been published. However, most of those inventions used a single key to encrypt successive blocks of data. Paone’s innovation — in the most general terms — was to change the encryption key for each data block, based on additional, randomly generated data. B. Procedural History Paone filed his initial application for the present patent on December 12, 1997. Following that initial application, the PTO rejected Paone’s claims as unpatentable in three successive office actions, dated September 29,1999, March 16, 2000, and October 30, 2000. In response to each of these rejections, Paone modified his claims and provided additional argument. Then, on July 10, 2001, the PTO deemed the described invention patentable, and issued the '789 Patent. On July 23, 2007, Paone commenced the present action against Microsoft, alleging that Microsoft was infringing the '789 patent. Specifically, Paone asserts that two components of Microsoft’s flagship computer operating system, Windows, infringe the '789 patent. The parties proceeded with discovery, during which time Microsoft on May 16, 2008 requested the PTO to reexamine the '789 patent. In early 2009, with the reexamination proceeding still pending, the parties briefed claim construction motions. However, before holding a Markmcm hearing, the Court on April 5, 2009 stayed the case pending the resolution of the reexamination proceeding. Then, before the stay was lifted, Microsoft also filed two more reexamination requests, dated June 29, 2009, and July 27, 2009. The three reexamination proceedings as a whole resulted in the cancellation of claims 1, 3, 23, and 32 of the '789 patent, but also a ruling that several claims, including claims 2, 24, 33, and 34, were patentable. A number of other claims were also found to be patentable after certain amendments. After the reexamination proceedings had been finalized, the Court on March 3, 2010 lifted the stay of the case. Partly as a result of the reexamination proceedings, Paone modified his position to assert that Microsoft was infringing claims 2, 24, 33, and 34 of the '789 patent, all of which had been ruled patentable by the PTO. These claims read in full as follows (the language of claims 1, 23, and 32 are also included, because some of the asserted claims are dependent on those claims). What is claimed is: 1. A computer implemented method for encrypting data comprising the steps of: creating at least one object key in a block cipher, the at least one object key comprising data and methods that operate on said data; creating a key schedule based upon the at least one object key; encrypting a random session object key in a block cipher encryption process with the at least one object key; encrypting a block of input plaintext data utilizing said key schedule; modifying the at least one object key based on seeding from the random session object key; modifying the key schedule based upon the at least one modified object key; encrypting a next block of input plain-text data utilizing said modified key schedule; and repeating the steps of modifying the at least one object key, modifying the key schedule and encrypting utilizing the modified key schedule until the encrypting of blocks of plaintext data is completed. 2. A computer implemented method as defined in claim 1, wherein the modification of the key schedule is independent of the input plaintext data. 23. A cryptographic communications system comprising: at least two networked computer systems linked by a communication channel; and each computer system including a central processing unit and a memory storage device for executing a block cipher encryption/decryption process; wherein the encryption process transforms an input plaintext message to a ciphertext message and the decryption process transforms the ciphertext message to the input plaintext message, the encryption/decryption process using at least one dynamic object key which is modified using a nonlinear function for each block of input data, each object key being associated with a different key schedule to encrypt/decrypt the input plaintext/out-put ciphertext message. 24. A cryptographic communications system as defined in claim 23, wherein the encryption/decryption process further includes the use of a random session object key having an initial state randomly generated by the computer system, and wherein the object key modifications are based on seeding from the random session object key. 32. A computer implemented method for encrypting data comprising the steps of: creating at least one object key in a block cipher, the at least one object key comprising data and methods that operate on said data; creating a key schedule based upon the at least one object key; encrypting a block of input plaintext data utilizing said key schedule; modifying the at least one object key based on at least a nonlinear function; modifying the key schedule based upon the at least one modified object key; encrypting a next block of input plain-text data utilizing said modified key schedule; and repeating the steps of modifying the at least one object key, modifying the key schedule and encrypting utilizing the modified key schedule until the encrypting of blocks of plaintext data is completed. 33. A computer implemented method a defined in claim 32, where in the nonlinear function is a hashing function. 34. A cryptographic communications systems [sic ] as defined in claim 23, wherein the non-linear function is a hashing function. Upon the lifting of the stay, the parties resumed their claim construction motions. Although the parties briefed claim construction before the case was stayed, the parties also filed supplemental claim construction briefs to address the reexamination proceedings. Then, on the consent of the parties, the Court appointed Gale R. Peterson, Esq., an experienced and well-regarded patent attorney, as a special master in this case for the limited purpose of conducting a Markman hearing and issuing a report and recommendation to the Court on claim construction. On June 23, 2010 Special Master Peterson conducted a non-evidentiary Markman hearing, at which the parties’ attorneys presented their arguments on claim construction. On August 11, 2010, Special Master Peterson issued an extensive and detailed Report and Recommendation on claim construction (the “Special Master’s Report”). In response to this report, both Paone and Microsoft filed memoranda of law on September 17, 2010, each objecting in part to the Special Master’s Report. Prior to the Markman hearing, the parties presented nine claim terms for construction. However, after meeting and conferring at the suggestion of the Special Master, the parties agreed on meanings for three of those terms. The remaining six terms in dispute are: Disputed Terms/Phrases Asserted Claims (or underlying independent claims) Containing the Disputed Terms/Phrases “object key” 1, 23, 24, 32 “random session object 1, 24 key”_ “repeating the step[ ] of 1, 32 modifying the at least one object key” “block”_1, 23, 32_ “key schedule” 1, 2, 23, 32 “block cipher” 1, 23, 26, 32 In light of the parties’ submissions and the Special Master’s Report, the Court now rules on the construction of these six claim terms. II. DISCUSSION A. Standard on Review of a Special Master’s Report and Recommendation Fed.R.Civ.P. 53(f)(1) provides that, “[i]n acting on a master’s order, report, or recommendations, the court ... may adopt or affirm, modify, wholly or partly reject or reverse, or resubmit to the master with instructions.” Rule 53(f)(4) further states that “[t]he court must decide de novo all objections to conclusions of law made or recommended by a master.” Under Markman, 517 U.S. at 390, 116 S.Ct. 1384, claim construction is a matter of law. Therefore, the Court reviews the Special Master’s recommendations de novo. B. Principles of Claim Construction The Special Master provided a helpful and detailed recitation of the core principles of claim construction in his Report, and the Court adopts that discussion in full. (See Special Master’s Report at 5-10.) In discussing these principles, the Special Master quoted extensively from the Federal Circuit’s leading case on the law of claim construction, Phillips v. AWH Corp., 415 F.3d 1303 (Fed.Cir.2005). Significant sections of that case bear repeating here. In Phillips, the Federal Circuit stated: It is a bedrock principle of patent law that the claims of a patent define the invention to which the patentee is entitled the right to exclude.... We have frequently stated that the words of a claim are generally given their ordinary and customary meaning. We have made clear, moreover, that the ordinary and customary meaning of a claim term is the meaning that the term would have to a person of ordinary skill in the art in question at the time of the invention, i.e., as of the effective filing date of the patent application----The inquiry into how a person of ordinary skill in the art understands a claim term provides an objective baseline from which to begin claim interpretation.... Importantly, the person of ordinary skill in the art is deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification.... The inventor’s words that are used to describe the invention — the inventor’s lexicography— must be understood and interpreted by the court as they would be understood and interpreted by a person in that field of technology.... In some cases, the ordinary meaning of claim language as understood by a person of skill in the art may be readily apparent even to lay judges, and claim construction in such cases involves little more than the application of the widely accepted meaning of commonly understood words.... In many cases that give rise to litigation, however, determining the ordinary and customary meaning of the claim requires examination of terms that have a particular meaning in a field of art. Because the meaning of a claim term as understood by persons of skill in the art is often not immediately apparent, and because pat-entees frequently use terms idiosyncrat-ieally, the court looks to those sources available to the public that show what a person of skill in the art would have understood disputed claim language to mean. Those sources include the words of the claims themselves, the remainder of the specification, the prosecution history, and extrinsic evidence concerning relevant scientific principles, the meaning of technical terms, and the state of the art.... Other claims of the patent in question, both asserted and unasserted, can also be valuable sources of enlightenment as to the meaning of a claim term. Because claim terms are normally used consistently throughout the patent, the usage of a term in one claim can often illuminate the meaning of the same term in other claims.... The claims, of course, do not stand alone. Rather, they are part of a fully integrated written instrument, consisting principally of a specification that concludes with the claims. For that reason, claims must be read in view of the specification, of which they are a part. As we stated in Vitronics [Corp. v. Conceptronic, Inc., 90 F.3d 1576 (Fed.Cir.1996) ], the specification is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term.... In light of the statutory directive that the inventor provide a full and exact description of the claimed invention, the specification necessarily informs the proper construction of the claims. Consistent with that general principle, our cases recognize that the specification may reveal a special definition given to a claim term by the patentee that differs from the meaning it would otherwise possess. In such cases, the inventor’s lexicography governs. In addition to consulting the specification, we have held that a court should also consider the patent’s prosecution history, if it is in evidence. The prosecution history, which we have designated as part of the intrinsic evidence, consists of the complete record of the proceedings before the PTO and includes the prior art cited during the examination of the patent.... Yet because the prosecution history represents an ongoing negotiation between the PTO and the applicant, rather than the final product of that negotiation, it often lacks the clarity of the specification and thus is less useful for claim construction purposes. Nonetheless, the prosecution history can often inform the meaning of the claim language by demonstrating how the inventor understood the invention and whether the inventor limited the invention in the course of prosecution, making the claim scope narrower than it would otherwise be.... Although we have emphasized the importance of intrinsic evidence in claim construction, we have also authorized district courts to rely on extrinsic evidence, which consists of all evidence external to the patent and prosecution history, including expert and inventor testimony, dictionaries, and learned treatises. However, while extrinsic evidence can shed useful light on the relevant art, we have explained that it is less significant than the intrinsic record in determining the legally operative meaning of claim language.... Within the class of extrinsic evidence, the court has observed that dictionaries and treatises can be useful in claim construction---- Because dictionaries, and especially technical dictionaries, endeav- or to collect the accepted meanings of terms used in various fields of science and technology, those resources have been properly recognized as among the many tools that can assist the court in determining the meaning of particular terminology to those of skill in the art of the invention.... We have also held that extrinsic evidence in the form of expert testimony can be useful to a court for a variety of purposes, such as to provide background on the technology at issue, to explain how an invention works, to ensure that the court’s understanding of the technical aspects of the patent is consistent with that of a person of skill in the art, or to establish that a particular term in the patent or the prior art has a particular meaning in the pertinent field. However, conclusory, unsupported assertions by experts as to the definition of a claim term are not useful to a court. We have viewed extrinsic evidence in general as less reliable than the patent and its prosecution history in determining how to read claim terms, for several reasons. First, extrinsic evidence by definition is not part of the patent and does not have the specification’s virtue of being created at the time of patent prosecution for the purpose of explaining the patent’s scope and meaning. Second, while claims are construed as they would be understood by a hypothetical person of skill in the art, extrinsic publications may not be written by or for skilled artisans and therefore may not reflect the understanding of a skilled artisan in the field of the patent.... Finally, undue reliance on extrinsic evidence poses the risk that it will be used to change the meaning of claims in derogation of the indisputable public records consisting of the claims, the specification and the prosecution history, thereby undermining the public notice function of patents. 415 F.3d at 1312-1319 (internal citations and quotations omitted, paragraphing is altered from original). With these basic principles in hand, the Court proceeds to construe the disputed claim language. C. Construction of the Claim Term “Object Key” The first term that the Court construes is “object key”, which appears throughout the patent’s claims and specification, as well as in the patent’s title. The parties agree that the term “object key” refers to a key that is used to encrypt data, and they also agree that this term did not have a standard meaning within the fields of computer science or cryptography prior to the filing of the '789 patent. The use of “object key” throughout the patent is typified by its use in claim 1, which states that one of the methods of the invention is “creating at least one object key in a block cipher, the at least one object key comprising data and methods that operate on said data.” ('789 Patent, 11:19-21; see also, e.g., id. at 18:12-14.) The parties and the Special Master construed “object key” as follows:_ Paone and Microsoft dispute two issues with respect to the construction of “object key.” The first, less contentious issue is whether the “object key” must be a “secret”. The second, more contentious issue is whether the “object key” must be defined in “object-oriented programming” and be “self-contained.” As the Special Master’s construction indicates, he found in favor of Paone on both of these issues, ruling that the “object key” need neither be “secret” nor defined in object-oriented programming and self-contained. 1. Must the Object Key be “Secret”? Neither the parties, the intrinsic evidence, nor the Special Master address in great detail whether the “object key” must be “secret.” Discussing this issue in his Report, the Special Master stated: Regarding [whether the object key must be] “secret,” although the specification does refer to a “secret” object key, e.g., “a secret key composed of two 2048-bit user object keys,” and “a 4096-bit secret key block cipher data encryption process,” the claims do not require that the “object key” be “secret.” During the Markman hearing, counsel for Paone explained that “secret” was not a necessary characteristic of an “object key.” Tr. at 12-14. That is, whether an “object key” was “secret” or not, would affect the security of the system, but was not a necessary attribute of an “object key” per se. Also, at least the first two “objects of the invention” listed in the '789 patent refer to “object key” with no requirement that the “object key” be “secret.” Although the issue is close, the master believes that in this instance, the plain language of the claim controls. That is, requiring that the “object key” be “secret” crosses the line from interpreting claims “in light of of’ the specification, to incorporating terms from the specification into the claims, which, of course, is improper. The “object key” may be, and perhaps preferably is, “secret,” but the claims do not expressly require the same. The specification also does not say that the “object key” must be “secret,” at least expressly. Moreover, it was unclear from the Markman hearing whether, and to what extent, “secret” has any impact on the ultimate question of infringement. On the current record, therefore, the master concludes that the claims do not require that an “object key” be “secret.” Or, in other words, a “key” otherwise meeting the terms of the claims is not excluded because it is not “secret.” However, that is subject to potential reconsideration. (Special Master’s Report at 44, fn. 15.) The Special Master’s points on the issue are well taken. Specifically, it is important that, while the title and specification for the patent refer to a “secret” object key, the claims themselves neither implicitly nor explicitly state that the “object key” must be secret. Nevertheless, reading the claims “in view of the specification,” Markman v. Westview Instruments, Inc., 52 F.3d 967, 978 (Fed.Cir.1995), the Court concludes that the “object key” must be secret. Not only is the object key referred to as “seeret” in several places in the specification and the patent title, but the “Background of the Invention” portion of the specification focuses almost exclusively on the importance in cryptography of maintaining the secrecy of an encrypted message. Specifically, Paone describes the invention in that section stating: Accordingly, the present invention seeks to overcome the disadvantages associated with currently available encryption methods and create ciphertext which is very secure and substantially immune to known eryptanalytic attacks. ('789 patent, 2:13-17.) Paone’s attorney conceded at oral argument that a non-secret object key would affect the security of an encryption system, and it appears to the Court that a non-secret object key would undermine the usefulness of the entire invention. As such, reading the claims in light of the specification, the Court concludes that the “object key” must be “secret,” in the sense that it cannot be available to the general public. However, in deference to the claim language itself, the Court declines to provide a more limiting definition of “secret.” 2. Must the Object Key be Defined in Object-Oriented Programming? The more central argument over the meaning of “object key” is whether the object key must be defined in what computer scientists call “object-oriented programming”. Concomitant with this dispute is whether the object key must be also “self-contained”. This disagreement is so contentious that the Special Master’s resolution of it consumes approximately 109 pages of the his 243-page Report. Thus, to fully understand the parties’ disagreement, a brief background discussion of object-oriented programming is in order. Object-oriented programming (“OOP”) is not easy to define, and a recently published book for beginning computer programmers notes that “OOP is difficult to summarize because it doesn’t represent a single concept ... and even experts are unable to agree on a common definition.” Richard Mansfield, Programming: A Beginner’s Guide, p. 264 (McGraw Hill 2009). Even the programming language C -I- +, one of the most widely used object-oriented programming languages, is viewed by some as “not a pure OOP language.” Na-mir C. Shammas, Foundations of C+ + and Object-oriented Programming, p. 10 (IDG Books Worldwide, Inc. 1995). However, on a very basic level, object-oriented programming is usually defined in contrast to a method of computer programming that preceded OOP, which is called “structured” (or “functional”) programming. Structured programming is a method of giving computers instructions in “reusable subroutines and functions ... [which] enjoy[] a certain level of autonomy”. Shammas at 7. Thus, structured programs can define a complicated task for a computer to do — say, calculate the square root of a number — and define that task in a “subroutine”. That subroutine contains all of the steps necessary to do the task, so the task can repeated over and over by using the subroutine, without forcing the programmer to re-write the individual steps each time. However, structured programming generally stores data in ways that permit data to be manipulated broadly, which “[i]n large-scale software projects ... can lead to chaos.” See Shammas at 7, 9. In other words, this means that in structured programming, the data used by a given subroutine is shared with and can be modified by other subroutines. One result of this is that when data becomes damaged or lost, it can be difficult to determine the source of the problem because so many different subroutines have access to the data. Object-oriented programming seeks to solve this problem. While an object-oriented program still defines complex tasks into subroutines, it allows only the piece of the program that uses each piece of data most directly to have immediate access to that data. Thus, in object-oriented programming, instead of using subroutines as the building blocks of a program, programmers use “objects”. “Objects” consist of both the instructions for various subroutines and the data needed to carry out those instructions. Thus, whereas the data in a structured program might be very loosely thought of as being in a shared pool, the data in an object-oriented program is encapsulated into pockets, accessible only by the “object” that will use that data directly. Any other part of the program that wishes to change an object’s data must go through the object to do so. Objects are thus described variously as having “attributes and [] methods that alter these attributes,” Shammas at 15; “both data ... as well as code that processes that data,” Mansfield at 264; or “data and the operations that manipulate the data,” Matt Weisfeld, The Object-Oriented Thought Process, p. 9 (Sams Publishing 2004). (The Court notes that while some of these sources post-date the filing of the '789 patent, there is no indication that the understanding of this basic theory in object-oriented programming has changed since the '789 patent was filed in 1997.) Generally, a programming language is viewed as either a “structured programming language” or an “object-oriented programming language” — although there are some exceptions to this rule. Returning, then, to the construction of the term at hand, Microsoft urges that the “object key” must be defined in an object-oriented program, while Paone asserts that “object key” is explicitly defined in the claims as “data and methods that operate on said data”. Microsoft bases its conclusion primarily on (1) Paone’s use of the word “object” in naming the claim term, and (2) Paone’s repeated indication that the object key “comprises data and methods that operate on said data.” (See, e.g., '789 Patent, 11:20-21.) Microsoft asserts that, in light of the state of the art in computer science, using the term “object” with a consistent indication that the element described contains both data and methods would indicate to a person skilled in computer science that the “object key” is intended to be executed in an object-oriented program. Microsoft contends that this conclusion is confirmed by the fact that more than one patent examiner who examined the '789 Patent understood that the term “ ‘object key comprising data and methods’ ... referfs] to an object associated with object-oriented programming.” (See Paone’s Claim Construction Brief at Ex. B, PAONE0003100.) Microsoft also points out that Paone never directly challenged this conclusion. Once Microsoft concludes that an “object key” must be defined in an object-oriented program, Microsoft then points to three technical dictionaries that define an “object” in object-oriented programming as “self-contained”. Based on this, Microsoft also maintains that an object key must be “self-contained”. After examining both the intrinsic and extrinsic evidence presented, the Special Master rejected Microsoft’s construction of “object key” as requiring that this element be executed in object-oriented programming or be self-contained. While the Special Master also rejected Paone’s assertion that “object key” was explicitly defined in the claims, he essentially ruled in Paone’s favor by not limiting the term as Microsoft proposed. The Special Master based his ruling first and foremost on the fact that no-tohere in the patent specification, the claims, or in the prosecution history does Paone explicitly assert that his invention is limited to execution in object-oriented programming. While Microsoft argues that Paone made a significant admission when he failed to contest the examiners’ assumption that the object key would be defined in object-oriented programming, Microsoft otherwise does not contest that the term “object-oriented programming” appears nowhere in the patent or in Paone’s submissions to the PTO. Likewise, the Special Master noted that there was no indication that the use of object-oriented programming rendered patentable the subject matter of the '789 patent. (See Special Master’s Report at 95 (“If the inventor’s belief had truly been — as Microsoft suggests — that his contribution and distinguishing feature over the prior art was the use of object-oriented programming, it would stand to reason (or, at least seemingly so) that the inventor would have included some mention of object-oriented programming in at least the specification, if not expressly in the claims.”); see also id. at 123 (“it is clear that the patentability of the asserted claims was not based on limiting ‘object key’ to implementation using object-oriented programming”).) As for the prosecution history of the '789 patent, the Special Master provided a detailed overview of the prosecution and reexamination proceedings, and determined that the examiners’ conclusion that “object key” implied the use of object-oriented programming did not require that the patent be so limited. First, although Paone never explicitly challenged this conclusion, he also never disclaimed that his patent would cover object keys executed in non-object-oriented programming. Moreover, the Special Master noted that the examiner who first suggested that the use of object-oriented programming was implicated did so by interpreting the word “object” in the context not of computer science generally, but in the context of object-oriented programming. The Special Master then noted that “[e]ven in the field of computer science, insofar as understood, ‘object’ only begins to take on a special connotation if the field is narrowed to object-oriented programming.” (Id. at 106.) Finally, the Special Master concluded that “here one reading the entire history of prosecution would see that the applicant expressly informed the PTO that ‘object key’ was not limited to implementation using object-oriented programming.” (Id. at 124.) Based on this, the Special Master concluded that the word “object” in “object key” connoted no special meaning, and that the “term is no different from ‘first key’ or ‘widget key’ or any other coined term.” (Id. at 34.) The Special Master rejected Microsoft’s proposed dictionary definitions of “object” as being definitions “in object-oriented programming,” and not definitions of “object” in computer science generally. (See id. at 39 (“each definition [of ‘object’ presented by Microsoft] begins, ‘[i]n object-oriented programming.’ Again, those definitions establish little more than ‘object’ has a recognized meaning in the field of object-oriented programming, and do not establish that one of ordinary skill in the art seeing ‘object key’ in the claims and specification of the '789 patent would, on that basis alone, construe “object key” as limited to object-oriented programming.”).) These dictionaries provided the source for limiting the object key to being “self-contained”, and with the rejection the dictionaries’ definitions necessarily followed the rejection of this limitation. Ultimately, the Special Master recommended that the Court find that the “object key” is merely the “first encryption key,” to be distinguished from the “random session object key,” which is the “second encryption key.” The Special Master did not address what it would mean that the “object key” should comprise both (1) data and (2) methods that operate on that data, but he did note that other claim terms provided that the object key was necessarily “dynamic,” and that it was “modified from an initial static state.” (Id. at 124.) In reviewing the Special Master’s Report, the Court agrees with the Special Master that an “object key” need not be executed in an object-oriented program and need not be self-contained. However, for the reasons that follow, the Court respectfully disagrees with the Special Master’s determination that the word “object” in the claim term connotes no special meaning in the context of the patent. First, with respect to the Court’s partial adoption of the Special Master’s recommendation, the Court agrees that Paone makes no explicit reference to object-oriented programming in any part of the patent. In addition, the Court agrees with and adopts the Special Master’s rulings on the import of the prosecution history with respect to the construction of the term “object key”, and agrees with the Special Master that the parties’ experts’ reports are both entitled to little weight. Thus, granting Paone the “full scope of [his] claim language,” Home Diagnostics, Inc. v. LifeScan, Inc., 381 F.3d 1352, 1358 (Fed.Cir.2004), the Court finds that Paone’s implicit reference to object-oriented programming does not limit the technical execution of the invention to an object-oriented programming language. As for the Court’s partial rejection of the Special Master’s recommendation, the Court notes that one of the most basic concepts of object-oriented programming is to create programs based on “objects” that contain both data and methods that operate on that data. Having reviewed both the intrinsic and extrinsic evidence, the Court finds that a person skilled in the art of computer science — who would necessarily have been aware in 1997 that object-oriented programming was the dominant paradigm of commercial computer programming — would recognize Paone’s construction as a reference to object-oriented programming. As such, Paone’s choice of the word “object” to modify “key” carries greater meaning than a purely coined term, such as “widget key” or “first key”. While the Court rejects the limitation that the object key must be executed in an object-oriented program, the Court holds that “object key” refers to an element of the invention that functions analogously to an object in an object-oriented program. Just like a bona fide object in an object-oriented program, the “object key” contains both data — the key data that will inform the operation of the cipher — and the methods that operate on that data. More importantly, just as in an object-oriented program, the methods contained in the object key are the only methods that operate on the key data. Here, while the nature of those methods comprised in the object key are not explicitly stated, the Court can readily deduce them. The Court begins with the general principal of claim construction that “claims are interpreted with an eye toward giving effect to all terms in the claim.” Bicon, Inc. v. Straumann Co., 441 F.3d 945, 950 (Fed.Cir.2006); accord Cohesive Technologies, Inc. v. Waters Corp., 543 F.3d 1351, 1368 (Fed.Cir.2008). In the 789 Patent, the Court must give meaning to, among other things, language in claims 1 and 32 that states that the object key comprises “data and methods that operate on said data”. In the Court’s view, this language would be superfluous if those methods were never utilized by the described invention. Thus, looking to the other language describing the invention, Claims 1 and 32 disclose only one operation that is performed on the key data: modification of that data for each plaintext block. Thus, to give meaning to “methods that operate on said data”, the Court construes this language to refer to methods that modify the object key’s data. This construction is consistent with other claims in the patent, as well as the patent specification. (See '789 Patent, 13:34-35 (describing in claim 14 “the modification method of the object key” (emphasis added)); 5:18-20 (“[t]he object key [] contains key modification methods that mutate the key’s state.”); 6:45-47 (“the object keys [ ] are composed of initial states that are created by the user and functions that modify the keys for each plaintext input block”); 7:4-9 (“After each block has been processed, the key modification methods in the object key ... are performed to modify the object key’s ... state”).) Nevertheless, as a matter of technology, there is no indication that this conceptual construction must be carried out in an object-oriented programming language. The claim language and specification say nothing that indicates that the invention must be practiced using a computer programming language that prevents other parts of the program from modifying the object key’s data, such as an object-oriented programming language would do. Indeed, the patent does not even suggest that this would benefit the invention. The Court’s construction is consistent with the Federal Circuit’s interpretation of the term “object” in a different patent involving computer science in TiVo, Inc. v. EchoStar Communications Corp., 516 F.3d 1290, 1306-07 (Fed.Cir.2008). While a single word need not have the same meaning in two different patents, the Federal Circuit’s reasoning in TiVo concerning the word “object” comports with this Court’s reasoning on that issue here. In TiVo, the Federal Circuit reviewed the construction of several claim terms involving computer software that each included the word “object”. The court held that the use of the word “object” did not require the use of an object-oriented programming language in practicing the invention, and stating: While the patent specification includes an embodiment showing the use of “a C// class hierarchy derivation of the program logic,” '389 patent, col. 8, 11. 9-10, and uses terms characteristic of object-oriented programming in connection with that example, neither the written description nor the claims anywhere state or imply that the invention must use object-oriented programming in general, or C// in particular. Without more, the use of an example that employs object-oriented programming is not sufficient to require that the claims be limited to embodiments using C// or a similar programming language. Id. at 1307. Here, unlike TiVo, Paone has not even presented an example of the '789 subject matter that is practiced using an object-oriented programming language. Thus, like the TiVo court, this Court finds that the use of the term “object” in the context of language typical of object-oriented programming does not require that the invention be practiced in an object-oriented programming language. As for the Microsoft’s request that “object key” be defined as “self-contained,” the Court agrees with the Special Master that the technical dictionaries from which Microsoft derives this definition beg the question. The Special Master points out that each definition of “object” that Microsoft relies on explicitly defines an “object” within the context of object-oriented programming. This, of course, assumes that Paone is describing an object that is defined in an object-oriented programming language. As the Court has found that no such limitation applies to this claim term, these definitions are not especially useful. The Court notes that Microsoft objects that the Special Master improperly discounted these dictionary definitions because he wrongly believed that the field of the '789 patent is only cryptography, to the exclusion of computer science. Whether or not this is an accurate characterization of the Special Master’s Report — at least one quotation from the Special Master’s Report that Microsoft offers in support of this thesis does not appear to actually exist, (see Microsoft’s Objections at 5) — the point is immaterial. Microsoft’s definitions explicitly require that the field of the invention is object-oriented programming, not computer science. Such is not the case. Moreover, while these technical dictionaries may provide a rough and ready definition of “object” within object-oriented programming, the Court has already noted that even experts do not appear to agree on a precise definition for either object-oriented programming or its components. See Mansfield at 264; see also TiVo, 516 F.3d at 1306 (“Tivo’s expert offered a broader definition for the term ‘object’, [and stated] that objects and object-oriented techniques can be used in many programming languages.”). Likewise, contrary to the characterization of objects as “self-contained”, one of the chief benefits of object-oriented programming— aside from data protection — is the use of “classes” and “inheritance”, which are ways for multiple objects to reuse the same programming code. See Shammas at 11, 14 (“Object-oriented programming supports code reuse in a manner not available in structured programming.”); Weis-feld at 14 (“Be aware that there is not necessarily a physical copy of each method for each object. Rather, each object points to the same physical code.”). Thus, while it may be a beneficial conceptual definition in some spheres to define objects in object-oriented programming as “self-contained”, this does not appear to be a strict technical requirement even within an object-oriented programming language. Therefore, the Court accepts in part and rejects in part the Special Master’s recommendation with respect to the construction of “object key”, and construes the term as follows: An “object key” is an encryption key that is not available to the general public, and which is composed of both (1) key data and (2) methods that modify that key data. The object key need not be implemented in an object-oriented programming language. D. Construction of the Claim Term “Random Session Object Key” The definition of the second term that the Court construes, “random session object key”, follows in part from the definition of “object key.” In the '789 Patent, the random session object key is an additional key that provides supplementary data to the object key to aid in the object key’s modification of its state. The term appears in multiple claims and throughout the specification. Typical of the term’s use are claims 1 and 23, which refer to “modifying the at least one object key based on seeding from the random session object key” and to an “encryption/deeryption process [that] further includes the use of a random session object key having an initial state randomly generated by the computer system, and wherein the object key modifications are based on seeding from the random session object key.” While the parties generally continue to dispute the import of the words “object key” in this term, the primary new dispute between the parties with respect to this term concerns the meaning of the word “session”. The parties and the Special Master defined “random session object key” as follows:_ In construing “random session object key”, the Special Master found that the term was, like “object key”, a purely coined term, and that the words “random”, “session”, and “object” in the term therefore need not be given any special meaning. After reviewing the relevant intrinsic and extrinsic evidence, the Special Master concluded that the “random session object key” was essentially a “second encryption key,” as distinguished from the “object key”, which he called the “first encryption key”. He noted that, like the “object key”, the “random session object key” was dynamic, but that this quality was described by other claim language. For his part, while Paone apparently gave meaning to at least the word “random” in his initial construction of “Random Session Object Key”, he does not object to the Special Master’s construction of the term. Microsoft, on the other hand, objects to the entirety of the Special Master’s construction. In objecting to the Special Master’s construction, Microsoft first asserts that the grammar of “random session object key” requires that the term be construed to be a type of “object key”, and contends that the Special Master’s construction does not achieve this. Microsoft also maintains that the word “random” must be given meaning in the term, and thus requests that “random session object key” be defined to have randomly generated data. Finally, and most centrally, Microsoft urges that the word “session” must be interpreted to define “random session object key” as being randomly generated for a “communications session.” In support of this last assertion, Microsoft relies primarily on references to the word “session” in prior art and in a textbook, each of which explain that a “session” is a “communications session.” In response, Paone notes that a number of the claims that reference the random session object key make no mention of communications usages, and at least one described embodiment of the invention involves encrypting data for storage on a single computer — an application that necessarily does not involve communication. Paone also presents a number of definitions of “session” from dictionaries that define the word more broadly, as: “the time during which a program is running”, Computer Dictionary: Third Edition, p. 337 (Microsoft Press 1997), “a period devoted to an activity”, The Oxford Dictionary and Thesaurus: American Edition, p. 1025 (Oxford University Press 1996), and “one or more instances of an application”, S.M.H. Collin, Dictionary of Personal Computing and the Internet, p. 169 (Fitzroy Dearborn Publishers 1997). First, with respect to the central question of whether the word “session” means “communications session”, the Court has reviewed the Special Master’s recommendation that the Court reject this limitation, and finds his analysis to be without error. As the Special Master points out, nothing in the patent itself indicates that “session” must mean “communications session.” Moreover, while it is not an inviolable rule, it is generally appropriate to interpret claim language to cover all specified embodiments of the invention. See, e.g., OnLine Tech v. Bodenseewerk Perkin-Elmer, 386 F.3d 1133, 1138 (Fed.Cir.2004) (“a claim interpretation that excludes a preferred embodiment from the scope of the claim is rarely, if ever, correct” (internal quotations and citations omitted)). Here, the '789 patent specification includes an embodiment that involves no communication. For these reasons and the further reasons set forth in the Special Master’s Report, the Court finds that the term “session” does not imply “communications session.” Nevertheless, the Court respectfully disagrees with the Special Master’s conclusion that the words “random”, “session”, and “object” import no particular meaning to the term “random session object key.” First, for the reasons explained above, the Court finds that “object key” has a special meaning that derives in part from the word “object” and in part from that word’s use in context. Thus, the Court now also finds that a random session object key incorporates the meaning of the term “object key”. The Court concludes this not only from basic rules of grammar, but also from the use of “random session object key” in the claim language. For example, claim 13 describes “a computer implemented as defined in claim 3, wherein the modification method of said random session object key includes a hashing function.” ('789 Patent, 13:28-30.) Claim 3, the claim on which claim 13 is dependent, introduces the “random session object key” as being involved in the encryption method, but never defines it as having “modification methods.” However, the language of claim 13 suggests that Paone assumed that the reader would infer from the definition of “object key” that a “random session object key” also comprised both (1) data and (2) methods to modify that data. Likewise, in describing the operation of the random session object key in the preferred embodiment of the invention, the specification states, “[ajfter each block has been processed, the key modification methods in the object key [ ] and the random session object key [ ] are performed to modify the object key’s and the random session object key’s state.” ('789 Patent 7:4-8.) Again, this description assumes a parallelism between the structure of the object key and the structure of the random session object key. Assuming, then, that “random session object key” is a type of object key, the Court further accords meaning to the words “random” and “session” as describing this type of “object key”. As for “random”, both Paone and Microsoft agree that the random session object key has data that is initially generated randomly. With respect to “session”, the Court has already rejected Microsoft’s construction that “session” means “communications session”. In place of this definition, the Court applies the more generic definition of this term suggested by Paone, “one or more instances of an application”, which the Court finds encompasses all of the described embodiments of the invention, and is consistent with the claim language itself. Therefore, the Court construes “random session object key” as follows: A “random session object key” is an object key, as defined above, with data that is generated randomly for each instance of the use of the encryption application. E. Construction of the Claim Term “Repeating the Step [ ] of Modifying the at Least One Object Key” The Court next construes the claim term “repeating the step[ ] of modifying the at least one object key.” This term appears in claims 1 and 32, in a form that for the present purposes is substantially identical. The relevant language in claim 1 reads: 1. A computer implemented method for encrypting data comprising the steps of: creating at least one object key in a block cipher, the at least one object key comprising data and methods that operate on said data; [creating a key schedule using the object key, encrypting a random session object key, and encrypting a block of plaintext using the key schedule] modifying the at least one object key based on seeding from the random session object key; modifying the key schedule based upon the at least one modified object key; encrypting a next block of input plain-text data utilizing said modified key schedule; and repeating the steps of modifying the at least one object key, modifying the key schedule and encrypting utilizing the modified key schedule until the encrypting of blocks of plaintext data is completed. ('789 Patent, 11:17-39 (emphasis added).) The parties’ primary dispute over this term is whether the disputed claim language implies that, for each data block, the object key must be modified from its present state, or whether it may be modified each time from its original state. The parties and the Special Master construed this term as follows: In construing this claim term, Paone asserts that the disputed claim language is clear on its face, and that it plainly encompasses modification of the original object key. By contrast, Microsoft asserts that the claim language is ambiguous, and that this ambiguity must be resolved by looking to the preferred embodiment of the invention — which describes the object key as being modified in each case from its present state. Microsoft further contends that this is the only reading of the claim that is consistent with the general described purposes of the invention and the prosecution history. Ultimately, the Special Master ruled in favor of Paone on this issue, finding that the language of the claim did not exclude the repeated modification of the original object key, and that the specification did not show otherwise. For the reasons that follow, the Court respectfully disagrees with the Special Master’s construction of this term, and finds that the disputed language limits the invention to modifying of the object key’s present state. The Court begins with the claim language itself. As relevant to the presently disputed term, claim 1 describes (1) the creation of an “object key”, (2) the modification of the object key, and (3) the “repeating [of] the step[ ] of modifying the at least one object key.” For the purposes of the following discussion, the Court will refer to these steps respectively as Step 1, Step 2, and Step 3. The Court construes all three steps to the extent necessary to resolve the parties’ dispute over the language describing Step 3. Beginning with the language of Step 1, “creating at least one object key in a block cipher, the at least one object key comprising data and methods that operate on said data”, the Court construes this language to indicate that the “object key” that is modified in Step 2 is at least initially a newly created object key. Step 2 then describes “modifying the at least one object key based on seeding from the random session object key”. With respect to this language, the Court notes that it has previously construed the methods that are comprised in the object key to be methods that modify the object key. For the same reasons that underlie that construction, the Court now conversely construes Step 2 to describe modification of the object key by operation of the object key’s own modification methods. The disputed claim language of “repeating the step[ ] of modifying the at least one object key” then describes Step 3. Read most literally, this claim language supports Paone’s construction. That is, Step 2 describes modification of the object key that is created in Step 1. Thus, when Step 3 essentially directs that Step 2 be repeated as written, it at least arguably describes a repeated modification of that same object key created in Step 1, based on that object key’s state as it existed in Step 1. Paone further asserts that any construction of Step 3 that limited modification of the object key to being based on the object key’s already modified state would result in rewriting claims 1 and 32 as follows (the language that Paone asserts is being improperly read into these claims is underlined): claim 1: “modifying the at least one object key based on seeding from the random session object key and the object key after it has already been once modified ” ('789 Patent, 11:17-38.) claim 32: “modifying the at least one object key using at least a nonlinear function and the object key after it has already been once modified ” (Id. at 18:10-31.) (Paone’s Objections at 22.) Paone then asserts that: As illustrated in the claims, however, claim 1 requires basing the modification on “seeding from the random session object key,” and claim 32 requires basing the modification on “at least a nonlinear function.” Whether or not the modification step could also be based upon “the object key after it has already been once modified,” the initial state of the object key, or something else is simply not a limitation of the claims. (Id. at 23.) However, Paone’s assertions highlight the first difficulty with his own construction of Step 3. In the Court’s view, Paone’s interpretation ignores the claim language in Steps 2 and 3 indicating that the object key is “modified”. In the opinion of the Court, this language implies that the object key’s data — whether in original or already modified form — is an input into the object key’s new state. (See, e.g, “Modify”, Merriam Webster Online Dictionary, available online at <http://www.merriam-webster.com/dictionary/modify> (“3a: to make minor changes in; 3b: to make basic or fundamental changes in often to give a new orientation to or to serve a new end <the wing of a bird is an arm modified for flying>”) (accessed February 2, 2011)). Thus, at the very least, the claims must be read to require that the “modification step” be based on the object