decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal


User Functions

Username:

Password:

Don't have an account yet? Sign up as a New User

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Oracle v. Google - Update on '702 Reexamination
Tuesday, September 20 2011 @ 09:00 AM EDT

One of the patents asserted in the Oracle v. Google case, U.S. Patent No. 5,966,702 [PDF], is subject to an ex parte reexamination as we have earlier reported. Oracle has now filed their response [PDF] to the first office action [PDF] in this reexamination. Not surprisingly, Oracle contends that the art cited by the examiner in the first office action is not relevant and that all of the claims should reissue as is.

There are nine claims in the patent that are being challenged, 3 independent claims (Claims 1, 7 and 13) and 6 dependent claims.

Those claims read (p. 51 of the PDF] as follows:

1. A method of pre-processing class files comprising:
determining plurality of duplicated elements in a plurality of class files;

forming a shared table comprising said plurality of duplicated elements;

removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files; and

forming a multi-class file comprising said plurality of reduced class files and said shared table....

5. The method of claim 1, wherein said step of determining a plurality of duplicated elements comprises:
determining one or more constants shared between two or more class files.
6. The method of claim 5, wherein said step of forming a shared table comprises:
forming a shared constant table comprising said one or more constants shared between said two or more class files.
7. A computer program product comprising:
a computer usable medium having computer readable program code embodied therein for pre-processing class files, said computer program product comprising:

computer readable program code configured to cause a computer to determine a plurality of duplicated elements in a plurality of class files;

computer readable program code configured to cause a computer to form a shared table comprising said plurality of duplicated elements;

computer readable program code configured to cause a computer to remove said duplicated elements from said plurality of class files to obtain a plurality of reduced class files; and

computer readable program code configured to cause a computer to form a multi-class file comprising said plurality of reduced class files and said shared table....

11. The computer program product of claim 7, wherein said computer readable program code configured to cause a computer to determine said plurality of duplicated elements comprises:
computer readable program code configured to cause a computer to determine one or more constants shared between two or more class files.
12. The computer program product of claim 11, wherein said computer readable program code configured to cause a computer to form said shared table comprises:
computer readable program code configured to cause a computer to form a shared constant table comprising said one or more constants shared between said two or more class files.
13. An apparatus comprising:
a processor;

a memory coupled to said processor;

a plurality of class files stored in said memory;

a process executing on said processor, said process configured to form a multi-class file comprising:

a plurality of reduced class files obtained from said plurality of class files by removing one or more elements that are duplicated between two or more of said plurality of class files; and

a shared table comprising said duplicated elements....

15. The apparatus of claim 13, wherein said duplicated elements comprise elements of constant pools of respective class files, said shared table comprising a shared constant pool.

16. The apparatus of claim 13, further comprising:

a virtual machine having a class loader and a runtime data area, said class loader configured to obtain and load said multi-class file into said runtime data area.
In rejecting these claims the examiner substantially relied upon the art cited by Google in its request for reexamination. Specifically, the examiner relied upon two prior patents:
USPN 5,815,718 [PDF] to Tock (file date 05/30/1996, issue date 09/29/1998, hereinafter, the "Tock patent" or '718; and

USPN 5,613,120 [PDF] to Palay, et al., (file date 10/20/1994, issue date 03/18/1997, hereinafter, the "Palay patent" or '120.

Each of the rejections, one under the Tock patent and one under the Palay patent, were based on Section 102 of the Patent Act, i.e., based on the cited prior art the claimed invention lacked novelty.

The critical elements of the three independent claims are embodied in Claim 1:

A method of pre-processing class files comprising:
determining plurality of duplicated elements in a plurality of class files;

forming a shared table comprising said plurality of duplicated elements;

removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files; and

forming a multi-class file comprising said plurality of reduced class files and said shared table>

The examiner explained how Tock disclosed each of these elements:
Tock discloses (1: 41-47) a method of pre-processing class files: "...an offline class loader that is used to produce an executable module whose classes are preloaded into memory without requiring runtime dynamic loading...the offline class loader modifies (pre-processing) the existing class structures to accommodate static loading." Tock discloses (FIG. 10, 8: 40-46) determining a plurality of duplicated elements in a plurality of class files: "...offline class loader proceeds to eliminate duplicate constants (determining plurality of duplicated elements)...For each class file (plurality of class files) (step 806), each entry in the class' constant pool is scanned for duplicate constants (step 812). Referring to FIG. 10, duplicate constants are detected by using a hash table."

Tock discloses (8: 45-55) forming a shared table comprising said plurality of duplicated elements: "Referring to FIG. 10, duplicate constants are detected by using a hash table (shared table). The hash value of the constant is determined by an appropriate hashing function (step 1102). A check is made to determine whether the hash value is contained in the hash table (step 1104). If the hash value exists in the hash table, then the constant is a duplicate and the entry is deleted from the constant pool by altering the constant's entry in the map table to reflect the memory location of the existing constant (step 1106). Otherwise, the constant's hash value and memory location are stored in the hash table (step 1108)."

Tock discloses (5: 38-50; 5: 29-34) removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files: ""The output of the offline class loader 302 can consist of two files: a constant pool file containing the constant data for the entire application; and an updated classfile (for each of said plurality of class files, class file is reduced by removing duplicates and representing as a single instance in constant pool file) containing the class data structures and class members..." "The offline class loader also performs a number of optimizations in order to produce a more compact representation of the executable code (duplicated elements removed). For example, the constant pool that is associated with each class is combined for all the classes residing in the application."

Tock discloses (FIG. 8B; 10: 29-32; 5: 38-50) a multi-class file comprising said plurality of reduced class files. Tock's class loader can output the constant pool file and updated class file as a single file. "Lastly, the offline class loader outputs the universal constant pool, an updated classfile containing the class data structures and the indicators specifying the memory storage requirements, as well as a special boot time indicator (step 930)." "The output of the offline class loader 302 can consist of two files: a constant pool file containing the constant data for the entire application; and an updated classfile containing the class data structures and class members. The data in both of these files is formatted as data definitions, where each definition specifies a bytecode and an offset indicating a memory location. The updated class file will include the memory storage indicators which will indicate in which type of memory storage device a particular set of bytecodes is to reside. However, the method and system described herein is not limited to producing these two files. Other file configuration can be used including, but not limited to, a single file containing all the related class data."

The examiner also explained how Palay discloses each of these elements:
Palay discloses (1: 11-14) a method of pre-processing class files by way of compiling and linking class files of object-oriented computer programs: "The present invention relates generally to software compilers and linkers, and more particularly to software compilers and linkers for compiling object-oriented computer programs."

Palay discloses (FIG. 6; 28: 39-61) determining a plurality of duplicated elements in a plurality of class files, identifying and removing duplicate class definitions and duplicate class symbol entries. "Two issues that must be addressed when doing this merge operation are what to do about duplicate members and the mapping of references from the relocations to the merged class instance table and the merged class symbol table. When merging the class definition tables 414, duplicate non-dynamic and internal dynamic class definitions are removed. Duplicate definitions of dynamic classes are considered to be an error. When merging class instance tables 416, duplicate entries are considered to be an error. Duplicate entries in the class symbol tables 408 are removed. There are no duplicate entries in the class relocation tables 412."

Palay discloses (28: 39-61) forming a shared table comprising said plurality of duplicated elements and creating merged tables as part of merging class information. "In step 606, the linker 112 reads in the object files 106,108 and the shared libraries 110 and merges together the class information contained in these files." "Two issues that must be addressed when doing this merge operation are what to do about duplicate members and the mapping of references from the relocations to the merged class instance table and the merged class symbol table. When merging the class definition tables 414, duplicate non-dynamic and internal dynamic class definitions are removed. Duplicate definitions of dynamic classes are considered to be an error. When merging class instance tables 416, duplicate entries are considered to be an error. Duplicate entries in the class symbol tables 408 are removed. There are no duplicate entries in the class relocation tables 412."

Palay discloses (28: 54-56) removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files and identifying and removing duplicate class definitions and duplicate class symbol entries. "When merging the class definition tables 414, duplicate non-dynamic and internal dynamic class definitions are removed."

Palay discloses (12: 11-14) a compiler that generates information about classes (plurality of class files) and how they are used. Such information is called information and is embedded in the object file produced by the compiler." Abstract, "A linker links the object file (plurality of object files) potentially with at least one other object file or shared library to thereby generate an executable file or shared library." Further actions performed by the linker, i.e., removing duplicates, necessarily results in reduced class files.

Palay discloses (7: 51-54) a multi-class file comprising said plurality of reduced class files and said shared table. Palay's linker creates a shared library in the form of an object file from the merged class information: "[T]he static linker 114 generates another shared library. As will be appreciated, a shared library is in the form of an object file." Also see FIG. 4 and Abstract.

Oracle, in turn, argues that Tock and Palay do not, in fact, disclose each of the elements of the critical independent claims. During an interview with the examiner, Oracle asserted that:
Patent Owner presented that Palay discloses "object files," not "class files," where "class files" comprise machine-independent bytecode and "object files" comprise machine code. [emphasis added]

Patent Owner further presented that Tock fails to disclose the recited "multi-class file," which is clearly defined in the '702 Patent as a machine-independent file or package comprising reduced class files. ('702 Patent, 1:29-31, 2:66-3:1, 4:63-5:28, and 10:25-51.) Instead, Tock discloses producing an "executable module," which is a runtime representation (i.e., a memory representation of a loaded class) of the classes for a particular client device, and is not in a machine-independent format. (Tock, 1:41-44, 5:38-50, and 7:36-8:13.)

In lay terms the Oracle argument is that Tock and Palay are machine specific while the '702 claims are machine independent, i.e., the inherent nature of Java. This appears to be the crux of the Oracle argument presented both during the interview with the examiner and in this office action response. If the examiner accepts this distinction, the question then becomes whether Tock and Palay remain prior art to '702, and if so, is there an obviousness rejection to be made under Section 103. That remains to be seen.

**************

Reexamination Docket

Patent No. 5966702
Reexamination Control No. 90/011492

Granted 3/23/11

Request for Ex Parte Reexamination [PDF]

Exhibit 4 - Claim Chart [PDF]

Exhibit 5 - Claim Chart [PDF]

Order Granting Reexamination [PDF]

Office Action in Ex Parte Reexamination [PDF]

Response to First Office Action [PDF]

******************

Documents

Office Action in Ex Parte Reexamination:

Reexamination

Claims 1, 5-7,11-13,15, and 16 of USPN 5,966,702 to Fresko et al. (hereinafter '702) (file date 10/31/1997, issue date 10/12/1999) are under reexamination. The Reexamination control number is 90/011,492.

Notice Regarding Certain Reexamination Issues

The patent owner is reminded of the continuing responsibility under 37 CFR 1.565(a), to apprise the Office of any litigation activity, or other prior or concurrent proceeding, involving this patent under reexamination throughout the course of this reexamination proceeding. The third party requester is also reminded of the ability to similarly apprise the Office of any such activity or proceeding throughout the course of this reexamination proceeding. See MPEP §§ 2207,2282 and 2286.

Extensions of time under 37 CFR 1.136(a) will not be permitted in these proceedings because the provisions of 37 CFR 1.136 apply only to "a Patent Applicant" and not to parties in a reexamination proceeding. Additionally, 35 U.S.C. 305 requires that reexamination proceedings "will be conducted with special dispatch" (37 CFR 1.550(a)). Extension of time in ex parte reexamination proceedings are provided for in 37 CFR 1.550(c).

Information Disclosure Statement

IDS received 04/28/2011 has been considered. Citations lacking dates are lined through. Court proceedings have been considered. However, the citations to court proceedings do not meet the requirements of 37 CFR 1.98 and have been lined through. Where patents, publications, and other such items of information are submitted by a party (patent owner or requester) in compliance with the requirements of the rules, the requisite degree of consideration to be given to such information will be normally limited by the degree to which the party filing the information citation has explained the content and relevance of the information. The initials of the examiner placed adjacent to the citations on the form PTO /SB /08A and 08B or its equivalent, without an indication to the contrary in the record, do not signify that the information has been considered by the examiner any further than to the extent noted above. See MPEP 2256.

Prior Art References

USPN 5,815,718 to Tock (file date 05/30/1996, issue date 09/29/1998, hereinafter, the "Tock patent" or '718, qualifies as a 102(e) reference. USPN 5,613,120 to Palay, et al., (file date 10/20/1994, issue date 03/18/1997, hereinafter, the "Palay patent" or '120), qualifies as a 102(a) reference.

Claim Rejections - 35 USC § 102

The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless -

(a) the invention was known or used by others in this country, or patented or described in a printed publication in this or a foreign country, before the invention thereof by the applicant for a patent.

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed in the United States before the invention by the applicant for patent or (2) a patent granted on an application for patent by another filed in the United States before the invention by the applicant for patent, except that an international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this subsection of an application filed in the United States only if the international application designated the United States and was published under Article 21(2) of such treaty in the English language.
Rejections

Claims 1,5-7,11-13,15, and 16 are rejected under 35 U.S.C. 102(e) as being anticipated by USPN 5,815,718 to Tock. See Request (02/15/2011) at pp. 10-11, 13, and Exhibit 4.

Per claim 1, Tock discloses (1: 41-47) a method of pre-processing class files: "...an offline class loader that is used to produce an executable module whose classes are preloaded into memory without requiring runtime dynamic loading...the offline class loader modifies (pre-processing) the existing class structures to accommodate static loading." Tock discloses (FIG. 10, 8: 40-46) determining a plurality of duplicated elements in a plurality of class files: "...offline class loader proceeds to eliminate duplicate constants (determining plurality of duplicated elements)...For each class file (plurality of class files) (step 806), each entry in the class' constant pool is scanned for duplicate constants (step 812). Referring to FIG. 10, duplicate constants are detected by using a hash table."

Tock discloses (8: 45-55) forming a shared table comprising said plurality of duplicated elements: "Referring to FIG. 10, duplicate constants are detected by using a hash table (shared table). The hash value of the constant is determined by an appropriate hashing function (step 1102). A check is made to determine whether the hash value is contained in the hash table (step 1104). If the hash value exists in the hash table, then the constant is a duplicate and the entry is deleted from the constant pool by altering the constant's entry in the map table to reflect the memory location of the existing constant (step 1106). Otherwise, the constant's hash value and memory location are stored in the hash table (step 1108)."

Tock discloses (5: 38-50; 5: 29-34) removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files: ""The output of the offline class loader 302 can consist of two files: a constant pool file containing the constant data for the entire application; and an updated classfile (for each of said plurality of class files, class file is reduced by removing duplicates and representing as a single instance in constant pool file) containing the class data structures and class members..." "The offline class loader also performs a number of optimizations in order to produce a more compact representation of the executable code (duplicated elements removed). For example, the constant pool that is associated with each class is combined for all the classes residing in the application."

Tock discloses (FIG. 8B; 10: 29-32; 5: 38-50) a multi-class file comprising said plurality of reduced class files. Tock's class loader can output the constant pool file and updated class file as a single file. "Lastly, the offline class loader outputs the universal constant pool, an updated classfile containing the class data structures and the indicators specifying the memory storage requirements, as well as a special boot time indicator (step 930)." "The output of the offline class loader 302 can consist of two files: a constant pool file containing the constant data for the entire application; and an updated classfile containing the class data structures and class members. The data in both of these files is formatted as data definitions, where each definition specifies a bytecode and an offset indicating a memory location. The updated class file will include the memory storage indicators which will indicate in which type of memory storage device a particular set of bytecodes is to reside. However, the method and system described herein is not limited to producing these two files. Other file configuration can be used including, but not limited to, a single file containing all the related class data."

Per claims 5 and 6, Tock discloses (8: 40-46; 9: 27-29; FIG. 10) determining one or more constants shared between two or more class files and forming a shared constant table comprising said one or more constants shared between said two or more class files. Tock describes scanning each class's constant pool for duplicate constants to be eliminated and merging the constants into a universal constant pool. "Next, the offline class loader proceeds to eliminate duplicate constants. This is performed in order to combine the constant pools of all the classes in a space efficient manner. For each class file (step 806), each entry in the class' constant pool is scanned for duplicate constants (step 812). Referring to FIG. 10, duplicate constants are detected by using a hash table." "Once space is allocated for the universal constant pool, each entry from the various class constant pools is merged into the universal constant pool (step 902)."

Per claim 7, Tock discloses (1: 4-7) a computer program product: "The present invention relates generally to object-oriented computer systems having classes that are dynamically loaded at runtime, and particularly to a system and method for a subset of the classes in a read-only memory."

Tock discloses (1: 41-47; 4: 6-34) a computer usable medium having computer readable program code embodied therein for pre-processing class files, using an offline class loader: "In summary, this disclosure pertains to an offline class loader that is used to produce an executable module whose classes are preloaded into memory without requiring runtime dynamic loading. The executable module, nevertheless, contains a class structure that is tailored for runtime dynamic loading. Thus, the offline class loader modifies the existing class structures to accommodate static loading." "Referring to FIG. 1, a server computer typically includes one or more processors 112, a communications interface 116, a user interface 114, and memory 110. Memory 110 stores...an operating system 118...an Internet communications manager program or other type of network access procedures 120... a compiler 122... a source code repository 124 ... . a class file repository 128... one or more class libraries 131 containing class files... an offline class loader 132 ... an assembler 134 which produces an object file representing the class members, class data structures, and memory storage indicators in a format that is recognizable for the linker., a linker 136 for determining the memory layout for a set of preloaded classes and for resolving all symbolic references., a browser 138...and one or more data files 146 for use by the server." (emphasis added) See limitations further addressed in claim 1 above.

The limitations of claims 11 and 12 are addressed in claims 5 and 6 above, respectively.

Per claim 13, Tock's description (FIG. 1; 4: 6-34) of a server computer includes an apparatus, including a processor, memory, class files stored in memory, processes executing on said processor and a shared table, as addressed in claim 1 above. See Tock FIG. 8B; 5: 29-50; 8: 40-46; 10: 29-32.

Per claim 15, Tock discloses (8: 40-46; 10: 29-32) that the duplicated elements comprise elements of constant pools of respective class files, said shared table comprising a shared constant pool. Tock describes eliminating duplicate constants and combining constant pools into a universal constant pool. "Next, the offline class loader proceeds to eliminate duplicate constants. This is performed in order to combine the constant pools of all the classes in a space efficient manner. For each class file (step 806), each entry in the class' constant pool is scanned for duplicate constants (step 812). Referring to FIG. 10, duplicate constants are detected by using a hash table." "Lastly, the offline class loader outputs the universal constant pool, an updated class file containing the class data structures and the indicators specifying the memory storage requirements, as well as a special boot time indicator (step 930)."

Per claim 16, Tock discloses (FIG. 12; 3: 46-52; 10; 29-43) a virtual machine having a class loader and a runtime data area, said class loader configured to obtain and load said multi-class file into said runtime data area. Tock describes a boot time initiator that loads a multi-class file into the runtime data area. "Lastly, the offline class loader outputs the universal constant pool, an updated class file containing the class data structures and the indicators specifying the memory storage requirements, as well a special boot time initiator (step 930). Referring to FIG. 12, the preloadable executable module and boot time initiator 1220 are permanently stored in the read-only memory of a client computer. Each time the client computer is powered on or rebooted, the boot time initiator 1220 is automatically executed. Among other tasks, the boot time initiator copies all methods and data that must be resident in random access memory during execution to the random access memory locations assigned to them by the linker...executing a Java browser (virtual machine)."

Claims 1 5-7,11-13, and 15 are rejected under 35 U.S.C. 102(a) as being anticipated by USPN 5,613,120 to Palay et al. See Request (02/15/2011) at pp. 11-12, 13, and Exhibit 5.

Per claim 1, Palay discloses (1: 11-14) a method of pre-processing class files by way of compiling and linking class files of object-oriented computer programs: "The present invention relates generally to software compilers and linkers, and more particularly to software compilers and linkers for compiling object-oriented computer programs."

Palay discloses (FIG. 6; 28: 39-61) determining a plurality of duplicated elements in a plurality of class files, identifying and removing duplicate class definitions and duplicate class symbol entries. "Two issues that must be addressed when doing this merge operation are what to do about duplicate members and the mapping of references from the relocations to the merged class instance table and the merged class symbol table. When merging the class definition tables 414, duplicate non-dynamic and internal dynamic class definitions are removed. Duplicate definitions of dynamic classes are considered to be an error. When merging class instance tables 416, duplicate entries are considered to be an error. Duplicate entries in the class symbol tables 408 are removed. There are no duplicate entries in the class relocation tables 412."

Palay discloses (28: 39-61) forming a shared table comprising said plurality of duplicated elements and creating merged tables as part of merging class information. "In step 606, the linker 112 reads in the object files 106,108 and the shared libraries 110 and merges together the class information contained in these files." "Two issues that must be addressed when doing this merge operation are what to do about duplicate members and the mapping of references from the relocations to the merged class instance table and the merged class symbol table. When merging the class definition tables 414, duplicate non-dynamic and internal dynamic class definitions are removed. Duplicate definitions of dynamic classes are considered to be an error. When merging class instance tables 416, duplicate entries are considered to be an error. Duplicate entries in the class symbol tables 408 are removed. There are no duplicate entries in the class relocation tables 412."

Palay discloses (28: 54-56) removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files and identifying and removing duplicate class definitions and duplicate class symbol entries. "When merging the class definition tables 414, duplicate non-dynamic and internal dynamic class definitions are removed."

Palay discloses (12: 11-14) a compiler that generates information about classes (plurality of class files) and how they are used. Such information is called information and is embedded in the object file produced by the compiler." Abstract, "A linker links the object file (plurality of object files) potentially with at least one other object file or shared library to thereby generate an executable file or shared library." Further actions performed by the linker, i.e., removing duplicates, necessarily results in reduced class files.

Palay discloses (7: 51-54) a multi-class file comprising said plurality of reduced class files and said shared table. Palay's linker creates a shared library in the form of an object file from the merged class information: "[T]he static linker 114 generates another shared library. As will be appreciated, a shared library is in the form of an object file." Also see FIG. 4 and Abstract.

Regarding claims 5 and 6, Palay discloses (28: 54-56) determining one or more constants •shared between two or more class files and forming a shared constant table comprising one or more constants shared between two or more class files: Palay identifies duplicates among the shared data so that they can be removed. "When merging the class definition tables 414, duplicate non-dynamic and internal dynamic class definitions (constants) are removed."

Regarding claim 7, Palay discloses (33: 8-11; 1: 11 -14) a computer program product / computer usable medium having computer readable program code embodied therein for pre-processing class files. The compiling and linking of object-oriented computer programs described in Palay involves pre-processing class files. "21. A computer program product comprising a computer readable medium having computer program logic recorded thereon for enabling a computer system to compile and link a source file, said computer program product comprising..." "The present invention relates generally to software compilers and linkers, and more particularly to software compilers and linkers for compiling object-oriented computer programs."

Palay discloses (Abstract; 28: 50-61) computer readable program code configured to cause a computer to determine a plurality of duplicated elements in a plurality of class files. Palay describes identifying and removing duplicate class definitions and duplicate class symbol entries.

"A system and method for compiling and linking a source file is described. A compiler generates class information pertaining to object-oriented classes referenced in the source file. The class information is sufficient to enable a linker to resolve class definitions and to perform class relocation operations. The compiler also generates an object file from the source file. The object file includes the class information. The compiler generates the object file such that resolution of class definitions and performance of class relocation operations are delayed until operation of the linker. A linker links the object file potentially with at least one other object file or shared library to thereby generate an executable file or shared library. The linker uses the class information contained in the object file to resolve class definitions and to perform class relocation operations." "Two issues that must be addressed when doing this merge operation are what to do about duplicate members and the mapping of references from the relocations to the merged class instance table and the merged class symbol table. When merging the class definition tables 414, duplicate non-dynamic and internal dynamic class definitions are removed. Duplicate definitions of dynamic classes are considered to be an error. When merging class instance tables 416, duplicate entries are considered to be an error. Duplicate entries in the class symbol tables 408 are removed. There are no duplicate entries in the class relocation tables 412." See additional limitations addressed in the rejection of claim 1 above.

Claims 11 and 12 are computer program product versions of claims 5 and 6 above. See limitations addressed above.

Regarding claim 13, Palay discloses (FIG. 2) an apparatus comprising a processor and memory coupled to said processor. Palay discloses (6: 14-15; FIG. 4) a plurality of class files stored in said memory. The object files comprise class files. "A linker links the object file with other object files and shared libraries."

Palay discloses (7: 51-54; FIG. 4) a process executing on said processor said process configured to form a multi-class file. Palay's linker creates a shared library in the form of an object file from the merged class information. "[T]he static linker 114 generates another shared library. As will be appreciated, a shared library is in the form of an object file."

Palay discloses (28: 54-56) a plurality of reduced class files obtained from said plurality of class files by removing one or more elements that are duplicated between two or more of said plurality of class files: Palay describes identifying and removing duplicate class definitions and duplicate class symbol entries. "When merging the class definition tables 414, duplicate nondynamic and internal dynamic class definitions are removed." The merging of class information and the removal of duplicates as expressly described in Palay necessarily would provide reduced class files.

Palay discloses (28: 50-61) a shared table comprising said duplicated elements. Palay describes creating merged tables as part of merging class information. "Two issues that must be addressed when doing this merge operation are what to do about duplicate members and the mapping of references from the relocations to the merged class instance table and the merged class symbol table. When merging the class definition tables 414, duplicate non-dynamic and internal dynamic class definitions are removed. Duplicate definitions of dynamic classes are considered to be an error. When merging class instance tables 416, duplicate entries are considered to be an error. Duplicate entries in the class symbol tables 408 are removed. There are no duplicate entries in the class relocation tables 412."

Regarding claim 15, Palay discloses (28: 54-56) that the duplicated elements comprise elements of constant pools of respective class files, said shared table comprising a shared constant pool. Palay describes eliminating duplicates and creating merged tables of class information. "When merging the class definition tables 414, duplicate non-dynamic and internal dynamic class definitions are removed (redundant constants removed)."

Since requester did not request reexamination of claims 2-4, 8-10,14, and 17-23 and did not assert the existence of a substantial new question of patentability (SNQP) for such claims (see 35 U.S.C. § 311(b)(2); see also 37 CFR 1.915b and 1.923), such claims will not be reexamined. This matter was squarely addressed in Sony Computer Entertainment America Inc., et al v. Jon W. Dudas, Civil Action No. 1:05CV1447 (E.D.Va. May 22,2006), Slip Copy, 2006 WL 1472462. (Not Reported in F.Supp.2d.) The District Court upheld the Office's discretion to not reexamine claims in an inter partes reexamination proceeding other than those claims for which reexamination had specifically been requested. The Court stated:
To be sure, a party may seek, and the PTO may. grant, inter partes review of each and every claim of a patent. Moreover, while the PTO in its discretion may review claims for which inter partes review was not requested, nothing in the statute compels it to do so. To ensure that the PTO considers a claim for inter partes review, § 311 (b)(2) requires that the party seeking reexamination demonstrate why the PTO should reexamine each and every claim for which it seeks review. Here, it is undisputed that Sony did not seek review of every claim under the '213 and '333 patents. Accordingly, Sony cannot now claim that the PTO wrongly failed to reexamine claims for which Sony never requested review, and its argument that AIPA compels a contrary result is unpersuasive.

The Sony decision's reasoning and statutory interpretation apply analogously to ex parte reexamination, as the same relevant statutory language applies to both inter partes and ex parte reexamination. 35 U.S.C. § 302 provides that the ex parte reexamination "request must set forth the pertinency and manner of applying cited prior' art to every claim for which reexamination is requested" (emphasis added), and 35 U.S.C. § 303 provides that "the Director will determine whether a substantial new question of patentability affecting any claim of the patent concerned is raised by the request..." (Emphasis added). These provisions are analogous to the language of 35 U.S.C. § 311(b)(2) and 35 U.S.C. § 312 applied and construed in Sony, and would be construed in the same manner. As the Director can decline to reexamine non- requested claims in an inter partes reexamination proceeding, the Director can likewise do so in ex parte reexamination proceeding. See Notice of Clarification of Office Policy To Exercise Discretion in Reexamining Fewer Than All the Patent Claims (signed Oct. 5, 2006) 1311 OG 197 (Oct. 31,2006). See also MPEP § 2240, Rev. 5, Aug. 2006. Therefore, claims 2-4, 8-10, 14, and 17-23 will not be reexamined in this ex parte reexamination proceeding.

Text of Response to First Office Action:

Docket No.: 154892800400
(PATENT)

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE

_____________________
In re Ex Parte Reexamination of:
Nedim FRESKO et al.

Control No.: 90/011,492

Reexamination Filing Date: February 15, 2011

Patent No.: 5,966,702

Issue Date: October 12, 1999

For: METHOD AND APPARATUS FOR PRE-
PROCESSING AND PACKAGING CLASS
FILES

___________________

Examiner: M. Steelman

Group Art Unit: 3992

Confirmation No.: 8223

___________________

RESPONSE TO FIRST OFFICE ACTION

MS Ex Parte Reexam
Central Reexamination Unit
Commissioner for Patents
P.O. Box 1450
Alexandria, VA 22313-1450

Dear Sir:

INTRODUCTORY COMMENTS

In response to a first Office Action issued on June 6, 2011 ("the Action"), for which a response was due on August 6, 2011, and for which an extension of time to September 6, 2011 was requested and granted, Patent Owner provides the following remarks and requests reconsideration.
Listing of the Claims begins on page 2 of this paper.

Examiner Interview Summary begins on page 7.

Listing of the Exhibits begins on page 9.

Remarks begin on page 10 of this paper.

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

LISTING OF THE CLAIMS

Claim 1 (issued): A method of pre-processing class files comprising:
determining plurality of duplicated elements in a plurality of class files;

forming a shared table comprising said plurality of duplicated elements;

removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files; and

forming a multi-class file comprising said plurality of reduced class files and said shared table.

Claim 2 (issued): The method of claim 1, further comprising:
computing an individual memory allocation requirement for each of said plurality of reduced class files;

computing a total memory allocation requirement for said plurality of class files from said

individual memory allocation requirement of each of said plurality of reduced class files; and

storing said total memory allocation requirement in said multi-class file.

Claim 3 (issued): The method of claim 2, further comprising:
reading said total memory allocation requirement from said multi-class file;

allocating a portion of memory based on said total memory allocation requirement; and

loading said reduced class files and said shared table into said portion of memory.

Claim 4 (issued): The method of claim 3, further comprising:
accessing said shared table in said portion of memory to obtain one or more elements not found in one or more of said reduced class files.
Claim 5 (issued): The method of claim 1, wherein said step of determining a plurality of duplicated elements comprises:
determining one or more constants shared between two or more class files.

2

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

Claim 6 (issued): The method of claim 5, wherein said step of forming a shared table comprises:
forming a shared constant table comprising said one or more constants shared between said two or more class files.
Claim 7 (issued): A computer program product comprising:
a computer usable medium having computer readable program code embodied therein for pre-processing class files, said computer program product comprising:

computer readable program code configured to cause a computer to determine a plurality of duplicated elements in a plurality of class files;

computer readable program code configured to cause a computer to form a shared table comprising said plurality of duplicated elements;

computer readable program code configured to cause a computer to remove said duplicated elements from said plurality of class files to obtain a plurality of reduced class files; and

computer readable program code configured to cause a computer to form a multi-class file comprising said plurality of reduced class files and said shared table.

Claim 8 (issued): The computer program product of claim 7, further comprising:
computer readable program code configured to cause a computer to compute an individual memory allocation requirement of each of said plurality of reduced class files;

computer readable program code configured to cause a computer to compute a total memory

allocation requirement of said plurality of class files from said individual memory allocation requirement of each of said plurality of reduced class files; and

computer readable program code configured to cause a computer to store said total memory allocation requirement in said multi-class file.

Claim 9 (issued): The computer program product of claim 8, further comprising:
computer readable program code configured to cause a computer to read said total memory

3

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

allocation requirement from said multi-class file;

computer readable program code configured to cause a computer to allocate a portion of memory based on said total memory allocation requirement; and

computer readable program code configured to cause a computer to load said reduced class files and said shared table into said portion of memory.

Claim 10 (issued): The computer program product of claim 9, further comprising:
computer readable program code configured to cause a computer to access said shared table in said portion of memory to obtain one or more elements not found in one or more of said reduced class files.
Claim 11 (issued): The computer program product of claim 7, wherein said computer readable program code configured to cause a computer to determine said plurality of duplicated elements comprises:
computer readable program code configured to cause a computer to determine one or more constants shared between two or more class files.
Claim 12 (issued): The computer program product of claim 11, wherein said computer readable program code configured to cause a computer to form said shared table comprises:
computer readable program code configured to cause a computer to form a shared constant table comprising said one or more constants shared between said two or more class files.
Claim 13 (issued): An apparatus comprising:
a processor;

a memory coupled to said processor;

a plurality of class files stored in said memory;

a process executing on said processor, said process configured to form a multi-class file comprising:

a plurality of reduced class files obtained from said plurality of class files by removing one

4

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

or more elements that are duplicated between two or more of said plurality of class files; and

a shared table comprising said duplicated elements.

Claim 14 (issued): The apparatus of claim 13, wherein said multi-class file further comprises a memory requirement, said memory requirement being computed by said process.

Claim 15 (issued): The apparatus of claim 13, wherein said duplicated elements comprise elements of constant pools of respective class files, said shared table comprising a shared constant pool.

Claim 16 (issued): The apparatus of claim 13, further comprising:

a virtual machine having a class loader and a runtime data area, said class loader configured to obtain and load said multi-class file into said runtime data area.
Claim 17 (issued): The apparatus of claim 16, wherein said class loader is configured to allocate a portion of said runtime data area based on said memory requirement in said multi-class file.

Claim 18 (issued): The apparatus of claim 17, wherein said class loader is configured to load said plurality of reduced class files and said shared table into said portion of said runtime data area.

Claim 19 (issued): The apparatus of claim 16, wherein said virtual machine is configured to access said shared table when a desired element associated with a first class file is not present in a corresponding one of said plurality of reduced class files.

Claim 20 (issued): A memory configured to store data for access by a virtual machine executing in a computer system, comprising:
a data structure stored in said memory, said data structure comprising:

a plurality of reduced class files associated with a plurality of corresponding classes, said plurality of reduced class files configured to be loaded by the virtual machine for execution of said plurality of classes;

5

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

a shared table comprising one or more elements that are duplicated between two or more of said plurality of classes, said shared table configured to be loaded into the virtual machine to be accessed for said duplicated elements; and

a memory requirement value configured to be read by a class loader of the virtual machine to allocate a portion of a runtime data area for loading said plurality of reduced class files and said shared table.

Claim 21 (issued): The memory of claim 20, wherein said duplicated elements are removed from said plurality of reduced class files.

Claim 22 (issued): The memory of claim 20, wherein said duplicated elements comprise constants and said shared table comprises a shared constant pool.

Claim 23 (issued): The memory of claim 20, wherein said memory requirement value is computed from individual memory requirements of said plurality of reduced class files and a memory requirement of said shared table.

6

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

Interview Summary Pursuant to 37 C.F.R. 1.560(b)

Patent Owner thanks the Examiners for the courtesy of an in-person interview to discuss the Action on August 4, 2011. In attendance for the interview were Examiners Mary Steelman, Eric Kiss, and Fred Ferris, and for the Patent Owners, Christopher Eide (48,375), Julie Akhter (59,570), George Simion (47,089), Benjamin Goldberg (technical expert), Tracy Druce (35,493), and Lissi Mojica (63,421). Claims 1, 7, 13, and 16 and the Tock and Palay references were discussed during the interview. The following recitations of claim 1 were primarily discussed: "plurality of class files," "plurality of reduced class files," and "multi-class file." Additionally, claim 16 and its recitation of a "class loader" configured to load classes into a virtual machine were discussed.

Patent Owner presented that Palay discloses "object files," not "class files," where "class files" comprise machine-independent bytecode and "object files" comprise machine code. (See also, the Examiner Interview Agenda accompanying the Examiner's Interview summary mailed August 4,2011.)

Patent Owner further presented that Tock fails to disclose the recited "multi-class file," which is clearly defined in the '702 Patent as a machine-independent file or package comprising reduced class files. ('702 Patent, 1:29-31, 2:66-3:1, 4:63-5:28, and 10:25-51.) Instead, Tock discloses producing an "executable module," which is a runtime representation (i.e., a memory representation of a loaded class) of the classes for a particular client device, and is not in a machine-independent format. (Tock, 1:41-44, 5:38-50, and 7:36-8:13.) (See also, the Examiner Interview Agenda.)

In response to the Patent Owner's presentation, the Examiners inquired regarding the requirement that "class files" include bytecode. Patent Owner directed the Examiners to the clear definition provided in the specification that class files comprise bytecode, and further that bytecode is machine-independent (in particular, pointing to the '702 Patent specification that states, "[c]lass files contain bytecode instructions," and that bytecode instructions include code and data in a machine-independent format ('702 Patent, 1:34, 2:62-3:1). The proper scope of the claims will be discussed in detail in the response to the Office Action.

7

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

The Examiners appeared to appreciate the distinctions between the claimed invention and the cited references as presented by the Patent Owner.

8

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

LISTING OF EXHIBITS

The following Exhibits are submitted herewith.

Exhibit Description
A Declaration of Prof. Benjamin Goldberg ("Goldberg Declaration")
B Curriculum Vitae of Prof. Benjamin Goldberg

9

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

REMARKS

Introduction

Claims 1, 5-7, 11-13, 15, and 16 are pending in the present reexamination of U.S. Patent No. 5,966,702 ("the '702 Patent"). The '702 Patent is directed to a method, computer program product, and apparatus for pre-processing and packaging a plurality of class files and forming a multi-class file. This is achieved through the following unique combination of features as set forth in exemplary claim 1:

  • "determining a plurality of duplicated elements in a plurality of class files"1

  • "forming a shared table comprising said plurality of duplicated elements"

  • "removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files" and

  • "forming a multi-class file comprising said plurality of reduced class files and said shared table."
The Office, during the original examination, found this combination of features—specifically "forming a multi-class file comprising said plurality of reduced class files and said shared table"—to be patentable over the prior art. (Office Action dated Jan. 29, 1999, page 3.)

The art of the present reexamination fails to compel a different conclusion. Neither of the cited references—Tock nor Palay—teaches or suggests the above claimed combination of features. In fact, and as stated by Professor Goldberg in his declaration, "the cited references fail to disclose an important feature of the claimed invention of the '702 Patent, overlooked by the original request, namely that the 'reduced class files' obtained by, and the 'multi-class file' resulting from the claimed method and apparatus are—like Java class files or other class files containing bytecode— machine-independent, allowing them to be downloaded from a server to a variety of hardware systems." (Goldberg Decl., ¶ 13.) For example, the '702 Patent states, "[t]o accommodate the

10

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

variety of hardware systems used by clients, applications or applets are distributed in a platform- or machine-independent format such as the Java® class file format. Object-oriented applications are formed from multiple class files that are accessed from servers and downloaded individually as needed" ('702 Patent, 1:29-35); and "[w]hen a virtual machine wishes to load the classes in the multi-class file, the location of the multi-class file is determined and the multi-class file is downloaded from a server, if needed." ('702 Patent, 5:18-22.) Furthermore, the '702 Patent is clear that the multi-class files of the claimed invention serve as a "single package for efficient storage" of a plurality of class files,2 addressing the storage inefficiencies of JAR files containing (machine-independent) class files. ('702 Patent, 4:44-5:5.)

Tock's disclosure is quite different than the claimed features of the '702 Patent. "Tock generally discloses a method and system for statically loading classes in read-only memory (ROM) of a client device. Tock's system became known as 'ROMizer.'" (Goldberg Decl., ¶ 16.) Tock describes that the goal of the disclosed offline class loader is to determine which methods and variables associated with each class can be stored in ROM and which must be stored in a random access memory (RAM) device. (Tock, 1:41-67.) According to Professor Goldberg's declaration "[t]he package output by the class loader of Tock is a machine-dependent, 'executable module,' and is formatted as 'data definitions, where each definition specifies a bytecode and an offset indicating a memory location'—that is, the output of the class loader is a runtime representation (i.e., a memory representation of a loaded class) of the classes for a particular client device, and is no longer in a machine-independent format. (Id. at 1:41-44, 5:38-50, and 7:36-8:13.)" (Goldberg Decl., ¶ 17.) "Thus, Tock's 'executable module' contains a machine-dependent (i.e., machine-specific) memory representation of the class information and is not a 'multi-class file' as recited." (Goldberg Decl., ¶ 17.)

11

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

Palay's disclosure is also very different than the claimed features of the '702 Patent. Palay describes systems and methods for compiling C++ source code files into object files and linking the object files into an executable file, in a manner that allows the linker to resolve class definitions and perform class relocation when creating the executable file. (Palay, Abstract, 6:1-27.) According to Prof. Goldberg's declaration, "[t]he '702 Patent makes clear that '[c]lass files contain bytecode instructions,' and further that such bytecode instructions of the 'class files' are machine-independent. ('702 Patent, 1:29-38; 2:62-3:15.)" (Goldberg Decl., ¶ 30.) Further, Palay fails to disclose class files (or an equivalent thereto) as object files do not contain bytecode instructions or a machine-independent format. "In fact, the very nature of object files—being compiled from source code (e.g., C++ source code) into machine code—is that they are machine-dependent." (Goldberg Decl, ¶ 31.) Therefore, object files are not, and do not disclose, "class files" as recited. Moreover, the described manipulation of the object files in Palay fails to disclose a "multi-class file" as recited. As such, basic features of the claims are deficient in Palay.

Accordingly, Patent Owner submits that all of the rejections should be withdrawn.

II. Brief Summary of the Invention

As stated in Professor Goldberg's declaration, "[A]n important feature of the claimed invention of the '702 Patent, overlooked by the original Request, [is] that the 'reduced class files' obtained by, and the 'multi-class file' resulting from the claimed method and apparatus are—like Java class files and other class files containing bytecode—machine-independent, allowing them to be downloaded from a server to a variety of hardware systems." (Goldberg Decl., % 13.) For example, the '702 Patent states, "[t]o accommodate the variety of hardware systems used by clients, applications or applets are distributed in a machine-independent format such as the Java® class file format. Object-oriented applications are formed from multiple class files that are accessed from servers and downloaded individually as needed" ('702 Patent, 1:29-35); and "[w]hen a virtual machine wishes to load the classes in the multi-class file, the location of the multi-class file is

12

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

determined and the multi-class file is downloaded from a server, if needed." ('702 Patent, 5:18-22.) Furthermore, the '702 Patent is clear that the "multi-class file" of the claimed invention serves as a "single package for efficient storage," addressing the storage inefficiencies of JAR files containing (machine-independent) class files. ('702 Patent, 4:44-5:5.) "Because a multi-class file as used in the '702 Patent is in a machine-independent format, the 'reduced class files' it contains are also machine-independent, just like the 'class files' from which they were obtained." (Goldberg Decl., ¶ 13.) The '702 Patent makes "clear that the 'multi-class file' and the plurality of reduced 'class files' it contains are to be loaded by a virtual machine, further indicating that they must be machine-independent (i.e., the reduced class files and multi-class file contain machine-independent bytecode). ('702 Patent, 1:29-31, 2:66-3:1, 4:63-5:28, and 10:25-51.)" (Goldberg Decl., ¶ 13.)

Prior to the filing of the '702 Patent, an issue with the class file format and the class loading process was that class files often contained duplicated data. ('702 Patent, 1:38-48.) The storage, transfer, and processing of the individual class files were generally inefficient due to the redundancy of the information. Also, an application may contain many class files, all of which are loaded and processed in separate transactions. This slowed down the application and degraded memory allocator performance. Further, a client was typically required to maintain a physical connection to the server for the duration of the application transfer process in order to access class files on demand. (Id.)

A Java archive (JAR) format had been developed to group class files together in a single transportable package known as a JAR file. (Id. at 4:45-60.) Broadly speaking, JAR files encapsulate Java classes in archived, compressed format. A JAR file can be identified in an HTML document within an applet tag, and when a browser application reads the HTML document and finds the applet tag, the JAR file is downloaded to the client computer and decompressed. Thus, a group of class files may be downloaded from a server to a client in one download transaction. After downloading and decompressing, the archived class files are available on the client system for

13

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

individual loading as needed in accordance with standard class loading procedures. The archived class files remain subject to storage inefficiencies, however, due to duplicated data between files, as well as memory fragmentation due to the performance of separate memory allocations for each class file. (Id.)

A breakthrough of the '702 Patent included a new approach for pre-processing and packaging class files in a manner to reduce memory requirements. The approach employed a "multi-class file," which is a machine-independent package containing a set of reduced class files and related items from a set of class files. ('702 Patent, 1:29-31, 2:66-3:1, 4:63-5:28, and 10:25-51.) (Goldberg Decl., 13.) The general idea of the "multi-class file" is to eliminate code and data duplicated among a plurality of class files (e.g., the plurality of class files associated with a particular application). Also, only one copy of duplicated code and data is placed in the "multi-class file" along with the non-duplicated code and data. (Id. at Abstract, 5:6-17.) An aspect of the claimed invention broadly includes forming a shared table comprising duplicated elements of the class files, obtaining reduced class files (what remains of the class files with the duplicated elements removed), and forming a multi-class file containing the reduced class files and the shared table of duplicated elements. This breakthrough is expressly reflected in the claims, for example, in claim 1 (and similarly in other independent claims) as "determining ... duplicated elements in a plurality of class files," "forming a shared table" of the duplicated elements, "removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files," and "forming a multi-class file comprising said plurality of reduced class files and said shared table."

An exemplary method for pre-processing and packaging a set of class files into a multi-class file is illustrated in the flow diagram of Figure 4 (shown below) and described at least in column 9, lines 9-65. Additionally, an exemplary embodiment of the multi-class file format is depicted in Figure 5 (shown below) and described at least in column 9, lines 66-67.

14

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

The exemplary method for forming a multi-class file begins at 400 with a set of class files "S" (typically part of one application), where the class files contain machine-independent bytecode. At 401, the pre-processor reads and parses each class in "S." At 402, the pre-processor examines the constant pool tables of each class to determine the set of class file constants (e.g., strings and numerics, as well as others specific to the class file format) that can be shared between classes in "S." A shared constant pool table is created at 403, with all duplicate constants determined from 402. At 404, the pre-processor removes the duplicate, shared constants from the individual constant pool tables of each class. At 405, the pre-processor may compute the in-core memory requirements of each class in "S," as would normally be determined by the class loader for the given virtual machine. This is the amount of memory the virtual machine would allocate for each class, if the

15

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

virtual machine were to load each class separately. After considering all classes in "S," and the additional memory requirement for the shared constant pool table, the total memory requirement for loading "S" is computed at 406. At 407, the pre-processor produces a "multi-class file" (mclass) file that contains the shared constant pool table created at 403, information about memory allocation requirements determined at 405 and 406, and all classes in "S," with their respective reduced constant pool tables. The mclass file for the class set "S" is output at 408.

Figure 5 is a simplified block diagram of an embodiment of the multi-class file format output by the method of Figure 4. Mclass file 500 comprises shared constant pool table 501, memory allocation requirements 502, and the set of individual classes 503. The set of individual classes 503 comprises the class file structures for classes 1 through N (N being the number of classes in the set), along with the corresponding reduced constant pool tables 1 through N. The size of the shared constant pool table 501 is dependent on the number of duplicate constants found in the set of classes. The memory allocation requirements 502 may be represented as a single value indicating the total memory needed to load all class structures (classes 1 through N) in individual classes 503, as well as the shared constant pool table 501.

The "multi-class file" is typically considerably smaller than the sum of the sizes of the individual class files from which it was derived because the classes therein share information. It can be loaded by the virtual machine during or prior to the execution of an application, instead of having to load each contained class on demand. The virtual machine is also able to take advantage of the allocation requirements information to pre-allocate all required memory for the multi-class set. This solves many of the problems associated with class loading. (Id. at 10: 16-24.)

The smaller size of the "multi-class file" (relative to the plurality of class files before processing) results in the classes taking up less space on servers or storage devices, less network or file transfer time to read, and less memory when loaded, as well as faster execution (in part, because shared constants are resolved at most once). (Id. at 10: 25-35.)

16

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

As further described in the '702 Patent (e.g., at column 10, lines 36-51), a "multi-class file" further consolidates the loading of required classes instead of loading the classes one by one. Using allocation information, only one dynamic memory allocation is needed instead of multiple allocation operations. This results in less fragmentation, less time spent in the allocator, and less waste of memory space. Because the class files are consolidated in a single "multi-class file," only a single transaction is typically needed to perform a network or file system search, to set up a transfer session (e.g., HTTP), and to transfer the entire set of classes. This minimizes pauses in the execution that can result from such transactions and provides for deterministic execution, with no pauses for class loading during a program run. Also, once the multi-class file is loaded and parsed, there is no need for the computer executing the program to remain connected to the source of the classes.

Accordingly, the approach employed by the '702 Patent includes determining a plurality of duplicated elements in a plurality of "class files" (which contain machine-independent bytecode) and forming a "multi-class file," which is a package containing a set of reduced class files and other related items in a machine-independent format similar to the class files from which the package was formed. Neither of the cited references discloses or reasonably suggests such features.

III. Claims 1, 5-7,11-13,15, and 16 Are Not Anticipated by Tock (Ground 1)

A. Tock fails to disclose or suggest a "multi-class file," a machine-independent package of processed "class files."

Tock generally discloses a method and system for statically loading classes in read-only memory (ROM) of a client device. Tock's system became known as 'ROMizer'." (Goldberg Decl., 1[ 16.) Tock teaches that the goal of the offline class loader is to determine which methods and variables associated with each class can be stored in a ROM and which must be stored in a random

17

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

access memory (RAM) device. (Tock, at 1:8-21.) Methods that invoke Java interfaces or utilize non-static instance variables need to reside in random access memory. This is because the bytecodes that implement interfaces are determined at runtime and non-static instance variables are altered for each instantiation of the associated class. The offline class loader finds these methods and variables and flags them by inserting a special indicator that specifies that they are to be loaded in a RAM device. "The offline class loader performs a number of optimizations in order to produce a more compact representation of the executable code." (Goldberg Decl., ¶ 18.) For example, "the constant pool that is associated with each class is combined for all the classes residing in the application. In addition, the offline class loader performs additional processing to tailor the class files that were originally structured for dynamic loading for a preloaded class environment." (Goldberg Decl., ¶ 18.)

Further, "Tock discloses that the offline class loader performs two other transformations to the class files to output the executable module that renders the offline class loader's output machine-dependent). (Tock, Fig. 3; 6:37-44.)" (Goldberg Decl., ¶ 19.) First, a "static initializer is created, which performs class initialization for the classes that are preloaded." (Tock, 6:37-41.) Second, "the offline class loader performs bytecode quickening of the bytecodes, which renders them machine-dependent: 'bytecodes using a non-quick instruction that symbolically reference methods are recoded in a quick instruction format that references the methods directly.' (Tock, 6:41-44.)" (Goldberg Decl., ¶ 19.) According to Prof. Goldberg's declaration, "[t]he altered bytecodes that result from these steps are no longer the bytecodes from the class files after duplicate removal. As such, the output of Tock, a runtime representation of processed class files for a client device, is not, and does not include, a file or other data structure that includes machine-independent bytecode." (Goldberg Decl., ¶ 19.) "In contrast to Tock, the '702 Patent makes clear that the structure of the recited 'class file' must contain machine-independent bytecode. ('702 Patent at least at 4:63-5:28.)" (Goldberg Decl., ¶ 19.)

18

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

B. Tock fails to disclose or suggest "a multi-class file" as recited by claims 1,5-7,
11-13,15, and 16.

Claim 1 recites,3 inter alia:
"forming a multi-class file comprising said plurality of reduced class files and said shared table."
As described above and by Professor Goldberg's declaration, "a 'multi-class file,' read in light of the specification of the '702 Patent, is a machine-independent package that includes a set of reduced class files and a shared table of duplicated elements determined from the set of reduced class files. ('702 Patent, 5:6-17.)" (Goldberg Decl., ¶ 14.) Additionally, "the '702 Patent makes clear that the recited 'class files' and 'multi-class file' must contain machine-independent bytecode. (Id. at 1:29-35, 2:66-3:1, 4:63-5:28, and 10:25-51)." (Goldberg Decl., ¶ 14.) Further, the "multi-class file" consolidates the loading of a plurality of classes associated with an application, for example, and provides for more efficient storage, transfer, and processing of the plurality of machine-independent class files. (Id. at 1:29-35 and 4:63-5:5.) As such, and according to Professor Goldberg's declaration, "one of ordinary skill in the art would necessarily read the recited 'multi-class file' as requiring a machine-independent package." (Emphasis added; Goldberg Decl., ¶ 14.)

The Office Action states "Tock discloses (FIG. 8B; 10: 29-32: 38-50) a multi-class file comprising said plurality of reduced class files." (Action, page 6). The Office appears to primarily rely on Tock's disclosure of an offline class loader that can output a constant pool file and updated class files as "a single file" for disclosing the recited "multi-class file." (Action, page 6.) As described below, however, the output of Tock's offline class loader, i.e., the "single file," is an '"executable module' [that] contains a machine-dependent (i.e., machine-specific) memory representation of the class information and is not a 'multi-class file' as required by the claims." (Goldberg Decl., ¶ 17.)

19

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

In particular, Patent Owner submits that Tock is quite different than the claimed invention of the '702 Patent. Tock discloses a method and system for statically loading classes in read-only memory (ROM) of a client device. As described above, and according to Prof. Goldberg's declaration, "[t]he output of Tock, a runtime representation of processed class files for a client device, is not, and does not include, a file or other data structure that includes machine-independent bytecode." (Goldberg Decl., ¶ 19.) More specifically, Professor Goldberg states "I conclude that the Requester and Office have overlooked that the package output by the offline class loader of Tock is formatted as 'data definitions, where each definition specifies a bytecode and an offset indicating a memory location' — that is, the output of the class loader is a runtime representation (i.e., a memory representation of a loaded class) of the classes for a particular client device, and is no longer in a device independent format." (Goldberg Decl. 17.) (Tock, 5:38-50 and 7:36-8:13.) Further to this point, Tock states that the offline class loader "is used to produce an executable module whose classes are preloaded into memory without requiring runtime dynamic loading." (Tock, 1:41-44) "Tock's 'executable module' contains a machine-dependent (i.e., machine-specific) memory representation of the class information and is not a 'multi-class file' as required by the claims." (Goldberg Decl., ¶ 17.)

Tock further discloses that the offline class loader performs two other transformations that render its output machine-dependent. (Tock, Fig. 3; 6:37-44.) (Goldberg Decl., ¶ 19.) First, a "static initializer is created, which performs class initialization for the classes that are preloaded." (Tock, 37-41.) Second, the offline class loader performs bytecode quickening of the bytecodes, which renders them machine-dependent: "bytecodes using a non-quick instruction that symbolically reference methods are recoded in a quick instruction format that references the methods directly." (Tock, 41-44.) "The altered bytecodes that result from these steps are no longer the bytecodes from the class files after duplicate removal." (Goldberg Decl., ¶ 19.) "As such, the output, a runtime representation of processed class files for a client device, is not, and does not include, a file or other

20

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

data structure that includes machine-independent bytecode, and therefore would not have been considered a 'multi-class file'" as required by the claims of the '702 Patent. (Goldberg Decl., ¶ 19.)

The Office further cites to FIG. 8B and column 10, lines 29-32 in support of the rejection. (Action, page 6.) These portions, however, do not cure the deficiency of Tock discussed above. For example, "FIG 8B and column 10, lines 29-32 discloses that the universal constant pool file and updated class files are output by the class loader, and include an indicator specifying the memory storage requirements and a boot time initiator. This description fails to disclose or suggest that the output is a 'multi-class' file as recited; rather, it is further made clear that the output is machine-dependent because it includes a boot time initiator for a particular client device." (Goldberg Decl., ¶ 20.)

Patent Owner also submits that no intermediate form of the processed class files, e.g., the updated class files, in Tock satisfies the recited "multi-class file." For example, as indicated in Fig. 3 of Tock, class files 128 are processed by offline class loader 132, which outputs the updated class file and constant pool 302. (Tock, 5:8-50.) In addition to formatting the class files as a memory representation of loaded classes as discussed above, "Tock further indicates at column 6, lines 37-44 that the offline class loader 132 itself performs the transformation of bytecode quickening, rendering the updated class files machine-dependent." (Goldberg Decl., ¶ 21.) "As such, there is no intermediate updated class, having duplicate entries removed, that can be considered in a machine-independent format." (Goldberg Decl., ¶ 21.)

Accordingly, for at least these reasons, Tock fails to disclose or suggest the concept of a "multi-class file" or package as required by independent claims 1,7, and 13 at least because the output of the offline class loader does not include a "multi-class file."

Furthermore, Tock clearly teaches away from a machine-independent multi-class file (teaching a machine-dependent "executable module" for a client device), and necessary modifications of Tock to meet the features of claim 1 would impermissibly modify the principle of

21

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

operation of Tock (e.g., modifying the output of the offline class loader, which includes a machine-dependent runtime representation of the loaded classes, to include a machine-independent multi-class file) and therefore cannot render the claims obvious. (MPEP §§ 2143.01, 2143.01(VI).)

For at least these reasons, Tock does not teach or suggest "a multi-class file" as recited in independent claims 1,7, and 13. Accordingly, the rejection to claims 1,5-7, 11-13, 15, and 16 should be withdrawn.

C. Tock fails to disclose or suggest the features of dependent claim 16.

Claim 16, which depends from claim 13, also cannot be anticipated by Tock. Claim 16 adds additional features not found in Tock: "a virtual machine having a class loader configured to obtain and load said multi-class file into said runtime data area." In particular, Tock fails to disclose a class loader configured as recited by claim 16 "to obtain and load said multi-class file into said runtime data area." (Goldberg Decl., ¶ 23.)

The Office Action states "Tock discloses (FIG. 12; 3: 46-52; 10: 29-43) a virtual machine having a class loader and a runtime data area .... Tock describes a boot time initiator that loads a multi-class file into the runtime data area." (Action, page 9.)

Initially, Patent Owner submits that Tock fails to disclose a "virtual machine" or a "class loader" as recited. As stated in Professor Goldberg's declaration: "Portions of Tock cited in the Office Action at page 9 (e.g., relating to the offline class loader and the Java browser [i.e., 3:46-52 and 10:29-43]), do not disclose a class loader as recited. For instance, Tock discloses a Java browser and a class loader associated therewith, but the class loader is described (e.g., at 4:36-39) for loading classes to a user's address space. This discloses neither a 'virtual machine' nor a 'class loader' configured as recited in claim 16." (Goldberg Decl., ¶ 24.) Moreover, as stated previously, Tock does not disclose a machine-independent "multi-class file," and as such, this disclosure fails

22

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

to disclose "a virtual machine having a class loader configured to obtain and load said multi-class file into said runtime data area" as recited.

Additionally, and according to Professor Goldberg's declaration, "the Java interpreter mentioned at column 3, lines 46-52 of the Action, is not described as receiving the output of the offline class loader. Instead it is described as used for executing a Java application, and therefore does not disclose or suggest the 'virtual machine' as recited." (Goldberg Decl., ¶ 25.)

The Office Action and Requestor further cite to Figure 12 of Tock for these features of claim 16. However, "lock's Figure 12 shows the contents of the read-only memory of a client computer, and no class loader is shown." (Goldberg Decl., ¶ 26.) Figure 12 illustrates a boot time initiator 1220, which copies over data from ROM to RAM when the device is powered up. There is no disclosure, however, that boot time initiator 1220 is a class loader configured to obtain a multi-class file and load it into the runtime data area. In fact, Tock specifically discloses that "the boot time initiator copies all methods and data that must be resident in random access memory during execution to the random access memory locations assigned to them by the linker" (Tock, 10:37-41), where "[t]he output from the linker 136 is a preloadable executable module 306 containing the methods and data" (Tock, 5:65-67). At an earlier step in Tock, the output of the offline class loader (i.e., the updated class files) was "transmitted to an assembler 134 which produces an object module having the required format for the linker .... Once the memory layout is determined, the linker 136 resolves all symbolic references and replaces them with direct addresses." (Tock, 5:51-60.) "That is, the updated class files are assembled into object modules (i.e., machine code modules) and linked by the linker into a preloadable executable module (again, comprising machine-dependent code having no symbolic references)." (Goldberg Decl., ¶ 26.) Subsequently, "the preloadable executable module and boot time initiator 1220 are permanently stored in the read-only memory of a client computer." (Tock, 10:33-35.) "Thus, the boot time initiator in Tock does not load the executable module with a class loader; it merely copies the code ("methods") that is already in (loaded)

23

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

machine code format, not byte code format, into 'random access memory locations.'" (Goldberg Decl., ¶ 26.) Accordingly, "lock's offline class loader is a 'preloader' that produces a 'preloaded' output file containing classes that do not require runtime dynamic loading." (Goldberg Decl., ¶ 26.)

For at least these reasons, Tock fails to disclose a class loader configured to load a multi-class file into a virtual machine as required by claim 16.

D. Tock fails to disclose or suggest the features of dependent claims 5,6,11,12, and 15.

Tock further fails to disclose or suggest the features of claims 5,6, 11, 12, and 15 at least because Palay fails to disclose the features of independent claims 1, 7, and 13, from which claims 5, 6, 11, 12, and 15 depend respectively. Accordingly, the rejection to claims 5, 6, 11, 12, and 15 should be withdrawn.

IV. Claims 1, 5-7,11-13, and 15 Are Not Anticipated by Palay (Ground 2)

A. Palay fails to disclose or suggest "class files," comprising bytecode.

Palay generally describes systems and methods for compiling and linking source files that include methods for merging class information from object files. (Palay, Abstract, 6:1-27.) For example, a compiler generates class information pertaining to object-oriented classes referenced in the source file, where the class information is sufficient to enable a linker to resolve class definitions and to perform class relocation operations. The compiler also generates an object file from the source file, where the object file includes the class information. The compiler generates the object file such that resolution of class definitions and performance of class relocation operations are delayed until operation of the linker. A linker links the object file potentially with at least one other object file or shared library to thereby generate an executable file or shared library. The linker uses

24

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

the class information contained in the object file to resolve class definitions and to perform class relocation operations. (Id.)

Palay describes operation of the linker as follows:

In step 606, the linker 112 reads in the object files 106, 108 and the shared libraries 110 and merges together the class information 406 contained in these files. In particular, the linker 112 merges together the class symbol tables 408 contained in these files to generate a merged class symbol table. Similarly, the linker 112 merges together the class relocation tables 412, class instance tables 416, class reference tables 410, class definition tables 414, and class information variable tables 418 to generate a merged class relocation table, a merged class instance table, a merged class reference table, a merged class definition table, and a merged class information variable table.

Two issues that must be addressed when doing this merge operation are what to do about duplicate members and the mapping of references from the relocations to the merged class instance table and the merged class symbol table. When merging the class definition tables 414, duplicate non-dynamic and internal dynamic class definitions are removed. Duplicate definitions of dynamic classes are considered to be an error. When merging class instance tables 416, duplicate entries are considered to be an error. Duplicate entries in the class symbol tables 408 are removed. There are no duplicate entries in the class relocation tables 412.
(Col. 28, lines 39-61.) (Emphasis added.)

As such, Palay generally describes compilers and linkers for C++ that operate on object files to delete duplicate class definitions (e.g., "duplicate non-dynamic and internal dynamic class definitions are removed"), where other items that are detected as duplicates are "considered to be an error" (e.g., "[d]uplicate definitions of dynamic classes are considered to be an error"). (See, e.g., 28:51-61.)

B. Palay fails to disclose or suggest "a plurality of class files," let alone
"determining [a] plurality of duplicated elements in a plurality of class files," or
"removing said duplicated elements from said plurality of class files to obtain a
plurality of reduced class files" as recited by claim 1 (and similarly 7 and 13).

Claim 1 recites, inter alia:

25

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

"determining [a] plurality of duplicated elements in a plurality of class files."
The '702 Patent specifically states that "[c]lass files contain bytecode instructions." ('702 Patent, 1:34.) The '702 Patent further states that Java classes are complied into machine-independent bytecode class files, where each class contains code and data in a machine-independent format called the class file format. (Id. at 2:62-3:1.) As such, and according to Professor Goldberg's declaration, "one of ordinary skill in the art would necessarily read the recited 'class files' as requiring machine-independent bytecode." (Goldberg Decl., ¶ 30.)

The Office Action, in adopting the Requester's analysis, states "Palay discloses (FIG. 6; 28: 39-61) determining a plurality of duplicated elements in a plurality of class files . . . ." (Action, page 10.) As described in greater detail below, Patent Owner submits that Palay discloses methods and systems relating to "object files," which are not equivalent to or the same as "class files." (Goldberg Decl., 31.)

In contrast to "class files," which comprise bytecode instructions, Palay describes a compiler and linker for C++ that operate with object files; Palay's object files are not "class files." In particular, "one of ordinary skill in the art, reading the specification and the definition of the class file format found there, would necessarily conclude that 'class files' include machine-independent bytecodes, and further recognize that Palay's C++ object files include machine-dependent executable code." (Goldberg Decl., ¶ 32.) "Palay's disclosure of merging class information found in object files (see, e.g., '702 Patent, 28:39-61; Fig. 6), where 'object files 106' are what is being read in and having duplicated entries removed therefrom, fails to disclose 'class files' that comprise bytecode instructions." (Goldberg Decl., ¶ 31.) "In fact, the very nature of object files—being compiled from source code (e.g., C++ source code) into machine code—is that they are machine-dependent." (Goldberg Decl., ¶ 31.) Therefore, object files are not, and do not disclose, "class files" as recited by independent claims 1,7, and 13. Accordingly, this basic feature of the claims is

26

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

deficient in Palay, such that claimed features derived therefrom are also deficient, and the rejection should be withdrawn.

For at least these reasons Palay fails to disclose or suggest the recited "plurality of class files," "removing said duplicated elements from said plurality of class files to obtain a plurality of reduced class files," or "removing said duplicated elements from said plurality of class files," as recited by claim 1 (and similarly claims 7 and 13). Accordingly, the rejection of claims 1,5-7, 11-13, and 15 should be withdrawn.

C. Palay fails to disclose or suggest the features of dependent claims 5,6,11, and 12.

Claim 5 further adds that determining a plurality of duplicated elements includes "determining one or more constants shared between two or more class files," and claim 6 further adds that forming a shared table includes "forming a shared constant table comprising said one or more constants shared between said two or more class files." These features are not disclosed or reasonably suggested by Palay. Claims 11 and 12 recite similar features as claims 5 and 6 respectively.

The Office Action states that Palay discloses the features of claims 5 and 6 in column 28, lines 54-56, stating: "[w]hen merging the class definition tables 414, duplicate non-dynamic and internal dynamic class definitions (constants) are removed." (Action, page 12.) (Parenthetical added to citation of Palay by Requester and adopted by the Office.) It is unclear to the Patent Owner what the relevance of this portion of Palay is to the recited features of claims 5 and 6. In particular, "Palay is silent as to the removal of duplicate 'constants.' At best, Palay describes the removal of duplicate 'class definitions' shared between two or more classes, however, this is not the same or equivalent to removal of duplicate constants of class files." (Goldberg Decl., ¶ 36.) Furthermore, removing duplicate class definitions per the operation of Palay's linker 112 does not teach or

27

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

suggest modifying Palay's invention to remove shared constants of class files. (Goldberg Decl., ¶ 36.)

Accordingly, claims 5,6, 11, and 12 should be confirmed for these additional reasons.

D. Palay fails to disclose or suggest the features of dependent claim 15.

Palay further fails to disclose or suggest the features of claim 15 at least because Palay fails to disclose the features of independent claim 13 from which claim 15 depends. Accordingly, the rejection to claim 15 should be withdrawn.

V. Supplemental Information Disclosure Statement

Patent Owner further draws the Examiner's attention to the Supplemental Information Disclosure Statement filed herewith. The Supplemental Information Disclosure Statement cites further information produced during the pending litigation since the mailing of the Office Action.

VI. Conclusion

For at least these reasons, Patent Owner requests reconsideration and withdrawal of the rejections in the Action and confirmation of the patentability of claims 1, 5-7, 11-13, 15, and 16 of the '702 Patent.

Patent Owner notes that the Request and the Action include a number of assertions and allegations, including those concerning the '702 Patent specification and claims, and the cited references. Patent Owner has addressed the references and the assertions and allegations to the extent understood. Patent Owner does not subscribe to any assertion or allegation in the Request and the Action regardless of whether it is specifically addressed herein.

In the event the U.S. Patent and Trademark office determines that an extension and/or other

28

Reexam Control No. 90/011,492
U.S. Patent No. 5,966,702

Docket No.: 154892800400

relief is required, Patent Owner petitions for any required relief including extensions of time and authorizes the Commissioner to charge the cost of such petitions and/or other fees due in connection with the filing of this document to Deposit Account No. 03-1952 referencing docket no. 158492800400.

Dated: September 6, 2011

Respectfully submitted,

By Electronic Signature /Christopher B. Eide/
Christopher B. Eide
Registration No.: 48,375
MORRISON & FOERSTER LLP
[address, phone number]

_______________

1 Throughout this Response, recited claim language is in quotes and boldface.

2 The '702 Patent makes clear that "[c]lass files contain bytecode instructions," where bytecode instructions include code and data in a machine-independent format.('702 Patent, 1:34, 2:62-3:1.)

3Throughout this Response, Patent Owner refers to independent claim 1. The analysis as to claim 1 applies to the other independent claims (claims 7 and 13) unless otherwise noted.

29


  


Oracle v. Google - Update on '702 Reexamination | 109 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections here please
Authored by: jesse on Tuesday, September 20 2011 @ 09:21 AM EDT
Thank you

[ Reply to This | # ]

News Pick discussions
Authored by: jesse on Tuesday, September 20 2011 @ 09:22 AM EDT
Thank you

[ Reply to This | # ]

Off topic discussions
Authored by: jesse on Tuesday, September 20 2011 @ 09:23 AM EDT
Thank you

[ Reply to This | # ]

COMES thread
Authored by: jesse on Tuesday, September 20 2011 @ 09:24 AM EDT
Thank you.

[ Reply to This | # ]

If they're all Turing-complete machines
Authored by: Anonymous on Tuesday, September 20 2011 @ 09:36 AM EDT
Then the calculations will all be reducible to
the same set of formulas, no matter how
many intermediate steps are involved.

It's particularly galling that the respondents
know this, and know that the patent in
question should never have been granted,
but they're willing to game the system
anyway.

[ Reply to This | # ]

What is 'device independant' anyway?
Authored by: Anonymous on Tuesday, September 20 2011 @ 09:41 AM EDT
Everytime I see someone claim something is device independant, what I see is
something that runs on some kind of abstraction layer or virtual machine. In
case of Java the Java Virtual Machine.

This just means that device independance is nothing other than dependance on on
a virtual device. And device independance is a myth. You will need an
abstraction layer for every different device you want to run it on that is
device dependant and implements the virtual device.

From a programmers view there is no difference between developping for a virtual
machine or a 'real'one.

How then can device independance be a disctinction for a patent on a programming
language? And if someone develops a chip that directly run java byte code ... oh
wait:
http://www.tomshardware.co.uk/nazomis-java-accelerator-chip-for-wireless-apps,ne
ws-4655.html

So now we have a chip that natively runs Java byte code, what then makes the
JavaVM different from a 386 emulator like Bochs?

[ Reply to This | # ]

Oracle v. Google - Update on '702 Reexamination
Authored by: ThrPilgrim on Tuesday, September 20 2011 @ 10:29 AM EDT
Looking at the claims here, haven't Oracle managed to get a patent on
re-factoring code on the fly.

Or am I missing something.

---
Beware of him who would deny you access to information for in his heart he
considers himself your master.

[ Reply to This | # ]

Gaming the system again
Authored by: Anonymous on Tuesday, September 20 2011 @ 10:42 AM EDT
I read this patent application not as a new method but only on processing what
data.

The process can be done with grep; sort -u; and a merge
or in language Oracle may understand:
Select distinct class_name from classes

These processes predate Java and Oracle together
So the patent can only be on processing what and (hoping) for what result.

You can do this on a piece of paper or from top of your head
Didn't the supreme court said something about that ?

/Arthur

[ Reply to This | # ]

Joining an ex parte re-examination?
Authored by: celtic_hackr on Tuesday, September 20 2011 @ 11:38 AM EDT
Is it possible for a third party to join an ex parte re-examination? For
example, could I, as a owner of a software company file an action against this
patent, and join the current re-examination? Conversely, I assume I am legally
entitled to file a separate action against this patent, and include in my claim,
these two prior arts and also make the claim of obviousness, and that it
describes a "purely mental" process. I love that phrase for it's many
nuanced meanings that can be taken away from it. Then I can include in my claim
a counter to Oracle's ridiculous "distinctions".

Of course, the downside is, were I to file either such claim, my limited
anonymity here would be destroyed. Everyone would know who I really am.

Not, that I'm rich or famous or anything. I just like my privacy.

[ Reply to This | # ]

I can do this in my head the aid of a pencil and paper
Authored by: Anonymous on Tuesday, September 20 2011 @ 01:18 PM EDT
The three independent claims, 1, 7 & 13, are all processes that I can do in
my head with the aid of a pencil and paper. I thought that the Supreme Court
ruled that doing something on a computer that could be done by someone in their
head with the aid of a pencil and paper was a mental process and therefore not
patentable, and that merely adding "on a computer" was not enough to
make it patentable.

[ Reply to This | # ]

Oracle v. Google - Update on '702 Reexamination
Authored by: tknarr on Tuesday, September 20 2011 @ 03:42 PM EDT

I'd note that Oracle's argument about machine-dependent vs. machine-independent fails on it's face. Most of today's machine-dependent object code isn't actually directly executable by the hardware. The native instruction set of the hardware is microcode, and the main thing the CPU does is execute a loop in microcode that fetches the next object-code instruction, decodes it and executes the correct microcode instructions to perform the operation specified in the object-code instruction. Which is exactly what the JVM does: fetches the next bytecode instruction, decodes it and executes the correct object-code instructions to perform the operation specified in the bytecode instruction.

[ Reply to This | # ]

Oracle v. Google - Update on '702 Reexamination
Authored by: dio gratia on Wednesday, September 21 2011 @ 12:42 AM EDT
Patent Owner presented that Palay discloses "object files ," not "class files," where "class files" comprise machine-independent bytecode and "object files" comprise machine code. [emphasis added]
With the aid of jad or another Java disassembly method we can demonstrate the direct equivalence of Java source code and byte code. Byte code can be thought of as a standardized shorthand that is used to interpret shorter signs (in the semiotic sense) that mean the same as longer portions of syntax. The syntax is limited which is why you don't run out of shorter signs (byte code). What makes it machine-independent is it's proximity to source code.

See Semiotics 101: Taking the Printed Matter Doctrine Seriously, Kevin Emerson Collins Washington University in Saint Louis - School of Law, Associate Professor of Law, Indiana University Maurer School of Law – Bloomington, (PDF 384 KB). The introduction, Page 2:

The contemporary printed matter doctrine restricts the products of human ingenuity that can be patented under section 101 of the Patent Act. Roughly stated, it dictates that : “information recorded in [a] substrate or medium” is not eligible for patent protection—regardless of how nonobvious and useful it is—if the advance over the prior art resides in the “content of the information". (1 DONALD S. CHISUM, CHISUM ON PATENTS § 1.02[4], at 1-25 to -26 (2009)).
Even a casual reading of the current narrow printed matter doctrine tells us the distinction Oracle is trying to make shouldn't lead to patentability under § 101 of the Patent Act.

I could find no free on line viewable Chisum On Patents reference regardless of the year edition and that argument by Patent Owner put a burr under my blanket.

[ Reply to This | # ]

On-a-computer with a computer program product
Authored by: Ian Al on Wednesday, September 21 2011 @ 04:28 AM EDT
What do claims 7, 8 and 9 do?

If the files were not on-a-computer would the invention not then work?

Where do they describe what the computer program product is required to do? Is
it a spreadsheet to calculate all those memory additions? Could I do it more
cheaply with a calculator?

Is it a machine or is it a method?

If I used a pencil, paper and a calculator could I do all this as an abstract
idea in my head? When do the abstract ideas transform into a physical machine or
a process with an innovatory concept and significant post-process activity?

It's a lot of Bilski, isn't it?

---
Regards
Ian Al
Software Patent: code for Profit!

[ Reply to This | # ]

Programming techniques.
Authored by: Ian Al on Thursday, September 22 2011 @ 04:35 AM EDT
Gene Quinn has explained that it is the claims in the patent which define the
protected invention and not the method of making the software that implements
it. That is why a software patent is independent of processor, operating system,
programming language or programming techniques.

We see in Microsoft v. AT&T that installing the software in a general
purpose computer makes it into a potentially infringing apparatus or machine.

In the present apparatus we are told that it has, as a component, a computer
with memory. The invention is completed with the addition of a plurality of
class files and a program to process those class files. There are no specific
types of class files cited.

When the complete apparatus or machine is made, the class files are rearranged
into another formulation of class files comprising a revised collection. The
invention uses a programming technique of tables and class sorting to remove
redundant appearances of classes.

The end product of these programming techniques is to produce executable files
that run more efficiently on a virtual processor inside the computer. The
inventive concept is the programming technique. All the other features of the
invention are non-specific including the target virtual processor.

Please note that none of the algorithms used to employ the programming technique
are protected.

The reason for claims to include a computer with memory is only that programming
techniques involving computer file data manipulation have to have their computer
file data manipulated on a computer. The computer is not a component of the
invention: it is the field of use of the programming technique.

If the invention is run until all of the class files have been manipulated into
other class files with less duplication of the class symbols, what does the
invention then do? As far as I can see, it converts one set of class symbols
into another set with less class symbol duplication and does nothing further.

Running the more efficient class files on an emulation of an abstract idea of a
processor is not part of the invention. What the revised class files actually do
is not part of the invention.

So, is a programming technique, involving the software implementation of
abstract ideas of file transformation, patentable subject matter? Is the
on-a-computer claim just the narrowing of the field of use of a programming
technique that does not actually require a computer because a programming
technique is an abstract idea? Is there a further narrowing because the
invention only works with class files that have been produced by an inefficient
compiler?

Would the use of an efficient compiler to change the source code files into
efficient class files also infringe on this patent if it used the programming
technique as part of the compiler? Would the infringing machine change from the
smartphone to the computer used by the app programmer? Would the damage then not
depend on how many smartphones used class files?

The programming is not carried out on the computer in which the invention is to
be used in the case we are reviewing. Once the apps are installed on a Dalvik or
a Java virtual processor computer in a smart phone, the class files are no
longer manipulated. Once the smart phone has had its apps installed, the
invention does nothing further. Once it is imported into the US, the owner might
install new apps. How can the extent of Google's inducement of the owner to use
the programming technique during the installation of new apps be established?

If Benson was an attempt to patent a computer algorithm that converted BCD to
binary, is this an attempt to patent the computer programmer's tools of the
trade which are used to write computer algorithms? Is it an attempt to patent
the software programmers' abstract ideas?

How many of the other patents at issue reduce to programming techniques? The
security one is bound to. That is the narrowing of an abstract security idea
field of use to a computer in order that a computer programming technique can
implement it. There is no security machine or process made. It is only a method
of implementing an abstract idea in the field of use of computing.

---
Regards
Ian Al
Software Patent: code for Profit!

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )