UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`World Programming Limited
`
`Petitioners
`
`v.
`
`SAS Institute, Inc.
`
`Patent Owner
`____________
`
`Case No. Unassigned
`Patent 7,447,686
`____________
`
`
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 7,447,686
`
`
`
`
`
`
`
`

`

`I. 
`
` 
`
` 
`
` 
`
` 
`
` 
`
`Petition for IPR of U.S. Patent 7,447,686
`
`TABLE OF CONTENTS
`INTRODUCTION ........................................................................................... 1 
`Summary of Unpatentability Grounds .................................................. 1 
`II.  MANDATORY NOTICES, STANDING, AND FEES .................................. 1 
`  Mandatory Notices ................................................................................ 1 
`Certification of Grounds for Standing ................................................... 2 
`Fees ........................................................................................................ 2 
`III.  OVERVIEW OF THE ’686 PATENT ............................................................ 2 
`Subject Matter of the ’686 Patent .......................................................... 2 
`The Priority Date of the Challenged Claims ......................................... 6 
`IV.  SUMMARY OF PRIOR ART ......................................................................... 6 
`Background ........................................................................................... 6 
`InterViso: Dealing with the Complexity of Federated Database
`Access by Marjorie Templeton et al. (“InterViso”) .............................. 9 
`Implementation of a Database Factory by Asokan R. Selvaraj et
`al. (“Selvaraj”) ..................................................................................... 12 
`CLAIM CONSTRUCTION .......................................................................... 20 
`Level of Ordinary Skill in the Art ....................................................... 21 
`VI.  THERE IS A REASONABLE LIKELIHOOD THAT THE CHALLENGED
`CLAIMS ARE UNPATENTABLE .............................................................. 21 
`  Ground 1: Claims 13-40, 43-45, and 50 are Obvious in Light of
`InterViso as modified by Selvaraj and in View of the
`Knowledge of a POSITA Under 35 U.S.C. § 103 .............................. 21 
`1.  Motivation to Modify InterViso with Selvaraj ......................... 21 
`
`V. 
`
` 
`
` 
`
` 
`
` 
`
`i
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`Claim 1 ...................................................................................... 25 
`2. 
`Claims 13-15 and 25-26 ............................................................ 51 
`3. 
`Claim 16-18 ............................................................................... 54 
`4. 
`Claim 19 .................................................................................... 55 
`5. 
`Claims 20-24 and 29 ................................................................. 57 
`6. 
`Claims 27-28 ............................................................................. 60 
`7. 
`Claims 30-32 ............................................................................. 61 
`8. 
`Claim 33 .................................................................................... 62 
`9. 
`10.  Claims 34 and 35....................................................................... 62 
`11.  Claims 36, 38-39 ....................................................................... 64 
`12.  Claims 37, 40 ............................................................................ 65 
`13.  Claim 43 .................................................................................... 67 
`14.  Claims 44-45 ............................................................................. 67 
`15.  Claim 50 .................................................................................... 70 
`VII.  CONCLUSION .............................................................................................. 70 
`
`
`ii
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`LIST OF EXHIBITS
`
`1001 U.S. Patent No. 7,447,686
`
`1002 CV of Dr. David Maier
`
`1003
`
`1004
`
`1005
`
`1006
`
`1007
`
`1008
`
`1009
`
`1010
`
`1011
`
`1012
`
`1013
`
`1014
`
`Expert Declaration of Dr. David Maier
`
`File History of the ’686 Patent
`
`IEEE 100: The Authoritative Dictionary of IEEE Standards Terms,
`(7th ed. 2000) (“IEEE Dictionary”)
`
`InterViso: Dealing with the Complexity of Federated Database
`Access, by Marjorie Templeton et al., VLDB Journal, Vol. 4, Issue 2
`(April 1995) (“InterViso”)
`
`SQL in a Nutshell: A Desktop Quick Reference, by Kevin Kline &
`Daniel T. Kline (1st ed. 2001) (“Nutshell”)
`
`Informix Guide to SQL: Tutorial, by Informix Press (2nd ed. 2000)
`(“Tutorial”)
`
`Transact-SQL Programming, by Kevin Kline et al. (1st ed. 1999)
`(“Transact”)
`
`SQL: The Complete Reference, by James R. Groff & Paul N.
`Weinberg (1st ed. 1999) (“Groff”)
`
`The C Programming Language, by Brian Kernighan & Dennis Ritchie
`(2nd ed. 1988) (“Ritchie”)
`
`Expert Declaration of Dr. Sylvia Hall-Ellis
`
`SunWorld Online - New Products, advertisement for InterViso 3.0
`(December 1995)
`
`Implementation of a Database Factory, by Asokan R. Selvaraj &
`Debasish Ghosh, ACM SIGPLAN Language Tips, Vol. 32, Issue 6
`(June 1997) (“Selvaraj”)
`
`
`
`i
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`I.
`
`INTRODUCTION
`Petitioners request inter partes review of claims 13-40, 43-45, and 50 of U.S.
`
`Patent No. 7,447,686 (“the ’686 Patent”).
`
`Petitioners assert that there is a reasonable likelihood that the challenged
`
`claims are unpatentable and request review of, and cancellation of, the challenged
`
`claims under 35 U.S.C. § 103.
`
`
`
`Summary of Unpatentability Grounds
`
`Ground
`1
`
`Summary
`Claims 13-40, 43-45, and 50 are obvious in view of InterViso,
`Selvaraj, and the knowledge of a POSITA.
`
`II. MANDATORY NOTICES, STANDING, AND FEES
` Mandatory Notices
`Real Party-in-Interest: The real parties-in-interest are Petitioner World
`
`Programming Limited, Yum! Brands, Inc., Pizza Hut, Inc., Pizza Hut, LLC, and
`
`Angoss Software Corporation.
`
`Related Matters: The ’686 Patent is subject to a pending lawsuit entitled SAS
`
`Institute Inc. v. World Programming Limited et al., Case No. 2:18-cv-00295-JRG
`
`(E.D. Tex.) (the “Litigation”) in which Petitioner is the defendant. In addition, on
`
`the same day this Petition was filed, Petitioner concurrently filed one other Petition
`
`relating to the ’686 Patent.
`
`1
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`Lead Counsel: Lead Counsel is Christopher V. Ryan, Reg. No. 54,759 of
`
`Baker Botts L.L.P., and Back-up Counsel is Brian W. Oaks, Reg. No. 44,981 of
`
`Baker Botts L.L.P.
`
`Service Information: Baker Botts L.L.P., 98 San Jacinto Boulevard, Suite
`
`1500, Austin, Texas 78701-4078; Tel. (512) 322-2500; Fax (512) 322-2501.
`
`Petitioners consent to service by electronic mail at WPL_IPR@bakerbotts.com. A
`
`Power of Attorney is filed concurrently herewith under 37 C.F.R. § 42.10(b).
`
` Certification of Grounds for Standing
`Petitioners certify that the ’686 Patent is available for IPR. Petitioners are not
`
`barred or estopped from requesting IPR of the ’686 Patent.
`
`
`Fees
`The Office is authorized to charge any fees that become due in connection
`
`with this Petition to Deposit Account No. 02-0384.
`
`III. OVERVIEW OF THE ’686 PATENT
`
`Subject Matter of the ’686 Patent
`The ’686 patent describes translating a database query statement from the
`
`language format of one database system so that it is textualized (put into text) in the
`
`format of a different system. Ex. 1001, Abstract; Ex. 1003, ¶¶92-98. The patent
`
`explains that many known vendor-specific dialects of SQL are not fully compatible.
`
`Ex. 1001, 1:13-20, 2:18-25, 2:49-53, Claims 15, 18, 26. The patent purports to solve
`
`the compatibility problem by “textualizing” a query received in one SQL dialect,
`2
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`into the format of another. 1:13-20. The “textualization process” for translating a
`
`statement is depicted in Fig. 2.
`
`
`
`2:18-25, Fig. 2.
`
`The process breaks a SQL statement and its related metadata into “logical
`
`pieces or components,” and parses into a SQL tree to represent the native syntax of
`
`the query. 3:1-15. Then, the process “utilizes database specific textualizations 52”
`
`(difference data) to translate the query into a third-party vendor-specific SQL query.
`
`2:18-25, 3:15-29. A modular system made up of components or software objects
`
`perform these textualizations, by rewriting the query in the format of the target
`
`database. 3:50-60. Fig. 3 below depicts the “object-oriented approach” of the
`
`3
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`preferred embodiment, in which component software objects associate with logical
`
`pieces of the query tree to perform textualizations.
`
`
`
`Fig. 3, 3:50-54. When there is no syntactic variation for a given part of the query,
`
`the textualization employs a base or native method, leaving query syntax unchanged.
`
`3:54-60. Where the syntax differs, software components employ database-specific
`
`textualization methods to translate query text into the database-specific format. 3:56-
`
`58; 4:12-15; 7:4-6; 7:48-52.
`
`The preferred embodiment describes components to address phrases,
`
`expressions, and identifiers in a query, to perform textualization, as shown in Fig. 5.
`
`4
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`
`
`Different types of components are identified by what they do. 4:19-25. For example,
`
`an expression component is an “abstract type of component” that may be used as the
`
`entry point to textualize all parts of the query, or to textualize specific functions
`
`within a phrase/clause, such as a “concatenation operation” or an “addition
`
`operation.” 5:37-47, 6:57-59, 6:26-37. “Phase components handle textualization of
`
`SQL statement clauses or phrases, such as WHERE clauses or FROM clauses found
`
`in SQL select statements.” 4:23-25, 5:61-63. Identifier components handle the
`
`textualization of “low-level ‘physical’ entities,” such as “table names, column
`
`names, literals, and aliases.” 4:51-57.
`
`These component software objects are the software routines that handle the
`
`textualization of all or part of a database statement. 3:15-18; 4:15-18. The specific
`
`types of components described in the preferred embodiments are not recited in claim
`
`5
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`1, the ‘686 patent’s only independent claim. 9:61-10:50. And the specification says
`
`“different component objects may be used instead of or in addition to” those
`
`described. 8:7-13. Indeed, the patent is not limited to the object-oriented approach,
`
`and says that its “textualization system may be implemented in many ways and
`
`through different types of programming languages.” 3:48-49.
`
`
`The Priority Date of the Challenged Claims
`The ’686 patent was filed as U.S. Patent Application No. 10/303,106 on Nov.
`
`22, 2002 and does not claim priority to any earlier application. Ex. 1004; Ex. 1003,
`
`¶99. Accordingly, Nov. 22, 2002 is the earliest priority date for all claims.
`
`IV. SUMMARY OF PRIOR ART
` Background
`A database is a collection of related data. Systems that access data in
`
`computerized databases often use a database management system (DBMS) to store
`
`and manipulate that data. Ex. 1010, 4-5. Databases may reside on a single computer
`
`or be distributed over a network. Id., 34-37. SQL is the computer language used to
`
`interact with a relational DBMS (RDBMS). Id., 4-5. In SQL, there are four primary
`
`“data manipulation” statements that may contain multiple clauses/phrases: SELECT,
`
`INSERT, DELETE, and UPDATE. Id., 68-69. Ex. 1003, ¶¶67-70.
`
`Conceptually, a relational database is a set of one or more tables, called
`
`relations, which are made up of one or more columns, called fields, with data stored
`
`6
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`in one or more rows, called records. Ex. 1003, ¶¶64-65; Ex. 1010, 53-54, 56-58.
`
`How a collection of database tables is defined (e.g. table names, column names, data
`
`types, etc.) is called a schema. Ex. 1003, ¶78; see also Ex. 1010, 402. Figure 2-1
`
`shows an example.
`
`Ex. 1010, 15.
`
`Applications typically access data by issuing commands to a DBMS. Ex.
`
`1003, ¶¶79-81; Ex. 1010, 4-5. In SQL, commands requesting data (queries) use a
`
`
`
`7
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`SELECT statement. Id., 4, 92. The syntax of a SQL query requesting a set of
`
`columns from a table is:
`
`SELECT {column(s)}
`
`FROM {table}
`
`Id., 92-94.1 The SELECT clause indicates which column(s) are desired. The FROM
`
`clause indicates which table contains the column(s). To narrow the results to rows
`
`meeting a search condition, the WHERE {condition} clause is added. Id., 92-94. Ex.
`
`1003, ¶¶72-75.
`
`As the ’686 patent admits, it was well-known that different database vendors
`
`used dialects of SQL having syntactical differences from one another. Ex. 1001,
`
`1:15-20; Ex. 1003, ¶¶71, 91. The patent cites as known examples, the differing
`
`syntax used for outer join and concatenation operations. 2:26-35, 4:46-47, 8:26-55.
`
`These, and many other syntactical differences between different vendor
`
`implementations of SQL were well-known. Ex. 1010, 32-33, 85-86, 174; Ex. 1007,
`
`6; Ex. 1003, ¶¶83-87.
`
`To accommodate these differences, it was known for database programs that
`
`connect to multiple different databases to “require a special adapter for each
`
`supported DBMS, which generates the appropriate SQL dialect.” Ex. 1010, 32-33.
`
`
`1
`Reserved SQL keywords in example queries are shown in bold herein.
`
`8
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`To that end, “virtually all programs that support multiple databases include specific
`
`‘drivers’ for communicating with each of the major DBMS brands.” Id., 34. See also
`
`Ex. 1003, ¶¶76-77. Allowing a database application to access different databases
`
`through a common interface simplified programming, and, prior art database
`
`integration products, such as the system disclosed in InterViso (discussed below),
`
`did just that. See id., ¶90.
`
`In addition to the background knowledge that a person of ordinary skill in the
`
`art (POSITA) would have brought to bear on the subject matter discussed in the ’686
`
`patent, the following prior art demonstrates that the subject matter of the challenged
`
`claims would have been known by or obvious to a POSITA.
`
`
`
`InterViso: Dealing with the Complexity of Federated Database
`Access by Marjorie Templeton et al. (“InterViso”)
`InterViso, a paper, discloses a modular architecture for a federated database
`
`system that provides a front-end platform for integrating many different local
`
`databases. Ex. 1006, 287-90; Ex. 1003, ¶¶111-22. InterViso was published in
`
`Volume 4, Issue 2 of the VLDB Journal, a date-stamped copy of which was available
`
`at the Gemmill Library of Engineering, Mathematics and Physics, at the University
`
`of Colorado in Boulder on or shortly after May 30, 1995. Ex. 1006; Ex. 1012, ¶¶40-
`
`50, attachments 1a-1j. It was indexed by subject matter and searchable at that library,
`
`and it was included in several well-known indices with keyword searching
`
`capabilities, including SCOPUS and ACM Digital Library. Id. It was cited in papers
`9
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`to Urhan and Amsaleg. Id. It was available as a printed publication more than one
`
`year before the earliest priority date of the ’686 patent. Id.
`
`Examples of InterViso’s local databases include Informix, Oracle, DB2,
`
`Sybase, Ingres and others as seen in Fig. 1 below. Ex. 1006, 290-91. The InterViso
`
`system masks database-specific identifiers, functions, and SQL command and
`
`phrase formats from the user, presenting instead a federated system that appears to
`
`users as a single database. Id., 287-88. Though the data actually resides in its local
`
`DBMSs, it appears to users or application programs to be structured according to a
`
`federated database schema. Id., 293. The mappings between federated and local
`
`tables, columns, and data types are stored in InterViso’s “data dictionary (DD/D).”
`
`Id., 291-92.
`
`
`
`10
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`InterViso supports its own dialect of the SQL query language that is based on
`
`the “ANSI SQL89” standard. Id., 311. Users and applications “express all queries in
`
`SQL against the federated schema.” Id., 308. Queries are processed by the InterViso
`
`Server’s “Optimizer Controller,” which routes queries, or parts of queries, to one or
`
`more local databases. Id., 290-91. Each local database has a driver (Database
`
`Management System Interface or DBMSI) that translates the query into the schema
`
`and the database-specific SQL of the local (target) databases that store the data. Id.,
`
`309-10. The DBMSI also “makes DBMS specific calls, and does local transaction
`
`management[]. Id., 292.
`
`The DBMSIs (drivers) are modular. Each “has several parts that are assembled
`
`into a module that is specific to a DBMS and operating system.” Id., 307. Those
`
`components include a Parser, a Schema Translator, and a Language Translator. Id.,
`
`307-08. The Parser “[r]eads text SQL commands and generates a parse tree.” Id.,
`
`307. The Schema Translator “[t]ransforms the parsed SQL query tree from federated
`
`to local form.” Id., 308. The Language Translator “[g]enerates a query in the local
`
`DBMS language from the query tree.” Id., 308. The DBMSI textualizes (puts into
`
`text form) translated queries to “issue[] queries to the DBMSs in their query
`
`language.” Id., 288.
`
`11
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`
`
`Implementation of a Database Factory by Asokan R. Selvaraj et al.
`(“Selvaraj”)
`Selvaraj, a paper, describes how to apply the Factory Method Pattern, an
`
`object-oriented technique for constructing objects with different implementations, to
`
`applications that interface with multiple different kinds of database systems. Ex.
`
`1014, 14-18; Ex. 1003, ¶¶123-41. Selvaraj was published in Volume 32, Issue 6 of
`
`the ACM SIGPLAN Notices, a date-stamped copy of which was available at the
`
`Gemmill Library of Engineering, Mathematics and Physics, at the University of
`
`Colorado in Boulder on or shortly after July 14, 1997. Ex. 1014; Ex. 1012, ¶¶85-94,
`
`attachments 5a-5e. It was indexed by subject matter and searchable at that library,
`
`and it was included in the ACM Digital Library index. Id. Selvaraj was available as
`
`a printed publication more than one year before the earliest priority date of the ’686
`
`patent. Id.
`
`In 2002, it was common to need different variations of a software application.
`
`Several approaches exist to allow different versions of an application share common
`
`parts of the implementation, while have other portions that are specialized. One is
`
`conditional compilation, which as discussed below was used in InterViso, and
`
`another is inheritance—a common object-oriented technique. Selvaraj shows how
`
`conditional compilation to handle software variation can be replaced with
`
`inheritance by using sub-type classes in an object-oriented implementation. Ex 1003,
`
`¶¶123-26. To do so, Selvaraj presents “an adaptation of the Factory Method Pattern
`12
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`and the Abstract Factory Pattern,” which are well-known approaches to designing
`
`object-oriented applications, “as a generic solution to the problem of de-coupling
`
`application code from the underlying database and its associated interface
`
`mechanisms.” Ex. 1014, 14-15.
`
`Selvaraj explains that the design of a typical application that interfaces to
`
`different database systems would use a utility class hierarchy. Id., 14. The hierarchy
`
`would typically be structured around those parts of the database interface that are
`
`common among different database products and to account for variability when
`
`different implementations of the classes may be required. The common parts of the
`
`implementation may be factored out as base (default) utility classes. To address
`
`differences between the databases, sub-type classes would supply database-specific
`
`functionality. Id.
`
`Selvaraj describes an example using a default class for database transactions
`
`that contains functionality that would be common to most databases. Id. However,
`
`modifications are required to accommodate database-specific differences. Using
`
`Oracle as an example,2 Selvaraj explains the class hierarchy would include a base
`
`
`2 Though Selvaraj describes the problem with reference to Oracle and Informix
`
`databases and an example class hierarchy, a POSITA would understand that the
`
`
`
`13
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`utility
`
`class
`
`(DbTransaction),
`
`seen
`
`below,
`
`and
`
`a
`
`sub-type
`
`class
`
`(DbOracleTransaction) that inherits common elements from the base utility class
`
`and provides the required database-specific overrides. Id., 14
`
`
`
`See id., 15 (left side of Fig. 1). Different versions of DbTransaction will then be
`
`created, depending on whether sub-type classes exist for a specific database vendor.
`
`Id., 14-15. Selvaraj notes that conditional compilation can be used to ensure use of
`
`sub-type classes needed for the interface to a particular database. Id.
`
`Selvaraj then explains, however, that the disadvantage of using conditional
`
`compilation “is the strong physical coupling between the application code and the
`
`database interface.” Id. As a result, a change in one sub-system, such as a change in
`
`behaviors of the database interface, will require the application to be recompiled and
`
`tested. Id. Because the code has to be separately compiled for each database system
`
`
`same approach may be used for any number of database vendors and with other
`
`class hierarchies. Ex. 1003, ¶¶138-42.
`
`14
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`that the application must work with, this could result in substantial time spent testing
`
`and recompiling. Id., 14-15. Ex. 1003, ¶¶128-31.
`
`Selvaraj presents the Factory Method Pattern as an alternative to conditional
`
`compilation. It is a well-known object-oriented design that employs what are known
`
`in the art as “factory methods” to create objects, whose types can be decided at
`
`runtime, rather than being statically linked at compile-time, as is done with
`
`conditional compilation. Id., ¶¶133-35, 139. By delegating the process of creating
`
`objects to a special method called the Factory Method, applications can leave
`
`responsibility for determining which sub-type classes are needed to the Factory
`
`Method. This spares the rest of the application the need to determine appropriate
`
`types whenever an object needs to be created from a utility class or one of its
`
`subclasses. Id.
`
`The left-hand portion of Selvaraj’s Figure 2, reproduced above, shows an example
`
`of an application using the getFactory() method to create a required database factory
`
`
`
`15
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`object. Ex. 1014, 16. That object (i.e. the factory object) then contains all of the
`
`appropriate methods (called make methods) to create the utility objects when
`
`required, either of a default class or including the overrides of a sub-type class,
`
`needed to interface with the database. Id., 15-16.
`
`By way of illustration, and using a simplified family of utility classes for
`
`performing database transactions and queries, Selvaraj explains that if an Informix
`
`database could use the default makeDbTransaction() method but needed to work
`
`with a database-specific makeDbQuery() method, a sub-type class with the override
`
`makeDbQuery() method would be used for Informix. That method would make a
`
`DbInfQuery utility object, rather than a default DbQuery utility object when the
`
`application invokes the factory object. Id., 18. Similarly, if the Oracle database
`
`needed a customized makeDbTransaction() method, a sub-type class with the
`
`override makeDbTransaction() method would be used
`
`to make
`
`a
`
`DbOracleTransaction utility object, rather than a default DbTransaction utility
`
`object. Id. These sub-type factory classes are highlighted at the bottom of the figure
`
`below. Ex. 1003, ¶¶136-38.
`
`16
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`
`
`The details of the database-specific specialization are implemented in these
`
`sub-type classes. When the factory object is returned to the application, it will
`
`contain the appropriate make methods for whichever database product the
`
`application is working with. The specific make methods in the factory object for a
`
`given database may then be invoked to create utility objects of the appropriate
`
`classes, making use of appropriate subclasses as needed, shown below. Ex. 1014,
`
`16; Ex. 1003, ¶¶137-39.
`
`17
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`
`
`The highlighting above shows that the when the factory object is created,
`
`DbInfFactory object inherits from the DbDefaultFactory class, and indirectly from
`
`the abstract DbFactory interface. Id. The makeDBQuery() method in the Informix-
`
`specific DbInfFactory class selectively overrides the default makeDbQuery()
`
`method in the DbDefaultFactory class. That override causes the Informix factory
`
`object to point to the makeDbQuery method whose code is implemented in the
`
`Informix sub-type class, rather than to the default method. Id., 16.
`
`Selvaraj’s Figure 2, as highlighted below, shows that using the Factory
`
`Method, an Application uses the getFactory() method in the DbFactoryUtils class to
`
`create a factory object for interfacing with the database it is using. Id.; Ex. 1003,
`
`¶¶140-41.
`
`18
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`
`
`“Assuming the system is configured to use Informix, this function will simply
`
`create a new DbInfFactory object and return it to the Application.” Ex. 1014, 15.
`
`The factory object can then be used to create utility objects of the appropriate type
`
`to interface with the Informix database, and the application is unaware that any
`
`specific sub-typing has occurred. Id., 15-18.
`
`On the other hand, if the Application needed an interface object for the Oracle
`
`database, rather than Informix, its call to the same getFactory() method would create
`
`
`
`19
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`a DbOracleFactory object, as shown below. The factory object can then be used to
`
`create utility objects of the appropriate type to interface with the Oracle database.
`
`
`
`This works because the getFactory() method creates a factory object for the
`
`appropriate DBMS. Ex. 1003, ¶141. That DBMS-specific factory object is aware of
`
`the different sub-type classes used with its database. Ex. 1014, 15. However, “[t]he
`
`Application is unaware of the exact sub-type of the DbFactory object that it receives
`
`(nor does it care) and manipulates the returned object only through the DbFactory
`
`abstract interface.” Id. Thus, the implementation details used by the sub-type
`
`methods are hidden from the Application.
`
`V. CLAIM CONSTRUCTION
`
`In an IPR, claims are “construed using the same claim construction standard
`
`that would be used to construe the claim in a civil action under 35 U.S.C. [§] 282(b).”
`
`37 C.F.R. § 42.100(b); Phillips v. AWH Corp., 415 F.3d 1303, 1312-13, 1317 (Fed.
`
`20
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`Cir. 2005) (en banc). The claim terms should be given their plain and ordinary
`
`meanings in light of the specification and prosecution history.
`
` Level of Ordinary Skill in the Art
`A person of ordinary skill in the art (“POSITA”) at the time the ’686 patent
`
`was filed (Nov. 22, 2002) would have had at least an undergraduate degree or
`
`equivalent in computer science. Ex. 1002; Ex. 1003, ¶¶61-62. The POSITA would
`
`also have two to three years of engineering, research, or development experience
`
`related to database systems. Id. A person with less education, but more relevant
`
`practical experience, also meets the definition. Id.
`
`VI. THERE
`IS A REASONABLE LIKELIHOOD THAT THE
`CHALLENGED CLAIMS ARE UNPATENTABLE
` Ground 1: Claims 13-40, 43-45, and 50 are Obvious in Light of
`InterViso as modified by Selvaraj and in View of the Knowledge of
`a POSITA Under 35 U.S.C. § 103
`1. Motivation to Modify InterViso with Selvaraj
`InterViso describes a system that worked with many SQL databases from
`
`Oracle, Sybase, Informix, and others. Ex. 1006, 287, 290-91. InterViso explains that
`
`“each one” of its local RDBMSs that support SQL “has some differences in syntax
`
`or functionality.” Id., 308-09. Each of InterViso’s DBMSIs are drivers tailored to a
`
`specific local RDBMS that “it controls.” Ex. 1006, 290-92, 308-09. In particular,
`
`each DBMSI includes a Language Translator module that uses conditional
`
`compilation to address “variants of SQL” syntax amongst the RDBMSs. Id. For the
`
`21
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`reasons described in Selvaraj, a POSITA would have been motivated to modify the
`
`InterViso Language Translator module, so that it made use of the factory method to
`
`create objects from database-specific subtype classes, rather than conditional
`
`compilation, to address variations in SQL syntax between InterViso and its local
`
`databases.
`
`Like in Selvaraj, the DBMSIs of InterViso interface to many different
`
`database systems. Although each RDBMS supports SQL, “each one has some
`
`differences in syntax or functionality” that a specially-compiled Language
`
`Translator module accommodates. Id. InterViso explains that the Language
`
`Translator module was designed to adapt to changes in the SQL standard, but it faced
`
`challenges due to the need to recompile and retest the InterViso DBMSI. Ex. 1006,
`
`313-15; Ex. 1003, ¶¶145-48. Selvaraj explains that these problems are caused by the
`
`dependencies created when conditional compilation of the system is used to address
`
`variations between databases. Id.; Ex. 1014, 14-15.
`
`Selvaraj provides a solution. As discussed in Section IV.C, Selvaraj explains
`
`that de-coupling application code from the underlying database and its interface
`
`mechanisms avoids the need to recompile and retest the software to accommodate
`
`changes in the interface. Id. To achieve this decoupling, Selvaraj advocates using
`
`the factory method with a hierarchy of utility classes, rather than conditional
`
`compilation, to implement database-specific specializations. Id. Using the Factory
`
`22
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`Method “to de-couple different parts of a system promotes much easier evolution of
`
`software.” Id., 16. Selvaraj’s technique allows the same application to interface with
`
`different databases. Applying it to InterViso’s Language Translator would eliminate
`
`the need to track and deploy different versions in each DBMSI. Ex. 1003, ¶¶146-49.
`
`Thus, a POSITA would have been motivated to replace InterViso’s conditionally-
`
`compiled Language Translator with one that applied Selvaraj’s factory method, to
`
`invoke appropriate sub-type methods in the component objects that address
`
`variations in SQL syntax. Ex. 1003, ¶149; See KSR Int’l Co. v. Teleflex Inc., 550
`
`U.S. 398, 418-20 (2007) (explaining that a teaching, suggestion, or motivation to
`
`combine is one way to show obviousness).
`
`Selvaraj explains, and a POSITA would understand, the different tasks that
`
`the program needs to perform to interface with a database should be separated into
`
`a hierarchy of different utility classes responsible for those tasks. Ex. 1003, ¶150;
`
`Ex. 1014, 14. “Once this set of classes and their responsibilities are established, these
`
`classes can be specialized differently to work with different database products” using
`
`sub-type classes to provide database-specific implementations as needed. Id. In
`
`InterViso, the different tasks that the compiled Language Translator performs relate
`
`to textualizing the different elements of the SQL syntax (represented in the parse
`
`tree) to generate a translated SQL statement. Ex. 1006, 308-09. It would have thus
`
`been obvious to a POSITA in light of Selvaraj to establish a set of utility classes in
`
`23
`
`

`

`Petition for IPR of U.S. Patent 7,447,686
`
`InterViso responsible for textualizing the different elements of SQL syntax, which
`
`are defined by SQL grammar. Ex. 1003, ¶¶150-52. As explained below for limitation
`
`1[f], it would have been obvious in view of Selvaraj’s guidance, to organize the
`
`classes of InterViso’s Language Translator