UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD. ServiceNow, Inc. Petitioner. BMC Software, Inc.

Transcription

1 UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD ServiceNow, Inc. Petitioner v. BMC Software, Inc. Patent Owner Filing Date: August 30, 2000 Issue Date: May 17, 2005 TITLE: ENTERPRISE MANAGEMENT SYSTEM AND METHOD WHICH INCLUDES A COMMON ENTERPRISE WIDE NAMESPACE AND PROTOTYPE BASED HIERARCHICAL INHERITANCE PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 6,895,586

2 Table of Contents Page I. MANDATORY NOTICES UNDER 37 C.F.R. 42.8(A)(1)... 1 A. Real Party ln lnterest under 37 C.F.R. 42.8(b)(1)... 1 B. Related Matters under 37 C.F.R. 42.8(b)(2)... 1 C. Lead and Back Up Counsel under 37 C.F.R. 42.8(b)(3)... 1 D. Service Information... 2 E. Power of Attorney... 2 II. PAYMENT OF FEES 37 C.F.R III. REQUIREMENTS FOR INTER PARTES REVIEW UNDER 37 C.F.R AND A. Grounds for Standing under 37 C.F.R (a)... 3 B. Identification of Challenge under 37 C.F.R (b) and Statement of Precise Relief Requested... 3 C. Requirements for Inter Partes Review 37 C.F.R (c)... 4 IV. BRIEF BACKGROUND OF THE UNDERLYING TECHNOLOGY... 4 V. SUMMARY OF THE CLAIMED SUBJECT MATTER... 8 A. The Specification of the 586 Patent... 8 B. The Challenged Claims of the 586 Patent VI. CLAIM CONSTRUCTION UNDER 37 C.F.R (B)(3) A. enterprise B. namespace C. object D. prototype E. instance F. dynamically inherits G. traits H. sharing the plurality of objects i

3 Table of Contents (continued) Page I. agent application VII. CLAIMS 1, 4, AND 7 ARE UNPATENTABLE A. Identification of Prior Art and Date Qualification B. Brief Summary of the Prior Art Applied Against Claims 1, 4, and Brief Overview of Glasser Brief Overview of Davis C. Claim 1 is Obvious Over Glasser in View of Davis providing a hierarchical namespace (Claim 1[a]) adding a plurality of objects to the namespace, wherein the objects relate to software and hardware of the one or more computer systems (Claim 1[b]) sharing the plurality of objects with a plurality of the one or more computer system [sic]... (Claim 1[c1]) wherein at least one of the objects is a prototype and at least one of the objects is an instance (Claim 1[c2]) wherein the instance dynamically inherits traits from the prototype; and wherein the values of the traits inherited from the prototype change dynamically (Claim 1[c3]) D. Claim 4 is Obvious Over Glasser in View of Davis E. Claim 7 is Obvious Over Glasser in View of Davis VIII. CONCLUSION ii

4 List of Exhibits Ex. No Description of Document 1001 to Michael E. Brasher et al Declaration of David Klausner 1003 U.S. Patent No. 5,956,715 to Daniel S. Glasser et al Excerpts from Fred Davis, The Windows 95 Bible (1996) 1005 Excerpts from Microsoft Computer Dictionary (3d ed. 1997) 1006 RFC 1067, A Simple Network Management Protocol (August 1988) 1007 Excerpts from Joint Claim Construction and Prehearing Statement filed on April 17, 2015 in BMC Software, Inc. v. ServiceNow, Inc., Case No. 14 CV 903 JRG (E.D. Tex.) iii

5 ServiceNow, Inc. ( Petitioner ) submits this Petition for Inter Partes Review of claims 1, 4, and 7 of (Ex. 1001) ( 586 patent ). I. MANDATORY NOTICES UNDER 37 C.F.R. 42.8(A)(1) A. Real Party ln lnterest under 37 C.F.R. 42.8(b)(1) The Petitioner, ServiceNow, Inc., is the real party in interest. B. Related Matters under 37 C.F.R. 42.8(b)(2) The 586 patent is the subject of one pending litigation involving the Petitioner: BMC Software, Inc. v. ServiceNow, Inc., Case No. 14 CV JRG (E.D. Tex. Sept. 23, 2014), in which the patent owner contends that the Petitioner infringes the claims of the 586 patent challenged in this Petition. C. Lead and Back Up Counsel under 37 C.F.R. 42.8(b)(3) Petitioner provides the following designation of counsel. LEAD COUNSEL Heidi L. Keefe (Reg. No. 40,673) hkeefe@cooley.com zpatdcdocketing@cooley.com COOLEY LLP ATTN: Patent Group 1299 Pennsylvania Ave., NW, Suite 700 Washington, DC Tel: (650) Fax: (650) BACK UP COUNSEL Phillip E. Morton (Reg. No. 57,835) pmorton@cooley.com zpatdcdocketing@cooley.com COOLEY LLP ATTN: Patent Group 1299 Pennsylvania Ave., NW, Suite 700 Washington D.C T: (703) F: (703) Andrew C. Mace (Reg. No. 63,342) amace@cooley.com zpatdcdocketing@cooley.com COOLEY LLP

6 LEAD COUNSEL BACK UP COUNSEL ATTN: Patent Group 1299 Pennsylvania Ave., NW, Suite 700 Washington, DC Tel: (650) Fax: (650) D. Service Information This Petition is being served to the current correspondence address for the 586 patent, BRAKE HUGHES BELLERMANN LLP, c/o CPA Global, P.O. Box 52050, Minneapolis, MN The Petitioner may be served at the addresses provided above for lead and back up counsel, and consents to electronic service at those addresses. E. Power of Attorney Filed concurrently with this Petition in accordance with 37 C.F.R (b). II. PAYMENT OF FEES 37 C.F.R This Petition requests review of three (3) claims of the 586 patent. Accordingly, a payment of $23,000 is submitted herewith. This payment is calculated based on a $9,000 request fee (for up to 20 claims), and a postinstitution fee of $14,000 (for up to 15 claims). See 37 C.F.R (a). This Petition meets the fee requirements of 35 U.S.C. 312(a)(1). 2

7 III. REQUIREMENTS FOR INTER PARTES REVIEW UNDER 37 C.F.R AND A. Grounds for Standing under 37 C.F.R (a) The Petitioner certifies that the 586 patent is available for inter partes review and that the Petitioner is not barred or otherwise estopped from requesting inter partes review on the ground identified in the present Petition. The Petitioner is unaware of any previous petition for inter partes review or request for reexamination with respect to the 586 patent. B. Identification of Challenge under 37 C.F.R (b) and Statement of Precise Relief Requested The Petitioner respectfully requests that the Board initiate inter partes review of claims 1, 4, and 7 of the 586 patent. This Petition cites the following prior art references, included as Exhibits 1003 through 1004: Ex. No. Description of Prior Art Reference 1003 U.S. Patent No. 5,956,715 to Daniel S. Glasser et al. ( Glasser ) 1004 Fred Davis, The Windows 95 Bible (1996) ( Davis ) As explained in Part VII.A.1 below (discussion under Prior Art and Date Qualification ), each of the references listed above qualifies as prior art to the 586 patent. The ground on which this Petition is based is listed below: 3

8 Ground Claims Basis for Challenge 1 1, 4, 7 Unpatentable over Glasser in view of Davis, under 35 U.S.C. 103(a) Part VII below provides a detailed explanation as to why claims 1, 4, and 7 are unpatentable based on the ground identified above. This Petition cites additional prior art materials (Exhibits 1005 through 1006) for background purposes. The Petitioner has also submitted an accompanying Declaration of David Klausner ( Klausner Decl. ) (Exhibit 1002), a technical expert with almost 50 years of experience, including extensive experience in computer programming and software development. (Klausner Decl., Ex. 1002, 1 5, Ex. A.) C. Requirements for Inter Partes Review 37 C.F.R (c) The Board should institute inter partes review of claims 1, 4, and 7 because this Petition establishes a reasonable likelihood of prevailing. Each limitation of claims 1, 4, and 7 is disclosed and/or suggested by the Glasser and Davis prior art, as explained in detail in Part VII. IV. BRIEF BACKGROUND OF THE UNDERLYING TECHNOLOGY The 586 patent discloses a computer based system and method for managing a distributed computer system. ( 586, Ex. 1001, Abstract, 3:36 38.) 4

9 This section will provide a brief background of the state of the art pertinent to a person of ordinary skill in the art as of August A. Computer and Network Management By no later than the 1980s, the computer had become a common tool in large businesses and other enterprises. By the 1980s, businesses frequently used computers connected to a network (commonly known as a Local Area Network (LAN)), which allowed the computers to communicate with each other using network communications technology. (Klausner Decl. 14.) As the number of devices connected to computer networks increased, the need for software tools to monitor and manage those devices also increased. An entire industry, commonly known today as network management or enterprise management, grew out of this need and was well established by August As explained by Mr. Klausner, a person of ordinary skill in the art as of August 2000 would have had at least a bachelor s degree in electrical engineering or computer science (or equivalent degree or experience) with at least two years of experience in computer programming and software development, including the development of software programs for information retrieval and communication with other computers over a network. (Klausner Decl., Ex. 1002, 11.) 5

10 (Id. 15.) As explained in the Background section of the 586 patent, [m]anagers of an enterprise often employ software packages known as enterprise management systems to monitor, analyze, and manage the resources of an enterprise. ( 586, Ex. 1001, 1:23 26.) B. Hierarchical Namespaces One of the terms recited in the challenged claims is a namespace, which refers to a concept familiar to persons of ordinary skill in the art. (Klausner Decl., Ex. 1002, 16.) The term namespace generally refers to a set of unique names, each name uniquely identifying a particular resource that can be accessed. Namespaces typically provide a naming scheme that specifies the syntax and format for the names in the namespace. (Id.) Namespaces were widely used in computer systems (and remain in wide use today) to identify objects in computer systems or networks. (Id. 16, 17.) One familiar example of a namespace is the Uniform Resource Locator (URL) system used to identify resources on the Internet. (Id. 17.) As the 586 patent acknowledges, [t]he internet is one example of a namespace. ( 586, 1:61.) The internet comprises many individual computer systems which are linked together through an addressing system which guarantees that every server name is different from every other server name. ( 586, 1:61 65.) The naming 6

11 scheme in the Internet context achieves the property of unique accessibility through the user of a hierarchical name structure. ( 586, 1:65 67.) For example, an Internet address such as computer.site.division.bmc.com identifies a toplevel domain name associated with the company (e.g. bmc.com ), and also designates lower levels of the hierarchy including division names, subdivision names, site names, server names, and so on. ( 586, 2:4 7.) Another example of a namespace is a directory service in which all resources on a network are made accessible to users and applications. ( 586, 2:21 24.) C. Inheritance Inheritance is a pervasive concept throughout computer science. (Klausner Decl. 18.) Generally speaking, inheritance refers to a process in which an object in a computer system can derive attributes or traits from another object. The concept of inheritance is similar to biological inheritance in which an organism derives characteristics or traits from its parents. (Id.) One example of inheritance that will be discussed extensively in this Petition is set forth in U.S. Patent No. 5,956,715 to Daniel S. Glasser et al. ( Glasser ), a Microsoft patent that describes a technique for managing access to folders and files in a Microsoft Windows environment. Glasser discloses a technique in which a user can specify access permissions for a particular folder on 7

12 a computer. Once those access permissions have been established, the children of that folder (including the folders and files contained in that folder) can inherit those permissions. (Glasser, Ex. 1003, 7:13 14 ( A folder s access permissions can be inherited by its descendants in hierarchy 400. ).) Further discussion of Glasser is set forth in Part VII.B.1 below. V. SUMMARY OF THE CLAIMED SUBJECT MATTER A. The Specification of the 586 Patent The 586 patent generally describes a method and apparatus for organizing information for managing a computer network. Figure 3 shows an enterprise computing environment 200 that could be employed with the alleged invention: The elements of the enterprise computing environment 200 include computers and peripherals such as workstation 210a, a personal computer 212a, 8

13 a laptop or notebook computer 214, a server 216, or a networked printer 218. ( 586, 8:20 24.) These computing elements are connected through a local area network (LAN) 204 or a wide area network (WAN) 202. ( 586, 7:64 67, 8:12 17.) A key concept in the 586 patent is an object, which is used to encapsulate data and events relating to the computing resources in an enterprise. ( 586, 9:16 19.) The specification provides the following description of objects: In one embodiment, the improved enterprise management system provides the sharing of data and events, both runtime and stored, across the enterprise. Data and events may comprise objects. As used herein, an object is a self contained entity that contains data and/or procedures to manipulate the data. Objects may be stored in a volatile memory and/or a nonvolatile memory. The objects are typically related to the monitoring and analysis activities of the enterprise management system, and therefore the objects may relate to the software and/or hardware of one or more computer systems in the enterprise. ( 586, 9:16 26 (emphasis added).) The specification describes two concepts relating to objects that are relevant to the challenged claims: (1) hierarchical organization of the objects into a namespace, and (2) the ability of objects in the namespace to inherit traits from prototype objects. 9

14 Hierarchical Organization of Objects in a Namespace Each object in the 586 patent may be organized into a namespace in which each object has a unique name that distinguishes it from other objects in the namespace. ( 586, 11:22 24.) The objects in a namespace may be organized hierarchically. ( 586, 11:44 46, 12:46 51.) Figure 6 provides an example of a hierarchically organized object namespace: Figure 6 shows a hierarchy represented by a series of parent and child relationships in which each object can have child objects. The highest level object in the hierarchy, known as the root object, is named enterprise 402. ( 586, 13:53 55.) That object has two direct child objects, hosts 404 and employees 406. ( 586, 13:53 56.) The hosts 404 object in turn has two child objects, saturn 408 and neptune 410. ( 586, 13:57 58.) 10

15 Each object also has various attributes. For example, the hosts object 404 in Figure 6 has a count attribute with a value of 2 while the employees object 406 also has a count attribute but with value of 5, and a departments attribute with a value of 2. ( 586, Fig. 6.) Inheritance From Prototype Objects Objects in a namespace can also inherit attributes and/or values from other objects. Figure 7 at the right shows a dashed line and arrow running from right to left, from object b 456 to object a 454. This dashed line indicates a dynamic inheritance link between the two objects. ( 586, 14:52 54.) In this example, the dashed line indicates that object b 456 will inherit or derive attributes and/or values from object a 454. ( 586, 14:54 57.) The 586 patent uses the word prototype to identify the object from which attributes are dynamically inherited object a 454 in this example. ( 586, 14:44 46, 14:54 55.) The patent calls the object that inherits the attributes, object b 456 in this example, an instance object. ( 586, 14:47 49, 14:54 55.) 11

16 Therefore, object b 456 dynamically inherits the attributes, values, and children of object a 454. ( 586, 14:55 57.) The inheritance technique described in the 586 patent is straightforward. (Klausner Decl. 29.) Using the exemplary instance object b 456 in Figure 7 (excerpt shown on the right), the patent describes how to ascertain values for attributes x and y for that object. For attribute x, the system first searches object b 456 to see if it already has a defined value for that attribute. ( 586, 15:3 5.) In this case, because object b 456 already has a value of 12 for that attribute, as indicated in Figure 7, the search ends. ( 586, 15:5 6 ( If the attribute is found locally, the search ends. ).) Object b 456 therefore does not inherit a value for the x attribute. But object b 456 will inherit a value for the y attribute. This is because object b 456 has no value for attribute y. The system therefore, upon finding no locally set value, searches object a 454 for a value. ( 586, 15:6 7.) Because prototype object a 454 has a value of 20 for attribute y, object b 456 inherits that value for its y attribute. ( 586, 15:10 13.) B. The Challenged Claims of the 586 Patent This Petition addresses claims 1, 4, and 7. Independent claim 1 reads: 12

17 1. A method for managing an enterprise, wherein the enterprise comprises one or more networked computer systems, the method comprising: providing a hierarchical namespace; adding a plurality of objects to the namespace, wherein the objects relate to software and hardware of the one or more computer systems; sharing the plurality of objects with a plurality of the one or more computer system, wherein at least one of the objects is a prototype and at least one of the objects is an instance, wherein the instance dynamically inherits traits from the prototype; and wherein the values of the traits inherited from the prototype change dynamically. ( 586, Ex. 1001, 26:37 49 (Claim 1).) Claims 4 and 7 depend from claim 1: 4. The method of claim 1, defining an association of a plurality of objects which specifics [sic] a relationship between the objects. 7. The method of claim 1, wherein each computer system of the plurality of the one or more networked computer systems stores an agent application, wherein the agent application is configurable to monitor the software and hardware of a computer system. ( 586, Ex. 1001, 26:60 62, 27:1 6 (Claims 4, 7).) 13

18 VI. CLAIM CONSTRUCTION UNDER 37 C.F.R (B)(3) A claim in an unexpired patent shall be given its broadest reasonable construction in light of the specification of the patent in which it appears. 37 C.F.R (b). As the Federal Circuit has recognized, the broadest reasonable construction standard is different from the manner in which the scope of a claim is determined in litigation. See In re Swanson, 540 F.3d 1368, (Fed. Cir. 2008). Nevertheless, all but one of the nine terms identified for construction below are expressly defined in the patent specification. The parties in the concurrent litigation have also exchanged claim construction positions for these terms and filed them with the district court. Although they are not binding on the Board, they are nonetheless included herewith so the Board is aware of the positions taken by the parties. (See Joint Claim Construction and Prehearing Statement, Ex ) 2 2 Exhibit 1007 is a copy of the Joint Claim Construction and Prehearing Statement (JCCS) filed with the district court in which the patent owner and the Petitioner set forth positions on the meaning of certain terms. Because the district court litigation involves patents beyond the 586 patent, the JCCS included in Exhibit 1007 was redacted to remove portions related to those other patents. 14

19 A. enterprise The specification of the 586 defines enterprise as follows: As used herein, an enterprise refers to a network comprising one or more computer systems. ( 586, Ex. 1001, 1:22 23.) The Board should therefore interpret enterprise to mean a network comprising one or more computer systems. B. namespace One of ordinary skill in the art would have understood the term namespace to refer to a set of unique names. (Klausner Decl. 34.) This is consistent with the Background section of the 586 patent which provides the following description of the namespace term: ( 586, 1:54 60.) The term namespace generally refers to a set of names in which all names are unique. As used herein, a namespace may refer to a memory, or a plurality of memories which are coupled to one another, whose contents are uniquely addressable. Uniquely addressable refers to the property that items in a namespace have unique names such that any item in the namespace has a name different from the names of all other items in the namespace. Based on the description above, the term namespace under its broadest reasonable construction should be construed as a set of names in which all 15

20 names are unique, and which may refer to a memory, or a plurality of memories which are coupled to one another, whose contents are uniquely addressable. C. object The 586 patent provides the following definition of the term object : As used herein, an object is a self contained entity that contains data and/or procedures to manipulate the data. Objects may be stored in a volatile memory and/or a nonvolatile memory. ( 586, 9:19 22.) The Board should therefore construe the term object as a self contained entity that contains data and/or procedures to manipulate the data, which may be stored in a volatile memory and/or a nonvolatile memory. D. prototype The specification of the 586 patent defines prototype as follows: As used herein, a prototype is an object in a namespace from which attributes, values, and/or children are dynamically inherited by another object. ( 586, Ex. 1001, 14:44 46.) The term prototype should therefore be construed as an object in a namespace from which attributes, values, and/or children are dynamically inherited by another object. 16

21 E. instance The term instance is closely related to prototype. The specification of the 586 patent defines instance as follows: As used herein, an instance is an object in a namespace which dynamically inherits attributes, values, and/or children from another object in the namespace. ( 586, Ex. 1001, 14:46 49.) The term instance should therefore be interpreted as an object in a namespace which dynamically inherits attributes, values, and/or children from another object in the namespace. F. dynamically inherits Claim 1 requires that the instance dynamically inherits traits from the prototype. The specification provides the following description of dynamic inheritance: As used herein, dynamic inheritance includes the ability to derive attributes, values, and/or children from another object, where the attributes, values, and/or children may change over time. ( 586, 14:57 60.) The Board should therefore interpret dynamically inherits as derives attributes, values, and/or children from another object, where the attributes, values, and/or children may change over time. 17

22 G. traits The final clause of claim 1 recites that the instance dynamically inherits traits from the prototype; and wherein the values of the traits inherited from the prototype change dynamically. The specification does not appear to provide any express definition for traits as used in claim 1, but repeatedly states that inheritance of traits is synonymous with inheritance of information associated with an object, for example, attribute values and/or child objects. ( 586, Ex. 1001, 4:9 11 ( The instance inherits from the prototype traits such as attribute values and/or child objects. ), 11:58 62 ( [A] first object (called an instance) dynamically inherits attribute values and children from a second object (called a prototype). ) (emphasis added to both).) Accordingly, the Board should construe traits under its broadest reasonable construction as information associated with an object, such as attribute values and/or child objects. This definition is consistent with the definitions of prototype, instance, and dynamically inherits described above, which come from the 586 patent specification. Notably, none of those definitions describe the inheritance of traits, but instead, specify inheritance of attributes, values and/or children. This is consistent with a view that traits as recited in claim 1 are synonymous with attribute values and/or child objects. 18

23 Finally, the Petitioner notes that the 586 patent provides express definitions for object traits and attribute traits. ( 586, 17:9 11 ( As used herein, object traits are pieces of data that hold additional information about an object type. ), 17:21 23 ( As used herein, attribute traits are pieces of data that hold additional information about one or more attributes. ).) But those are not the same traits that are dynamically inherited from the prototype, as recited in claim 1. These object traits and attribute traits are described in a different part of the specification in describing a special type of object called a schema object. ( 586, 17:8 9, 17:20 21.) The claims under their broadest reasonable construction are not limited to schema objects and nothing in the specification indicates that these schema object traits are the same traits that are dynamically inherited from the prototype as recited in the claim. H. sharing the plurality of objects Claim 1 recites the step of sharing the plurality of objects with a plurality of the one or more computer system.... The specification provides a specific definition for the sharing phrase as used in claim 1: As used herein, sharing objects may include making objects accessible to one or more applications and/or computer systems and/or sending objects to one or more applications and/or computer systems. ( 586, 9:28 32.) The Board should therefore construe 19

24 sharing the plurality of objects to mean making the plurality of objects accessible or sending the plurality of objects. I. agent application Dependent claim 7 recites an agent application that is configurable to monitor the software and hardware of a computer system. The specification defines an agent application as follows: As used herein, an agent, agent application, or software agent is a computer program that is configured to monitor and/or manage the hardware and/or software resources of one or more computer systems. ( 586, 1:29 33.) The term agent application should therefore be interpreted as a computer program that is configured to monitor and/or manage the hardware and/or software resources of one or more computer systems. VII. CLAIMS 1, 4, AND 7 ARE UNPATENTABLE This Petition identifies the following ground on which IPR should be instituted for claims 1, 4, and 7: Ground Claims Basis for Challenge 1 1, 4, 7 Unpatentable over Glasser in view of Davis, under 35 U.S.C. 103(a) Ground 1 relies primarily on Glasser for the vast majority of the claim limitations. As shown in the analysis below, Glasser is a strong reference that 20

25 could potentially invalidate claim 1 by itself based on anticipation or singlereference obviousness. But the Petitioner is mindful of the Board s preference that IPR petitioners avoid multiple and potentially redundant grounds of anticipation or obviousness. The Petitioner has therefore proposed a single comprehensive ground that includes Glasser and Davis to reduce the number of grounds, simplify the present Petition, and reduce the burden on the Board. A. Identification of Prior Art and Date Qualification Each limitation of claims 1, 4, and 7 is disclosed or suggested by U.S. Patent No. 5,956,715 to Daniel S. Glasser et al. (Ex. 1003) ( Glasser ) in view of Fred Davis, The Windows 95 Bible (1996) (Ex. 1004) ( Davis ). Each reference qualifies as prior art to the 586 patent. Glasser qualifies as prior art under 35 U.S.C. 102(e) (pre AIA) because it issued from an application filed before the earliest filing date to which the 586 patent could claim priority (August 30, 2000). In particular, Glasser states on its face that it issued from an application filed in the United States on September 23, 1996, claiming priority to an application filed on December 13, 1994, both dates being before August 30, (Glasser, Ex. 1003, face page.) Glasser also qualifies as prior art under 102(a) because it issued on September 21,

26 Davis was published in (Davis, Ex. 1004, at copyright page (003).) It therefore qualifies as prior art under at least 35 U.S.C. 102(b) (pre AIA) because it was published more than one year before August 30, B. Brief Summary of the Prior Art Applied Against Claims 1, 4, and 7 1. Brief Overview of Glasser Glasser, entitled Method and System for Controlling User Access to a Resource in a Networked Computing Environment, describes a technique for specifying access permissions associated with folders, files, and other computing objects accessible over a computer network. (Klausner Decl., Ex. 1002, ) Glasser explains that security is necessary in a networked environment because the user of a client computer cannot be trusted with unlimited access to all server resources. (Glasser, Ex. 1003, 1:46 47.) Glasser addresses this concern by disclosing a technique for assigning access permissions to folders and files. 22

27 More specifically, Glasser describes a method and system for establishing or manipulating access controls for particular network resources, such as files and file folders or directories in a hierarchical file storage system associated with a server computer. (Glasser, 3:3 7.) Figure 4 shows an exemplary hierarchy 400 of folder and file resources. (Glasser, 6:55 58.) Using the example in Figure 4, root folder 401 contains folder 410 named Public, and another folder 420 named Private, each containing other folders and/or files. (Glasser, 6:58 7:4.) As this Petition will explain below, the folders and files in Glasser qualify as objects, and the set of names of those objects discloses a hierarchical namespace. Glasser explains that one way of limiting access to folders and files is to use access control lists, which specify the privileges of particular users with respect to particular resources or collections of resources. (Glasser, 1:56 58.) An ACL [access control list] for a given folder contains a list of users (and user groups) and their respective access permissions for that folder. (Glasser, 7:7 9.) 23

28 Glasser teaches a technique for allowing a user to set or change the access control list (ACL) values associated with a particular folder or file object. Figure 6B (at right) shows a user interface 600 that allows the user to specify access permissions for Public folder 410. Dialog box 600 shows the names of the users and/or user groups (611, 612, and 613) that have access to the Public folder 410, as well as the rights they have been granted. (Glasser, 8:12 26.) The user can make changes to those permissions through the user interface. (Glasser, 8:47 54.) Changing the access permissions for a folder may, for example, generate an updated access control list (ACL) for the selected folder object. (Glasser, 8:47 9:3.) Once the user has established access permissions for an object such as a folder, other folders and files can inherit those access permissions. (Glasser, 7:13 14 ( A folder s access permissions can be inherited by its descendants in 24

29 hierarchy 400. ).) Using the exemplary Public folder 410 in Figure 4 (at right), FY 94 folder 411 may inherit access permissions from its parent Public folder 410. (Glasser, 7:29 32.) The specific mechanics of how inheritance works in Glasser are described in detail in the analysis of claim 1 below. As shown below, a parent folder object in Glasser qualifies as a prototype for purposes of the 586 patent, and a child folder object qualifies as an instance. 2. Brief Overview of Davis This petition also cites Davis, a 1996 textbook describing aspects of the Microsoft Windows 95 operating system. This is the same operating system identified as the preferred embodiment in Glasser. (Glasser, 4:24 26 ( In the specific embodiment, operating system 150 is the Microsoft Windows 95 operating system [for] IBM PC and compatible computers.... ).) This Petition cites Davis because it provides additional background detail on the Windows 95 embodiment described in Glasser. (Klausner Decl. 67.) As explained below, Davis confirms that folder and file objects in Windows 95 are unique, discloses several techniques for adding objects to the hierarchical file system in Windows, 25

30 and describes a further example of an agent application. The rationale and motivation for combining Glasser with Davis is provided with the limitations below where both references are cited in combination. C. Claim 1 is Obvious Over Glasser in View of Davis Claim 1 is the only independent claim addressed in this Petition. For the convenience of the Board, independent claim 1 has been reproduced below with its limitations divided using bracketed notations (e.g. [a], [b], etc.) that will be used to separate the analysis of the claim limitations below: 1. A method for managing an enterprise, wherein the enterprise comprises one or more networked computer systems, the method comprising: [a] [b] [c1] [c2] providing a hierarchical namespace; adding a plurality of objects to the namespace, wherein the objects relate to software and hardware of the one or more computer systems; sharing the plurality of objects with a plurality of the one or more computer system, wherein at least one of the objects is a prototype and at least one of the objects is an instance, 26

31 [c3] wherein the instance dynamically inherits traits from the prototype; and wherein the values of the traits inherited from the prototype change dynamically. ( 586, 26:37 49 (Claim 1).) Each limitation of claim 1 is disclosed or suggested by Glasser in view of Davis. The preamble of claim 1 recites, [a] method for managing an enterprise, wherein the enterprise comprises one or more networked computer systems, comprising a series of steps. The preamble is fully disclosed by Glasser. As explained in Part VI.A above, enterprise is defined in the specification as a network comprising one or more computer systems. ( 586, 1:22 23.) This language is reflected in the preamble claim language itself, which recites that the enterprise comprises one or more computer systems. Glasser discloses a method for managing an enterprise. An exemplary enterprise is shown in Figure 1 of Glasser, which shows a computer network 110 that includes peer server 120 and client system 130: 27

32 (Glasser, Fig. 1.) Figure 1 above shows a network 110 that links multiple computing nodes. (Glasser, 3:24 25.) The claimed one or more computer systems for purposes of claim 1 includes at least peer server 120 and client 130, which are computers such as personal computers or workstations. (Glasser, 3:25 31.) Server 120 in Figure 1 also includes persistent storage medium 121. (Glasser, 3:33 36.) Although server 120 and client 130 provide one or more computer systems, as recited in the preamble, the server could share resources with other computers. (Glasser, 4:60 64 (discussing resources of peer server 120, such as file folders, that are to be shared with other nodes of network 110. ) (emphasis 28

33 added).) Figure 6B of Glasser, for example, shows Public folder 410 being shared with user groups Chinetui 612 and The World 613, confirming that the folder could be accessed by a potentially large number of client computers. (Glasser, 8:22 26 & Fig. 6B.) As explained by Mr. Klausner, one of the key purposes of a computer network is to allow multiple client computers to access a common resource through a server. (Klausner Decl. 59.) It would therefore have been obvious that the enterprise in Glasser could have included not just server 120 and client 130, but many other client computers as well. (Id.) Although not required by claim 1, therefore, the enterprise in Glasser could have included multiple client computers. (Id.) Glasser further discloses [a] method for managing an enterprise, as recited in the preamble of claim 1. Glasser explains that it provides a unified and straightforward approach to managing file and other resource security in a networked computing environment. (Glasser, 2:5 7 (emphasis added).) Glasser further provides a method and system for establishing or manipulating access controls for particular network resources, such as files and file folders or directories in a hierarchical file storage system associated with a server computer. (Glasser, 3:3 6.) Glasser also discloses a user interface (such as Figure 6B reproduced in Part VII.B.1 above) that allows the user to monitor access 29

34 permissions for resources, including listing the users and associated access permissions for a selected resource. (Glasser, Fig. 6B & 8:19 26.) Monitoring and managing access permissions associated with enterprise resources qualify as managing an enterprise as recited in the preamble. (Klausner Decl. 60.) 1. providing a hierarchical namespace (Claim 1[a]) The hierarchical namespace in Glasser takes the form of the set of names associated with the folders and file objects in a file system, the names uniquely identifying files and folders stored on a nonvolatile storage medium. More specifically, Glasser explains that server 120 runs the Microsoft Windows 95 operating system. (Glasser, 4:24 27.) Windows 95 supports a hierarchical file system having files and folders. (Glasser, 4:28 30 (emphasis added).) This hierarchical file system would have been familiar to persons of ordinary skill in the art, and in fact, almost anyone who had used a Windowsbased desktop or laptop computer. (Klausner Decl. 62.) As explained in Glasser, the Windows hierarchical file system included the well known elements of folders (also known as directories ) that in turn could contain other folders or files. (Glasser, 4:28 35.) 30

35 Figure 4 shows an exemplary hierarchy 400 having a set of unique names for folders and files on hard disk 121. As explained in Glasser: The folders and files of hierarchy 400 are stored on hard disk 121 in this embodiment. Folder 401 is the root of the hierarchy for device D:\, which is hard disk 121. (Glasser, 6:57 58.) Root folder 401 contains Public folder 410 and Private folder 420, each having folders and/or files with unique names. (Glasser, 6:58 7:4 & Fig. 4.) As noted in Part VI.B above, a namespace is a set of names in which all names are unique, and which may refer to a memory, or a plurality of memories which are coupled to one another, whose contents are uniquely addressable. The namespace in Glasser clearly satisfies this definition. Each folder and file in hierarchy 400 has a unique name that can be used to identify that object. Figure 4 itself shows that no two items in hierarchy 400 share the same name. The 31

36 folders and files in hierarchy 400 are also stored on a memory, such as hard disk 121. (Glasser, 6:58 59 ( Folder 401 is the root of the hierarchy for device D:\, which is hard disk 121. ).) Glasser therefore discloses the step of providing a hierarchical namespace. The uniqueness requirement of the namespace definition, although sufficiently disclosed by Glasser alone, would also have been obvious over Glasser in view of Davis. Davis describes aspects of the Windows 95 operating system the same operating system identified as the preferred embodiment in Glasser. (Glasser, Ex. 1003, 4:24 26.) As explained in Davis, [a] file stored on your hard disk is a file object, and the directory in which it is stored is a folder object. (Davis, at 76.) Most objects perform unique functions; that s why every object bears a unique name. (Id. at 77 (emphasis added).) Davis therefore discloses that each file and folder object has a unique name. (Klausner Decl. 66.) Rationale and Motivation to Combine Glasser and Davis: It would have been obvious to one of ordinary skill in the art that each folder and file shown in Figure 4 of Glasser, or any other file or folder used in the embodiment in Glasser, would have had a unique name, as disclosed in Davis. (Id. 67.) One of ordinary skill in the art would have found Glasser and Davis readily combinable for several reasons. The two references are analogous references in the same field of 32

37 describing features for managing folders and files using the Microsoft Windows operating system. (Id.) Glasser, assigned to Microsoft, specifically identifies Windows 95 as the preferred embodiment for the access control system. (Glasser, 4:24 27, 4:28 32.) Davis also describes features of Windows 95, and in fact, describes the same access control feature and even depicts the same user interface dialog that appears in Figure 6B in Glasser. (Compare Glasser, Fig. 6B (folder access control dialog) with Davis, at 336, Fig (folder access control dialog).) Davis further explains that it is designed to help you learn the inner secrets of Windows 95 so you can optimize your system and your software. (Davis, at 8.) Microsoft Windows 95 was a software product widely known to and used by persons of ordinary skill in the art. (Davis, at 3 4.) As explained by Mr. Klausner, in light of the common and overlapping subject matter, one of ordinary skill in the art would have naturally consulted Davis to provide additional detail on the Windows 95 implementation used in Glasser. (Klausner Decl. 67.) Moreover, the fact that folder and file objects have unique names was also within the general knowledge of persons of ordinary skill in the art. (Klausner Decl. 68.) For example, any user who had attempted to save a file into a folder by using the name of an existing file in that folder would have received the familiar error message that a file of that name already exists. (Id.) Using the 33

38 exemplary hierarchy 400 in Glasser, if root folder 401 contained two folders identically named Public, the operating system could not know which one to access if the user asked the computer to display the contents of a folder using that name. (Id.) The requirement that names in a namespace be unique, therefore, adds nothing of patentable significance and would have been obvious to a person of ordinary skill in the art. (Id.) Glasser, either alone or in view of Davis, therefore discloses or suggests all aspects of claim 1[a]. 2. adding a plurality of objects to the namespace, wherein the objects relate to software and hardware of the one or more computer systems (Claim 1[b]) The plurality of objects added to the namespace in Glasser takes the form of the plurality of folders and files as shown in hierarchy 400 of Figure 4 above. These folders and files qualify as objects that are added to the namespace when they are saved or copied to the hierarchical file system. As explained in Part VI.C above, an object is a self contained entity that contains data and/or procedures to manipulate the data, which may be stored in a volatile memory and/or a nonvolatile memory. This disjunctive definition under its broadest reasonable construction is satisfied by a self contained entity that contains data, which may be stored in nonvolatile memory. The folders and files in Glasser qualify as objects under this definition: 34

39 Windows 95 supports a hierarchical file system having files and folders. Files can store data, programs, and other computer information, and can be manipulated as objects using the graphical user interface functionality provided by Windows 95. Folders, sometimes referred to as directories, are used to collect related files together and thus provide a convenient way for users to organize their information. (Glasser, 4:28 35 (emphasis added).) Davis provides a similar description of files and folders in the Windows 95 file system, and uses the word objects to refer to them: As I mentioned earlier, Windows 95 treats each software and hardware resource in your computer as an individual object. For example, a file stored on your hard disk is a file object, and the directory in which it is stored is a folder object. Folder objects are containers that hold collections of other objects. (Davis, at 76 (under Manipulating Objects ) (emphasis added).) Glasser and Davis confirm that folders and files are self contained entities that contain data, and therefore, qualify as objects that were added to the namespace. These folder and file objects are also stored in a volatile and/or nonvolatile memory, as required by the definition of object discussed above. The folder and file objects in Glasser are stored in a persistent storage medium 121 such as a 35

40 hard disk. (Glasser, 6:58 59 ( Folder 401 is the root of the hierarchy for device D:\, which is hard disk 121. ).) Persistent storage medium 121 can include any persistent storage device suitable for reading and writing computer files and organized structures of computer files, such as a magnetic hard disk or writeable optical disk. (Glasser, 3:33 36 (emphasis added).) As explained by Mr. Klausner, hard disk 121 qualifies as a nonvolatile memory in which an object may be stored. (Klausner Decl., Ex. 1002, 36, 37, 72.) Glasser does not describe the process by which the objects in the namespace (e.g. folders and files) were added to the namespace in the first instance. But it would have been obvious to one of ordinary skill in the art that those objects were added to the namespace. (Klausner Decl. 73.) For example, the Public 410 and Private 420 folders in Glasser would not be present in hierarchy 400 unless they were added to that namespace, for example, by having been created on or copied to the storage medium 121. (Id.) Although Glasser alone sufficiently discloses and renders obvious the step of adding a plurality of objects to the namespace, the adding step would also have been obvious over Glasser in view of the further teachings in Davis. Davis describes several techniques for adding folder and file objects to the hierarchical file system, including techniques that almost anyone who has used a computer 36

41 would have immediately recognized. (Klausner Decl. 74.) For example, Davis explains that a user could have employed straightforward and familiar user interface commands such as Create Folder to create a new folder object, or Save As to save a new file object with a name chosen by the user. (Davis, Ex. 1004, at 105 ( A Create Folder button creates a new folder within the currently selected folder view. ); id. at 107 (describing process of saving new files to a folder using the Save As command).) Users could also have added files or folders to the file system by dragging and dropping folder or file icons, causing the selected objects to be moved or copied to the specified location in the hierarchical file system. (Id. at ) It would therefore have been obvious to a person of ordinary skill in the art that the plurality of folder and file objects in Glasser were added to the hierarchical namespace, as disclosed in Davis. (Klausner Decl. 74.) The rationale and motivation to combine Glasser and Davis is provided in the discussion of claim 1[a], above. The techniques from Davis described in the preceding paragraph also represented basic folder and file manipulation skills that would have been within the knowledge of a person of ordinary skill in the art. Finally, claim 1[b] requires that the objects relate to software and hardware of the one or more computer systems. One of ordinary skill in the art 37

42 would have found this limitation obvious over the disclosures of Glasser alone, or in view of Davis. (Klausner Decl. 75.) One of ordinary skill in the art would have understood that the folder and file objects in Glasser could have related to any type of data that could be stored on a storage medium or device, including software programs and information about hardware devices. (Id.; see also Glasser, 4:30 33 ( Files can store data, programs, and other computer information.... ).) The computer operating system itself, for example, is stored on a computer system using folder and file objects, and the operating system clearly relates to both software and hardware of the computer system. (Klausner Decl. 75.) It would have been obvious to one of ordinary skill in the art, therefore, that the folder and file objects in Glasser could relate to software and hardware of the one or more computer systems. (Id.) This aspect of claim 1[b], although obvious over Glasser alone, is also obvious over Glasser in view of Davis. Davis discloses several examples of folder and file objects in the Windows operating system that relate to software and hardware of one or more computer systems. For example, Davis describes file objects that specify how the operating system (software) should use the random access memory (hardware) in the computer. (Davis, at 498 ( By setting parameters in your CONFIG.SYS, SYSTEM.INI, and other files, you can designate areas 38

43 of upper memory to be either available or off limits to Windows and memory managers. ).) Davis also describes certain folder objects that contain information about hardware devices such as printers. (Id. at 84 ( For example, the System folder contains the core of the Windows 95 operating system, including the 32 bit code that makes up the interface. ); id. at 310 ( Windows 95 copies the appropriate printer related system files to your local Windows System folder. ).) Davis therefore discloses that folder and file objects may relate to software and hardware of the one or more computer systems. Folders and files are basic and generic computing objects that an operating system uses to organize and store data. It would have been obvious to one of ordinary skill in the art that the folder and file objects in Glasser could relate to software and hardware of the computer system, such as the operating system as described in Davis. (Klausner Decl. 77.) The rationale and motivation to combine Glasser and Davis is provided above. Glasser, alone or in view of Davis, therefore discloses adding a plurality of objects to the namespace, wherein the objects relate to software and hardware of the one or more computer systems, as recited in the claim. 39

44 3. sharing the plurality of objects with a plurality of the one or more computer system [sic]... (Claim 1[c1]) As explained in Part VI.H above, the phrase sharing the plurality of objects includes either making the plurality of objects accessible or sending the plurality of objects. Glasser discloses that folder and file objects ( the plurality of objects ) are made accessible to at least the server 120 and client 130 computer systems ( the one or more computer system ). One of ordinary skill in the art would have recognized that the folder and file objects in Glasser may be shared with a plurality of computer systems, including at least server 120 and client 130 (the plurality of computer systems ). (Klausner Decl. 79.) Glasser explains that its system is embodied in a multiuser computer network that includes a client computer, a server computer that controls a resource sharable among users of the network, such as a shared file folder or directory.... (Glasser, 2:8 11 (emphasis added); see also Glasser, 4:60 64 ( In particular, file security component 166 of operating system 150 (see FIG. 2B below) uses registry 167 to store access permissions (access control lists) for resources of peer server 120, such as file folders, that are to be shared with other nodes of network 110. ) (emphasis added).) 40

