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

Gear

Groklaw Gear

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


You won't find me on Facebook


Donate

Donate Paypal


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 - Before We Talk About Damages
Thursday, June 09 2011 @ 11:50 AM EDT

At least one so-called patent expert has been quoted extensively in the past few days asserting that the damages that could be assessed against Google could be astronomical and will wipe out Android. That strikes this writer as getting the cart before the horse. First, the Oracle patents will have to be found valid, either by the court or in reexamination. To the extent the claims contained within those patents are modified and/or narrowed, the basis for the alleged infringement by Google may not survive. As I have noted in earlier articles, more than 50% of patents that are subjected to reexamination end up with their claims being denied or narrowed. So there is a strong likelihood that, at least in reexamination, the Oracle patents may not end up being what they appear to be today.

Second, after the claims are substantiated in some form and interpreted by the court, the question will be whether Android infringes those claims in their entirety. Keep in mind that a patent claims consists of a series of declaratory statements, each of which must be found to be applicable to the allegedly infringing software for the entire claims to be found infringed. For example, consider the following claim 1 from Oracle's '447 patent:

A method for providing security, the method comprising the steps of:
  • establishing one or more protection domains, wherein a protection domain is associated with zero or more permissions;
  • establishing an association between said one or more protection domains and one or more classes of one or more objects; and
  • determining whether an action requested by a particular object is permitted based on said association between said one or more protection domains and said one or more classes.

For this claim to be infringed, the allegedly infringing software must perform each of the three bullet points. If it only performs two but not the third, it doesn't infringe. So changing even one of those bullet points in the claim through reexamination or invalidity assessment by the court could have a dramatic impact on whether the claim, and thus the patent, is infringed.

Of course, Google, even absent the reexamination, already argues that Android does not perform all of the elements of the allegedly infringed claims as set forth in its answer to the amended complaint [PDF], although it does so in the general terms of an answer and counterclaim, not with specificity. That will come at a later stage in the pre-trial activity when Oracle must allege the infringement with specificity and Google must set forth its grounds for non-infringement and invalidity with specificity. Anyone pretending to know at this time how this case will come out and what damages could be assessed is simply not well informed. Oh, and by the way, if you want to learn how judges are supposed to determine damages in a patent case, you might want to check out Compensatory Damage Issues in Patent Infringement Cases, A Pocket Guide for Federal District Court Judges. [PDF]

So what about those Oracle patents? Are they being reexamined? What is the status of those reexaminations? Is the new prior art before the USPTO substantial? Let's take a look, and while we are doing so, note that the examiners have not accepted every argument advanced by Google as to invalidity:

Patent No. 6125447
Reexamination Control No. 90/011491

Granted 3/23/11

Request for Ex Parte Reexamination [PDF]

Exhibit 8 - Claim Chart [PDF]

Exhibit 9 - Claim Chart [PDF]

Order Granting Reexamination [PDF]

Text of Reexamination Decision:
DECISION GRANTING EX PARTES REEXAMINATION

Substantial New Question of Patentability
A substantial new question of patentability affecting claims 1-24 of USPN 6,125,447 to Gong (hereinafter '447) is raised by the present request for ex partes reexamination filed on 02/15/2011.

Patent Assignment

The '447 Patent is currently assigned to Sun Microsystems, Inc. The '447 Patent issued from US Patent Application No. 08/988,439 (hereinafter '439), filed on 12/11/1997.

Information Disclosure Statement

IDS received 02/15/2011 has been considered.

References Presenting Substantial New Question of Patentability

In the request for reexamination, the Requester alleges that '447 claims 1-24 are unpatentable over the following references, alone or in combination:

USPN 5,412,717 to Fischer ("Fischer" or '717) (file date 05/15/1992, issue date 05/02/1995), qualifies as a 35 U.S.C § 102(b) reference. Previously cited on an IDS, but never used in a rejection of Application '439.

          "The Gateway Security Model in the Java Electronic Commerce Framework" by Theodore Goldstein ("Goldstein") 11/29/1996, qualifies as a 35 U.S.C § 102(b) reference.

"Java APIs: Playing Monopoly with Java via the JECF", Rawn Shah ("Shah") 12/01/1996, qualifies as a 35 U.S.C § 102(b) reference.

Prosecution History

The '447 patent issued from the '439 application filed on 12/11/1997. The '447 patent is generally directed (2: 52-65) to a method and apparatus for maintaining and enforcing security rules/policies using protection domains. An association is established between the protection domain and a class of object. The association and the class to which the object belongs are used in the determination of permissible actions for the object.

A non-final Office action (08/25/1999) rejected all claims, claims 1-24. Claims 1,10, and 19 were rejected as anticipated by USPN 5,758,153 to Atsatt et al. Claims 2-9, 11-18, and 20-24 were rejected under 35 USC 103(a) as unpatentable over Atsatt et al. The non final rejection noted that, while obvious, Atsatt failed to clearly disclose:

- a code identifier associated with at least one protection domain and at least one class, where the step and means for establishing the association between the protection domains and the classes of one or more objects includes the step and means for associating the protection domains and the classes based on the code identifier.

-the use of a source code to define each class in accordance with the code identifier.

-keys, however keys are well known in the art as being identifiers for a record or group of records in a data file (See definition of key).

Regarding claims 6, 15, and 24, the non final rejection noted that Atsatt discloses associating the protection domains and the classes based on data persistently stored (access control list), wherein the data associates code identifiers, as described above, with a set of permissions (rights).

Applicant's response (11/24/1999) included arguments that failed to persuade the Examiner: protection domains are associated with users (which are internally represented by objects that are instances of the class Credentials); a system that associates protection domains and object classes. A Final Rejection was issued (02/16/2000) maintaining all rejections. During an interview 05/05/2000, it was agreed that the Atsatt reference does not teach an association between the classes and the protection domain and does not teach "sources of code" associated with protection domains. Claims were found to be allowable, pending an update search of prior art. In the Reasons for Allowance the Examiner noted "With respect to claims 1,7, 10, 16 and 19, the Examiner asserts that the novelty of the claims, when read as a whole, are the steps and means for establishing an association between one or more protection domains and one or more classes of one or more objects (or sources of code) and determining whether an action requested by an object is permitted based on this association." The '439 application issued as the '447 patent on 09/26/2000.

Reexamination Requester's Position

The Request indicates that the Third Party requester considers:
Ground #1: Claims 1-24 to be unpatentable over Fischer.
Ground #2: Claims 1 -24 to be unpatentable over Goldstein in view of Shah.

Substantial New Question

The substantial new question of patentability (SNQ) has been raised based on patents and/or printed publication not considered in an earlier concluded examination of the patent being reexamined. In the present instance, Requester asserts an SNQ to be raised by Fischer, alone, or the combination of Goldstein and Shah, which were not applied or discussed in rejecting any claim during the prosecution of the '447 Patent.

Re. Ground #1: Fischer
It is generally agreed that the consideration of Fischer, alone, proposed by Third Party requester raises a substantial new question of patentability as to claims 1-24 of the '447 Patent.

As pointed out on pages 15-17 & 17-18 of the Request, Fischer discloses a computer system security using a set of authorities and/or restrictions referred to as "program authorization information" or "PAI" ('717, 2:16-30). The PAI is assigned to a program to be executed, "to thereby delineate the types of resources and functions that the program is allowed to utilize." See id. This PAI for the program may be combined, as appropriate, with PAI associated with a calling program ('717, 19: 40-54). "The PAI defines the range of operations that a program may execute and/or defines those operations that a program cannot perform" ('717, 2: 34-36). As illustrated in at least Figure 3C of Fischer, the program can include an object-oriented data structure ('717, Fig. 3C; 7: 49 - 8: 2). Therefore, Fischer discloses establishing an association between one or more protection domains, i.e., PAI, and one or more classes of one or more objects, i.e., a class represented by the object-oriented data structure, as recited in independent claims 1,10, and 19 of the '447 patent. Fischer also discloses establishing an association between one or more protection domains and one or more sources of code, as recited in independent claims 7 and 16 of the '447 patent. For example, according to Fischer, the PAI can be associated with a signer of a digital certificate ('717, 6: 25-35; Fig. 2) or a manufacturer of a program ('717, 9: 3-8; 16: 12-25). See claim chart, Exhibit 8.

Fischer's teachings were considered on an IDS, but not used in the prosecution of the '439 Application which became the '447 Patent. Further, there is a substantial likelihood that a reasonable Examiner would consider these teachings important in deciding whether or not independent claims 1,7, 10, 16, and 19 are patentable. The significant new question of patentability raised by Fischer has not been decided in a previous examination of the '447 Patent. Additionally, it is found that Fischer raises a substantial new question of patentability on all dependent claims, claims 2-6, 8-9, 11-15, 17-18 and 20-24.

Re. Ground #2: Goldstein in view of Shah
It is generally agreed that the consideration of Goldstein, taken with Shah, proposed by Third Party requester, raises a substantial new question of patentability as to Claims 1-24 of the '447 Patent.

Goldstein describes a "Gateway" extension to the Java security model, for use in the Java Electronic Commerce Framework ("JECF") (Goldstein, p. 1). According to Goldstein, an application called a "cassette" is associated with a set of permissions (i.e., a protection domain) represented by "Roles" (Goldstein, p. 7-8, 10, 13-14, and Figs. 1 and 5-6). The Roles may be defined on a per-package basis so that any class that is part of the package (e.g., a cassette package) is necessarily associated with the protection domain (Goldstein, p. 10). All classes in a package have access to package-private data members and methods (Goldstein, p. 10). Goldstein also discloses establishing an association between the protection domain of a user's cassette with a class corresponding to a protected resource such as a JECF database (Goldstein, p. 11-12). As would have been recognized by a person of ordinary skill in the art reviewing Goldstein, the Roles are objects that represent and/or contain the specific authorizations (e.g., permissions) for a particular cassette as well as a digital signature (based on a public/private key pair) corresponding to the creator of the cassette (Goldstein, p. 13).

Shah, in support of Goldstein's teachings related to JECF, further explains (p. 3), "[R]oles dictate the available resources and security levels and control [the] program's interface to the JECF code. A local database contains these access control lists and role information. Each... cassette with its specific roles must be signed by a trusted authority before use to guarantee the identity of the originator." Shah clarifies that these Roles inherently include objects that represent and/or contain specific authorizations for a set of code, as well as a digital signature corresponding to the creator of the code.

Therefore, Goldstein, in view of Shah, discloses providing computer system security, which includes associating protection domains with object-oriented program structures, such as classes of objects and sources of code, as recited in the claims of the '447 patent.

Decision Granting the Order

A substantial new question of patentability affecting claims 1-24 of USPN 6,125,447 to Gong is raised by the request for reexamination. In view of the above, the request for reexamination is GRANTED. Claims 1-24 of USPN 6,125,447 to Gong will be reexamined.

Office Action on the Merits

An Office action on the merits will be provided in due course.

Ongoing Duty to Disclose

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 the patent under reexamination throughout the course of this reexamination proceeding. The third party requester is also reminded of the ability to similarly appraise the Office of any such activity or proceeding throughout the course of this reexamination proceeding.


Patent No. 6192476
Reexamination Control No. 90/011521

Granted 3/23/11

Request for Ex Parte Reexamination [PDF]

Exhibit 10 - Claim Chart [PDF]
Exhibit 11 - Claim Chart [PDF]

Exhibit 12 - Claim Chart [PDF]

Order Granting Reexamination [PDF]

Text of Reexamination Decision:
Response to Request for Ex Parte Reexamination

The Third Party Request (03/01/2011) for ex parte reexamination of claims 1-21 of USPN 6,192,476 Bl to Gong is acknowledged. A substantial new question of patentability affecting claims 1-21 of USPN 6,192,476 Bl to Gong (hereinafter "Gong" or '476) is raised by the Third Party's request for ex parte reexamination.

Information Disclosure Statement

The Information disclosure statement (PTO-SB-08) filed on 03/01/2011 has been considered.

Ongoing Duty to Disclose

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 the patent under reexamination throughout the course of this reexamination proceeding. The third party requester is also reminded of the ability to similarly appraise the Office of any such activity or proceeding throughout the course of this reexamination proceeding.

Prosecution History

10/143574, filed 05/13/2002, now USPN 6,934,758 is a continuation of 09/537746, filed 03/30/2000, now USPN 6,389,540
09/537746 is a continuation of 09/044915, filed 03/20/1998, now USPN 6,138,238
09/044915 is a continuation in part of 08/988431, filed 12/11/1997, now USPN 6,192,476 (issue date 02/20/2001)
09/044915 Claims Priority from Provisional Application 60/076,048, filed 02/26/1998

The original Examiner issued a non final office action (08/25/1999) objecting to claims 8-10 and 18-20, and rejecting claims 1, 3, 6-7, and 21-23 as anticipated by USPN 5,311,591 to Fischer. A Final Office action was issued in response to Applicant's Response (11/19/1999) maintaining the rejection. An agreement was reached (Interview Summary, 05/11/2000) noting that Fischer '591 failed to disclose "determining whether an action is authorized based on permissions associated with a plurality of routines in a calling hierarchy associated with a principal." The following correspondence, a Request for Reconsideration (05/18/2000) recited, "The limitation expressed as "permissions associated with a plurality of routines in a calling hierarchy," is not taught at least because the "request" made by the program, disclosed by Fischer, maps to the "request" of Applicant's claims, and therefore can not also map to another element of Applicant's claims. That is, the "request" of Fischer does not properly map to "a routine in a calling hierarchy" as argued in the final Office Action (final Office Action, page 4). Furthermore, since the claims actually recite "a plurality of routines" (emphasis provided), the single "request" of Fischer would not properly he mapped to the "plurality of routines" recited in the claims, in any case. Atsatt does not cure the deficiencies of Fischer, because Atsatt also does not teach or suggest permissions associated with a plurality of routines in a calling hierarchy." The application issued and USPN 6,192,476 Bl on 02/20/2001.

Prior Art References

USPN 5,412,717 to Fischer, entitled "Computer System Security Method And Apparatus Having Program Authorization Information Data Structures," file date 05/15/1992, issue date 05/02/1995 (hereinafter "Fischer" or '717), qualifies as a 102(b) reference. [USPN 5,412,717 to Fischer is an abandoned patent. USPN 5,311,591 to Fischer, a continuation of '717, was used in the original prosecution of the Gong '431 Patent Application.]

Elliott I. Organick, "The Multics System: An Examination of Its Structure", 1972 (hereinafter "Organick"), qualifies as a 102(b) reference.

USPN 5,958,050 to Griffin et al., entitled "Trusted Delegation System," file date 12/26/1996, issue date 09/28/1999 (hereinafter "Griffin" or '050), qualifies as prior art under 102(e).

Patrick Chan, "The Java Class Libraries An Annotated Reference", 09/1996 (hereinafter "Chan"), qualifies as prior art under 102(b).

Summary of Patent under Reexamination

The '476 patent claims a method, computer readable medium, and system embodiments of enhancing security by limiting access to a resource depending on permissions, wherein the permissions are dynamic and change depending on the permission levels of the requesting code ('476, 2:59-62). Instructions from a code stream create principals (thread objects/processes, '476, 3: 1-2). Execution of a principal results in requests to access certain actions/functions or certain resources, where successful access depends on the permission levels associated with the underlying code associated with the function ('476, Abstract; 7:11-15; 8:55-58). As a "principal" (execution thread/process) requests an action, a determination is made as to whether such action execution is authorized based on permissions associated with each routine (method/function) in a calling hierarchy (call stack) invoked by or on behalf of the associated thread. The calling hierarchy indicates the routines (e.g. functions, methods) that have been invoked by or on behalf of a principal (e.g. thread, process) but have not been exited ('476, 3:1-10). "The sequence of calls that resulted in execution of the currently executing code of a thread is reflected in the call stack of the thread ('476, 10:58-60)." A security policy maps a particular code identifier and a particular authorized permission ('476, 9: 21-25). According to an embodiment of the present invention, protection domains, sets of permissions granted to one or more principals, are used to enforce security within computer systems ('476, 8: 57-58).

Significant New Question of Patentability

The request indicates that Requester considers the following substantial new questions of patentability (SNQs) to be raised by the prior art cited in the Request:
SNQ 1. A substantial new question of patentability as to claims 1-21 is raised by reference USPN 5,412,717 to Fischer. Requester has proposed that claims 1-21 are anticipated by USPN 5,412,717 to Fischer. USPN 5,311,591 to Fischer was cited during the prosecution of the '431 patent application (USPN 6,912,476). Fischer's teachings ('717) (now abandoned), are presented in a new light using rational not recognized or considered in the previous examination.

The Examiner of record, in the statement for allowance noted (Interview Summary) that the Fischer '591 reference "does not teach or suggest determining whether an action is authorized based on permissions associated with a plurality of routines in a calling hierarchy associated with a principal." As taken from the Request, p. 17, in a discussion regarding Gong '476, "This limitation is described in further detail in the specification: "A calling hierarchy indicates the routines (e.g. functions, methods) that have been invoked by or on behalf of a principal (e.g. thread, process) but have not been exited." See '476 patent at 3:7-10. In other words, when a calling hierarchy is present on the call stack of a principal, the access rights of the principal depend on the source of the code on the call stack; because the source of the code on the call stack will vary, as certain code is implemented and then exited, the access rights of the principal will vary as well. See '476 patent, Abstract." Requester also notes features not considered by the original examiner of the '431 Patent Application: that Fischer '717 incorporates by reference USPN 4,868,877 and USPN 5,005,200 ('717, 6: 37), where the Abstract of '200 discloses an "enhanced digital signature certification" which employs a "hierarchy of nested certifications and signatures" (action authorizations based on permissions associated with a plurality of routines).

Fischer discloses in one embodiment an "originating program" that "calls a program" (a request). Each time a program call is made, Fischer' invention checks the Program Authorization Information, PAI, for authorization (determining whether said action is authorized); the PAI of Fischer incorporates by reference two other patents, see id. at 6:37, with the same inventor-U.S. Patent Nos. 4,868,877 and 5,005,200-which disclose an "enhanced digital signature certification" which employs "[a] hierarchy of nested certifications and signatures," see U.S. Patent No. 5,005,200, Abstract. This hierarchy of nested certifications and signatures is linked to the associated hierarchy of programs that carries the certifications and signatures in question (permissions associated with a plurality of routines in a calling hierarchy). The PCB of the called program is not added to the top of the execution stack (calling hierarchy/call stack) until it is determined that the program is permitted to be invoked ('717, 15: 63-67). Associated with this hierarchy, "each new PCB will include a field such as 150 that points to the 'previous' or calling program control block" ('717, 10: 26-28). The Fischer's Program Control Block (PCB) is analogous to the calling hierarchy or call stack, as disclosed by Gong '476.

It is agreed that the consideration of Fischer '717, alone, raises a substantial new question of patentability as to claims 1-21 of Gong '476. See Request 03/01/2011, pages 16-18 and Exhibit 10 claim chart. There is a substantial likelihood that a reasonable examiner would consider these teachings important in deciding whether or not the claims are patentable.

SNQ 2. A substantial new question of patentability as to claims 1,3,4, 6,10,12,13, 15, and 19-21 is raised by the Organick reference. Organick was not previously cited in the examination of Application Control No. 08/988,431 which issued as USPN 6,192,476 Bl to Gong.

Organick discloses a sophisticated security control system, called The Multics system which employs a "ring structure" to achieve the controlled sharing of information. See Organick at p. xvi. The Multics system used access controls along with the ring structure to allow for multi-level permission: "access control and ring brackets ... are fundamental to the system of protection and to the controlled sharing of data and procedures in Multics." See Organick at p. 133. The Multics system will first implement its security system upon the detection of a request: "[RJing compartmentalization is carried out with some hardware aid. Multics exploits special GE 645 fault-detection hardware to detect and trap a process whenever it attempts to make a cross-ring reference, in order to invoke the intervention of supervisory software." See Organick at p. 133. Once the request is detected, therefore, the Multics system will implement its supervisory software. This software will allow some actions and disallow certain other actions. Specifically: a procedure that is assigned the category of ring r is privileged during its execution to call (or to reference) any procedure (or data) segment in ring r or in any ring peripheral to, that is "outside of," ring r. Conversely, a procedure of ring r is prevented from referencing data segments in a more "privileged," that is, "inner" ring and is permitted call access to more privileged procedures only through specially controlled entry points called "gates." See Organick at p. 130. Organick clearly discloses a set of permissions that are based on a multitude or plurality of routines, i.e., procedures that are assigned to rings, in a calling hierarchy. The rings of Organick correspond directly to the "protection domains and permissions" of the '476 patent. For example: "The segments of any one process are associated with a set of generally two, but possibly more, concentric rings." See id. (emphasis added). In fact, Organick discloses "up to 64 rings," wherein the rings are associated with fault-inducing bit patterns that may allow or deny access depending on the function or access level sought, i.e., permissions. See id. at p. 153. Organick discloses "fault-detection hardware to detect and trap a process whenever it attempts to make a cross-ring reference," (detecting a request). Organick then discloses referencing the ring level permission of the procedure (determining whether an action is authorized); wherein the supervisory software of Organick references "two, but possibly more, concentric rings" (permissions...) associated with the variable number of related "segments of any one process," (... associated with a plurality of routines in a calling hierarchy).

It is agreed that the Organick reference raises a substantial new question of patentability as to claims 1, 3, 4, 6,10,12,13,15, and 19-21 of USPN 6,192,476 Bl to Gong. There is a substantial likelihood that a reasonable examiner would consider these teachings important in deciding whether or not the claims are patentable.

SNQ3. A substantial new question of patentability as to claims 1-21 is raised by the combination of Griffin and Chan. Neither Griffin nor Chan was previously cited in the examination of Application Control No. 08/988,431 which issued as USPN 6,192,476 Bl to Gong.

Griffin discloses a security management program, or trust management system, "for management of trust relationships among code segments to be executed inside a trust boundary." See Griffin at 1:22-25. Trust in program code can be varied for a user given the user's particular circumstances and the source of the program code. See id. at 3:26-29. Griffin discloses ('050, 4: 29-37) that portions of code being examined and executed are class defined in an object oriented programming environment, although the invention is not limited to object oriented programs. A "code identifier" analyzes the code and determines "whether execution of the portion of code is allowed by the policy rules given the potential resource use." See id., at Abstract. The code analyzer of Griffin employs a set of permissions— what it calls certificates or policies—which are granted to one or more principals; these "[certificates and policies can be specified in hierarchical form, so that some levels of security can be delegated to trusted entities." See id

Griffin discloses that "[i]f it is determined that clearance to trust is required to grant a particular access, a path of trust (in a calling hierarchy associated with said principal) must be found before the access will be granted by the trust manager," (detecting a request); Griffin then employs a "trust manager" that "examines each new class before it is allowed to load," (determining whether the action is authorized).

Chan, a text book of describing Java Class Libraries, provides explicit teachings of the Security Manager (analogous to Griffin's trust manager) class. A security manager may be defined with permission checks of the current execution context (principal/thread/process), information that the system has about the currently executing thread (including the thread group to which it belongs, the identity of the user executing the Java program, and the machine on which the Java program is executing) (1188-1189). "For some methods to perform some of the permission checking, they may need to inspect the execution stack (calling hierarchy) to find out information about the current execution context." (1189)

The combination would have been obvious because Griffin teaches that a path of trust must be found before the access will be granted by the trust manager, and then employs a trust manager to examine each new class before it is allowed to load. Chan provides a supporting definition of the Security Manager, known to examine the calling hierarchy of the stack to analyze the permission authorizations. It would have been obvious to one of ordinary skill in the art at the time of the invention to modify Griffin's disclosed trust manager, with the specific details provided by Chan to determine whether permissions should be granted.

It is agreed that the combination of Griffin and Chan raises a substantial new question of patentability as to claims 1-21 of USPN 6,192,476 Bl to Gong. There is a substantial likelihood that a reasonable examiner would consider these teachings important in deciding whether or not the claims are patentable.

Decision Granting the Order

A substantial new question of patentability affecting claims 1-21 of USPN 6,192,476 Bl to Gong is raised by the request for reexamination. In view of the above, the request for reexamination is GRANTED. Claims 1-21 of USPN 6,192,476 Bl to Gong will be reexamined.



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]

Text of Reexamination Decision:
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.


Patent No. 7426720
Reexamination Control No. 95/001560

Granted 4/18/11

Request for Inter Partes Reexamination [PDF]

Exhibit 17 - Claim Chart [PDF]

Exhibit 18 - Claim Chart" [PDF]

Exhibit 19 - Claim Chart [PDF]

Exhibit 20 - Claim Chart [PDF]

Exhibit 21 - Claim Chart [PDF]

Exhibit 22 - Claims Chart [PDF]

Exhibit 23 - Claim Chart [PDF]

Office Action in Inter Partes Reexamination [PDF]

Order Granting Reexamination [PDF]

Text of Reexamination Decision:
DETAILED ACTION

The instant request for inter partes reexamination alleges a substantial new question of patentability affecting claims 1-8, 10-17, and 19-22 of USPN 7,426,720 Bl to Fresko.

Current Litigation

U.S. District Court for the Northern District of California - Oracle America, Inc. v. Google, Inc., Civil Action No.: 3:10-cv-03561

Scope of Reexamination

On November 2, 2002, Public Law 107-273 was enacted. Title III, Subtitle A, Section 13105, part (a) of the Act revised the reexamination statute by adding the following new last sentence to 35 U.S.C. 303(a) and 312(a):

The existence of a substantial new question of patentability is not precluded by the fact that a patent or printed publication was previously cited by or to the Office or considered by the Office. For any reexamination ordered on or after November 2, 2002, the effective date of the statutory revision, reliance on previously cited/considered art, i.e., "old art," does not necessarily preclude the existence of a substantial new question of patentability (SNQ) that is based exclusively on that old art. Rather, determinations on whether a SNQ exists in such an instance shall be based upon a fact-specific inquiry done on a case-by-case basis.

In the instant request for reexamination the examiner has considered old art taken in a new combination (viewed in a new light) and new art that was not before the previous examiner at the time of allowance.

Background

Application Control Number 10/745,023 (file date 12/22/2003)rissued as USPN-7,426,72031 . (09/16/2008) to Fresko. A terminal disclosure was filed (07/10/2007) and accepted (09/20/2007) over Application control number 10/745,022, now USPN 7,293,267, where similar subject matter was claimed by the same inventor.

A non final office action (04/27/2009) rejected claims 1-24 as obvious over USPN 6,823,509 B2 to Webb, in view of US Pub No. 2003/0088604 Al to Kuck. It was noted that Web did not disclose a runtime environment to clone the memory space as a child runtime system process responsive to a process request and to execute the child runtime system process. However Kuck disclosed the missing teaching. The non final office action also provided a provisional nonstatutory double patenting rejection of claims 1,6-12, and 17-24 over claims 1,8-14, and 21-28 of copending Application 10/745,022. Applicant's Response (07/10/2007) amended claims 1, 12, and 24 to clarify that the invention sets operating system level resource management parameters on the child runtime system processes, and asserted that Webb / Kuck did not teach the existence of a resource controller that sets operating system level resource management parameters on a child runtime system process. Applicant cancelled dependent claims 9 and 20. A final office action (10/18/2007) maintained the rejection and responded to the Applicant's argument noting that Kuck is relied upon for teaching the existence of a resource controller to set operating system level resource management parameter on the child runtime system process at paragraph [0064]. An interview (12/17/2007), discussing Applicant's claim amendments after final (12/18/2007) (amended claims 1,12, and 24, canceled claims 7 and 18, added new claims 25 and 26), was followed by an Advisory Action (01/23/2008) denying entry of claim amendments, as they changed the scope of the claims. Subsequent to an RCE (01/31/2008), incorporating the amendments of 12/18/2007, a Notice of Allowance (05/20/2008) was issued. Claims 1-6, 8, 10-17, 19, and 21-26 were allowed. Applicant's argued that the present invention reduces both the allocation overhead and the memory space usage of virtual machines by using copy-on-write cloning, so that referenced segments are lazily copied at modification time, thus reducing the time and space needed to initialize and execute the child runtime system. Applicant argued that nothing in Webb or Kuck discloses reducing memory usage for virtual machines by using copy-on-writing cloning. An Examiner's Amendment added the terms "a processor; a memory" to claims 1 and 24. The Examiner noted that the prior art of record failed to teach: "a runtime environment to clone the memory space as a child runtime system process responsive to a process request and to execute the child runtime system process and a copy-on-write process cloning mechanism to instantiate the child runtime system process by copying references to the memory space of the master runtime system process into a separate memory space for the child runtime system process, and to defer copying of the memory space of the master runtime system process until the child runtime system process needs to modify the referenced memory space of the master runtime system process as recited in independent claims."

Overview of USPN 7,426,720 Bl to Fresko

The '720 patent relates to a method and system for the "dynamic preloading of classes through memory space cloning of a master runtime system process" relying in all the claims on a copy-on-write process cloning mechanism. See '720 patent, Claims 1,10, and 20. The '720 patent recites the cloning of a master runtime process into one or more child runtime processes to support the spawning of multiple and independent isolated user applications. See '720 patent 2:44-48. Each of the independent claims of the '720 patent rely on a copy-on-write process cloning mechanism to instantiate the child runtime system process. See id. at Claims 1,10, and 20.

The '720 specification acknowledges that a well-known process cloning mechanism in the prior art was the fork() system call of the Unix and/or Linux operating systems: "an example of a process cloning mechanism suitable for use in the present invention is the fork () system call provided by the Unix or Linux operating systems, such as described in [the prior art reference] M. J. Bach, 'The Design of the Unix Operating System,' Ch. 7, Bell Tele. Labs., Inc. (1986)." See '720 patent at 4:54-5:6 (citing Chapter 7 of the APA-Bach reference). When implementing the fork() system call, use of the copy-on-write process allows for the operating system to create a copy of the context of the parent process into the memory space of the child process by copying only references to the memory space, deferring the actual copying of the individual memory space segments until, and if, the child process attempts to modify the referenced data of the parent process context. See id. at 4:63-5:3. The 720 patent then describes a "copy on-write variant" of this fork() system call "[i]n a copy-on-write variant of the fork() system call, the operating system only copies references to the memory space and defers actually copying individual memory space segments until, and if, the child process attempts to modify the referenced data of the parent process context." See id. at 4:66-5:3. The 720 patent lists the reduced impact on system memory as a primary benefit of the combination of a fork() system call with copy-on-write. See 720 patent at 3:21-40. The 720 patent incorporates by reference only Chapters 2 and 7 of the APA-Bach reference, which the Applicant relied on for discussion of the fork( ) system call.

Prior Art

Third Party Requester proposes a substantial new question of patentability to be raised based on the teachings disclosed by the following prior art references:
10. USPN 6,823,509 to Webb, "Virtual Machine with Reinitialization," published on Dec. 12, 2001, issued on Nov. 23, 2004 ("Webb"), Exhibit 6, qualifies as a 102(b) reference.

11. US Patent Publication No. 2003/0088604 Al to Kuck, "Process Attachable Virtual Machines," published on May 8, 2003 (hereinafter "Kuck"), Exhibit 7, qualifies as a 102(e) reference. 12. M.J. Bach, The Design of the Unix Operating System, Bell Telephone Labs., Inc. (1986); excerpts ("APA-Bach"), Exhibit 8, qualifies as a 102(b) reference.

13. Jeff Dike, "A user-mode port of the linux kernel," Proceeding ALS '00 Proceedings of the 4th annual Linux Showcase & Conference - Volume 4, USENIX Association Berkeley, CA, USA (2000) ("Dike"), Exhibit 9, qualifies as a 102(b) reference.

14. Udo Steinberg, "Fiasco u-Kernel User-Mode Port," Dresden University of Technology, Institute of System Architecture (Dec. 19, 2002) ("Steinberg"), Exhibit 10, qualifies as a 102(b) reference.

15. USPN 6,405,367 to Bryant et al., "Apparatus and Method for Increasing the Performance of Java Programs Running on a Server," issued on June 11, 2002 ("Bryant"), Exhibit 11, qualifies as a 102(b) reference.

16. US Patent Application Pub. No. 2004/001,787 to Traut et al., "Method for Forking or Migrating a Virtual Machine," filed on Jul. 11, 2002, published on Jan. 15, 2004, and issued as a United States Patent on Dec. 25, 2007 ("Traut"), Exhibit 12, qualifies as a 102(b) reference.

17. Sriram Srinivasan, Advanced Perl Programming. O'Reilly & Associates, Inc. (August 1997) ("Srinivasan"), Exhibit 13, qualifies as a 102(b) reference.

18. USPN 6,854,114 to Sexton, "Using a virtual machine instance as the basic unit of user execution in a server environment," filed on Feb. 25, 2000, issued on Feb. 8, 2005 ("Sexton"), Exhibit 14, qualifies as a 102(b) reference.

19. USPN 6,075,938 to Bugnion et al., "Virtual Machine Monitors for Scalable Multiprocessors," filed on June 10, 1998, issued on June 13, 2000 ("Bugnion"), Exhibit 15, qualifies as a 102(b) reference.

20. USPN 6,330,709 to Johnson et al., "Virtual Machine Implementation for Shared Persistent Objects," filed on Feb. 25, 2000, issued on Dec. 11,2001 ("Johnson"), Exhibit 16, qualifies as a 102(b) reference.
Webb and Kuck were considered in the prosecution of the '023 Application, but their teachings were not combined with the complete APA teachings of Bach, which was incorporated by reference into the '023 Application (USPN 7,426,720 Bl to Fresko, 4: 56-58). APA-Bach, Chapter 9 was not previously considered by the Examiner or listed in an IDS statement. Thus, the combination, with new citations, presents teachings in a new light.

Proposed SNQs

The Requester has alleged substantial new questions of patentability as follows:

SNQ 1:
The requester proposes that the APA-Bach teachings (Request 03/01/2011, pp. 20-25 & Claim Chart Exhibit 17) taken in combination with Webb and Kuck, raises a substantial new question of patentability regarding claims 1-8, 10-17, and 19-22.

Analysis: The combination of Webb, Kuck, and APA-Bach are viewed in a new light and provide teachings non-cumulative to the prior art considered by the Patent Office during the prosecution of the '720 patent.

Webb / Kuck provide relevant teachings of cloning the master runtime system process along with the motivation to reduce memory usage and overhead when instantiating and executing virtual machines. Webb teaches a computer system including a memory and a processor. See Webb at 3:56-4:2. Webb implements a class pre-loader: "[a]t run-time objects are created as instantiations of these class files, and indeed the class files themselves are effectively loaded as objects." See Webb at 1:22-38. Webb's disclosure of a master runtime system process to interpret and to instantiate the representation as a class definition in a memory space of the master runtime system process is clear in Fig. 3, which Webb explains is the "initialization of a loaded class (step 350), which represents calling the static initialization method (or methods) of the class . .. this application must be performed once and only once before the first active use of a class" which then allows for "[t]he new application class [to load the application classes into the JVM (step 410), and involves the steps shown in Fig. 3 for all the application classes." See Webb at 6:59-65 & 7:34-39. Kuck discloses a runtime environment to clone the memory space as a child runtime system process responsive to a process request and to execute the child runtime system process. See Kuck at [0064]-[0065].

Requester proposes that the APA-Bach reference appears to teach the very feature that was believed to distinguish the claimed invention over the previous prior art, notably: "[t]he copy-on-write bit, used in the fork system call, indicates that the kernel must create a new copy of the page when a process modifies its contents." See APA-Bach at 287. And, even more specifically, APA-Bach discloses: "As explained in Section 7.1, the kernel duplicates every region of the parent process during the fork system call and attaches it to the child process. Traditionally, the kernel of a swapping system makes a physical copy of the parent's address space, usually a wasteful operation, because processes often call exec soon after the fork call and immediately free the memory just copied. On the System V paging system, the kernel avoids copying the page by manipulating the region tables, page table entries, and pfdata table entries: It simply increments the region reference count of shared regions .... The page can now be referenced through both regions, which share the page until a process writes to it. The kernel then copies the page so that each region has a private version. To do this, the kernel turns on the 'copy on write' bit for every page table entry in private regions of the parent and child processes during fork. If either process writes the page, it incurs a protection fault, and in handling the fault, the kernel makes a new copy of the page for the faulting process. The physical copying of the page is thus deferred until a process really needs it." See APA-Bach at 289-90.

It is agreed that the consideration of APA-Bach, taken in combination with Webb / Kuck, for the teachings that were not present in the prosecution of the application which became the Fresko '720 patent, raises a substantial new question of patentability. There is a substantial likelihood that a reasonable examiner would consider the APA-Bach teachings, taken in combination with Webb / Kuck, important in deciding whether or not the claims are patentable. Accordingly, it is agreed that the APA-Bach teachings, in combination with Webb / Kuck, raises a substantial new question of patentability with respect to claims 1-8, 10-17, and 19-22, which question has not been decided in a previous examination of the Fresko '120 patent.

SNQ 2: The requester proposes that Dike, with evidentiary support by Steinberg, raises a substantial new question of patentability regarding claims 1-8, 10-17, and 19-22. (Request 03/01/2011, pp. 7-8, 25-28 & Claim Chart Exhibit 18)

Analysis: The teachings of Dike, as evidenced by Steinberg, are non cumulative to the prior art considered by the Patent Office during the prosecution of the '720 patent.

Dike describes the creation of a Linux virtual machine that runs on Linux, wherein the virtual machine systems are all cloned, using the fork() system call, onto the host system (Dike, 2.1, 2.3). Since all of the systems need access to the kernel data, Dike employs a shared data state between the processes, disclosing a copy-on-write mechanism to allow all of the processes to access the kernel data. Dike provides the teaching that was missing from the original examination by explicitly disclosing the underlying cloning process is the Linux fork() call, and further noting that the Linux fork() cloning is optimized using copy-on-write. Further supporting evidence of the cloning optimization (using copy on write) is provided by Steinberg: "[t]he created child process inherits copies of the parent process data space, heap and stack, which are copied on demand using a copy-on-write mechanism." See Steinberg at 21.

It is agreed that the consideration of Dike, supported with evidence by Steinberg, for the teachings that were not present in the prosecution of the application which became the Fresko '720 patent, raises a substantial new question of patentability. There is a substantial likelihood that a reasonable examiner would consider the Dike / Steinberg teachings important in deciding whether or not the claims are patentable. Accordingly, it is agreed that Dike / Steinberg raises a substantial new question of patentability with respect to claims 1-8, 10-17, and 19-22, which question has not been decided in a previous examination of the Fresko '120 patent.

SNQ 3: The requester proposes (Request 03/01/2011, pp. 7-8, pp. 25-28 & Claim Chart Exhibit 18) that the combination of Dike and Steinberg raises a substantial new question of patentability regarding claims 1-8, 10-17, and 19-22.

Analysis: The teachings of Dike and Steinberg are noted above. To the extent that it is found that Dike does not anticipate claims 1-8, 10-17 and 19-22 of the 720 patent, then the combination of Dike and Steinberg teaches all the elements of these claims. Dike discloses process cloning and explicitly references copy-on-write as the default mechanism for process cloning. Steinberg provides teachings that define the copy-on-write mechanism.

It is agreed that consideration of Dike, in combination with Steinberg, for the teachings that were not present in the prosecution of the application which became the Fresko '720 patent, raises a substantial new question of patentability. There is a substantial likelihood that a reasonable examiner would consider the Dike / Steinberg teachings important in deciding whether or not the claims are patentable. Accordingly, it is agreed that an obvious combination of Dike / Steinberg raises a substantial new question of patentability with respect to claims 1-8, 10-17, and 19-22, which question has not been decided in a previous examination of the Fresko '120 patent.

SNQ 4: The requester proposes that Bryant, in combination with APA-Bach, raises a substantial new question of patentability regarding claims 1-8, 10-17, and 19-22. (Request 03/01/2011, pp. 8-9, 28-31 & Bryant in view of APA Bach - Claim Chart Exhibit 19)

Analysis: The teachings of Bryant and APA-Bach, are non cumulative to the prior art considered by the Patent Office during the prosecution of the '720 patent.

Bryant discloses a method and apparatus useful for increasing the performance of Java programs by executing a fork command and creating a child Java machine. Bryant discloses a Java server that "invokes the Java virtual machine and preloads all potentially needed object files during initialization of the Java virtual machine to speed up the actual execution of a particular Java application. The Java server accomplishes the execution of a particular Java application by forking itself and then having the child Java server run the Java class files in the already loaded Java virtual machine for the specific Java CGI-BIN script." See Bryant at 2:46-48.

Requester proposes that the APA-Bach reference appears to teach the very feature that was believed to distinguish the claimed invention over the previous prior art. The APA-Bach disclosure of the copy-on-write mechanism, teaches the purported point of novelty of reducing memory usage for virtual machines by using copy-on-write cloning. (Bach, 192, 287-290)

It is agreed that the consideration of APA-Bach, taken in combination with Bryant, for the teachings that were not present in the prosecution of the application which became the Fresko '720 patent, raises a substantial new question of patentability. There is a substantial likelihood that a reasonable examiner would consider the APA-Bach teachings, taken in combination with Bryant, important in deciding whether or not the claims are patentable. Accordingly, it is agreed that the APA-Bach teachings, in combination with Bryant, raise a substantial new question of patentability with respect to claims 1-8, 10-17, and 19-22, which question has not been decided in a previous examination of the Fresko '120 patent.

SNQ 5: The requester proposes that Bryant in combination with Traut raises a substantial new question of patentability regarding claims 1-8, 10-17, and 19-22. (Request 03/01/2011, pp. 8-9, 28-31 & Bryant in view of Traut Claim Chart Exhibit 20)

Analysis: The teachings of Bryant and Traut, are non cumulative to the prior art considered by the Patent Office during the prosecution of the '720 patent.

Bryant's teachings are discussed above. The Traut prior art reference discloses the use of a copy-on-write process cloning, mechanism while forking a virtual machine, and provides the suggestion that that the forking process saves memory resources and increases speed. (Traut, [0012], [0026], [0029], and [0031])

It is agreed that the consideration of Bryant and Traut, for the teachings that were not present in the prosecution of the application which became the Fresko '720 patent, raises a substantial new question of patentability. There is a substantial likelihood that a reasonable examiner would consider the teachings of the combination of Bryant and Traut important in deciding whether or not the claims are patentable. Accordingly, it is agreed that Bryant, in combination with Traut, raises a substantial new question of patentability with respect to claims 1-8, 10-17, and 19-22, which question has not been decided in a previous examination of the Fresko '120 patent.

SNQ 6: The requester proposes that the combination of Srinivasan and APA-Bach raises a substantial new question of patentability regarding claims 1-8, 10-17, and 19-22. (Request 03/01/2011, pp. 31-33, & Claim Chart Exhibit 21)

Analysis: The Srinivasan and notable citations of the APA-Bach reference are non-cumulative to the prior art considered by the Patent Office during prosecution of the '720 patent.

The Srinivasan reference (pp. 193-194), explicitly uses fork() to spawn a worker process. The fork system call disclosed by Srinivasan was commonly used with the copy-on-write mechanism to further streamline the impact on system memory, as described by APA-Bach. The APA-Bach discloses copy-on-write with the object-oriented code. Requester proposes that the Srinivasan / APA-Bach combination appears to teach the very feature that was believed to distinguish the claimed invention over the previous prior art.

It is agreed that the consideration of Srinivasan and AP A-Bach, for the teachings that were not present in the prosecution of the application which became the Fresko '720 patent, raises a substantial new question of patentability. There is a substantial likelihood that a reasonable examiner would consider the combination of teachings of Srinivasan and AP A-Bach important in deciding whether or not the claims are patentable. Accordingly, it is agreed that Srinivasan, in combination with APA-Bach, raises a substantial new question of patentability with respect to claims 1-8, 10-17, and 19-22, which question has not been decided in a previous examination of the Fresko '120 patent.

SNQ 7: The requester proposes (Request 03/01/2011, pp. 9, 33-36 & Claim Chart Exhibit 22) that the combination of Sexton and Bugnion raises a substantial new question of patentability regarding claims 1-8, 10-17, and 19-22.

Analysis: Sexton is directed to reducing memory usage for virtual machines by providing readonly access to shared data. See Sexton at 5: 29-44; 5: 53-57; 8:41-64. Sexton provides the suggestion for reducing memory by sharing data between multiple ("spawned", '114, 8: 2) virtual machines and otherwise creating a VM data structure to hold modified data (i.e., fork process, 8: 1-18; 8: 40-64), for the purpose of resource management. The Bugnion reference discloses (6: 29-36; 14: 55-64; 15: 66 - 16: 1) a Virtual Machine Monitor ("VMM") layer that "maintains copy-on-write disks."

Requester proposes that the Sexton / Bunion combination appears to teach the very feature that was believed to distinguish the claimed invention over the previous prior art.

It is agreed that the consideration of Sexton / Bunion, for the teachings that were not present in the prosecution of the application which became the Fresko '720 patent, raises a substantial new question of patentability. There is a substantial likelihood that a reasonable examiner would consider the combination of teachings of Sexton and Bunion important in deciding whether or not the claims are patentable. Accordingly, it is agreed that Sexton, in combination with Bunion, raises a substantial new question of patentability with respect to claims 1-8, 10-17, and 19-22, which question has not been decided in a previous examination of the Fresko '120 patent.

SNQ 8: The requester alleges (Request 03/01/2011, pp. 9, 33-36 & Claim Chart Exhibit 23) that the obvious combination of Sexton and Johnson raises a substantial new question of patentability regarding claims 1-8, 10-17, and 19-22.

Analysis: Sexton's teachings are noted above. The Johnson reference "introduces copy on write storage" used for access to static variables. (Johnson, 18: 34-44) Each JVM has its own copies of any static variables defined for a class of which it has an instance.

Requester proposes that the Sexton / Johnson combination appears to teach the very feature that was believed to distinguish the claimed invention over the previous prior art.

It is agreed that consideration of Sexton / Johnson, for the teachings that were not present in the prosecution of the application which became the Fresko '720 patent, raises a substantial new question of patentability. There is a substantial likelihood that a reasonable examiner would consider the combination of teachings of Sexton and Johnson important in deciding whether or not the claims are patentable. Accordingly, it is agreed that Sexton, in combination with Johnson, raises a substantial new question of patentability with respect to claims 1-8, 10-17, and 19-22, which question has not been decided in a previous examination of the Fresko '120 patent.



Patent No. RE38104
Reexamination Control No. 90/011490

Granted 3/28/11

Request for Ex Parte Reexamination [PDF]

Order Granting Reexamination [PDF]

Text of Reexamination Decision:
ORDER GRANTING EX PARTE REEXAMINATION

A substantial new question of patentability affecting claims 11-41 of United States Reissued Patent RE38,104 is raised by the request for ex parte reexamination.,br>
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 "an applicant" and not to parties in a reexamination proceeding. Additionally, 35 U.S.C. 305 requires that ex parte reexamination proceedings "will be conducted with special dispatch" (37 CFR 1.550(a)). Extensions of time in ex parte reexamination proceedings are provided for in 37 CFR 1.550(c).

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 Reissued Patent No. RE38,104 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.

Printed Publications Cited in the Request

The request cites the following prior art patents and printed publications as raising a substantial new question of patentability (SNQ):
1. Gries, David, Compiler Construction for Digital Computers, (John Wiley & Sons, Inc., 1971), (hereinafter, the "Gries 1971 reference").
2. U.S. Patent 4,571,678 (Chaitin).
3. Gabriel, Richard P., Performance and Evaluation of Lisp Systems, (MIT Press, 1985), (hereinafter, the "Gabriel 1985 reference").
Prosecution History

RE38,104 is a reissue of U.S. Pat. 5,367,685 (issued from application 07/994,655, filed December 22, 1992). The '104 reissued patent issued from application 09/261,970, filed March 3, 1999. A reasonable summary of the prosecution history of the '104 reissued patent is contained in the request, (Request for Ex Parte Reexamination, 2/15/2011, pp. 6-8). Although the request selectively emphasized a portion of the examiner's reasons for allowance in the '685 patent's file, (Request at 7), the emphasized portions appear to be consistent with the scope of the claims under consideration. Specifically, the requester notes that the ' 104 patent's claims generally include: (1) receiving an intermediate form of code with symbolic references; and (2) determining numeric references corresponding to the symbolic references. (Request at 11.) Because these claim features are consistent with the previously stated reasons for allowance in the '685 patent file, and because there appear to be no conflicting statements or further elaboration on allowability of these claim features in the reissue applications, these features appear to have likewise been important in allowing the '104 reissue patent claims.

Substantial New Questions of Patentability

A. The SNQ Requirement


The Office may only grant a reexamination request if an SNQ affecting any claim of the patent concerned is raised by the request, with or without consideration of other patents or printed publications. 35 U.S.C. §§ 303(a) and 304.

The court in Swanson evaluated the scope of the SNQ requirement in reexamination, extensively citing the legislative history of the original reexamination statute and the 2002 amendment:

"[I]n passing the original reexamination statute, Congress stated that 'this new procedure will permit any party to petition the patent office to review the efficacy of a patent, subsequent to its issuance, on the basis of new information about preexisting technology which may have escaped review at the time of the initial examination of the patent application,' and explained that the substantial new question requirement bars 'reconsideration of any argument already decided by the office, whether during the original examination or an earlier reexamination."' In re Swanson, 540 F.3d 1368, 1377 (Fed. Cir. 2008) (quoting H.R. Rep. No. 96-1307 (1980)) (emphasis omitted). "[T]he substantial new question requirement 'guard[s] against simply repeating the prior examination on the same issues and arguments' and bars 'a second examination, on the identical ground that had previously been raised and overcome." Id. at 1380 (quoting//? re Recreative Technologies Corp., 83 F.3d 1394, 1396-97 (Fed. Cir. 1996)). Further, "[t]he issue raised must be more than just questioning the judgment of the examiner." Id. (quoting H.R. Rep. No. 107-120 (2002)). "[T]o decide whether a reference that was previously considered by the PTO creates a substantial new question of patentability, the PTO should evaluate the context in which the reference was previously considered and the scope of the prior consideration and determine whether the reference is now being considered for a substantially different purpose." Id.

A prior art patent or printed publication raises a substantial question of patentability where there is a substantial likelihood that a reasonable examiner would consider the prior art patent or printed publication important in deciding whether or not the claim is patentable, unless the same question of patentability has already been decided as to the claim in a final holding of invalidity by the Federal court system or by the Office in a previous examination. MPEP § 2242.

B. the Gries 1971 reference

The request asserts that a substantial new question of patentability as to claims 11-41 of the '104 patent is raised by the Gries 1971 reference. (Request at 12-13.) The examiner agrees.

As noted by the requester, the Gries 1971 reference discloses: (1) receiving an intermediate form of code with symbolic references; and (2) determining numeric references corresponding to the symbolic references. Specifically, the Gries reference discloses resolving a symbolic reference (a pointer to a symbol table entry) to obtain a value associated with a variable (loading the value by using the address containing the value, a numerical reference).

Because this new, non-cumulative teaching appears to be relevant to the features asserted to be missing from the prior art in the examiner's reasons for allowance in the parent patent's file, there is a substantial likelihood that a reasonable examiner would consider the Gries 1971 reference important in deciding whether or not claims 11-41 of the '104 patent are patentable. Accordingly, the Gries 1971 reference raises an SNQ as to claims 11-41.

C. the Chaitin '678 patent

The request asserts that a substantial new question of patentability as to claims 11-41 of the '104 patent is raised by the Chaitin '678 patent. (Request at 13-14.) The examiner agrees.

As noted by the requester, the Chaitin '678 patent discloses: (1) receiving an intermediate form of code with symbolic references (i.e., symbolic registers); and (2) determining numeric references corresponding to the symbolic references (rewriting the intermediate language code replacing symbolic registers with real machine register numbers). (Request at 13-14.)

Because this new, non-cumulative teaching appears to be relevant to the features asserted to be missing from the prior art in the examiner's reasons for allowance in the parent patent's file, there is a substantial likelihood that a reasonable examiner would consider the Chaitin '678 patent important in deciding whether or not claims 11-41 of the '104 patent are patentable. Accordingly, the Chaitin '678 patent raises an SNQ as to claims 11-41.

D. the Gabriel 1985 reference

The request asserts that a substantial new question of patentability as to claims 11-41 of the '104 patent is raised by the Gabriel 1985 reference. (Request at 14-15.) The examiner agrees.

As noted by the requester, the Gabriel 1985 reference discloses: (1) receiving an intermediate form of code with symbolic references (i.e., interpreted code); and (2) determining numeric references corresponding to the symbolic references (i.e., resolving a function name to its address). Although an address of a functional may reasonably be interpreted as a numeric reference, the examiner notes that "BCD" in the Gabriel 1985 reference does not appear to mean "binary coded decimal" as described in the request.

Because this new, non-cumulative teaching appears to be relevant to the features asserted to be missing from the prior art in the examiner's reasons for allowance in the parent patent's file, there is a substantial likelihood that a reasonable examiner would consider the Gabriel 1985 reference important in deciding whether or not claims 11-41 of the '104 patent are patentable. Accordingly, the Gabriel 1985 reference raises an SNQ as to claims 11-41.


Patent No. 6910205
Reexamination Control No. 95/001548

Granted 4/14/11

Request for Inter Partes Reexamination [PDF]

Order Granting Reexamination [PDF]

Text of Reexamination Decision:
ORDER GRANTING INTER PARTES REEXAMINATION

A substantial new question of patentability affecting claims 1-4 and 8 of United States Patent 6,910,205 is raised by the present request for inter partes reexamination.

Extensions of time under 37 CFR 1.136(a) will not be permitted in inter partes reexamination proceedings because the provisions of 37 CFR 1.136 apply only to "an applicant" and not to the patent owner in a reexamination proceeding. Additionally, 35 U.S.C. 314(c) requires that inter partes reexamination proceedings "will be conducted with special dispatch" (37 CFR 1.937). Patent owner extensions of time in inter partes reexamination proceedings are provided for in 37 CFR 1.956. Extensions of time are not available for third party requester comments, because a comment period of 30 days from service of patent owner's response is set by statute. 35 U.S.C. 314(b)(3).

The patent owner is reminded of the continuing responsibility under 37 CFR 1.985(a), to apprise the Office of any litigation activity, or other prior or concurrent proceeding, involving Patent 6,910,205 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 § 2686 and 2686.04.

I. IDENTIFICATION OF EVERY CLAIM FOR WHICH REEXAMINATION IS REQUESTED

Reexamination of claims 1-4 and 8 of the '205 patent has been requested. (Request for Inter Partes Reexamination, 2/17/2011, p. 1.)

II. REFERENCES CITED IN THE REQUEST

The request cites the following patents and printed publications as raising a substantial new question of patentability:
7. L. Peter Deutsch et al., Efficient Implementation of the Smalltalk-80 System, Proceedings of the 11th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages, pp. 297-302, 1984 (hereinafter, "Deutsch");

8. David Wakeling, A Throw-Away Compiler for a Lazy Functional Language, Fuji International Workshop on Functional and Logic Programming, pp. 287-300, 1995 (hereinafter, "Wakeling");

9. Brian T. Lewis et al., Clarity MCode: A Retargetable Intermediate Representation for Compilation, ACM, IR '95, 1/95, San Francisco, California, USA, pp. 119-128, 1995 (hereinafter, "Lewis");

10. Paul Tarau et al., The Power of Partial Translation: An Experiment with the C-Ification of Binary Prolog, ACM Symposium on Applied Computing, pp. 152-156, 1995 (hereinafter, "Tarau");

11. Frank Yellin, The JIT Compiler API, The JIT Compiler API, October 4, 1996, pp. 1-23 (hereinafter, "Yellin");

12. U.S. Patent 6,081,665 (Nilsen et al.);

13. U.S. Patent 5,842,017 (Hookway et al.);

14. Peter Magnusson, Partial Translation, Swedish Institute of Computer Science Technical Report (T93.5), Oct. 1993 (hereinafter, "Magnusson"); and 15. U.S. Patent 5,768,593 (Walters et al.).
III. PROSECUTION HISTORY

The '205 patent issued from application 10/194,040, filed July 12, 2002, as a continuation of application 08/884,856, now patent 6,513,156. Claims 1-4 and 8 of the '205 patent correspond to the '040 application's claims 32, 2-4, and 33, respectively.

In the first Office action on the merits in the '040 application (addressing original claims 1-31), the examiner rejected several claims under 35 U.S.C. § 102(e) as being anticipated by the Walters '593 patent. '040 App., Non-Final Rejection, 3/5/2004.

In response, the applicants added new claims 32 and 33 (and amended claim 2 to depend from claim 32), asserting that Walters did not teach or suggest "generating, at runtime, a new virtual machine instruction that represents or references one or more native instructions that can be executed instead of a first virtual machine instruction," as found in claim 32, or "representing at least one native machine instruction with a virtual machine instruction that is executed after compiling the function," as found in claim 33. '040 App., Remarks 6/1/2004, p. 12.

The examiner disagreed with the applicants' arguments, finding that the Walters '593 patent disclosure of cross-compiling an application such that some parts are native code and some are native code blocks met the language of claim 33, including representing that at least one native machine instruction with a virtual machine instruction (non-native instruction) that is executed after the compiling of the function. '040 App., Final Rejection, 9/23/2004. All of the Art Unit: 3992 pending claims were rejected under the doctrine of nonstatutory double patenting as being unpatentable over claims 1-47 of U.S. Pat. 6,513,156 (issued from the parent application), and claims 1, 8-12, 21, 22, 29-31, 33-36, and 38-41 were rejected under § 102(e) as being anticipated by the Walters '593 patent, but claims 2-7, 32, and 37 were not rejected on the basis of prior art1. Id.
---------
1 The Final Rejection stated on p. 3 that claims 1,8-12, 19-22, and 29-31 were rejected under § 102(e), but in the discussion of the rejection, the limitations of claims 1, 8-12, 21, 22, 29-31, 33-36, and 38-41 were mapped to the teachings of the Walters '593 patent.
---------

The applicants canceled claims 1, 8-12, 21, 22, and 29-31, leaving claims 2-7 and 32-41 the only remaining pending claims. A terminal disclaimer was filed to overcome the double patenting rejection. '404 App., Amendment, 10/7/2004.

In an Advisory Action, the examiner allowed claims 2-7 and 32 but maintained the rejection of claims 33-41 under § 102(e). The examiner compared the limitations in allowable claim 32 with those in rejected claim 33:
Claim 32 details generating a new virtual machine instruction that is executed instead of a first virtual machine instruction and represents one or more native instructions wherein the new virtual machine instruction is executed instead of the first virtual machine instructions. Claim 33 does not read upon this same interpretation. Claim 33 details inputting virtual machine instructions, compiling a portion of the instructions wherein at least one native machine instruction is represented by a virtual machine instruction. In claim 33, the represented virtual [machine] instruction is the same virtual [machine] instruction inputted. Therefore, one simply compiles a portion of the overall function and executes the whole function by determining if the next virtual [machine] instruction of the function is precompiled or not and acting accordingly by directly executing the native code or interpreting and executing the instruction. The cited prior art of record allows for this and therefore the rejection is maintained.
'404 App., Advisory Action, 12/14/2004.

On January 3, 2005, an interview was conducted during which the applicants' representative proposed to amend claim 33 wherein the native machine instruction is represented with a new virtual machine instruction that is executed after the compiling of the function. The examiner agreed and entered an Examiner's Amendment, inserting the word "new" into the final limitation of claim 33, changing it to its patented language, "representing said at least one native machine instruction with a new virtual machine instruction that is executed after the compiling of the function." '040 App., Examiner's Amendment, 1/13/2005 (underlining in original to indicate amended matter). The examiner provided detailed reasons for allowance:
Claims 32 and 2-7 teach generating at run-time a new virtual machine instruction that represents one or more native instructions that can be executed instead of a first virtual machine instruction.

Claim 33 teaches compiling a portion of virtual machine instructions into at least one native machine instruction wherein the native machine instruction is represented with a new virtual machine instruction that is executed after the compiling of the function.

Claims 34, 35, and 38-41 teaches a hybrid virtual and native machine instruction data structure which stores a copy of a selected virtual machine instruction that was overwritten in the sequence of virtual machine instructions by the new virtual "machine instruction. The cited prior art of record, in particular Walters, teaches a technique for increasing the speed of executing non-native applications, i.e. bytecodes, by cross-compiling portions of the application that would be beneficial in native code for faster execution into native instructions and having the entry bytecode for the compiled instructions point to location of the stored native instructions. Therefore, when the application is executed, a determination is made to see if the current bytecode is an entry bytecode. If this determination is positive, the corresponding set of native instruction(s) is executed. If this determination is negative, then the bytecode is interpreted and executed. The cited prior art of record however, does not teach or allude to the generation of a new virtual [machine] instruction that represents the one or more native instructions such that this new instruction is executed either (1) instead of the original virtual [machine] instruction or (2) after the compiling of the function. Walters makes the original non-native instruction an entry instruction for the native instructions, therefore, the original non-native instruction is always executed and no new virtual [machine] instruction is created to be executed. The cited prior art of record also does not teach or allude to the hybrid virtual-native instruction set maintaining a copy of the selected virtual [machine] instruction that was overwritten by the new virtual machine instruction. As stated above, Walters makes the original non-native instruction an entry instruction for the native instruction(s), therefore, the original non-native instruction is always executed and no new virtual [machine] instruction is created to be executed, yet alone overwrites an original virtual [machine] instruction such that both are stored in the overall hybrid virtual-native instruction set. Therefore, the claims are allowable over the cited prior art of record for at least the reasoning disclosed above.
'040 App., Notice of Allowability, 1/13/2005, pp. 2-4.

IV. SUBSTANTIAL NEW QUESTIONS OF PATENTABILITY (SNQ)

A. Deutsch


The request sets forth that the third party requester considers an SNQ as to claims 1-4 and 8 is raised by Deutsch, considered alone or in combination with the Walters '593 patent. (Request at 23-25.) The examiner disagrees.

The request asserts that Deutsch teaches generating a new virtual machine instruction that references native instructions, i.e., creating a new call instruction from a virtual machine instruction which includes a translated procedure in native code and (a) executing the new virtual machine instruction instead of an original virtual machine instruction, i.e., executing the new call instruction and (b) executing the new virtual machine instruction after compiling of the function. (Request at 24 (citing Deutsch at 298-300).)

The cited portions of Deutsch appear to be concerned with translation of v-code (code in the instruction set of the Smalltalk-80 v-machine) into n-code (code that executes directly on the hardware without interpretation). Deutsch at 298, col. 1. In this way, Deutsch avoids interpretation overhead and gains the opportunity for certain types of optimizations. Id. at 298, col. 2. Deutsch further describes a dynamic translator that finds a v-code routine corresponding to a procedure about to be executed, translates it into n-code, and completes the call. Id. Deutsch addresses compatibility issues by generating special n-code that calls a subroutine to ensure that an object is represented in a form where accesses to its named parts are meaningful, i.e. the runtime state is stored in a data structure (data object for procedure activation records) compatible with the v-machine. Id. at 299. For the actual execution of methods, Deutsch describes the generation of n-code calls that initially invoke a method-lookup to find the corresponding n-code method address and subsequently overwrite the n-code call with a call to the found address. Id. at 300.

Although the request asserts that Deutsch discloses generating a new virtual machine instruction (v-code instruction, using Deutsch's terminology), this does not appear to be the case. Because the disclosure of Deutsch does not appear to support the alleged new technological teaching set forth in the request, the request has not shown that there is a substantial likelihood that a reasonable examiner would consider Deutsch important in deciding whether or not claims 1-4 and 8 of the '205 patent are patentable. In the proposed combination of Deutsch and the Walters '593 patent, the requester asserts the same alleged new teaching in Deutsch as the basis for the proposed SNQ. Accordingly, Deutsch, considered alone or in combination with the Walters '593 patent, does not raise an SNQ as to claims 1-4 and 8.

B. Wakeling

The request sets forth that the third party requester considers an SNQ as to claims 1 -4 and 8 is raised by Wakeling, considered alone or in combination with the Walters '593 patent. (Reque st at 25-26.) The examiner disagrees.

The request cites 3 different portions of Wakeling (p. 288 (describing prior approaches to interpreting code), p. 291 (describing the throw-away compilation technique that is used to execute X-code (a form of bytecode)), and p. 296 (describing an "idea that never made it" in which the cost of function calls was reduced by using self-modifying machine code). It appears that the requester relies on the teaching on p. 296 of Wakeling for the teaching of generating a new virtual machine instruction. (Request at 25.) Upon closer review, the cited portion of Wakeling appears to teach the same dynamic code modification technique taught by Deutsch as discussed above, where a native code instruction is overwritten once the address of compiled code is known. Wakeling at 296. This is described as the "don't test, just enter" approach. Id. Wakeling describes the initial state of the dynamically-modifiable instruction as a jump to the supervisor, and after native code had been generated it was overwritten with a jump to that code. Id. This approach was abandoned by the author due to the overhead associated with cache coherency operations, system calls needed to flush any copies of the original native instruction already loaded into the instruction cache so that the replaced instruction would have to be loaded instead prior to execution. Id.; see also id. at 292 (further describing the cache coherency problems associated with throw-away compilation). There is no apparent teaching of a new virtual machine instruction being generated.

Because the disclosure of Wakeling does not appear to support the alleged new technological teaching set forth in the request, the request has not shown that there is a substantial likelihood that a reasonable examiner would consider Wakeling important in deciding whether or not claims 1-4 and 8 of the '205 patent are patentable. In the proposed combination of Wakeling and the Walters '593 patent, the requester asserts the same alleged new teaching in Wakeling as the basis for the proposed SNQ. Accordingly, Wakeling, considered alone or in combination with the Walters '593 patent, does not raise an SNQ as to claims 1-4 and 8.

C. Lewis

The request sets forth that the third party requester considers an SNQ as to claims 1-4 and 8 is raised by Lewis, considered alone or in combination with the Walters '593 patent. (Request at 26-27.) The examiner disagrees.

The request asserts that Lewis teaches generating a new virtual machine instruction that references native instructions, i.e., creating a new call instruction from a virtual machine instruction which includes a translated procedure in native code and (a) executing the new virtual machine instruction instead of an original virtual machine instruction, i.e., executing the new call instruction and (b) executing the new virtual machine instruction after compiling of the function. (Request at 26-27 (citing Lewis at 119 and 126).) The request specifically asserts that the rewritten trampoline instruction taught by Lewis is a new virtual machine instruction. However, the trampoline instructions taught by Lewis consist of platform-specific machine code rather than virtual machine code (consistent with the teachings of Deutsch and Wakeling discussed above). Lewis at 126, first paragraph.

Because the disclosure of Lewis does not appear to support the alleged new technological teaching set forth in the request, the request has not shown that there is a substantial likelihood that a reasonable examiner would consider Lewis important in deciding whether or not claims 1 -4 and 8 of the '205 patent are patentable. In the proposed combination of Lewis and the Walters '593 patent, the requester asserts the same alleged new teaching in Lewis as the basis for the proposed SNQ. Accordingly, Lewis, considered alone or in combination with the Walters '593 patent, does not raise an SNQ as to claims 1-4 and 8.

D. Tarau

The request sets forth that the third party requester considers an SNQ as to claims 1 -4 and 8 is raised by Tarau, considered alone or in combination with the Walters '593 patent. (Request at 27-28.) The examiner agrees.

As noted in the request, Tarau teaches modifying byte code to reference machine code and (a) executing the new virtual machine instruction instead of an original virtual machine instruction, i.e., executing the modified byte code to direct execution of the machine code and (b) executing the new virtual machine instruction after compiling of the function. (Request at 28 (citing Tarau at 152, 153, and 155).) Because this new, noncumulative technological teaching is relevant to the features asserted to be missing in the prior art in the examiner's reasons for allowance, there is a substantial likelihood that a reasonable examiner would consider Tarau important in deciding whether or not claims 1-4 and 8 of the '205 patent are patentable. Accordingly, Tarau, considered alone or in combination with the Walters '593 patent, raises an SNQ as to claims 1-4 and 8.

E. Yellin

The request sets forth that the third party requester considers an SNQ as to claims 1 -4 and 8 is raised by Yellin, considered alone or in combination with the Walters '593 patent. (Request at 29-30.) The examiner disagrees.

The request cites pp. 3-4 of Yellin as allegedly teaching generating a new virtual machine instruction that references native instructions, i.e., the new byte code that replaces the existing byte code and that references the native code. (Request at 29 (citing Yellin at 3-4).) However, the cited portion of Yellin is directed to the use of quick codes, which utilize an unassigned bytecode to shadow another bytecode. A "quick" bytecode is a more efficient implementation of the bytecode it replaces, but it still refers to byte code rather than referencing native code. In the example given on p. 4 of Yellin, a string.lengthQ function, compiled into bytecode invokevirtual #4, is rewritten as bytecode invokevirtual_quick 3 1 in order to avoid the overhead of checking whether the String class does in fact have a lengthO method, whether the current method is entitled to call the lengthQ method, the location of the lengthO method within the String class's method table, and the total argument length of the lengthO method. Although a new virtual machine instruction is generated, the new instruction does not represent or reference native instructions.

Because the disclosure of Yellin does not appear to support the alleged new technological teaching set forth in the request, the request has not shown that there is a substantial likelihood that a reasonable examiner would consider Yellin important in deciding whether or not claims 1 -4 and 8 of the '205 patent are patentable. In the proposed combination of Yellin and the Walters '593 patent, the requester asserts the same alleged new teaching in Yellin as the basis for the proposed SNQ. Accordingly, Yellin, considered alone or in combination with the Walters '593 patent, does not raise an SNQ as to claims 1-4 and 8.

F. The Nilsen '665 patent

The request sets forth that the third party requester considers an SNQ as to claims 1-4 and 8 is raised by the Nilsen '665 patent, considered alone or in combination with the Walters '593 patent. (Request at 30-32.) The examiner disagrees.

The request is extremely vague as to what specific portion in the Nilsen '665 patent corresponds to the new virtual machine instruction asserted to be taught, (see Request at 31 (citing portions of 8 different columns of Nilsen as allegedly teaching generating a new virtual machine instruction that references native instructions). However, it appears that the requester is equating a pointer table with the new virtual machine instruction.

The request relies in part on a pleading in the concurrent litigation, in which Oracle America, Inc. (the patent owner of record) argues that Google, Inc. (the real party in interest identified in the request for inter partes reexamination) is liable for infringing the '205 patent under the doctrine of equivalents. (Request at 20, 30-33.) The request highlights a portion of the infringement contention, reading "The differences, if any, between a 'new virtual machine instruction' and an entry in the jitEntry table are insubstantial," and asks the Office to accept the highlighted portion as a patent owner admission for the truth of the matter asserted.2
----------
2 Presumably, the requester is denying this contention in the ongoing litigation rather than holding up any part of it as truth. The Office lacks the resources and jurisdiction to decide the issue either way.
----------
(Id. at 20.) The request attempts to further supplement or define the alleged admission by generalizing it to any pointer in a table to native code. (Id.) However, because the highlighted sentence, standing on its own, is not an admission relating to any prior art, and it is directed to matters affecting liability rather than patentability, it has no probative value in determining whether a substantial new question of patentability exists. See MPEP § 2617. The cited statements are given no weight as an admission appropriate for consideration during reexamination.

Because the request relies on improper evidence and vague assertions to support the alleged SNQ, the request fails to persuasively show that that there is a substantial likelihood that a reasonable examiner would consider the Nilsen '665 patent important in deciding whether or not claims 1-4 and 8 of the '205 patent are patentable. In the proposed combination of the Nilsen '665 patent and the Walters '593 patent, the requester asserts the same alleged new teaching in the Nilsen '665 patent as the basis for the proposed SNQ. Accordingly, the Nilsen '665 patent, considered alone or in combination with the Walters '593 patent, does not raise an SNQ as to claims 1-4 and 8.

G. The Hookway '017 patent

The request sets forth that the third party requester considers an SNQ as to claims 1 -4 and 8 is raised by the Hookway '017 patent, considered alone or in combination with the Walters '593 patent. (Request at 32-33.) The examiner disagrees. Similar to the proposed SNQ based on the Nilsen '665 patent, the request improperly relies on statements by the patent owner to support an assertion that a pointer table equates to the claimed generation of a virtual machine instruction. See the discussion of the Nilsen '665 patent above.

Because the disclosure of the Hookway '017 patent does not appear to support the alleged new technological teaching set forth in the request, the request has not shown that there is a substantial likelihood that a reasonable examiner would consider the Hookway '017 patent important in deciding whether or not claims 1-4 and 8 of the '205 patent are patentable. In the proposed combination of the Hookway '017 patent and the Walters '593 patent, the requester asserts the same alleged new teaching in the Hookway '017 patent as the basis for the proposed SNQ. Accordingly, the Hookway '017 patent, considered alone or in combination with the Walters '593 patent, does not raise an SNQ as to claims 1-4 and 8.

H. Magnusson

The request sets forth that the third party requester considers an SNQ as to claims 1 -4 and 8 is raised by Magnusson, considered alone or in combination with the Walters '593 patent. (Request at 33-35.) The examiner agrees.

As noted in the request, Magnusson teaches modifying virtual machine code (intermediate form code for a target machine simulator) to reference machine code and (a) executing the new virtual machine instruction (a "TRANSLATED" instruction) instead of an original virtual machine instruction, i.e., executing the modified virtual machine instruction to direct execution of the machine code and (b) executing the new virtual machine instruction after compiling of the function. (Request at 34 (citing Magnusson at 9).) Because this new, noncumulative technological teaching is relevant to the features asserted to be missing in the prior art in the examiner's reasons for allowance, there is a substantial likelihood that a reasonable examiner would consider Magnusson important in deciding whether or not claims 1 -4 and 8 of the '205 patent are patentable. Accordingly, Magnusson, considered alone or in combination with the Walters '593 patent, raises an SNQ as to claims 1-4 and 8.


Patent No. 6061520
Reexamination Control Nos. 90/011489 and 90/011647

90/011489 Granted 3/23/11
90/011647 Decision pending

90/011489

Request for Ex Parte Reexamination [PDF]

Order Granting Reexamination [PDF]

Text of Reexamination Decision:
ORDER GRANTING EX PARTE REEXAMINATION

A substantial new question of patentability affecting claims 1-4, 6-13, 15, 16, and 18-23 of United States Patent 6,061,520 is raised by the request for ex parte reexamination.

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 "an applicant" and not to parties in a reexamination proceeding. Additionally, 35 U.S.C. 305 requires that ex parte reexamination proceedings "will be conducted with special dispatch" (37 CFR 1.550(a)). Extensions of time in ex parte reexamination proceedings are provided for in 37 CFR 1.550(c).

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 Patent No. 6,061,520 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.

Printed Publications Cited in the Request

The request cites the following prior art printed publications as raising a substantial new question of patentability (SNQ):
1) Brian T. Lewis, L. Peter Deutsch, and Theodore C. Goldstein. Clarity MCode: A Retargetable Intermediate Representation for Compilation, ACM, IR '95, 1/95, San Francisco, California, USA (1995) (hereinafter "Lewis").

2) M. Cierniak & W. Li. Briki: an Optimizing Java Compiler, IEEE Compcon '97 Proceedings (Feb. 1997) (hereinafter "Cierniak").

3) Dyer, Java Decompilers Compared, JavaWorld.com (July 1, 1997).

Prosecution History

The '520 patent issued from application 09/055,947, filed April 7, 1998. In the first action on the merits of the '947 application, the examiner: 1) rejected claims 1 and 3 as anticipated by the Cierniak reference also cited by the present requester, 2) objected to claims 2, 4, and 5, indicating that these claims would be allowable if rewritten in independent form, and 3) indicated that claims 6-23 were allowable as filed. '947 App., Non-Final Rejection, 7/21/1999. The examiner provided a statement of reasons for the indication of allowable subject matter: "[The Cierniak reference] fails to teach... constant pool storage; and... explicit operations (e.g., initialization, allocation, manipulation and simulation) with respect to 'play' execution." Id. at 4.

Following a telephonic interview conducted October 13, 1999, the applicants amended the limitation of claim 1 that included the term "play executing" by substituting different language for that term: "simulating execution of [play executing] the byte codes of the clinit method against a memory without executing the byte codes to identify the static initialization of the array by the preloader;". '947 App., Amendment, 10/18/1999, p. 2 (markup in original, indicating the added and deleted text).

The examiner subsequently allowed claims 1-23, providing the following reasons for allowance:
[T]he cited prior art, either singly or in combination, fails to anticipate or render obvious the simulation of execution with respect to class initialization, without executing byte codes.

Ciemiak, "Briki: An Optimizing Java Compiler", teaches of comparing the execution of byte codes, but fails to address the issue of simulating the process without execution.
'947 App. Notice of Allowability, 1/4/2000, p. 2.

Substantial New Questions of Patentability
A. The SNQ Requirement


The Office may only grant a reexamination request if an SNQ affecting any claim of the patent concerned is raised by the request, with or without consideration of other patents or printed publications. 35 U.S.C. §§ 303(a) and 304. The court in Swanson evaluated the scope of the SNQ requirement in reexamination, extensively citing the legislative history of the original reexamination statute and the 2002 amendment:

"[I]n passing the original reexamination statute, Congress stated that 'this new procedure will permit any party to petition the patent office to review the efficacy of a patent, subsequent to its issuance, on the basis of new information about preexisting technology which may have escaped review at the time of the initial examination of the patent application,' and explained that the substantial new question requirement bars 'reconsideration of any argument already decided by the office, whether during the original examination or an earlier reexamination.'" In re Swanson, 540 F.3d 1368, 1377 (Fed. Cir. 2008) (quoting H.R. Rep. No. 96-1307 (1980)) (emphasis omitted). "[T]he substantial new question requirement 'guard[s] against simply repeating the prior examination on the same issues and arguments' and bars 'a second examination, on the identical ground that had previously been raised and overcome." Id. at 1380 (quoting In re Recreative Technologies Corp., 83 F.3d 1394, 1396-97 (Fed. Cir. 1996)). Further, [t]he issue raised must be more than just questioning the judgment of the examiner." Id. (quoting H.R. Rep. No. 107-120 (2002)). "[T]o decide whether a reference that was previously considered by the PTO creates a substantial new question of patentability, the PTO should evaluate the context in which the reference was previously considered and the scope of the prior consideration and determine whether the reference is now being considered for a substantially different purpose." Id.

A prior art patent or printed publication raises a substantial question of patentability where there is a substantial likelihood that a reasonable examiner would consider the prior art patent or printed publication important in deciding whether or not the claim is patentable, unless the same question of patentability has already been decided as to the claim in a final holding of invalidity by the Federal court system or by the Office in a previous examination. MPEP § 2242.

B. Lewis

The request asserts that a substantial new question of patentability as to claims 1-4, 6-13, 15, 16, and 18-23 the '520 patent is raised by Lewis. (Request at 13-16.) The examiner agrees.

As noted by the requester, Lewis discloses simulating execution of code without actually running the code in order to identify the targeted,output of a given section of code. (Request at 15 (citing Lewis at 126).) Once the targeted output of a given section of code is known, a shortcut, referred to as a "CGValue," is created, which represents the state of the individual entries of the simulated stack, including constants, variable references, previously "executed" subexpressions, and procedure or method calls. (Id.) The CGValues operate as a set of shortcut instructions, such that "[g]ood code can be generated" when "the value of the expression is needed." (Id.) Because this new, non-cumulative teaching appears to be relevant to the features asserted to be missing from the prior art in the examiner's reasons for allowance, there is a substantial likelihood that a reasonable examiner would consider Lewis important in deciding whether or not claims 1-4, 6-13, 15, 16, and 18-23 of the '520 patent are patentable. Accordingly, Lewis raises an SNQ as to claims 1-4,6-13, 15, 16, and 18-23.

C. Cierniak

The request asserts that a substantial new question of patentability as to claims 1-4 and 6-23 the '520 patent is raised by Cierniak. (Request at 16-18.) The examiner disagrees.

The requester cites Cierniak at 182 as allegedly teaching play execution or simulated execution of computer code and alleges that this teaching is inconsistent with the examiner's reasons for allowance, asserting that the examiner "seems to have overlooked the disclosure of simulated execution of computer code within the Cierniak reference." (Request at 16-18.)

The prosecution history shows that the examiner considered this same cited section of Cierniak, including the disclosed symbolic emulation, in evaluating the patentability of the claims. '947 App., Non-Final Rejection at 3. Specifically, in the context of the rejection of claims 1 (originally reciting play execution) and 3 (more specifically defining play execution of claim 1), the examiner cited section 3.2 of Cierniak several times, mapping the stack allocation, stack recovery, and stack manipulation processes of Cierniak to the various steps involved in play execution as recited in the claims. Id. Accordingly, the requester's position that the examiner seemed to overlook the disclosure of a simulated execution of computer code within the Cierniak reference is unfounded.

Rather than raising a new question, the requester appears to be merely questioning the judgment of the examiner and asking the Office to initiate a second examination on grounds that had previously been raised and overcome. Thus, the request fails to show that a substantial new question of patentability is raised by Cierniak.

D. Cierniak in view of Dyer

The request asserts that a substantial new question of patentability as to claims 1-4 and 6-23 the '520 patent is raised by Cierniak in view of Dyer. (Request at 16-18.) The examiner disagrees.

As discussed above, the requester's characterization of the context in which Cierniak was previously considered and the scope of the prior consideration does not alone raise an SNQ. In presenting the combination of Cierniak in view of Dyer, the request cites Dyer as additionally "disclosing] the simulated execution of byte codes against a memory without executing the byte codes to identify the static initialization of an array." (Request at 18.)

Dyer discloses the results of testing 3 different JAVA decompilers: DejaVu, Mocha, and WingDis version 2.06. Dyer at 1. In the context of decompiling code containing a static initializer, the decompilers produced results as follows:
4) Mocha produced an illegal construction that used a bracketed initializer list as part of an assignment operation that was not a variable declaration,

5) WingDis apparently produced the same result as Mocha (code that was syntactically correct but semantically incorrect), and

6) DejaVu "emitted perfectly legal (but ugly) code" that initialized a temporary array, allocated memory for the temporary array, then individually assigned values to the temporary array elements before assigning the values of the temporary array to the variable of interest.
Dyer at 3-4.

