l~6 MICROSOFT CORPORATIONMicrosoft and Veritas dated August 19, 1996. Teaming up with Veritas and integrating the Volume Manager into Windows NT would serve as a testament by Microsoft

UNITED STATES DISTRICT COURTFOR THE WESTERN DISTRICT OF WASHINGTON

AT SEA TILE

VERIT AS OPERATING CORPORATIONa Delaware Corporation ~\l~6 0703~ L

PlaintiffCOMPLAINT FOR:

1) TRADE SECRETMISAPPROPRIATION;

2) BREACH OF CONTRACT3) BREACH OF THE IMPLIED

COVENANT OF GOOD FAITHAND FAIR DEALING;

4) UNFAIR COMPETITION;5) UNJUST ENRICHMENT AND

CONSTRUCTIVE TRUST;6) CONVERSION;7) COPYRIGHT INFRINGEMENT;

AND8) PATENT INFRINGEMENT

DEMAND FOR JURY TRIAL

MICROSOFT CORPORATIONa Washington Corporation

Defendant.

Plaintiff, Veritas Operating Corporation ("Veritas ), alleges as follows:

BACKGROUND

Over the course of nearly a decade, Microsoft has deliberately and surreptitiously

misappropriated Symantec ' s I valuable data storage technologies , misled and thereby convinced

I The named pl~intiff in this action, Veritas Operating Corporation, is part of the Veritas family of companies that

was merged into Symantec Corporation in early July, 2005. While Veritas Operating Corporation currently retainsits separate corporate existence , the post-merger Veritas family of companies (including Veritas OperatingCorporation), do business under the Symantec name. Thus, there are references throughout this complaint toSymantec. " All such references shall include Veritas Operating Corporation.

COMPLAINT - ICASE NO.

cc (Q) ~)f SUMMIT LAW GROUP PLLC315 FIF'IHAVENUE SOUIB, SUI1'E 1000

SEATIU: , WASHINGTON 98104-2682Telephone: (206) 676- 7000

Fax: (206) 676-7001

the United States government to issue patents to Microsoft based on technologies invented by

Symantec, attempted unsuccessfully to persuade Symantec to forgive Microsoft' s misdeeds

under the guise of expanding a business relationship, and ultimately built portions of its next-

generation operating system on this house of cards. Symantec brings this action to stop

Microsoft from its continued misappropriation of Symantec s confidential information and trade

secrets , including its wrongful incorporation ofSymantec intellectual property into its operating

systems. Symantec seeks an injunction to (a) preclude the further development, sale or

distribution ofthe "Vista" and "Longhorn" versions of the Windows client and server operating

systems (or whatever monikers are given to Microsoft' s next-generation Windows operating

systems) and all other infringing Microsoft products until such time as all Symantec intellectual

property is removed therefrom; (b) require the immediate removal of all Symantec intellectual

property therefrom; and ( c) require the immediate worldwide recall of all such software in

distribution channels , and all golden masters used to replicate such software.

Symantec also brings this action to require Microsoft to perform its obligations

under an agreement entitled "Microsoft Corporation Development and License Agreement with

Veritas Software Corporation

" ("

Agreement"), and to pay damages caused by Microsoft' s breach

of the Agreement. Symantec further brings this action to stop Microsoft' s unfair competition

and continuing infringement of a United States Patent covering features that Microsoft

wrongfully incorporated into its Windows operating systems in violation of the Agreement and

of S ymantec ' s intellectual property rights.

Microsoft' s pervasive and continuing disregard of Symantec s intellectual

property and contract rights has irreparably harmed Symantec and constitutes trade secret

misappropriation , breach of contract, breach of the implied covenant of good faith and fair

dealing, unfair competition , unjust enrichment, copyright infringement, and patent infringement.

COMPLAINT - 2CASE NO. SUMMIT LAW GROUP PLLC

315 FIFIHAVENUE SOUIB, SUITE 1000SEATILE , WASHINGTON 98104-2682

Telephone: (206) 676-7000Fax: (206) 676-7001

II. JURISDICTION AND VENUE

This Court has jurisdiction over the federal claims for patent and copyright

infringement (the "Federal Claims ) asserted herein pursuant to 28 U. c. 99 l33l and l338(a)

because they arise under the patent and copyright laws of the United States. This Court has

jurisdiction over the claims asserted herein arising under Washington law (trade secret

misappropriation, breach of contract, breach of the implied covenant of good faith and fair

dealing, unfair competition , and unjust enrichment/constructive trust) (the "State Claims

pursuant to 28 US. c. 9 l367(a), because the State Claims are so related to the Federal Claims

that they form part of the same case or controversy and derive from a common nucleus of

operative facts. This Court also has jurisdiction over the State Claims pursuant to 28 U.

9 1332(a), because the matter in controversy exceeds $75 000 , exclusive of interests and costs

and Plaintiff and Microsoft are citizens of different states.

Venue for this case is proper in this District and before this Court pursuant to 28

US.C. 99 1391(b), 1391(c), and 1400(b), in that Defendant resides and conducts business in the

Western District of Washington.

III. THE PARTIES

Plaintiff Veritas Operating Corporation is a corporation organized under the laws

of the State of Delaware with its principal place of business in the Northern District of

California. Veritas Operating Corporation is the successor-in-interest to Veritas Software

Corporation , a California corporation, the former succeeding to all of the rights and obligations

of the latter that relate to this action. Veritas Operating Corporation became a part of the

Symantec family of companies through a merger effective July 5 , 2005.

With a long history of innovative technology solutions and services , Symantec

helps individuals and enterprises protect and manage their digital assets. Symantec provides a

wide range of solutions including enterprise and consumer security, data management

application and infrastructure management, security management, storage and service


315 FIFIHAVENUE SOUIB, SUITE 1000SEATIU: , WASHINGTON 98104-2682

Telephone: (206) 676-7000

Fax: (206) 676-7001

management, and response and managed security services. Symantec is a world leader in

providing solutions to help individuals and enterprises assure the security, availability, and

integrity of their digital information. Through its recent merger with Veritas , Symantec has also

become a leading provider of data protection , storage management, high availability, disaster

recovery, and application performance management software to enterprise customers worldwide

including most Fortune 500 companies.

Defendant Microsoft is a corporation organized under the laws of the State of

Washington , with its principal place of business in Redmond, Washington , and was at all times

relevant herein conducting business in Washington. Microsoft describes itself as the world'

largest software company, providing its customers with operating system software (e.

g.,

the

Windows operating system) and applications software (e. Word and Excel.)

IV. GENERAL ALLEGATIONS

Microsoft' s Need for Volume Management Technology.

Symantec specializes in developing and marketing high-performance storage

software, among other things. Prior to its recent merger with Symantec, Veritas had long been

recognized as a leading software company for the delivery of enterprise solutions for data

protection and storage management applications, including "volume management " across

diverse server, operating system, storage and network environments. Volume management

allows data to be stored reliably and manipulated uniformly without regard to potential

differences in physical storage devices, essential to the data storage needs of many medium and

large business enterprises.

10. In the early 1990s , Microsoft set its sights on the market for server operating

systems used by business enterprises. It released the first version of its server operating system

Windows NT, in December of 1993. By 1996 , however, that operating system still lacked many

of the features and much of the functionality demanded by the enterprise customers whose

business it sought to capture. Windows NT' s rudimentary technology for storage management



Telephone: (206) 676- 7000Fax: (206) 676-7001

called FT Disk, had been designed by Microsoft to support only small server environments and

was not sufficient to address the needs of larger mission-critical server environments , where

scalability, reliability and manageability are of paramount concern. Microsoft had invested

neither the time nor the engineering resources necessary to develop sufficient enterprise storage

expertise to provide the products and services that larger enterprises demanded.

11. In contrast, by 1996 Symantec (through then unrelated Veritas) was well-

established in the enterprise storage market and had released several commercial versions of the

critically praised Volume Manager software product to the enterprise market. Volume Manager

was widely used , primarily by medium and large business enterprises , for the comprehensive

management of data storage devices, and was by all accounts the premier product in this space

and a large commercial success. Thus , as of 1996 , Symantec s knowledge of storage

management techniques and its track record in the enterprise market (through Veritas) were far

ahead and superior to that of Microsoft.

The Agreement Between the Parties.

12. Recognizing the commercial pressure and need to upgrade the feature set of the

Windows NT operating system , Microsoft was eager to obtain the Veritas storage technology.

Microsoft' s feature requirements for Windows NT included the enterprise-class storage

management features that Veritas s Volume Manager provided and that Microsoft' s FT Disk

lacked. Microsoft approached Veritas about the possibility of licensing a simplified version of

the Volume Manager product containing a subset of features to be incorporated into Windows

NT and successor products. A period of negotiations culminated in the Agreement between

Microsoft and Veritas dated August 19 , 1996. Teaming up with Veritas and integrating the

Volume Manager into Windows NT would serve as a testament by Microsoft to the server

market place that it was serious about addressing critical storage management issues, and satisfy

its need to include premier storage management tools in Windows NT.



Telephone: (206) 676- 7000Fax: (206) 676-7001

13. Under the Agreement, Veritas promised to provide a version of Volume Manager

with a limited subset of functionality for incorporation into the Windows NT platform. The idea

was that this version of Volume Manager (called the "Embedded Product" under the

Agreement), with the baseline features and the proven reliability ofVeritas s premier storage

management enterprise software, would replace the rudimentary FT Disk technology that

Microsoft had incorporated into Windows NT, thereby saving Microsoft at least five years of

internal development time. In exchange for granting Microsoft these valuable rights to the

Embedded Product , Veritas obtained the exclusive right vis-a-vis Microsoft to develop and sell

additional storage management products with more advanced features for use in conjunction with

Windows NT (the Veritas "Add-on Products). The Agreement contained a specific list of

features to be included in the Embedded Product, as well as an exemplary list of some of the

specific features exclusively reserved for Veritas to offer to customers for separate purchase as

part ofa Veritas Add- On Product. (See Agreement, Ex. A , Appx. A- I.) Any and all Add-on

features other than those listed to be included in the Embedded Product were reserved for

Veritas.

14. The Agreement specifically restricted Microsoft from (1) developing products

that competed with the Veritas Add-on Products, or incorporating into the Embedded Product

features exclusively reserved for Veritas (Agreement 99 1.2 3.1 , Ex. A, Appx. A-

1), and (2) using Veritas s confidential information (including but not limited to its source code

and knowledge gleaned from exposure to the source code) to develop replacements for the

Embedded Product or otherwise compete against Veritas (id. 992. , 12. , l2. , 12.8).

15. Because Veritas was to provide Microsoft with highly-sensitive confidential

information and trade secrets-the type that allowed Veritas to enjoy a leading position in the

enterprise storage management arena-the Agreement contained specific prohibitions on

Microsoft' s ability to use that information. For example, in addition to agreeing not to use

Veritas s confidential information to replace the Embedded Product or otherwise compete



Telephone: (206) 676- 7000Fax: (206) 676-7001

against Veritas , Microsoft also agreed to specific restrictions on the ability of any Microsoft

engineer who had access to the Volume Manager source code, including the Embedded Product

code, from participating in the development of any competing product for a period of time. (See

g.,

Agreement 99 12. , l2. ) These provisions were intended to ensure that Microsoft'

engineers could not-even inadvertently-use knowledge gained from access to Veritas s source

code in the development of a competitive product.

16. All of the prohibitions on Microsoft' s conduct were critically important to Veritas

because , without their protections, Microsoft would be able to use Veritas s confidential

information and trade secrets to compete directly with the Veritas Add-on Products, crippling

Veritas s market for those products and undermining Veritas s reasons for entering into the

Agreement.

17. Microsoft also agreed to regularly provide Veritas with copies of source code and

documentation for any modifications of the Embedded Product, and for portions of the Microsoft

Windows operating system related to the Embedded Product (including any updates), so that

Veritas could maintain complete compatibility of the Embedded Product and any Veritas Add-on

Products with the Windows operating system. (See , e. Agreement 993. , 7. 1.)

Veritas s Disclosure to Microsoft, Under NDA, of Confidential Information andTrade Secrets.

18. Time was of the essence. Microsoft needed an enterprise storage management

product better than the one it had for inclusion in the next version of its operating system, and it

needed the product quickly. To meet Microsoft' s deadlines , the parties agreed that Veritas

initially would convert, or "port " the vast majority ofVeritas s existing Volume Manager source

code so that it would be compatible with Windows NT. Microsoft consistently pressured Veritas

engineers to focus first on porting the Volume Manager product to Windows NT and to "not let

any other projects such as HW array integration an important feature reserved exclusively for

a Veritas Add-on Product (and one wrongfully misappropriated by Microsoft and later



Telephone: (206) 676-7000Fax: (206) 676-7001

incorporated by Microsoft into the operating systemHelay the delivery of the ported Volume

Manager code to Microsoft.

19. As part of the porting process , specific portions of the source code corresponding

to features exclusively reserved to Veritas under the Agreement would be disabled. As described

in the Agreement:

VERIT AS' Volume Manager is a full featured product forcomprehensive disk management. Through delivery of the fullVolume Manager to Microsoft as described in this AgreementVERIT AS will provide Microsoft with a subset to be embedded inthe Windows NT operating system that replicates the functions ofthe Microsoft FT Disk technology (plus some agreed additions)and that establishes a technology foundation for value added add-on products addressing the needs of enterprise servers. This willbe accomplished by VERIT AS' delivering the full VolumeManager with features that are selectively disabled, thus allowingfor an architectural foundation and common disk format for boththe embedded and add-on products.

(Agreement at p. 1.) Although portions ofVeritas s source code were functionally disabled, all

portions of the code (including disabled and enabled code) contained highly-sensitive confidential

information and trade secrets that were subject to the restrictions set forth in the Agreement

constraining Microsoft' s use of such information.

20. Starting in December of 1996 , and in accordance with the Agreement, Veritas

delivered to Microsoft ported versions of its copyrighted Volume Manager source code, in which

portions of the code relating to features reserved exclusively for Veritas Add-On Products were

disabled. In addition to providing this highly-sensitive code, Veritas also supplied Microsoft

with considerable confidential and trade secret information concerning the design, structure and

operation of Volume Manager specifically, and enterprise storage management technology and

know-how generally, including its confidential plans for future Add-On Products. Veritas

engineers spent considerable time training and educating Microsoft' s engineers on Veritas

confidential enterprise storage management technology. For example, on July 29 1997 , Veritas

held a highly confidential briefing with Microsoft regarding (among other things) its product



Telephone: (206) 676-7000Fax: (206) 676-7001

plans and architecture for common interfaces for management of hardware and software RAID

volumes (including interfaces for hardware-based snapshots), and followed up with additional

meetings and technical documentation in October 1997.

21. Indeed , Microsoft' s need for Veritas s know-how was so great that by 1999 the

parties entered into an amendment to the Agreement ("the 1999 Amendment") which included a

new obligation for Veritas to provide a minimum of five Veritas software engineers at

Microsoft' s Redmond facility to teach a team of Microsoft engineers Veritas s trade secrets and

cooperate with them to test Microsoft' s Embedded Product for inclusion in the Windows

operating system. (See, e. 1999 Amendment 9 8. ) The 1999 Amendment also continued

Microsoft' s obligation to provide Veritas with information and updates of code and

documentation so that Veritas could conform the Veritas Add-on Products to the latest version of

Windows , and retained the existing prohibitions against Microsoft' s use ofVeritas trade secrets

or confidential information for competitive purposes , and use of any engineer who had access to

Veritas s Volume Manager code to develop competitive products (although the restricted period

was reduced from 24 to 12 months).

22. After Veritas had transferred control over the source code to Microsoft in

December 1996 (enabling Microsoft to correct errors and optimize code, but not to add new

features-which was prohibited absent consent from Veritas), Veritas and Microsoft cooperated

in further porting and developing the Embedded Product based upon the licensed subset of

Veritas s Volume Manager product. In order to facilitate this cooperation, and as required by the

Agreement (and subsequently the 1999 Amendment), Microsoft provided Veritas with the

Windows operating system source code and related programmers ' notes on a regular basis during

the development of the next version of its operating system, Windows NT version 5. , which

was renamed to Windows 2000. This was critically important because Veritas s software

engineers needed regular access to the current version of such source code and related

programmers ' notes in order to maintain compatibility between Windows 2000 and the


315 FIFIHAVENUE SOUIB, SUITE 1000SEATIU: , WASHINGTON 98104-2682

Telephone: (206) 676-7000Fax: (206) 676-7001

Embedded Product, as well as to permit Veritas to develop the Veritas Add-on Products

compatible with the Windows operating system, as contemplated by the Agreement.

Microsoft' s Deployment of Windows 2000 and Subsequent Refusal to ProvideVeritas with Access to the Windows Software Code.

23. Veritas delivered on its end of the bargain and successfully ported the Embedded

Product code for inclusion in the Windows platform. Microsoft' s own testing of the Veritas

Embedded Product code indicated that it was impressive how it handled large configurations of

physical disks , a desirable feature for the enterprise market. Microsoft branded the Embedded

Product with the moniker "Logical Disk Manager

" ("

LDM") and incorporated it in every

shipping copy of Windows 2000 released in April 2000.

24. After the launch of Windows 2000 , the relationship between the parties changed

markedly. While Microsoft had delivered to Veritas regular updates to the LDM / Embedded

Product source code prior to the launch of Windows 2000 , after the launch Microsoft waited

longer and longer to provide such updates , despite Veritas s repeated requests. This refusal to

provide Veritas regular access to the LDM / Embedded Product source code-in violation of the

Agreement-had the practical effect of hindering Veritas s ability to ensure that the Veritas Add-

on Products would remain compatible with Microsoft' s constantly evolving Windows operating

system code.

25. Microsoft' s refusal to provide source code updates was not inadvertent. After the

launch of Windows 2000 , Microsoft embarked on a path of misusing V eritas ' s source code and

misappropriating its trade secrets to develop replacement and add-on products that would

compete with Veritas products in violation of the spirit and letter of the Agreement, in actions

that were deliberate , methodical , covert and intended to conceal Microsoft' s wrongful conduct.

Microsoft' s Breaches ofthe Agreement and Misappropriation ofVeritasIntellectual Property.

26. Although the Agreement specifically restricted Microsoft from developing and

distributing add-on features exclusively reserved for Veritas , Microsoft did so anyway in, among


315 FIFIHAVENUE SOUIB,SUITE 1000SEATIU: , WASHINGTON 98104-2682

Telephone: (206) 676-7000

Fax: (206) 676- 7001

other things , products it called "Virtual Disk Service

" ("

VDS") and "Volume Shadow Copy

Service

" ("

VSS"). Although the Agreement specifically restricted Microsoft from using

Veritas s confidential information (including source code) to inter alia create a product to

replace the LDM / Embedded Product, Microsoft did so anyway in a product it called "Logical

Volume Manager

" ("

L VM"). And although the Agreement specifically restricted Microsoft

from using any of its engineers who had access to the Volume Manager source code, including

the LDM / Embedded Product code, in the development of any competing product, Microsoft did

so anyway because the fastest and most expedient way to get to market with its competing

products was to breach the Agreement and to misappropriate Veritas s trade secrets. Indeed

unbeknownst to Veritas , even before Microsoft launched Windows 2000 and began improperly

using Veritas s confidential information to develop competing and replacement products

Microsoft had filed secret patent applications in which it claimed to own and to have invented

some of the very intellectual property provided to it by Veritas.

Microsoft Wrongfully Included in its "Vista" Operating SystemsFeatures Exclusively Reserved for Veritas and Based on VeritasConfidential Information and Trade Secrets.

27. The road that led to the discovery of Microsoft' s wrongful conduct began at a

recent Windows Hardware Engineers Conference ("WinHEC"), where Microsoft releases the

latest version of its Windows operating system code (in compiled binary form only) to hardware

engineers employed by other companies. These hardware engineers then make adjustments to

the software and hardware in their products in order to ensure that they will be compatible with

Windows. At WinHEC in early 2004 , Microsoft provided the "Longhorn" version of the next

planned major release of its Windows operating system to WinHEC members , the client version

of which it has since renamed "Vista." (References to "Vista" herein shall include Longhorn.

Rather than merely a minor revision of Windows, Microsoft promoted Vista as a fundamentally

improved and expanded version of Windows , containing many new features and a significant

amount of new software code to replace the existing Windows code.



Telephone: (206) 676- 7000Fax: (206) 676-7001

28. In the early 2004 WinHEC release of Vista (then named "Longhorn ), Microsoft

improperly included code implementing a number of features that the Agreement exclusively

reserved for Veritas Add-on Products. For example, Vista included: (1) a common interface for

hardware and software RAID volumes (VDS); (2) a common interface for hardware-based

snapshots (VSS); (3) growth of partitioned or "striped" RAID volumes (allowing more efficient

distributed data storage among a plurality of disks); and (4) support for multiple online disk

groups. The Agreement specifically acknowledges that Veritas planned to develop, and reserves

to Veritas for future development, a common interface for hardware and software RAID

volumes, among other listed features , to be provided as Veritas Add-on Products. (See, e.

g.,

Agreement, Ex. A 99 2. 2.4 , Appx. A- I at "Administration: Integration with Disk arrays

(HW/SW Raid).

29. Moreover, VDS and VSS directly result from Microsoft improperly using

Veritas s trade secrets , including among others those disclosed in Veritas s July 29 , 1997

presentation and October 1997 documentation provided to Microsoft described above, as well as

secrets embodied in the Embedded Product code. The Agreement specifically forbids Microsoft

from using Veritas s trade secrets (including but not limited to source code) in developing

competing products. (See, e. Agreement 99 2. , 12. ) Microsoft ignored these restrictions

and, in addition, improperly used VDS and VSS as a platform to tightly couple a disk-based

backup offering called Data Protection Manager ("DPM") with its operating system products.

30. On information and belief, even before Microsoft chose to develop, and include

within its operating system , code implementing certain features exclusively and explicitly

reserved to Veritas , it knew that such an act would be in breach of the Agreement. Despite this

understanding, Microsoft began developing such code in or about 2001 for inclusion in Vista.

On information and belief, over the next several years , not only did Microsoft know that it was

engaging in wrongful conduct, but it took affirmative steps to conceal its wrongful conduct from



Telephone: (206) 676- 7000Fax: (206) 676-7001

Veritas. As a result, Microsoft' s wrongful conduct remained hidden from Veritas until in or

about mid-2004.

31. On June l5 , 2004 Veritas met with Microsoft and presented the results of its

analysis of Vista, including its conclusions that: (1) Microsoft had breached the Agreement by

including features in Vista that were exclusively reserved for Veritas to provide as Veritas Add-

on Products; and , (2) in doing so , Microsoft also misused and misappropriated Veritas trade

secret and confidential information relating to those and other features. At this meeting

Microsoft denied that Vista included any code implementing features reserved exclusively to

Veritas and denied any misappropriation. Tellingly, Microsoft also denied Veritas access to the

Vista source code sought by Veritas that would have been useful to further confirm its

conclusions that Vista included code implementing reserved features (in addition to its ongoing

need for the code for development purposes).

32. On October 7 2004, Veritas and Microsoft met again to discuss Veritas s analysis

of Vista. On October 13 , 2004 , Microsoft finally supplied Veritas with a version of the Vista

volume management source code (referred to as "L VM" by Microsoft). V eritas analyzed this

source code and on November 15 , 2004 informed Microsoft that it had confirmed that Vista

contained code implementing numerous features exclusively reserved for the Veritas Add-on

Products , in violation of the Agreement.

33. On January 27 2005 , Veritas and Microsoft again met to discuss Microsoft'

improper bundling of features into the Windows operating system. During this meeting,

Microsoft engineers finally admitted that Vista included code developed by Microsoft to provide

features exclusively reserved for Veritas under the Agreement. Microsoft gave no explanation

claiming instead that-having been caught red-handed-it had attempted to "disable" such code

in Vista. Veritas informed Microsoft that even if sections of the code were temporarily

disabled" as Microsoft contended, such disabled code still would have to be removed because



Telephone: (206) 676- 7000Fax: (206) 676-7001

including the code was in violation of the Agreement. Moreover, Vista provided consumers with

a mechanism to re-enable such code after installation , in further violation of the Agreement.

34. On February 25 2005 , Veritas identified eleven specific sections of Vista code

improperly implementing features reserved for Veritas, informed Microsoft that the presence of

those eleven sections within the Vista code was a breach of the Agreement, and requested that

Microsoft delete those portions of code. Veritas also reiterated its claim that Microsoft' s VDS

code in Vista was the result of Microsoft' s misappropriation ofVeritas s confidential and trade

secret information.

35. On March 8 , 2005 , Microsoft counsel Craig Fielden stated that Microsoft would

remove nine of the eleven sections of Vista code identified by Veritas as implementing features

reserved to Veritas , but not the remaining two. Microsoft also denied any misappropriation

relating to VDS.

36. In July 2005 , Microsoft released the Beta 1 version of the Windows Vista

operating system. Despite Microsoft' s prior assurances otherwise, all ofVeritas s code that it

had agreed to remove still remained , including VDS code that is based upon misappropriated

Veritas source code, trade secrets and confidential information. In subsequent code releases

Microsoft claimed to have removed some of the code relating to features reserved to Veritas, but

it turned out that Microsoft surreptitiously placed code for such features in a different location

within the operating system. Microsoft' s continuing refusal to remove all of the improper code

sections demonstrates its blatant disregard of Symantec s rights. Microsoft must remove from its

operating systems and confirm that it has destroyed all of the improper code, and prohibit its

developers who created the improper code from implementing any same or similar code in the

future. Otherwise, if the past is prologue, Microsoft will simply use the same code or the same

code developers to craft new code for the same features , and thereby continue to benefit from the

development experience obtained only as a result of Microsoft' s breach ofthe Agreement and

misappropriation.


315 FIFIH AVENUE SOUIB, SUITE 1000SEATILE , WASHINGTON 98104-2682

Telephone: (206) 676- 7000Fax: (206) 676- 7001

Microsoft Secretly Developed a Supplanting Product to Replace theLDM/Embedded Product, and in Doing So Improperly Used VeritasTrade Secrets , Confidential Information, and Source Code.

37. Unbeknownst to Veritas at the time, in addition to developing prohibited features

(such as VDS and VSS) beginning in or about 2001 using Veritas s trade secrets, Microsoft

began secretly developing in or about 2002 a supplanting product to replace the LDM /

Embedded Product altogether, in further breach of the Agreement. Microsoft named this

supplanting product Logical Volume Manager, or "LVM." This LVM code, which Microsoft

recently provided to Veritas after numerous delays , is incorporated into Vista in place of the

LDM / Embedded Product code. LVM contains Veritas s trade secrets and confidential

information that Microsoft misappropriated from the LDM / Embedded Product source code and

related information, including proprietary algorithms , routines , code sequence and execution

order for creation and growth of logical RAID volumes. This supplanting product also contains

substantially identical copies of important source code segments from the LDM / Embedded

Product, conclusively establishing its ill-gotten source.

38. Under the Agreement, Microsoft may not use Veritas s source code and related

trade secrets in developing products that compete with Veritas , or that replace the LDM /

Embedded Product. (See, e. Agreement 99 2. , 12.2, 12. ) Instead of employing a process of

using Microsoft developers who had not previously accessed, analyzed and tested the LDM /

Embedded Product source code in order to avoid using any ofVeritas s confidential information

and trade secrets, Microsoft did exactly the opposite in order to shorten its development cycle

and to take unfair advantage ofVeritas s trade secrets. It had its own employees who had access

to the confidential information in the LDM / Embedded Product develop the L VM code and use

confidential and trade secret Veritas information, and copyrighted Veritas code, in doing so.


315 FIFIHAVENUE SOUIH, SUITE 1000SEATIU: , WASHINGTON 98104-2682

Telephone: (206) 676-7000

Fax: (206) 676- 7001

Microsoft Used Employees Intimately Familiar With the Veritas Codeto Design Microsoft Products and Features, Including VDS and L VMWhich Improperly Incorporate Veritas s Trade Secrets andConfidential Information.

39. Not only did Microsoft breach the Agreement by bundling features within its

Windows operating systems that the Agreement had exclusively reserved for the Veritas Add-on

Products and by improperly utilizing Veritas s confidential information , but, in order to do so

most efficiently, it improperly and knowingly used the very same Microsoft developers who had

previously accessed , analyzed and tested the LDM / Embedded Product code in great detail.

40. From 1998 through 2000 , Microsoft software developers who worked with the

source code provided by Veritas included Catherine van Ingen , Felipe Cabrera, Rod Gamache

Christian Teodorescu , and Deborah Jones , among others. Microsoft failed to obtain consent

from Veritas for any of these developers to be exempted from the prohibitions in the Agreement

on developing any competitive product for a period of 12 months after their access to the Veritas

source code had ceased. The only exception ever made to this 12 month prohibition related to

Norbert Kusters. Importantly, this exception was for the ostensible purpose of allowing Mr.

Kusters to maintain legacy FT Disk code for backward compatibility purposes and not for any

new development purposes.

41. The Microsoft developers , including Ms. van Ingen, regularly analyzed and even

developed revisions to the Veritas source code. During late 1999 and early 2000 she led a group

of at least five Microsoft software engineers who worked with Veritas engineers to conduct a

series of joint code reviews of the Veritas code in order to analyze and test the code for defects

or "bugs." As part ofthis project, Ms. van Ingen informed Veritas of revisions to the code

required by Microsoft. During the same time period, she also regularly attended code review

sessions during which the Veritas code was reviewed and analyzed extensively. Mr. Cabrera

Ms. Jones , and Mr. Teodorescu (among others) also participated in this Veritas code review

project, under the supervision of Ms. van Ingen.



Telephone: (206) 676-7000Fax: (206) 676-7001

42. After analyzing Veritas s LDM / Embedded Product code in detail under the

direction of Ms. van Ingen , Ms. Jones very soon thereafter served as the primary developer of the

VDS software code contained in Windows 2003. Consequently, Microsoft not only bundled the

VDS feature, which was reserved exclusively for Veritas , it used Veritas trade secret information

to do so. In developing VDS , Microsoft misappropriated Veritas trade secrets , including those

embodied in the LDM/Embedded Product source code as well as those communicated to

Microsoft during confidential briefings and in written memoranda. It was only through

information recently obtained by Veritas that it first became aware of Microsoft' s improper

means for developing VDS.

43. Microsoft also assigned Mr. Teodorescu and Ms. Jones (among others) to develop

competitive storage management products, which resulted in Microsoft' s L VM code, the

replacement for the LDM / Embedded Product code. Mr. Teodorescu was a primary developer

of the L VM code, including code sections relating to features exclusively reserved for Veritas to

provide as separate Veritas Add-On Products. Both Mr. Teodorescu and Ms. Jones were also

involved in Microsoft' s plans to bundle into Windows features exclusively reserved under the

Agreement for Veritas to provide as Veritas Add-on Products. Moreover, analysis of the L

code has confirmed that it embodies extensive trade secrets and confidential information of

Veritas , including certain portions that contain verbatim copies of segments taken from the

copyrighted LDM / Embedded Product code as well as code segments simply translated for

inclusion into L VM.

44. Microsoft' s exploitation ofVeritas s highly-sensitive proprietary information and

trade secrets in developing competing products, with the aid of engineers intimately familiar with

Veritas s crown jewels , was precisely the kind of action by Microsoft that Veritas feared the

most and the Agreement expressly prohibited.


315 FIFIHAVENUE SOUIH, SUITE 1000SEATILE , WASHINGTON 98104-2682

Telephone: (206) 676- 7000Fax: (206) 676- 7001

Microsoft Fraudulently Patented and Caused to be Published CertainVeritas Trade Secrets and Confidential Information.

45. In addition to surreptitiously misappropriating the Veritas intellectual property

described above, Microsoft was so bold as to file fraudulent documents with the U.

government claiming stake to certain Veritas inventions. In or about 2004, Veritas learned that

on November 29 , 1999 , Microsoft filed U. S. patent applications disclosing and claiming some of

the Veritas trade secret and proprietary information that had been confidentially disclosed to

Microsoft' s engineers under the Agreement. These applications issued as U. S. Pat. Nos.

553 387 ("the ' 387 Patent"), 6 629 202 ("the ' 202 Patent"), 6 681 310 ("the ' 310 Patent"

684 231 ("the ' 231 Patent"), and 6 735 603 ("the ' 603 Patent"). (The foregoing patents

collectively are referred to herein as the "Microsoft Patents.

46. The ' 310 Patent for a "storage management system having common volume

manager" discloses a number of Veritas trade secrets for common interface technology which

manages hardware and software RAID volumes-some of the very trade secrets that Veritas had

disclosed to Microsoft under the Agreement. In its application for the ' 310 Patent, to establish

the invention s supposed novelty, Microsoft lied to the US. Patent and Trademark Office (the

Patent Office ) by advising that " (iJn the past there has been no common volume manager able

to work with both a software volume provider and a hardware volume provider to control the

drivers for the storage devices " and claiming the ideas as its own. In fact, that was part of what

Veritas had disclosed to Microsoft in confidence under the Agreement, and Microsoft knew it.

Indeed , the "inventors" listed on the ' 310 Patent-Mr. Cabrera, Ms. van Ingen and Mr.

Kusters-were the same Microsoft employees who were aware of V eritas ' s common interface

technology, thereafter fraudulently claiming to have invented it. Ironically, Veritas later secured

its own patent on an improved common interface technology which manages hardware and

software RAID volumes , which Microsoft is now infringing. (See Section IV. infra.



Telephone: (206) 676- 7000Fax: (206) 676- 7001

47. Much the same tale can be told with respect to the remaining Microsoft Patents.

The ' 202 Patent for a "volume stacking model" discloses certain Veritas trade secrets with

respect to volume stacking technology, and the ' 231 Patent for "migration of friendly volumes

discloses aspects of V eritas ' s "disk merge" technology, and each of these patents list the very

same inventors as the ' 310 Patent. The ' 387 and ' 603 Patents disclose aspects ofVeritas s "disk

set ID" technology and add Mr. Gamache to the foregoing list of "inventors.

48. In sum , the Microsoft Patents disclose, and purport to claim for Microsoft , certain

proprietary and confidential information ofVeritas , and improperly name Microsoft' s employees

as inventors instead ofVeritas s. During their work on the LDM / Embedded Product, each of

the named "inventors" had access to and analyzed trade secrets and confidential information of

Veritas , and each had considerable interaction with and training from Veritas developers. In

filing the Microsoft Patents, Microsoft fraudulently concealed from the Patent Office the true

inventors of claimed inventions included therein, and Veritas s ownership thereof.

49. Microsoft has , to date, refused Veritas s request that it assign the Microsoft

Patents to Veritas.

Microsoft Attempted to Cleanse Its Misconduct By Proposing aReplacement "Framework Agreement.

50. In a revealing fait accompli , Microsoft, under the supervision of Microsoft

counsel Craig Fielden, proposed in 2002 a "Framework Agreement" to supersede the original

Agreement and the Amendment in order, purportedly, to "extend and expand" their relationship

with Veritas. Although the original Agreement contained a "buy-out" right that enabled

Microsoft to expand certain rights to the Embedded Product for a fee, it specifically did not give

Microsoft the rights to replace the Embedded Product. (See Agreement 9 5. ) With the

Framework Agreement, Microsoft sought to waive its "buy-out" right in exchange for an

unfettered license not only to the Embedded Product but also to Veritas s source code for Add-

on Products and related trade secrets. In various drafts of the Framework Agreement, Microsoft



Telephone: (206) 676- 7000Fax: (206) 676- 7001

acknowledged that it did not have, and desired to secure, certain rights to the Embedded Product

and the Veritas Add-on Products reserved to Veritas under the Agreement. Indeed , in a draft of

the Framework Agreement, Microsoft sought provisions that would have allowed it to introduce

features that (a) were reserved to Veritas under the Agreement, (b) were derived from Veritas

source code, (c) included trade secrets embodied in the Veritas code, and (d) were developed by

Microsoft employees who had access to Veritas code. Unbeknownst to Veritas at the time

Microsoft was already well on its way, at the time of its proposal , to committing each and every

one of these violations , and was attempting by its proposal to supersede the Agreement and

cleanse its misconduct.

51. Negotiations over the Framework Agreement ultimately broke down in 2004.

Tellingly, Microsoft refused to sign an agreement that did not contain a waiver of potential

claims by Veritas for Microsoft' s past infringement. Instead , Microsoft purported to exercise its

buy-out" right under the original Agreement, which it had already acknowledged did not

contain the rights it needed in order to avoid a breach of the original Agreement and

infringement ofVeritas s intellectual property. Microsoft did so after much of its

misappropriation and wrongful conduct took place, in an ill-conceived effort to whitewash some

of these activities. Of course, Microsoft knew that its improper exercise of the buy-out inter

alia could not give it the retroactive or prospective right to misuse the Veritas confidential

information and trade secrets , could not expunge its prior breaches of the Agreement, and could

not supersede numerous limitations and obligations under the Agreement, which is exactly why

it attempted to negotiate the Framework Agreement in the first place. Microsoft' s after-the-fact

attempt to exercise the buy-out was just another attempt to cover its tracks.

Microsoft' s Infringement of V eritas s ' 661 Patent.

52. On November 30 2004 United States Patent No. 6 826 661 ("the ' 661 Patent"

entitled "Methods and Systems for Storage Architectures" was duly and legally issued based

upon an application filed by Veritas on August 30, 2002 , naming four Veritas engineers as the


315 FIFIH AVENUE SOUIH, SUITE 1000SEATILE , WASHINGTON 98104-2682

Telephone: (206) 676-7000Fax: (206) 676- 7001

inventors. A copy of the ' 661 Patent is attached hereto as Exhibit A. Veritas is the assignee and

owner of the ' 661 Patent. The ' 661 patent discloses and claims methods and systems for

providing an improved common interface for RAID hardware and software volumes utilizing a

common data store. One or more of the ' 661 Patent's claims covers various aspects ofVDS

both alone and in combination with the DPM feature that Microsoft has more recently offered for

tightly-integrated use with its operating system products.

53. As noted above, Microsoft' s development ofVDS was based upon

misappropriation of Veritas trade secrets and was done in breach of the Agreement. To

compound this transgression, Microsoft has now used the ill-gotten VDS as a platform for the

closely-coupled integration ofDPM.

54. Microsoft' s Windows 2003 and Vista operating systems each provide the VDS

product, now in conjunction with DPM , in a manner that infringes one or more claims of the

, 661 Patent.

55.

full.

56.

V. FIRST CLAIM FOR RELIEFTRADE SECRET MISAPPROPRIATION

Veritas repeats the allegations of Paragraphs 1 through 54 as if set forth herein in

As explained in detail above, Microsoft' s engineers improperly used and publicly

disclosed certain Veritas trade secrets that Veritas had disclosed to Microsoft in accordance with

the Agreement. Microsoft used Veritas trade secrets in order to develop and include in Windows

NT and subsequent operating system products certain features that were reserved exclusively to

Veritas under the Agreement. Microsoft also misappropriated Veritas trade secret information

by using such information to create and incorporate L VM, VDS and VSS into Microsoft' s

operating system products. Microsoft also improperly used and publicly disclosed certain

Veritas trade secrets by incorporating them into the patent applications that issued as the

Microsoft Patents.


315 FIF'IHAVENUE SOUIH, SUITE 1000SEATIU: , WASHINGTON 98104-2682

Telephone: (206) 676-7000Fax: (206) 676- 7001

57. In accordance with the Washington Uniform Trade Secrets Act, Revised Code of

Washington ("RCW") 19. 108.050 , Veritas seeks an injunction against any further use or

disclosure by Microsoft of its trade secret information, forbidding Microsoft from making or

selling the products proven to improperly include its trade secrets, and requiring Microsoft to

recall and destroy all products proven to improperly include such trade secrets.

58. In accordance with the Washington Uniform Trade Secrets Act , RCW

19.108.030(1), Veritas seeks damages sufficient to: (1) compensate it for its actual losses

including lost profits resulting from Microsoft' s misappropriation and unlawful use and

disclosure ofVeritas s trade secrets; and , (2) recover to Veritas unjust enrichment of Microsoft

resulting from its misappropriation and unlawful use and disclosure ofVeritas s trade secrets.

59. In accordance with the Washington Uniform Trade Secrets Act, RCW

19.108.020(3) and/or 19. 108. 050 , Veritas seeks an order compelling Microsoft to assign to

Veritas the Microsoft Patents , and any other pending patent applications disclosing and/or

claiming Veritas trade secret information.

60.

61.

full.

62.

Because Microsoft' s misappropriation was willful and malicious, in accordance

with the Washington Uniform Trade Secrets Act, RCW 19.1 08.030(2), Veritas requests this

Court award exemplary damages equal to double the total amount awarded as compensatory

damages and unjust enrichment under RCW 19. 108. 030(1), together with all attorneys ' fees and

costs incurred in connection with this action, in accordance with RCW 19. 108.040.

VI. SECOND CLAIM FOR RELIEFBREACH OF CONTRACT


Veritas has complied with all ofthe obligations required by it to be performed

pursuant to the terms of the Agreement and the Amendment.



Telephone: (206) 676-7000

Fax: (206) 676- 7001

63. As explained in detail above, Microsoft breached its contractual obligations under

the Agreement and Amendment by, among other things: (1) including features in its operating

system products that are exclusively reserved for Veritas; (2) failing to provide Veritas requisite

information and updates of code and documentation; (3) failing to comply with its contractual

obligations directed to maintaining the confidentiality of V eritas ' s trade secret and confidential

information; and (4) utilizing Veritas s trade secret and confidential information in developing

products and fraudulently prosecuting patents.

64. Veritas seeks an order compelling Microsoft to perform its obligations under the

Agreement, including, inter alia: (1) compelling Microsoft to remove those features from its

operating system products (and any derivatives thereof) that are reserved exclusively to Veritas

under the Agreement or that incorporate any Veritas trade secrets or confidential information

and to recall and destroy all remaining stock of any Microsoft product that contains any such

feature; (2) enjoining Microsoft from making, selling, or using any operating system or other

product that improperly includes any feature reserved exclusively to , or derived from the trade

secrets of, Veritas; (3) enjoining Microsoft from enjoying the benefits of any head start

Microsoft has gained from using developers who had access to Veritas source code to develop

LVM, VDS and VSS; and , (4) compelling Microsoft to provide Veritas with regular access to its

updated operating system code and programmers notes, as required by (inter alia) Sections 5.

and 7. 1 of the Agreement.

65. Veritas has been damaged as a result of Microsoft' s breaches , and seeks damages

in accordance with proof at trial , but in any event sufficient to: (1) compensate it for its actual

losses including lost profits resulting from Microsoft' s breaches; and, (2) recover to Veritas

unjust enrichment of Microsoft resulting from its breaches.

COMPLAINT - 23CASE NO.

SUMMIT LAW GROUP PLLC315 FIFIHAVENUE SOUIH, SUITE 1000

SEATILE , WASHINGTON 98104-2682Telephone: (206) 676-7000

Fax: (206) 676-7001

VII. THIRD CLAIM FOR RELIEFBREACH OF THE IMPLIED COVENANT OF GOOD FAITH AND FAIR DEALING

66.

full.

67.


As explained in detail above, in its dealings with Veritas , Microsoft breached the

implied covenant of good faith and fair dealing by: (1) including features in its operating system

products that are exclusively reserved for Veritas under the Agreement; (2) failing to provide

Veritas information and updates of code and documentation as required by the Agreement; and

(3) failing to comply with its contractual obligations under the Agreement and under applicable

law directed to respecting the confidentiality ofVeritas s trade secret and confidential

information.

68. Veritas has been damaged as a result of Microsoft' s breach in an amount in

accordance with proof at trial , but in any event in an amount sufficient to: (1) compensate

Veritas for its actual losses including lost profits resulting from Microsoft' s breach; and, (2)

recover to Veritas unjust enrichment of Microsoft resulting from its breach.

full.

VIII. FOURTH CLAIM FOR RELIEFUNFAIR COMPETITION

69. Veritas repeats the allegations of Paragraphs 1 through 68 as if set forth herein in

70. As explained in detail above, in its dealings with Veritas , Microsoft engaged in

unfair competition, in violation of Washington common law by: (1) including features in its

operating system products that are exclusively reserved for Veritas under the Agreement; (2)

failing to provide Veritas requisite information and updates of code and documentation; and , (3)

failing to comply with its contractual and other obligations directed to respecting the

confidentiality ofVeritas ' trade secret and confidential information.

71. In accordance with Washington common law, Veritas seeks an order compelling

Microsoft to perform its obligations under the Agreement, including, inter alia: (1) compelling



SEATILE , WASHINGTON 98104-2682Telephone: (206) 676- 7000

Fax: (206) 676-7001

Microsoft to remove those features in its operating system products (and any derivatives thereof)

that are reserved exclusively to Veritas under the Agreement or that incorporate any Veritas trade

secrets or confidential information , and to recall and destroy all remaining stock of any

Microsoft product that contains any such feature; (2) enjoining Microsoft from making, selling,

or using any operating system or other product that improperly includes any feature reserved

exclusively to , or derived from the trade secrets of, Veritas; (3) using Veritas trade secret

information to accelerate its development of competing offerings; and , (4) compelling Microsoft

to provide Veritas with regular access to its updated operating system code and programmers

notes , as required by (inter alia) Sections 5.3. 3 and 7. 1 of the Agreement.

72. In accordance with Washington common law, Veritas seeks damages sufficient

to: (1) compensate it for its actual losses including lost profits resulting from Microsoft' s unfair

competition , including improper use and disclosure ofVeritas s trade secrets; and , (2) recover to

Veritas unjust enrichment of Microsoft resulting from its unfair competition , including its

disclosure and use ofVeritas s trade secrets.

full.

IX. FIFTH CLAIM FOR RELIEFUNJUST ENRICHMENT AND CONSTRUCTIVE TRUST


74. As explained in detail above, Microsoft' s engineers improperly used and publicly

disclosed certain Veritas trade secrets that Veritas had disclosed to Microsoft in accordance with

the Agreement. Microsoft improperly used and publicly disclosed certain Veritas trade secrets

by (inter alia) incorporating them into the patent applications that issued as the Microsoft

Patents.

75. Inventions disclosed and claimed in the Microsoft Patents were invented by

Veritas employees and disclosed to certain Microsoft engineers in accordance with the

Agreement. In violation of the Agreement and the patent laws

g.,

35 U. C. 9 115 , Microsoft




Fax: (206) 676-7001

engineers who had worked in cooperation with the Veritas inventors under the Agreement filed

the patent applications that issued as the Microsoft Patents in an attempt to claim as their own the

inventions of the Veritas inventors. At all times , Microsoft and the Microsoft engineers who had

worked in cooperation with Veritas knew and appreciated that inventions and other trade secret

and confidential information disclosed and claimed in the Microsoft Patents were the property of

Veritas.

76. Microsoft' s continued possession of the Microsoft Patents is inequitable, and has

occurred at Veritas s expense.

77. Veritas seeks a judgment that Microsoft holds the Microsoft Patents (and any

related , pending applications) in a constructive trust on behalf of the true Veritas inventors, and

thus on behalf of Veritas.

78. Veritas seeks an order compelling Microsoft to assign the Microsoft Patents, and

any pending, related applications to Veritas in fulfillment of the constructive trust imposed by

the Court.

SIXTH CLAIM FOR RELIEFCONVERSION


full.

80. As explained in detail above, Microsoft has exercised unjustified and willful

interference with, and dominion over, Veritas s intellectual property, trade secrets , and

confidential information by improperly using and publicly disclosing certain Veritas intellectual

property including trade secrets that Veritas had disclosed to Microsoft in accordance with the

Agreement. Microsoft misused Veritas trade secrets in order to replace (e. , L VM) and

misappropriate certain features (e. , VDS , VSS) that were reserved exclusively to Veritas under

the Agreement. Microsoft also improperly used and publicly disclosed certain Veritas trade

secrets by incorporating them into the patent applications that issued as the Microsoft Patents.




Fax: (206) 676-7001

81. At all times of Microsoft' s acts of conversion, Veritas had the right to maintain

and/or use the subject intellectual property, trade secrets , and confidential information.

82. Veritas seeks damages sufficient to: (1) compensate it for its actual losses

including lost profits resulting from Microsoft' s acts of conversion; and , (2) recover to Veritas

unjust enrichment of Microsoft resulting from its acts of conversion.

XI. SEVENTH CLAIM FOR RELIEFCOPYRIGHT INFRINGEMENT


full.

84. Microsoft has infringed Veritas s Registered Copyright Nos. TXu1272637 and

TXu1272638 by developing, copying, making, using, offering for sale or selling various

operating system products incorporating L VM. As alleged above, L VM contains code segments

that constitute copies of portions ofVeritas s copyrighted code. Microsoft has committed such

acts of infringement with full knowledge of the existence ofVeritas s copyright rights, such acts

of infringement by Microsoft have been and continue to be willful and deliberate, and Veritas

believes such acts will continue in the future unless enjoined by the Court.

85. By reason of Microsoft' s acts of infringement, Veritas has suffered and will

continue to suffer damages , in amounts yet to be determined. Microsoft' s acts of infringement

have also resulted and continue to result in substantial unjust profits and unjust enrichment of

Microsoft in amounts yet to be determined. Such acts of infringement are causing irreparable

harm to Veritas and will continue to case irreparable harm unless enjoined by this Court.

XII. EIGHTH CLAIM FOR RELIEFPATENT INFRINGEMENT


full.

87. Microsoft has infringed one or more claims ofVeritas s ' 661 Patent by making,

using, offering for sale, or selling various operating system products incorporating VDS.



Telephone: (206) 676-7000

Fax: (206) 676-7001

Microsoft has further infringed one of more claims of the ' 661 patent by marketing DPM as part

of a tightly integrated package with its operating system , utilizing VDS as the platform for such

integration. Microsoft' s Vista operating systems continue to infringe one or more claims of the

661 Patent by (among other things) incorporating and marketing VDS alone and in conjunction

with DPM. Microsoft has committed such acts of infringement with full knowledge of the

existence of the ' 661 Patent and the rights ofVeritas with respect thereto. Such acts

infringement by Microsoft have been and continue to be willful and deliberate and Veritas

believes such acts will continue in the future unless enjoined by the Court.

88. By reason of Microsoft' s acts of infringement, Veritas has suffered and continues

to suffer damages , including lost sales and diminution of value of the ' 661 Patent, in amounts yet

to be determined.

89. Microsoft' s acts of infringement have resulted and continue to result in substantial

unjust profits and unjust enrichment of Microsoft in amounts yet to be determined. Such acts

infringement are causing irreparable harm to Veritas and will continue to cause irreparable harm

unless enjoined by the Court.

XIII. PRAYER FOR RELIEF

WHEREFORE , PlaintiffVeritas demands judgment in its favor and against Defendant

Microsoft as follows:

That the Court enter a judgment in favor of Veritas and against Microsoft on all

counts alleged herein;

That the Court issue a preliminary and, thereafter, permanent injunction against

Microsoft, and its officers , agents , servants , employees , and all others in active concert or

participation with Microsoft with notice, enjoining and restraining them from the following:

Producing, manufacturing, installing, distributing, circulating, or using any

product that includes any unlicensed Veritas software, any Veritas trade

secret, or any feature exclusively reserved to Veritas under the Agreement;



SEATIU: , WASHINGTON 98104-2682Telephone: (206) 676-7000

Fax: (206) 676-7001

Assisting, aiding or abetting any other person or entity in engaging in or

performing any of the activities referred to in subparagraph (a) above; and

Using any code developed by employees prohibited from engaging in

competitive development under the Agreement.

That the Court enter a judgment against Microsoft stating that Microsoft has

breached the Agreement by including features in its operating systems that were exclusively

reserved to Veritas under the Agreement and by utilizing Veritas trade secrets and confidential

information in developing VDS , VSS and L YM , and awarding damages to Veritas in

compensation of its losses caused by Microsoft' s breach;

That the Court order Microsoft to provide Veritas access to code and

documentation in accordance with Microsoft' s obligations under (inter alia) Sections 3. 5 and 7.

of the Agreement.

That the Court enter a judgment against Microsoft that it has infringed Copyright

Registration Nos. TXu1272637 and TXu1272638 , and one or more claims of us. Pat. No.

826 661 , and that such infringement was, and continues to be, willful;

That the Court issue a preliminary injunction and , thereafter, a permanent

injunction against Microsoft, and its officers , agents , servants , employees , and all others in active

concert or participation with Microsoft with notice, enjoining and restraining them from the

following:

Producing, manufacturing, installing, distributing, circulating, or using any

product found to infringe Copyright Registration Nos. TXu1272637 and

TXu1272638 or the ' 661 Patent;

Assisting or inducing any other person or entity in engaging in or

performing any ofthe activities referred to in subparagraph (a) above.

That the Court order Microsoft to pay to Veritas general , special , actual and/or

statutory damages , according to proof at trial.



Telephone: (206) 676-7000Fax: (206) 676-7001

That the Court order Microsoft to recall and destroy all products found to include

features that infringe Copyright Registration Nos. TXu1272637 and TXu1272638 or the ' 661

Patent, or to incorporate any of the features reserved to Veritas under the Agreement, or to

include any confidential information or trade secrets misappropriated from Veritas.

That the Court order Microsoft to pay restitution of its profits from the above-

described activities.

10. That the damages awarded to Veritas for Microsoft' s willful infringement of the

661 Patent be trebled.

11. That the Court order Microsoft to pay to Veritas both the costs of this action and

reasonable attorneys ' fees incurred by Veritas in prosecuting this action.

12. For punitive and exemplary damages in a sum to be ascertained at trial.

13. For the imposition of a constructive trust, the corpus comprising the Microsoft

Patents , with Veritas the beneficiary, and an order of the Court compelling Microsoft to assign

the Microsoft Patents , and any pending related applications to Veritas.

14.

15.


For interest at the legal rate.

For such other and further relief as the Court may deem just and proper.



Fax: (206) 676-7001

DATED this 18th day of May, 2006.


Respectfully submitted

Mark A. Flagel (pro hac vice pending)Robert Steinberg (pro hac vice pending)Belinda S Lee (pro hac vice pending)Sean Pak (pro hac vice pending)LATHAM & WATKINS LLP633 West Fifth Street, Suite 4000Los Angeles , California 90071-2007Telephone: (213) 485- 1234Facsimile: (213) 891-8763

David A. Nelson (pro hac vice pending)LATHAM & WATKINS LLPSears Tower, Suite 5800Chicago , Illinois 60606Telephone: (312) 876-7700Facsimile: (3l2) 993-9767


SEATIU: , WASHINGTON 98104-2682Telephone: (206) 676- 7000

Fax: (206) 676- 7001

DEMAND FOR JURY TRIAL

Veritas hereby respectfully demands ajury trial on all issues properly triable to a jury.

DATED this 18th day of May, 2006.


Respectfully submitted

Mark A. Flagel (pro hac vice pending)Robert Steinberg (pro hac vice pending)Belinda S Lee (pro hac vice pending)Sean Pak (pro hac vice pending)LATHAM & WATKINS LLP633 West Fifth Street , Suite 4000Los Angeles, California 90071-2007Telephone: (213) 485- l234Facsimile: (213) 891-8763

David A. Nelson (pro hac vice pending)LATHAM & W ATKINS LLPSears Tower, Suite 5800Chicago , Illinois 60606Telephone: (312) 876-7700Facsimile: (312) 993-9767



Fax: (206) 676-7001

EXHIBIT A

(12) United States PatentUmbehocker et al.

111111111111111111111111111111111111111111111111111111111111111111111111111

USOO6826661B2

(10) Patent No. US 6,826,661 B2(45) Date of Patent: Nov. 30, 2004

(54) METHODS AND SYSTEMS FOR STORAGEARCHITECTURES

Steven Michael Umbehocker, MercerIsland , WA (US); Allen UnuecoBellevue , WA (US); Bruce LoweMonroe , WA (US); Venkeepuram R.Satlsh , Freemont , CA (US)

(73) Assignee: VERITAS Operating CorporationMountain View, CA (US)

(75) Inventors:

( *

Notice: Subject to any disclaimer, the term of thispatent is extended or adjusted under 35

c. 154(b) by 242 days.

(21) Appl. No. 10/232 132

(22) Filed: Aug. 30, 2002(65) Prior Publication Data

us 2004/0044856 Al Mar. 4, 2004

(51) Int. CI.7 ................................................ G06F 12/00(52) U.S. Cl.

.......................................................

7111154

(58) Field of Search

.................................

711/154 148711/6; 709/213 214

(56) References Cited

S. PATENT DOCUMENTS

442 791 A 811995655 081 A 811997758 125 A * 5/1998838 918 A 11/1998041 386 A * 3/2000108 782 A 8/2000141 759 A 10/2000415 289 Bl * 7/2002430 611 Bl 812002480 901 Bl * 11/2002

484 177 Bl * 11/2002

622,176 B2' 9/2003640 278 Bl . 10/2003

2002/0095602 AI 7/20022002/0143942 Al . 1012002

Wrabetz et aI.Bonnell et aI.Misinai et aI. ................ 703/23Prager et aI.Bello ............................ 711/4Fletcher et aI.BraddyWilliams et aI. .............. 707/10Kita et aI.

Weber et aI. ............... 7r1i1/246Van Huben et ill. .......... 707/10Jones et aI. ................. 7191328Nolan et aI. ................... 711/6Pherson et aI.Li el aI. ..................... 7r1i1/225

110

R""""

"'.

2003/0204580 Al . 1012003 Baldwin et aI. ............ 7r1i1(2T3

2003/0233510 Al . 1212003 Umbehocker et aI. ...... 71111002004/0010666 AI' 112004 Umbehocker et aI. ...... 711/156

FOREIGN PATENT DOCUMENTS

135746500(176060113898702(25870

10(200312(20005(20013(2002

OTHER PUBLICATIONS

International search report application number PeT/US03/27295 mailed Mar. 5 , 2004.Anonymous

, "

IBM Storage Tank TM A Distributed Storage

System , IBM Corporation , Online! Jan. 24 2002, pp. 1-XPOO2270407, http://www.almaden.ibm.com/cs/storag-esystems/sto rtank/ExtS torage Ta nkP aperO 1 24-02. pdtWoithe

, "

A Common Interface for Host Bus AdaptersStorage Networking Industry Association Fibre ChannelWor Group (SNIA-FCWG), Online! Jan. 2001 , pp. 1-4XP002270111, http:/hbaapi.sourceforge. net/Common%20HBA %20API %20White%20Paper%2OvOl28011.pdf.

. cited by examiner

Primary Examiner-Hiep T. Nguyen(74) Attorney, Agent, or Firm-Meyertons Hood KivlinKowert & Goetzel , P.c.; B. Noel Kivlin

(57) ABSTRACT

Methods and systems for storage architectures are provided.Storage resource provider modules interface with storageresources to perform storage operations. A storage manage-ment data store maintains storage data associated with astorage environment of the storage resources. The storageresource provider modules retrieve and update the storagemanagement data in response to processing the storage

operations. In one embodiment, a storage managementapplication requests a selected storage resource provider

module to perform a selected storage operation. The storagemanagement application determines the selected storageresource provider module by acquiring the storage manage-ment data in the data store.

14 Claims, 4 Drawing Sheets

'00

"...

Reoo"",ON

",.

Exhibit A

s. Patent Nov. 30, 2004

130

140.

Sheet 1 of 4

110.

Fig. 1

Resourc~

US 6,826,661 B2

100

110.

140.

S. Patent Nov. 30, 2004

ProvIde ResourceProvider Modules

.".

Store StorageManagement Os in StorageManagement OS

.,..

Access the OS toManage StorageEnvironment

Fig. 2

Sheet 2 of 4 US 6,826,661 B2

.v"

210

220

230

200

S. Patent

(n,err.co To Has,App.

Nov. 30, 2004 Sheet 3 of 4

312Provick StorageManaiement App.

Associatt ResourceProvidc:r ModulesWIth StoraseManagement App.

Create StorageManagement OS

Update OS.

Fig. 3

310

320

330

340

US 6,826,661 B2

300

Store storagemanasemenl data In 332

S. Patent Nov. 30, 2004

450

460

410 I

Sheet 4 of 4

430.

US 6 826,661 B2

400

k'"

430.

410N

Fig. 4

US 6 826 661 B2

METHODS AND SYSTEMS FOR STORAGEARCHITECTURES

FIELD OF INVENTION

The present invention is related to storage architectures,and more particularly to methods , and systems that providestorage architectures to access storage management data.

BACKGROUND INFORMATION

Storage networking is the practice of connecting storagedevices to computing devices (e. , clients, servers , and thelike) by using networks (e. , Fibre Channel , Internet SmallComputer System Interface (iSCSI), and others) instead of

traditional point- to-point Small Computer System Interface I(SCSI) channels. A network used to connect servers tostorage devices is referred to as a storage area network(SAN). Typically, within a SAN environment , computingdevices have access to the available storage devices. This 20

presents a wide variety of benefits, including server platfornlfail-over wherein a failed storage device and failed serverare automatically recovered by another operational serverplatform and operational storage device without requiring

any recabling of the operational storage devices.Prior to the development of SAN technology, local and

wide area networks provided access between computing

devices that did not always include storage devices. Con-nections were established with network protocols such asTransmission Communication Protocol (TCP), UnreliableDatagram Protocol (UDP), and others. Some of these pro-tocols ensure that message ordering is preserved and thatmessages are not lost. Distributed File Systems (DFS) suchas network file system (NFS) and Common Internet filesystem (CIFS) are layered on top of network protocols. 35

Distributed Pile Systems provide uniformed named access tofiles and their data storage devices across a network con-sisting of heterogeneous computing devices. Using DFSaccess to files or data storage devices is transparent to anyparticular computing device. Thus, access is consistentacross the DFS without the need for physical locations orother details associated with any particular file or data. Thisaccess transparency is often referred to as storage virtual-ization.

Storage arrays provide access to storage disks within ashared storage environment. The storage arrays include thestorage disks, software to access those storage disks

controllers, memory, power supplies, and the like. Hostapplications within the shared storage environment commu-nicate with the storage arrays to gain access to storage

locations on the storage disks controlled by the storage

arrays. However, this access is typically in the form ofvendor-specific interfaces provided by the vendors of thestorage arrays. In some cases, vendors provide softwarelibraries to gain access to the storage arrays (e. , by 55

implementing APls). In other cases , vendors provide com-mand line interfaces , where the commands are encoded in aspecific data format , such as Extensible Markup Language(XML) data fornlat and others.

Often storage management applications are interposedbetween the host applications and the underlying physicalstorage arrays. This is done, to free the host applications

from the responsibilities of maintaining storage as well as tocentralize storage management. Each storage managementapplication is responsible for managing storage for a plurality of host applications and a plurality of storage arrays.However, in a heterogeneous shared storage environment

with disparate storage arrays , the storage management appli-cations are forced to know and manage a variety of inter-faces in order to properly maintain and manage storage forthe host applications.

Moreover, existing storage architectures do not makestorage management data centrally accessible to the appli-cations that manage each vendor s storage arrays. Storage

management data is critical to any storage architecture; itincludes, for instance , configuration settings associated with

10 each storage array. Conventionally, applications aggregate

the storage management data from the storage arrays andassimilate the results in isolation from other applications.

However, if the various applications are not well integratedand coordinated, then the quality and timeliness of the

storage data can be impacted.

Therefore , there is a need for a system and method forflexibly managing storage. Purthernlore, there is a need tocentrally provide storage management data , where the stor-age management data can be accessed by each of theapplications in order to provide a consistent representation

of a storage environment.

SUMMARY OF TIlE INVENTION

According to one aspect of the present invention, a

method of managing storage across a heterogeneous storageenvironment is presented. A storage management applica-tion is provided that is interfaced to a host application. Aplurality of storage resource provider modules is associated

30 with the storage management application. Moreover, storagemanagement data is stored on a storage management datastore. The storage management data is associated with thestorage management application and with each of the stor-age resource provider modules. Further, the storage man-agement application accesses the data store when receivinga request to access a selected storage resource from the hostapplication in order to be assigned to one of the storage

resource provider modules by the data store. The assignedstorage resource provider module retrieves and stores stor-

40 age management data from and to the data store in order tosatisfy the request.

According to another aspect of the present invention, a

storage management architecture system is provided. Thestorage management architecture system includes a plurality

45 of storage resources , a plurality of storage resource providermodules, and a storage management data store havingstorage management data. Each of the storage resourceprovider modules interfaces with a different storage

resource , and stores and retrieves storage management data50 from and to the data store in order to maintain a consistent

storage environment representation in the data store.According to yet another aspect of the present invention

another storage management architecture system is dis-closed. The storage management architecture systemincludes a plurality of storage resources , where each storageresource includes an interface used to perform storage

management operations on the storage resources, and wheretwo or more of the interfaces are different from one another.The storage management architecture system also includes a

60 plurality of storage resource provider modules, where eachstorage resource provider module communicates with one ofthe interfaces. Additionally, the storage management archi-tecture system includes a storage management data storecapable of storing storage management data associated withthe storage management operations. The storage resOurceprovider modules act as an intermediary on behalf of acalling application when processing the storage manage-

US 6,826,661 B2

ment operations , and the provider modules retrieve and storeresults associated with processing the storage managementoperations in the data store.

BRIEf DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a flow diagram of one method for providingstorage architectures , according to the present invention;

FIG. 2 shows a flow diagram of another method forproviding storagc architectures, according to the presentinvention;

FIG. 3 shows a block diagram of one storage architecturesystem , according to the present invention; and

FIG. 4 shows a block diagram of another storage archi-tecture system , according to the present invention.

DESCRIPTION OF THE PREFERREDEMBODIMENTS

In the following detailed description of various embodi-ments of the present invention , reference is made to theaccompanying drawings that form a part hereof, and in

which is shown by way of illustration specific embodimentsin which the invention may be practiced. It is to be under-stood that other embodiments may be utilized and structuralchanges may be made without departing from the scope of the present invention.

As used herein a "storage management applicationincludes software modules or applications that managestorage resources on behalf of host applications. In someinstances, storage management applications are VolumeManager (VM) applications processing in a shared storageenvironment , such as a Storage Area Network (SAN) envi-ronment or any networked environment (e. , TCP/IP usingiSCSI and others). In other instances, the storage management application is a SAN manager application, or other

storage management operation, such as a snapshotoperation, a mirror operation , and the like. Host applicationsare applications that interface with the storage managementapplications to gain access to storage resources.

In various embodiments of the present disclosure , storagearrays include storage resources , software (e. , native stor-age array provided interfaces) to access the storageresources, controllers, memory, power supplies, and the like.Storage resources can include whole storage arrays , storagedisks , communication ports, Logical Unit Numbers (LUNs)assigned to communication ports, Access Control Lists(ACI..s), Host Bus Adapters (HBAs), virtual storage disksassigned by the storage arrays, bindings, and the like. Thestorage arrays typically include front-end adapter interfacesthat are accessible to the host applications to access the

storage resources and back-end adapter interfaces that thestorage array uses to control the storage resources directly.

In various embodiments of the present disclosure, the

front-end adapter interfaces are interfaced to storage

resource provider modules. Beneficially, the back-endadapter interfaces may remain unchanged with the teachingsof the present disclosure. Storage arrays themselves mayadditionally be storage appliances, high-density or blade

servers, or maybe internally embedded in switches.Moreover, depending upon the operations being performedon a storage array, a storage array can be designated a host.Similarly, under some conditions , a host can be designateda storage array.

FIG. 1 illustrates a block diagram of one storage archi-tecture system 100, according to the present invention. Thestorage architecture system 100 includes a plurality of

storage provider resource modules (e. , 110. 110.M) anda storage management Data Store (DS) 130 having storagemanagement data (e. , configuration settings) associated

with storage resources (e. , 240. 140.N) of a storage5 environment for the storage architecture system 100.

Each of the storage resource provider modules 110 isimplemented to interface with a different storage resource140. The storage resource provider modules 110 store andretrieve storage management data from and to the DS 130.

10 In this way, the storage resource provider modules 110 assistin maintaining a consistent and stable storage environmentrepresentation within the DS 130, when storage manage-ment data is altered or otherwise accessed. This storageenvironment representation is centrally managed and avail-

S able through the DS 130 to the storage resource providermodules 110 and any other application processing in thestorage environment. ADS 130 is described in U.S. patentapplication Ser. No. 10/113 394 , the description of which isincorporated by reference herein.

20 In one embodiment , the storage management architecturesystem also includes a storage management application(e. , VM , SAN manager, or other storage operation) (notshown in FIG. 1). The storage management applicationreceives storage management operations from a plurality ofhost applications. These operations are inspected by thestorage management application to determine the appropri-ate storage resource 140 that is impacted by the operations.The DS 130 is then queried to determine the appropriatestorage resource provider module 110 needed in order to

30 process the operations on behalf of the storage managementapplication. Results associated with the operations are madeavailable to the storage management application in the DS130. In this way, the storage management application indi-rectly interfaces with each of the storage resources 140through the storage resource provider modules 110.

In one embodiment, the storage resources 140 are storagearrays having disparate interfaces that are needed to performstorage management operations on them. Interfaces aredisparate when the commands, naming standards, calling

40 syntaxes, and/or parameter orders are different. In somecases, the interfaces are disparate when different vendorsprovide the storage arrays or when different versions/releases of storage arrays are not compatible.

In some instances, a plurality of host applications are45 permitted access to DS 130 in order to acquire the storage

management data. The host applications can use the storagemanagement data to make decisions about whether to pro-cess a particular storage management operation. In this way,the DS 130 is available for use by any application within tbe

50 storage environment, and any application altering the stor-age management data can directly or indirectly cause thestorage management data to be updated within the DS 130.Thus , operations performed by applications are coordinatedsynchronized, and managed through the DS 130, without

55 requiring code modifications to each of the applicationsoperating within the storage environment.

The DS 130 provides access and update methods to thestorage resource provider modules 110 and any other appli-cations processing within the storage environment. In some

60 cases, the methods can be restricted based on security suchthat some methods are publicly available for use , and othermethods are private having restricted use. This ensures thata rogue application cannot inadvertently alter the storagemanagement data in a manner that is undesirable. Security

65 can also be provided using any Public Key Infrastructure(PKI) technique, such as public-private key encryption

authentication using certificates , and/or authorization.

US 6 826,661 B2

Another embodiment includes storage management datathat has configuration settings associated with storage resid-ing within the storage resources 140 along with state infor-mation associated with the storage resources 140. Thus , thestorage provider resource modules 110 can acquire the state 5information from the DS 130 to determine when storagemanagement operations can be permissibly processed on theappropriate storage resources 140 or when some storagemanagement operations must be held in abeyance until state changes within a storage resource 140.

FIG. 2 illustrates a flow diagram of one method 200 formanaging storage across system 100, according to the

present jnventiou. System 100 includes a variety of appli-cations that access and manage storage. In one embodimentstorage management data is provided to the applications in order to assist in accessing storage or managing the con-figuration settings of the storage.

In some embodiments , the applications are layered suchthat applications at higher levels of abstraction receive

storage management data that is virtualized. Additionally, 20applications at lower levels of abstraction receive storage

management data that is less virtualized or, in some casesdata that represents physical mappings of storage within astorage resource. In one such embodiment, a storageresource 140 represents a storage entity that includes storagemanagement data about storage embodied by the storageentity. In various embodiments of the present disclosure , astorage resource 140 is a storage array.

Each storage array includes an interface (e. , a set of 30

commands, operations, and the like) that permits otherapplications to perform storage operations on each of thestorage arrays. These operations can be used to acquireexisting storage management data (e. , configuration

settings). Alternatively, the operations can be used to alter the configurations of storage, thus, altering the storage

management data within the storage arrays. In a singlestorage architecture that is used to manage a storageenvironment, a plurality of disparate storage arrays can be inuse.

As noted above , disparate storage arrays have differentinterfaces , which are used to perform storage operations.Different interfaces can include different naming proceduresfor commands, different syntaxes for the commands, and/ordifferent ordering for parameters that are passed to the 45commands. Typically, storage arrays provided by differentvendors will have disparate interfaces. However, in somecases , storage arrays provided by the same vendor can havedisparate interfaces , such as when different versions/releasesof one storage array is not compatible with another storagearray.

In the method 200, at 210, a plurality of storage resourceprovider modules 110 is provided for system 100. Eachstorage resource provider module 110 acts as an intermedi-ary on behalf of other applications in order to performstorage operations on a storage resource 140. The storageoperations are accessed by the other applications using aconsistent interface (e. , consistent calling syntax , namingstandard , and parameter passing order).

This consistent interface is used as a front-end interface for each of the storage resource provider modules 110 and isused for interactions between the other applications and thestorage resource provider modules 110. In this way, the otherapplications need not know the individual disparateinterfaces, which may be needed , to access disparate storageresources 140 within the architecture. Each storage resourceprovider module 110 also includes a unique back-end inter-

face used to directly communicate with a specific storageresource 140. The storage resource provider modules 110translate storage operations requested by the other applica-tions from the front-end interface to an appropriate back-endinterface in order to act as an intermediary to the storage

resources 140 on behalf of the other applications. One suchinterface is described in U.S. patent application Ser. No.10/175,029, which is incorporated by reference herein.At 220, storage management is stored within storage

10 management data store (DS) 130. DS 130 acts as a centraldata repository for all storage management data in thearchitecture. The storage resource provider modules 110 andother applications can access the DS 130 to acquire storagemanagement data (e. , storage configuration settings).Moreover, storage resource provider modules 110 canupdate storage management data in DS 130. In some casesthe other applications, can also update the storage manage-ment data in DS 130.

In one embodiment, DS 130 is available to storageresource provider modules 110 and the other applicationsover a data bus. Furthermore , DS 130 can be a singledatabase or a plurality of databases interfaced together. DS130 can be implemented in volatile storage , non-volatile

storage, or in a combination of volatile and non-volatile25 storages. Access to DS 130 can be

achieved with any

existing or custom-developed Application ProgrammingInterface (API) library. DS 130 maintains a consistent rep-resentation of the storage environment for system 100. Thisconsistent representation is embodied in the storage man-agement data.

Thus, at 230 , DS 130 is accessed to manage the storageenvironment. Please note , DS 130 and the storage manage-ment data can be used to interface the various applicationsthe storage resource provider modules 110 , and the storageresources 140. For example , if a first application wants toperform a first storage operation on a first storage resource140. , then the first application can access DS 110 providingDS 110 with the storage resource 140.1. DS 130 then

40 determines that the storage resource 140. 1 is associated witba first storage resource provider module 110. , and activatesa call to tbe first storage resource provider module 110.1 tointeract with the first application and the first storageresource 140.1. The first storage resource provider module110.1 then translates the first storage operation by using itsfront-end and back-end interfaces into commands recog-nized by the first storage resource 140. 1. The first storageresource 140.1 processes tbe commands, and the updatedstorage management data is provided to DS 130. The first

50 application can then obtain the updated storage managementdata from DS 130. In this way, DS 130 and the storagemanagement data are used to interface the various compo-nents of the storage architecture (e. , the applications, tbestorage resource provider modules, and the storage

55 resources).In one embodiment, this is achieved by representing tbe

storage resources 140 as storage objects having public andprivate accessible methods. The storage objects can bearranged hierarchically and managed by DS 130. In this way,the DS 130 can use the storage resource s methods to resolveand bind the appropriate storage resource provider modules110 to the appropriate storage resources 140.

As one of ordinary skill in the art now appreciates , storagearchitectures can be provided by implementing method 200

65 where the architectures are more flexibly managed.Moreover, the architectures permit the integration of newapplications with minimal or no code changes required of

US 6,826 661 B2

Object Module (OM) architecture , where storage resources140 and/or elements residing in the storage environment arerepresented as objects having methods (e. , public and

private) to retrieve and update storage management data.The storage management application accesses OS 130

when receiving a request from the host application to accessa selected storage resource 140 residing within the storageenvironment. The OS 130 access results in the storagemanagement application being directed to an appropriate

10 storage rcsource provider module 110. In an embodiment , the OS 130 executes a method associated witbthe storage resource object in order to resolve the interfaceto use with the storage resource 140. The interface isprovided to the OS 130 as a dynamic pointer to a specificstorage resource provider module 110. 1. Thus , the storagemanagement application is indirectly assigned tbe specificstorage resource provider 110.1 to act on its bchalf whensatisfying the request from the host application. As oneskilled in the art readily recognizes, this permits storage

resources 140 to have interfaces dynamically addedmodified , and/or deleted , by having the OS 130 resolve theinterface pointer when access is requested of a storageresource object.

The assigned storage resource provider module 110.translates the request into formats , syntax , and commandsrecognized by the appropriate storage resource 140.1, andpermits the storage resource 140.1 to process the request. At340, storage management data associated with satisfying therequest is then updated in the OS 130 by the assigned storage

30 resource provider module 110.1. The updated storage man-

agement data is then available to the storage managementapplication to provide to the host application.

In some embodiments, the storage resource providermodules 110 also listen for events that occur within theirassigned storage resources 140. These events can be raisedwhen state changes occur within the storage resources 140signaling that the storage management data (e. , configu-ration settings) have been altered. When such events are

40 detected , the storage resource provider modules 110 canautomatically and dynamically update the correspondingstorage management data in the OS 130. In this way, the OS130 includes a timely and accurate representation of thestorage management data for the entire storage environment.

FIG. 4 illustrates a block diagram of another storagearchitecture system 400 , according to the present invention.The storage architecture system 400 includes a plurality ofstorage resources 410.1-410. , a plurality of storage

resource provider modules 430.1-430. , a storage manage-50 ment OS 450, and a calling application (CA) 460. Each of

the storage resources 410 includes interfaces (e. , com-mands and operations having specific calling syntaxesnaming standards, and parameter orders) that permit theprocessing of storage management operations thereon. A

55 number of the storage resource interfaces 410 are different.In other words , the calling syntaxes, naming standards forcommands, and/or parameter ordering for commands aredifferent for one storage resource 410. 1 and another storageresource 410.

Each storage resource provider module 430 communi-cates with a specific storage resource interface 410. Thestorage resource provider modules 430 act as intermediariesbetween the CA 460 and the storage resources 410. Thuswhen the CA 460 is requesting a storage management

65 operation a storage resource provider module 430 is called(directly or indirectly) to process the storage managementoperation on behalf of the CA 460. Results associated with

existing applications. Conventionally, the integration of newapplications required significant coding changes to existingapplications, since storage management data was not cen-trally accessible to the applications, and was thereforepassed and carried around in storage by each of the appli- 5

cations during processing. Furthermore , there is no require-ment with the present invention for operations to he pro-cessed synchronously since asynchronous operations arealso permissible. Additionally, OS 130 can include taskobjects that when acccssed provide the current state , status,or progress of a previously requested and/or pending opera-tions. Additionally, new provider modules 110 can bedynamically integrated and installed into OS 130 , therebyproviding (,,'ontinuity of service. Also , OS 130 can issuealerts to applications indicating when high priority changes to the storage environment have occurred.

FIG. 3 illustrates a flow diagram of another method 300for managing storage across system 100, according to the

present invention. At 310 , a storage management applicationis provided. The storage management application can be 20

, SAN manager, or other storage managementoperations, such as a snapshot operation , a mirror operationand the like.

At 312, the storage management application is interfacedto a host application. A host application can be any application that accesses storage located within a storage resource140. The storage management application interceptsaccesses destined for the storage resource 140 and fulfills theaccess requests on behalf of the host application. In this way,the storage management application can manage storagemore efficiently within a storage environment.

At 320 , storage resource provider modules 110 are asso-ciated with the storage management application. In oneembodiment, each storage resource provider module 110 interfaces with a distinct storage resource 140. All storageresource provider modules 110 include a consistent interface(e. , naming standard, calling syntax , parameter order, andthe like), which is presented to the storage managementapplication for use. This consistent interface is used by thestorage management application to request that storageoperations be performed on a storage resource 140. Therequested storage operations can originate from the host

application. Alternatively, the requested storage operationscan originate from the storage management application

, 45such as when the storage management application is per-forming scheduled operations or when the storage manage-ment application detects information in the storage environ-ment that warrants a request for a storage managementoperation.

At 330, a storage management OS 130 is created. OS 130is interfaced to the storage resource provider modules 110the storage application, and in some cases, the host appli-cation. In one embodiment, OS 130 is available via a databus to the storage management application and the storageresource provider modules 110. Further, OS 130 can residein a volatile storage , a non-volatile storage, and/or a com-bination of volatile and non-volatile storages.

At 332, storage management data (e. , configuration

settings and the like) associated with storage residing on storage resources 110 within the storage environment is

stored in OS 130. Access to the data is provided via anycommercially available API (in cases where the OS 130 is acommercially available OS 130), via any custom-developedAPI (in cases where the OS 130 is custom developed), viaany Command Line Interface (CLI), and/or via any protocol.Moreover, in one embodiment , OS 130 is accessible via an

US 6,826,661 B2

processing the storage management operation can beretrieved by the CA 460 from the OS 450, and stored by theappropriate storage resource provider modules 430 in the OS450.

The OS 450 includes storage management data (e. , 5

configuration settings or state information associated withthe storage resources 410. The OS 450 is used to store andretrieve storage management data and provides a centrallylocated repository for acquiring configuration and stateinformation about the storage envirooment. In the embodi-ment shown , OS 450 can be accessed over a network andprovides an API library permitting access to the OS 450from external applications (e. , the CA 460 or the storageresource provider modules 430).

The CA 460 can also , in some embodimems, acquire 15storage managemcnt data directly from the OS 450. The CA460 can also use the OS 450 to determine the appropriatestorage resource provider module 430 that is to be used toprocess a storage management operation on an appropriatestorage resource 410. For example, the CA460 can query the 20OS 450 with a storage resource identifier to acquire adynamic pointer reference to an appropriate storage resourceprovider module 430.

Of course it is readily apparent to one of ordinary skill in

the art, that a variety of other techniques can be used toresolve which storage resource provider module 430 isappropriate for the CA 460 in any given circumstance. Forexample, the CA 460 can access methods of a storageresource object , where internally the storage resource object 30was instantiated and includes private methods to bind anappropriate storage resource provider module. All suchtechniques are intended to fall within the scope of the

present disclosure.

The CA 460 can be a storage management application or 35a host application. Moreover, the CA 460 is presented byeach of the storage resource provider modules 430 with aconsistent calling syntax to perform storage managementoperations. Each of the storage resource provider modules430 translates the consistent calling syntax into a specific 40

syntax recognized by their assigned storage resource inter-faces 410.

CONCLUSION

The metbods and systems discussed above permitimproved storage architectures. These architectures includestorage resource provider modules that act as gatekeepersfor storage resources in a storage environment. The storageresource provider modules also permit other applications toprocess storage management operations using a consistent 50calling syntax , naming standard , and parameter order. Eachstorage resource provider module communicates directlywith one of the storage resources. Moreover, the architec-tures include a storage management OS that centrally pro-vides storage management data (e. , configuration settings 55and state information) for all the storage resources. The OSis accessed and updated by the storage resource providermodules, and in some instances other applications process-ing within the storage envirooment.

AI; one of ordinary skill in the art now appreciates upon reading the present disclosure, the methods and systems

presented in this disclosure permit more flexible implemen-tations of storage management architectures that are easierto develop and maintain. Moreover, newly developed appli-cations can be more robust, since they can be integrated 65within the storage architecture independent of the codingdetails associated with other existing applications. The OS

of the present disclosure permits applications to operate

independent of one another, since the DS includes a con-sistent and stable representation of the storage environmentat any particular moment.

Although specific embodiments have been illustrated anddescribed herein , it will be appreciated by one of ordinaryskill in the art that any arrangement that is calculated toachieve the same purpose may be substituted for the specificembodiments shown. This application is intended to cover

10 any adaptations or variations of the present invention.Therefore , it is intended that this invention be limited onlyby the claims and the equivalents thereof.

What is claimed is:1. A storage management architecture system , compris-

Ing:a plurality of storage resources;

a plurality of storage resource provider modules; anda storage management data store having storage manage-

ment data;wherein each of the storage resource provider modules

interfaces with a different storage resource , and storesand retrieves storage management data to and from thedata store in order to maintain a consistent storage

environment representation in the data store.2. The storage management architecture of claim 1 further

comprising:a plurality of host applications and a storage management

application that receives storage management opera-tions from the plurality of host applications;

wherein the storage management application accesses thedata store to select the storage resource provider mod-ules that will process operations on behalf of the

storage management application.3. The storage management architecture system of claim

2 wherein a storage resource is dynamically bound to astorage resource provider module within the data store.

4. The storage management architecture system of claim, wherein a storage management application uses the stor-

age management data included in the data store to managea storage environment on behalf of the plurality of hostapplications , and wherein the storage management applica-tion uses the storage resource provider modules to indirectlyinterface with the storage resources.

5. The storage management architecture system of claim, wherein the storage resources include storage arrays and

45 wherein two or more of the storage arrays have disparateinterfaces from one another, where the interfaces are used toperform storage management operations on the storagearrays.

6. The storage management architecture system of claim, wherein the storage management data is used to make

decisions about storage management operations.7. The storage management architecture system of claim

, wherein the data store is a database having access andupdate methods, where a number of the methods are publiclyavailable for use and a number of the methods are privatehaving restricted use.

8. The storage management architecture system of claim, wherein the storage management data includes storage

configuration settings and states associated with the storageresources.

9. A storage management architecture system , compris-ing:

a plurality of storage resources, wherein each storage

resource includes an interface used to perform storagemanagement operations on the storage resourceswherein two or more of the interfaces are different fromone another;

US 6,826 661 B2

a plurality of storage resource provider modules , whereineach storage resource provider module communicateswith one of the interfaces; and

a storage management data store capable of storing stor-age management data associated with the storage man- 5agement operations;

wherein the storage resource provider modules act as anintermediary on behalf of a calling application wbenprocessing the storage management operations, and theprovider modules retrieve and store results associatedwith processing the storage management operations inthe data store.

10. The storage management architecture system of claim, wherein the calling application is at least one of a host

application and a storage management application.

11. The storage management architecture system of claim, wherein the calling application retrieves the storage

management data from the data store.12. The storage management architecture system claim 9,

wherein the storage resource provider modules access tbedata store is accessible over a network.

13. The storage management architecture system of claim, wberein the calling application requests one of the storage

management operations by calling a storage resource pro-vider module associated with a particular storage resource.10 14. The storage management architecture system of claim

, wherein tbe provider modules provide consistent callingsyntaxes to the calling application for requesting the storageoperations.

Documents

l~6 MICROSOFT CORPORATIONMicrosoft and Veritas dated August 19, 1996. Teaming up with Veritas and integrating the Volume Manager into Windows NT would serve as a testament by Microsoft