45 Glasser specifically confirms that at least server 120 and client 130 can access the folders in hierarchy 400. Client 130 may access folders over the network, such as Public folder 410 on server 120, if the client has the appropriate permissions. (Glasser, 9:58 63 ( FIG. 9 is a flowchart of the steps for accessing from client 130 a selected folder in a resource hierarchy having associated ACLs... Responsively to a command issued by the user, client 130 requests peer server 120 to access the folder or a file in the folder (step DA). For example, client 130 can request to open for reading or writing or otherwise access folder 410 or file 415. ) (emphasis added); Fig. 9.) If the user has permission for the requested access (step DK) [in Fig. 9], access is granted (step DL); otherwise, access is denied (step DM). (Glasser, 10:25 27.) The folder and file objects are, of course, also accessible to server 120. (Glasser, 4:50 54.) Glasser therefore discloses making accessible ( sharing ) the folder and file objects ( plurality of objects ) with at least server 120 and client 130. As explained in the preamble of claim 1, one of ordinary skill in the art would also have appreciated that the one or more computer systems could have included many other client computers beyond client 130. (Klausner Decl. 81; see also Glasser, e.g., Fig. 6B (showing Public folder 410 shared with user group The World 613).) Davis similarly discloses that folder and file objects can be shared 41

46 with other computer systems across a network. (Davis, at 327.) Glasser and Davis therefore disclose or suggest sharing the plurality of objects with a plurality of the one or more computer system [sic], as recited in the claim. 4. wherein at least one of the objects is a prototype and at least one of the objects is an instance (Claim 1[c2]) For the convenience of the Board, the constructions of the terms relevant to this claim limitation (see Part VI) are reproduced in the table below: Term prototype instance dynamically inherits Broadest Reasonable Construction object in a namespace from which attributes, values, and/or children are dynamically inherited by another object object in a namespace which dynamically inherits attributes, values, and/or children from another object in the namespace derives attributes, values, and/or children from another object, where the attributes, values, and/or children may change over time As explained in detail below, Glasser discloses each of these limitations. 42

47 The prototype in Glasser takes the form of a parent folder object such as Public folder 410 from Figure 4 (excerpt at the right). The instance object takes the form of a child folder, such as FY 94 folder 411 which is a child of Public folder 410 in Figure 4. Both objects are in the hierarchical namespace as both are represented in hierarchy 400 shown in Figure 4. Glasser explains that the child FY 94 folder 411 (the instance ) may dynamically inherit access permissions from its parent Public folder 410 (the prototype ). In particular, each folder object in Glasser can include an access control list (ACL) which for a given folder contains a list of users (and user groups) and their respective access permissions for that folder. (Glasser, 7:5 9.) The folder s ACL is checked each time that any remote user attempts to access the folder or its contents. (Glasser, 7:9 10; id., 9:58 10:29 (Fig. 9).) A folder object in Glasser can inherit values from the access control list (ACL) of its parent folder. (Glasser, 7:13 14 ( A folder s access permissions can be inherited by descendants in hierarchy 400. ).) In particular, if a particular folder object does not have its own ACL, that folder will inherit the ACL associated with 43

48 its closest ancestor that does have an ACL. (Glasser, 7:28 29.) Again using Public folder 410 as the prototype (shown at the right), Glasser explains that if folder 411 has no ACL of its own and folders 401 and 410 each have an ACL, folder 411 inherits its ACL from folder 410 but not from folder 401. (Glasser, 7:29 32 (emphasis added).) In this example, the FY 94 folder 411 (the instance ) dynamically inherits access permissions from its direct parent, Public folder 410 (the prototype ). As noted, the fact that the root folder 401 also has an ACL is irrelevant here because the inheritance does not proceed beyond the nearest ancestor having an ACL (Glasser, 7:28 29), in this case Public folder 410. Glasser provides other examples of dynamic inheritance. Referring back to Figure 4 shown in relevant part at the right, the Private folder 420 contains child folders Secret Projects 421 and Payroll 422. Either of these child folders (each an instance ) can inherit access control list (ACL) attributes from the parent Private folder 420 (the prototype ). As explained in Glasser: if folder 420 has 44

49 an ACL that denies all access permissions to a given user, and folders 421 and 422 lack ACLs of their own, then folders 421 and 422 inherit the permissions of the parent folder 420 and so cannot be accessed by that user. (Glasser, 7:14 18 (emphasis added).) This provides another example of an instance object (child folder) dynamically inheriting traits from a prototype object (parent folder). 3 In both of these examples, the child folder ( instance ) object derives attributes, values, and/or children from another object, i.e. the parent folder ( prototype ) object, as required by the definition of dynamically inherits. Although the examples above use the folder objects shown in Figure 4, Glasser confirms that any folder in the namespace can have an access control list (ACL) from which access permissions may be inherited. (Glasser, 7:5 7, 7:13 14.) One of ordinary skill in the art would have understood that inheritance of access 3 As explained in the text, each folder can have its own access control list (ACL). (Glasser, 7:5 7.) Glasser allows users to specifically set ACL values for a folder that will override the values the folder would otherwise inherit. (Glasser, 7:18 25.) The 586 patent discloses a similar mechanism. ( 586, 15:5 6 ( If the attribute is found locally, the search ends. ).) As explained in the text, if a folder in Glasser has no ACL, it can inherit ACL values from an ancestor folder. (Glasser, 7:18 23.) 45

50 control traits in Glasser, and the ability to change access permissions (as discussed below), could also have been applied to any folder in the system. (Klausner Decl. 88.) It would therefore have been obvious to a person of ordinary skill in the art that the inheritance technique could have been applied to folder objects that relate to software and hardware of the one or more computer systems, such as the operating system related folders and files described in Davis. (Id.) A final requirement of the dynamically inherits definition from the specification is that the attributes, values, and/or children may change over time. ( 586, 14:57 60.) This requirement is also incorporated into the final limitation 1[c3] of claim 1, and therefore, addressed immediately below. 5. wherein the instance dynamically inherits traits from the prototype; and wherein the values of the traits inherited from the prototype change dynamically (Claim 1[c3]) The first part of this claim limitation, which requires that the instance dynamically inherits traits from the prototype, was largely encompassed into the express definitions of instance and prototype, which were fully addressed above. In the interests of brevity, this Petition will not repeat that analysis. As explained in Part VI.G, the term traits includes at least attribute values. ( 586, 4:9 11 ( The instance inherits from the prototype traits such as attribute values and/or child objects. ) (emphasis added), 11:58 62 (same).) The 46