The output of the DejaVu decompiler is similar to the pseudo-code used in the '520 patent to describe the functions performed by a method created by the JAVA compiler, '520 patent at col. 2, lines 1-13 (Code Table #2), but there does not appear to be an indication that any of the decompilers identified the static initialization as such, e.g., the keyword static does not appear in any of the segments of example decompiled code corresponding to static initializers. See Dyer at 3-4 and 9-10. Further, there is no discussion in Dyer as to how any of the decompilers achieved the illustrated results, i.e., it is not clear whether any of the decompilers disclosed by Dyer simulated execution of byte codes against a memory without executing the byte codes. Because the disclosure of Dyer does not appear to support the new teaching alleged by the requester, the request fails to persuasively show that Dyer, considered alone or in combination with Cierniak, raises an SNQ.


90/011647

Request for Ex Parte Reexamination [PDF]

Exhibit 10 - Claim Chart [PDF]

Exhibit 11 - Claim Chart [PDF]

Exhibit 12 - Claim Chart [PDF]

  


Oracle v. Google - Before We Talk About Damages | 57 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections
Authored by: ankylosaurus on Thursday, June 09 2011 @ 11:58 AM EDT
It can be helpful to use 'mitsake -> correct' in the subject line of the
reply.

---
The Dinosaur with a Club at the End of its Tail

[ Reply to This | # ]

Off-topic Discussions
Authored by: ankylosaurus on Thursday, June 09 2011 @ 12:01 PM EDT
Anything not directly related to this article (but not items related to the News
Picks on the Groklaw home page).

---
The Dinosaur with a Club at the End of its Tail

[ Reply to This | # ]

News Picks Here
Authored by: feldegast on Thursday, June 09 2011 @ 12:03 PM EDT
Please make links clickable

---
IANAL
My posts are ©2004-2011 and released under the Creative Commons License
Attribution-Noncommercial 2.0
P.J. has permission for commercial use.

[ Reply to This | # ]

Sentence first, then the verdict
Authored by: DannyB on Thursday, June 09 2011 @ 12:07 PM EDT
one so-called patent expert has been quoted extensively in the past few days asserting that the damages that could be assessed against Google could be astronomical and will wipe out Android. That strikes this writer as getting the cart before the horse.
Sentence first, then the verdict.

(off with their heads!)

---
The price of freedom is eternal litigation.

[ Reply to This | # ]

Sigh. Patent examiner dazzled by razzle-dazzle...
Authored by: Anonymous on Thursday, June 09 2011 @ 12:26 PM EDT
The patent examiner misses the point that, as the data structures in Deutsch,
etc. are being generated, *all* of the virtual machine instructions are
"new" ones. The patent claims simply do the same operation again,
later. He's gotten so dazzled by an instruction being "new" that he
misses the fact that adding a "new" one is no different than adding
any of the "old" ones was when they were "new".

This trips on one of my pet peeves about patenting software; most of the terms
are simply made up; and if I build a functionally identical piece of code, but
call its components by different terms, it seems an examiner are dazzled by the
terminology.

[ Reply to This | # ]

Is it just me
Authored by: Anonymous on Thursday, June 09 2011 @ 12:36 PM EDT
Is it just me or do those 3 bullet points quoted from the 447 patent describe a
unix file system?

[ Reply to This | # ]

Today's Supreme Court decision seems to *hurt* Google
Authored by: Anonymous on Thursday, June 09 2011 @ 02:49 PM EDT
It's now a lot harder for Google to invalidate Sun/Oracle's patents.

[ Reply to This | # ]

Suggestion regarding posts that talk about patent claims
Authored by: JonCB on Thursday, June 09 2011 @ 08:16 PM EDT
PJ had a habit of prefacing any conversation about actual
patent claims with a warning along the lines of "If you're not
supposed to look at details of patents, look away now".

I'm assuming that was for a good reason, if so it might be
worth sticking to that process. It doesn't effect me either
way but i noticed the absence.

[ Reply to This | # ]

Question: How does a "Rocket Docket" not bankrupt a state?
Authored by: SilverWave on Friday, June 10 2011 @ 01:08 AM EDT
This Judge has a lot of real work to do and doesn't really have a lot of time
for these corporate shenanigans...

Which makes sense as they soak up resources that should be used for serious
crime and fraud etc..

So... the Texas court... what's with that?

What do they get out of it? Does it not just bleed the Texas court system dry?



---
RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions

[ Reply to This | # ]

Quinntessential Discussions
Authored by: Ian Al on Friday, June 10 2011 @ 09:10 AM EDT
In Bilski, the Supremes said,
In Benson, the Court considered whether a patent application for an algorithm to convert binary-coded decimal numerals into pure binary code was a “process” under §101. The Court first explained that “ ‘[a] principle, in the abstract, is a fundamental truth; an original cause; a motive; these cannot be patented, as no one can claim in either of them an exclusive right.’ ” The Court then held the application at issue was not a “process,” but an unpatentable abstract idea. “It is conceded that one may not patent an idea. But in practical effect that would be the result if the formula for converting . . . numerals to pure binary numerals were patented in this case.” A contrary holding “would wholly pre-empt the mathematical formula and in practical effect would be a patent on the algorithm itself.”

In Flook, the Court considered the next logical step after Benson. The applicant there attempted to patent a procedure for monitoring the conditions during the catalytic conversion process in the petrochemical and oil-refining industries. The application’s only innovation was reliance on a mathematical algorithm. Flook held the invention was not a patentable “process.” The Court conceded the invention at issue, unlike the algorithm in Benson, had been limited so that it could still be freely used outside the petrochemical and oil-refining industries. Nevertheless, Flook rejected “[t]he notion that post-solution activity, no matter how conventional or obvious in itself, can transform an unpatentable principle into a patentable process.” The Court concluded that the process at issue there was “unpatentable under §101, not because it contain[ed] a mathematical algorithm as one component, but because once that algorithm [wa]s assumed to be within the prior art, the application, considered as a whole, contain[ed] no patentable invention.” As the Court later explained, Flook stands for the proposition that the prohibition against patenting abstract ideas “cannot be circumvented by attempting to limit the use of the formula to a particular technological environment” or adding “insignificant postsolution activity.”

Finally, in Diehr, the Court established a limitation on the principles articulated in Benson and Flook. The application in Diehr claimed a previously unknown method for “molding raw, uncured synthetic rubber into cured precision products,” using a mathematical formula to complete some of its several steps by way of a computer. Diehr explained that while an abstract idea, law of nature, or mathematical formula could not be patented, “an application of a law of nature or mathematical formula to a known structure or process may well be deserving of patent protection.” Diehr emphasized the need to consider the invention as a whole, rather than “dissect[ing] the claims into old and new elements and then . . . ignor[ing] the presence of the old elements in the analysis.” Finally, the Court concluded that because the claim was not “an attempt to patent a mathematical formula, but rather [was] an industrial process for the molding of rubber products,” it fell within §101’s patentable subject matter.

In light of these precedents, it is clear that petitioners’ application is not a patentable “process.” Claims 1 and 4 in petitioners’ application explain the basic concept of hedging, or protecting against risk: “Hedging is a fundamental economic practice long prevalent in our system of commerce and taught in any introductory finance class.” see, e.g., D. Chorafas, Introduction to Derivative Financial Instruments; C. Stickney, R. Weil, K. Schipper, & J. Francis, Financial Accounting: An Introduction to Concepts, Methods, and Uses; S. Ross, R. Westerfield, & B. Jordan, Fundamentals of Corporate Finance. The concept of hedging, described in claim 1 and reduced to a mathematical formula in claim 4, is an unpatentable abstract idea, just like the algorithms at issue in Benson and Flook. Allowing petitioners to patent risk hedging would pre empt use of this approach in all fields, and would effectively grant a monopoly over an abstract idea. Petitioners’ remaining claims are broad examples of how hedging can be used in commodities and energy markets. Flook established that limiting an abstract idea to one field of use or adding token postsolution components did not make the concept patentable. That is exactly what the remaining claims in petitioners’ application do. These claims attempt to patent the use of the abstract idea of hedging risk in the energy market and then instruct the use of well-known random analysis techniques to help establish some of the inputs into the equation. Indeed, these claims add even less to the underlying abstract principle than the invention in Flook did, for the Flook invention was at least directed to the narrower domain of signaling dangers in operating a catalytic converter.
The Supremes also said that the machines or transformation test was useful, but not conclusive. They said that methods and processes could qualify as patentable subject matter. They did not want to foreclose on the possibility that there might be more patent classes in new technologies like IT.

Looking at the Oracle patents, they are not machine or transformation inventions. Neither are they process patents because there are no process steps that lead to, for instance, the production of precision rubber ducks (Diehr). The patents do not do anything and so there can be no significant post-solution activity. Unless we have discovered a new class of IT patent then all that is left is method. Gene Quinn asserts that a patented invention is defined by its claims and disclosures. If it is a software patent, all that needs to be done is to get a journeyman programmer to assemble the code: there is no invention actually in the software.

With 447, the security patent, the patent does not use standard computer software terms for the claims and disclosures. In fact, the terms used are equally applicable to a method of providing different user security domains in a warehouse protected by password coded locks. Different users get different passwords. In fact, it is an abstract idea. Oracle have obtained a patent on an abstract idea by limiting the use of the method to a particular technological environment, vis. the programming of security into an operating system. Note, there is no algorithm waiting to be protected by this patent, unlike the Flook and Diehr patents. The software cannot contain any of the inventive concepts of the patent.

Patent 720 is a form of Just In Time (JIT) precoding of classes when the run-time environment runs the program. This has to be a software patent. However, it is not about what the software does like playing music using a patented codec algorithm. It is guidance on how the journeyman programmer programs this specific part of the operating system. It does not say which math algorithm should be used: it just gives an abstract idea on how it might be done. It does not even say under what circumstances it should or could be done. Is this any more than an abstract idea such as one might find in a book on how to program an operating system? Why is it any less of an abstract idea than another book on the fundamentals of hedging. In this case the JIT process is not even reduced to math or an algorithm for a journeyman programmer to use. If Quinn is right and the software cannot contain part of the inventive content of the patent, how can abstract ideas of a method that the journeyman programmer might use to do his draftsman's work in any way patentable subject material?

I have not reviewed the rest to save you from a monster comment, but I suspect that these two are the only ones with any possible merit in them. However, if the other patents are clearly software, but revolve around the journeyman programmer doing his day job (as Quinn asserts) then it cannot be patentable subject material. Any others can only be method patents and any tie of the abstract ideas to IT or computer programs is a successful attempt to patent abstract ideas by artificially limiting the use of the method to a particular technological environment. That is, of course, unless they do not have the same shortcomings as the Bilski patent.

In other comments one person wondered if the security method was the pre-existing UNIX security method (Just like the ones that Sun used under licence). Someone else wondered if the patent was slightly different. If it is slightly different then it is not a major, patentable innovation. If it is like the industry norm for security methods then it becomes another abstract idea just like the Bilski patent.

If Gene Quinn is completely wrong and there can be a patentable inventive concept actually involved with the structure or the method of writing software, then that inventive concept must be made clear in the patent claims and disclosures. That brings up further issues,

  • If it is patentable subject material, then different code, operating system, hardware etc. can be employed to avoid infringement. If this is not actually possible then the patent must be on abstract ideas and not patentable subject matter.
  • If all the inventive concept of the method is in the software then it is a patent on math, alone. Math is not patentable subject matter.
  • If it is a machine patent then the inventive concept in the software must be defined in the claims and disclosures. If there is no inventive concept in the software, then putting the software together with hardware not subject to the patent claims (i.e. installing the software on hardware) is not manufacturing an infringing device.
  • If it is a process patent and there are no process steps outside of the software then there is no significant post-solution activity and the patent is invalid.

    Did I mention that I am not a lawyer?

    ---
    Regards
    Ian Al
    OK, Just one more article and then I'll seek help.

    [ Reply to This | # ]

  • Has Oracle swallowed a bomb?
    Authored by: Anonymous on Friday, June 10 2011 @ 05:37 PM EDT
    These are all Sun patents. Sun never enforced them to this extent.
    Did Sun deliberately obtain these as junk patents? They come in handy
    as stacks of paper on a bargaining table, as numbers in valuation charts,
    but with little or no technical or legal merit.

    [ Reply to This | # ]

    Can you sue the USPTO?
    Authored by: Anonymous on Friday, June 10 2011 @ 11:08 PM EDT
    If the US patent office are negligent in granting a patent
    that should not have been granted, and you lost money as a
    result, are you entitled to sue the patent office?

    [ 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 )