51 traits for purposes of Glasser take the form of the access permission attribute values for the ACL of a prototype object (such as a parent folder), which can be inherited by other objects (such as a child folder), as explained fully in the preceding limitation. These attributes values are pieces of information that hold additional information about folder object types, including information specifying a list of users (and user groups) and their respective access permissions for that folder. (Glasser, 7:7 9.) As this Petition will demonstrate below, the specific values in the access control list (ACL) may change dynamically as claimed. The 586 specification makes clear that the phrase change dynamically in this last clause means may change over time. ( 586, Ex. 1001, 14:57 60 ( As used herein, dynamic inheritance includes the ability to derive attributes, values, and/or children from another object, where the attributes, values, and/or children may change over time. ) (emphasis added).) As noted above, the values that may change over time in Glasser include the values associated with the access control list (ACL) for the prototype object (e.g. parent folder), which may be inherited by child objects. 4 4 As explained later in this section, the patent owner has taken a different position in the concurrent litigation regarding the meaning of change 47

52 In fact, one of the key purposes of the alleged invention of Glasser is to facilitate the ability to change access permissions for folder and file objects. (Klausner Decl. 91.) For example, Figure 6B below shows a user interface that allows the user to modify access permissions for the Public folder 410: (Glasser, Fig. 6B.) dynamically as recited in claim 1. But as explained in the text and analysis at the end of this section, Glasser discloses the change dynamically requirement of claim 1 even under the patent owner s position. 48

53 Dialog box 600 in Figure 6B shows the names of the users and/or user groups (611, 612, and 613) that have access to the shared Public folder 410, as well as the rights granted to each user or group. (Glasser, 8:12 26.) Dialog box 600 also includes control buttons 615 which, when selected with pointing device 127, cause additional dialog boxes (not shown) to be displayed for use in changing access permissions for the selected resource. (Glasser, 8:27 30 (emphasis added).) These include the Add button 616, Remove button 617, and Edit button 618 for adding, removing or editing the access privileges, respectively, associated with the specified user or group. (Glasser, 8:30 36.) Glasser discloses that the values of the traits inherited from the parent folder such as the access control list (ACL) values for Public folder 410 may change over time. This is because the changes made by the user in dialog box 600 may result in a change to, or creation of, an access control list (ACL) for the selected folder object. (Glasser, 8:47 9:3.) For example, if the selected folder already has its own ACL, the changes made to the display list are merged with the previous contents of the ACL to form the updated ACL (step BB) [of Figure 7]. (Glasser, 8:60 63.) Otherwise, the modified display list itself... becomes the folder s new ACL. (Glasser, 8:63 66.) The ACL values that are inherited from a parent folder (the prototype ), therefore, may change over time. 49

54 Glasser in view of Davis therefore discloses or suggests that the instance dynamically inherits traits from the prototype; and wherein the values of the traits inherited from the prototype change dynamically, as recited in claim 1[c3]. For all of the reasons discussed above, therefore, claim 1 obvious over Glasser in view of Davis under 35 U.S.C. 103(a). Finally, the Petitioner notes that in the concurrent litigation, the patent owner has taken the position that the phrase in claim 1, the values of the traits inherited from the prototype change dynamically, has a meaning different from the one discussed above. The patent owner has argued that change dynamically in this part of claim 1 means that the values of the traits are inherited as they are changed, and thus, any changes to those values are reflected in the object inheriting them. The patent owner s construction is incorrect, as the adjective dynamically in this part of claim 1 modifies the change in the values, not the inheritance of those values by child objects. The claim separately also dynamically with respect to inheritance ( dynamically inherits ), so the phrase change dynamically should have a distinct meaning. But Glasser discloses the change dynamically requirement even under the patent owner s position. In particular, as noted above, [t]he folder s ACL is checked each time that any remote user attempts to access the folder or its contents. (Glasser, 7:

55 (emphasis added); id., 9:58 10:29 (Fig. 9).) As explained in detail above, that check can result in a folder inheriting the ACL access permission values from an ancestor folder. (Glasser, 7:13 25, 7:29 32.) For example, if the folder lacks its own ACL, the system searches the resource hierarchy for an ancestor folder from which an ACL can be inherited. (Glasser, Fig 9, 9:4 11, 9:8 9 ( If an ancestor is found (step DH) [Fig. 9], its ACL is inherited (step DI).... ).) Changes made to a parent folder, therefore, affect not only the ACL values used for the parent folder, but also affect the ACL values inherited by children of the parent folder. Because the ACL check and inheritance of ACL values occurs in Glasser each time access is requested, the child folder inherits up to date ACL values that reflect any changes that may have been made. Glasser therefore discloses the change dynamically requirement of claim 1 even under the patent owner s position. D. Claim 4 is Obvious Over Glasser in View of Davis Claim 4 depends from claim 1 and adds the step of defining an association of a plurality of objects which specifics [sic] a relationship between the objects. Claim 1 is obvious for the reasons explained in Part VII.C (analysis of claim 1). Claim 4 adds nothing of significance. Glasser and Davis both disclose the step of defining an association of a plurality of objects that specifies a relationship between them. As shown in 51

56 Figure 4, each object sits in a particular position in the hierarchy 400 and has at least one parent or child object. (Glasser, 6:55 7:4; see also 7:13 18 (describing folder 420 as the parent of folders 421 and 422).) The parent child relationship in Glasser, in fact, mirrors an exemplary relationship described in the 586 specification. ( 586, 15:43 45 ( In one embodiment, an association may specify a parent child relationship. ).) The 586 patent describes an association as an object or other piece of data which specifies a relationship between two or more objects. ( 586, 15:33 35.) The association data in Glasser includes resource hierarchy data that keeps track of parent child relationships of the folder and file objects, such as the ones in hierarchy 400 in Figure 4. The system in Glasser searches this resource hierarchy information to identify ancestor folders from which access permissions may be inherited. (Glasser, e.g., 10:6 8 ( [P]eer server 120 searches the resource 52

57 hierarchy (for example, hierarchy 400) to find the nearest ancestor having an ACL (step DG). ), 8:3 6 ( [P]eer server 120 determines the nearest ancestor having an ACL by searching upwards in the resource hierarchy (step AC) until a folder having an ACL is found or the root of the hierarchy is reached (step AD). ), 9:8 10 ( Peer server 120 searches the resource hierarchy to determine which descendants of the selected resource, if any, have ACLs of their own (step CA). ) (emphasis added to all).) Glasser therefore discloses the claimed association. In fact, as explained by Mr. Klausner, the system could not perform the access control list (ACL) inheritance process described in Glasser if it did not have resource hierarchy data that identified the ancestor folders for a particular folder or file object. (Klausner Decl. 98.) Glasser therefore discloses defining an association which species a relationship between the objects (e.g. parent and child folders). Although Glasser alone sufficiently discloses this limitation, it is also obvious over Glasser in view of the disclosures in Davis. Davis describes a technique for navigating folders using the Windows 95 graphical user interface. Figure 3 31, for example, shows a treelike display created by the operating system showing the parent child relationships between folders in the hierarchy: 53

58 (Davis, Ex. 1004, at 73.) The graphical display described in Davis qualifies as a piece of data that specifies a relationship between two or more of the objects. (Klausner Decl. 100.) In this case, the display shows a relationship between a folder such as the root folder and the child folders contained within the root folder. One of ordinary skill in the art would have understood that the window shown in Figure 3 31 above comprises a piece of data that specifies a relationship between the parent folder and the objects contained within it. (Id.) The combination of Glasser and Davis would have predictably resulted in the system of Glasser with the additional ability to define an association by opening windows that display the hierarchy 54