`
`Filed on behalf of Petitioner
`By: Richard F. Giunta
`
`Elisabeth H. Hunt
`
`Randy J. Pritzker
`
`WOLF, GREENFIELD & SACKS, P.C.
`
`600 Atlantic Avenue
`
`Boston, MA 02210
`
`Tel: (617) 646-8000
`
`Fax: (617) 646-8646
`
`RGiunta-PTAB@wolfgreenfield.com
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________
`
`RPX Corporation
`Petitioner
`
`v.
`
`Applications in Internet Time, LLC
`Patent Owner
`_____________
`
`Case No. TBD
`Patent No. 7,356,482
`_____________
`
`DECLARATION OF MARK E. CROVELLA, PH.D.
`
`
`RPX Exhibit 1002
`RPX v. AIT
`
`
`
`
`
`
`
`
`
`
`
`
`
`TABLE OF CONTENTS
`
`TABLE OF CONTENTS
`
`I.
`
`I.
`
`PERSONAL AND PROFESSIONAL BACKGROUND ................................. 1
`
`PERSONAL AND PROFESSIONAL BACKGROUND ............................... ..1
`
`II. MATERIALS REVIEWED AND CONSIDERED .......................................... 3
`
`II. MATERIALS REVIEWED AND CONSIDERED ........................................ ..3
`
`III. LEVEL OF ORDINARY SKILL IN THE ART ............................................... 4
`
`III. LEVEL OF ORDINARY SKILL IN THE ART ............................................. ..4
`
`IV. THE BASICS OF MULTI—LAYERED APPLICATION
`
`IV. THE BASICS OF MULTI-LAYERED APPLICATION
`DEVELOPMENT .............................................................................................. 6
`
`DEVELOPMENT ............................................................................................ ..6
`
`V. SUMMARY OF THE ‘482 PATENT CLAIMS ............................................... 9
`
`SUMMARY OF THE ‘482 PATENT CLAIMS ............................................. ..9
`
`V.
`
`VI. CLAIMS 1-59 ARE UNPATENTABLE IN LIGHT OF THE PRIOR
`
`VI. CLAIMS 1-59 ARE UNPATENTABLE IN LIGHT OF THE PRIOR
`ART IDENTIFIED IN RPX’S PETITIONS ................................................... 16
`
`ART IDENTIFIED IN RPX’S PETITIONS ................................................. ..16
`
`A. Popp Discloses Each Limitation of Claims 1, 2, 7-13, 18-22, 27-33,
`A. Popp Discloses Each Limitation of Claims 1, 2, 7-13, 18-22, 27-33,
`38-42, 47-52, and 57-59 of the ‘482 Patent ............................................... 17
`38-42, 47-52, and 57-59 of the ‘482 Patent ............................................. ..17
`
`B. Kovacevic Discloses Each Limitation of Claims 1, 8, 10, 19-21, 28,
`B. Kovacevic Discloses Each Limitation of Claims 1, 8, 10, 19-21, 28,
`30, 39-41, 47, 49, 58 and 59 of the ‘482 Patent ........................................ 48
`30, 39-41, 47, 49, 58 and 59 of the ‘482 Patent ...................................... ..48
`
`C. Balderrama and Java Complete Render Claims 1, 2, 7-12, 19-22,
`C. Balderrama and Java Complete Render Claims 1, 2, 7-12, 19-22,
`27-32, 39-42, 47-51, 58 and 59 of the ‘482 Patent Obvious ..................... 66
`27-32, 39-42, 47-51, 58 and 59 of the ‘482 Patent Obvious ................... ..66
`
`D. Popp and Codd Render Claims 3-6, 23-26, and 43-46 of the ‘482
`D. Popp and Codd Render Claims 3-6, 23-26, and 43-46 of the ‘482
`Patent Obvious ........................................................................................... 97
`Patent Obvious ......................................................................................... ..97
`
`E. Kovacevic and Codd Render Claims 3-6, 23-26, and 43-46 of the
`E. Kovacevic and Codd Render Claims 3-6, 23-26, and 43-46 of the
`‘482 Patent Obvious ................................................................................106
`‘482 Patent Obvious .............................................................................. ..106
`
`F. Balderrama, Java Complete, and Codd Render Claims 3-6, 23-26,
`F. Balderrama, Java Complete, and Codd Render Claims 3-6, 23-26,
`and 43-46 of the ‘482 Patent Obvious .....................................................110
`and 43-46 of the ‘482 Patent Obvious ................................................... ..11O
`
`G. Popp and Anand Render Claims 13-17, 33-37, and 52-56 of the
`G. Popp and Anand Render Claims 13-17, 33-37, and 52-56 of the
`‘482 Patent Obvious ................................................................................115
`‘482 Patent Obvious .............................................................................. ..115
`
`VII. SIGNATURE .................................................................................................122
`
`VII. SIGNATURE ............................................................................................... ..122
`
`APPENDIX ............................................................................... ..123
`
`APPENDIX……………………………………………………………………...123
`
`
`
`
`i
`
`
`
`
`
`I, Mark E. Crovella, Ph.D., declare:
`
`1.
`
`I have been retained by Petitioner RPX Corporation (“RPX”), to
`
`assess U.S. Patent No. 7,356,482 (“the ’482 patent). I am being compensated for
`
`my time at a rate of $450 per hour, plus actual expenses. My compensation is not
`
`dependent in any way upon the outcome of RPX’s petitions. I understand that this
`
`Declaration is being submitted in connection with two petitions regarding the same
`
`‘482 patent, and that while many of the exhibits to both petitions are the same, they
`
`are required to have different numbering. Therefore, when I cite to an exhibit in
`
`this Declaration, I provide both of the exhibit’s numbers, one for each petition. For
`
`example, the ‘482 patent is Ex. 1001 in one petition and Ex. 1101 in the other
`
`petition; I therefore cite it as “Ex. 1001/1101”.
`
`I.
`
`PERSONAL AND PROFESSIONAL BACKGROUND
`2.
`
`I am Professor and Chair of the Department of Computer Science at
`
`Boston University. I received an undergraduate degree in Biology from Cornell
`
`University in 1982. I received a master’s degree in Computer Science from the
`
`University of Buffalo in 1989. I received a Ph.D. in Computer Science from the
`
`University of Rochester in 1994. The subject of my Ph.D. thesis was
`
`“Performance Prediction and Tuning of Parallel Programs.”
`
`3.
`
`From 1982 to 1984 I worked as a computer programmer for the State
`
`of Colorado. From 1984 to 1994 I was employed at Calspan Corporation, a
`
`1
`
`
`
`
`
`research and development firm in Buffalo, NY, where I rose to the level of Senior
`
`Computer Scientist. My work at Calspan focused on development of experimental
`
`software and large-scale simulation software in support of contracts between
`
`Calspan and the U.S. Department of Defense.
`
`4.
`
`In 1994, I joined the faculty of Boston University as an Assistant
`
`Professor of Computer Science. I was promoted to the rank of Associate Professor
`
`in 2000 and became a full Professor in 2006. Since 2013, I have served as Chair of
`
`the Department of Computer Science.
`
`5.
`
`I am well versed in application development architectures for client-
`
`server computing systems. For example, I developed large-scale client-server
`
`software for simulating radar systems in my position at Calspan, and I developed
`
`client-server applications for financial management in my position at the State of
`
`Colorado.
`
`6. My detailed employment background, professional experience, and
`
`list of technical papers and books are contained in my CV. (Ex. 1003/1103).
`
`7.
`
`Prior to reviewing the ‘482 patent, I was well familiar with the subject
`
`matter described and claimed in the ‘482 patent. The ‘482 patent concerns systems
`
`and methods for “dynamically generating an application.” (Ex. 1001/1101 at
`
`33:34, 34:54.) All of the ‘482 patent claims require generation of an application
`
`and/or its user interface (UI) using a multi-layered architecture. I am an expert in
`
`2
`
`
`
`
`
`the field of computer application development, including in multi-layered
`
`architectures for application UI generation.
`
`II. MATERIALS REVIEWED AND CONSIDERED
`8.
`
`In connection with my work on this matter, I have reviewed the ‘482
`
`patent (Ex. 1001/1101) as well as the other following documents:
`
`EXHIBIT
`
`DESCRIPTION
`
`1001/1101 U.S. Patent No. 7,356,482 (“the ‘482 patent”)
`
`1010/1110 Glenn E. Krasner and Stephen T. Pope, A Description of the Model-
`
`View-Controller User Interface Paradigm in the Smalltalk-80 System,
`
`ParcPlace Systems, 1988 (“Krasner”)
`
`1004/1104 U.S. Patent No. 6,249,291 (“Popp”)
`
`1005/1105 Srdjan Kovacevic, Flexible, Dynamic User Interfaces for Web-
`
`Delivered Training, Proceedings of the Workshop on Advanced
`
`Visual Interfaces, 1996 (“Kovacevic”)
`
`1006/1106 U.S. Patent No. 5,806,071 (“Balderrama”)
`
`1007/1107 Java Complete!, Datamation, March 1, 1996, pp. 28-49 (“Java
`
`Complete”)
`
`1008/1108 E. F. Codd, Does your DBMS run by the rules?, ComputerWorld,
`
`October 21, 1985, pp. 49-60 (“Codd”)
`
`1009/1109 U.S. Patent No. 5,710,900 (“Anand”)
`
`3
`
`
`
`
`
`1011/1111 Webster’s New World Dictionary of Computer Terms, 6th Edition
`
`(1997), p. 30 (definition of “application”), p. 274 (definition of “Java
`
`applet”)
`
`1012/1112 Barron’s Dictionary of Computer and Internet Terms, 6th Edition
`
`(1998), p. 22 (definition of “application,” “application program”), p.
`
`371 (definition of “program”)
`
`
`III. LEVEL OF ORDINARY SKILL IN THE ART
`9.
`
`For purposes of assessing whether prior art references disclose every
`
`element of a patent claim (thus “anticipating” the claim) and/or would have
`
`rendered the claimed invention obvious, I understand that the ‘482 patent and the
`
`prior art references must be assessed from the perspective of a person having
`
`ordinary skill in the art (“POSA”) to which the patent is related, based on the
`
`understanding of that person at the time of the invention date. I understand that a
`
`POSA is presumed to be aware of all pertinent prior art and the conventional
`
`wisdom in the art, and is a person having ordinary creativity. I have applied this
`
`standard throughout my declaration.
`
`10.
`
`I have been asked to provide my opinion as to the state of the art in
`
`the field of computer application development in the 1998 timeframe. I use the
`
`1998 timeframe because the ‘482 patent includes a certificate of correction with a
`
`priority claim describing the ‘482 patent as a continuation of an application filed in
`
`4
`
`
`
`
`
`December of 1998. Whenever I offer an opinion below about the knowledge of a
`
`POSA, the manner in which a POSA would have understood the claims of the ‘482
`
`patent, the manner in which a POSA would have understood the prior art, or what a
`
`POSA would have been led to do based on the prior art, I am referencing this
`
`timeframe (i.e., 1998). When I offer an opinion or explanation below about the
`
`teachings of the prior art and/or the claims of the ‘482 patent, I am explaining how
`
`the issue would have been viewed by a POSA in the 1998 timeframe, even if I do
`
`not say so specifically in each case. In my opinion, a POSA related to the ‘482
`
`patent in the 1998 timeframe would have had at least a B.S. in Computer Science
`
`or the equivalent, along with at least two years of computer programming
`
`experience in developing applications for client-server systems. This person would
`
`have been capable of understanding and applying the prior art references discussed
`
`herein.
`
`11. By 1998, I was an Assistant Professor of Computer Science, and I had
`
`over 15 years of computer programming experience on client-server systems,
`
`including application development in industry. Therefore, I was a person of more
`
`than ordinary skill in the art during the relevant time period. However, I worked
`
`with many people who fit the characteristics of the POSA, and I am familiar with
`
`their level of skill. When developing the opinions set forth below, I assumed the
`
`perspective of a person having ordinary skill in the art, as set forth above.
`
`5
`
`
`
`
`
`IV. THE BASICS OF MULTI-LAYERED APPLICATION
`DEVELOPMENT
`12. All of the independent claims of the ‘482 patent relate to the
`
`generation of an application using a system with information about unique aspects
`
`of the particular application in a first layer and information about the user interface
`
`and functions common to a variety of applications in a second layer. A third layer
`
`retrieves the data in the first and second layers in order to generate the
`
`functionality and user interface elements of the application. As discussed further
`
`below, all of this was well known, e.g., from the classic model-view-controller
`
`(MVC) architectural pattern for implementing UIs, at least a decade before the
`
`‘482 patent’s filing date.
`
`13. The MVC concept was developed in the 1970s and 1980s as a way of
`
`compartmentalizing the software for implementing applications with UIs, such that
`
`pieces of code could be reused across applications. Krasner (Ex. 1010/1110)1 is an
`
`early paper discussing the MVC paradigm and its use in Smalltalk-80, the
`
`programming system through which MVC was first developed. (Abstract.) The
`
`“model” layer in the MVC architecture is the application-specific part of the
`
`software, which defines the unique behavior of a particular application and stores
`
`its application-specific data. (p. 3, para. 3.) The “view” layer contains design
`
`elements, such as graphical components, that are generic to multiple applications
`
`1 Unless otherwise indicated, all citations in Section IV are to Ex. 1010/1110.
`
`6
`
`
`
`
`
`and thus can be reused across applications. (p. 3, para. 4.) The same view
`
`components can be used with multiple different models so that UI elements such as
`
`buttons and input fields need not be coded from scratch for every individual
`
`application, and the same model can be implemented with multiple different views
`
`to create different presentation styles for the same application. (p. 2, para. 4; p. 3,
`
`para. 2.) The “controller” layer creates the interface with the user in conjunction
`
`with the model and the view. (p. 3, para. 5.)
`
`14. The figure below illustrates how particular applications are generated
`
`from application-specific and application-generic (shared) layers:
`
`15. The classic MVC framework also typically incorporates change
`
`notification, so that user input that changes the view propagates to corresponding
`
`
`
`7
`
`
`
`
`
`updates to the model data, and changes to the model state cause corresponding
`
`updates to the view display. (p. 4, paras. 2-4; FIG. 1.) When a user takes an input
`
`action that causes a change that affects the application (e.g., by changing model
`
`data as presented in a view), one or more software components detect the change
`
`and notify model and/or view objects in the application that depend on the changed
`
`data (dependent objects) to update themselves accordingly. (p. 4, para. 3.) These
`
`software components function as a change management layer, often referred to as
`
`an “observer” layer in MVC.
`
`16. Today, MVC is a central design pattern for applications (“apps”)
`
`developed for mobile operating systems. The separation between app-specific
`
`model-layer objects and app-generic view-layer objects allows for generic UI
`
`elements (e.g., buttons, text fields, swipe-able elements, etc.) to be provided in
`
`toolkits that can be reused and shared by developers across apps. As a result, app
`
`developers need not code every UI element individually from scratch, but instead
`
`can leverage a generic pool of UI elements, and can rely on those generic elements
`
`to give their apps a consistent look-and-feel with other apps developed for the
`
`same operating system.
`
`17. As a Professor at Boston University, I have developed and regularly
`
`taught a course on the subject of mobile application development, a key aspect of
`
`which is teaching students how to design UI-driven applications. MVC is the first
`
`8
`
`
`
`
`
`design pattern that I introduce in the course, as it is classic and ubiquitous in
`
`modern interactive applications. As discussed below, the claims of the ‘482 patent
`
`largely correspond to the MVC architecture, which was well known to those of
`
`skill in the art before the ‘482 patent was filed. Each of the three primary prior art
`
`references discussed below (i.e., Popp, Kovacevic, and Balderrama) provides an
`
`example of a use of the basic MVC design pattern before the ‘482 patent’s priority
`
`date.
`
`V.
`
`SUMMARY OF THE ‘482 PATENT CLAIMS
`18. The ‘482 patent (Ex. 1001/1101)2 describes and claims a
`
`straightforward form of multi-layered application development architecture as
`
`described in Section IV above. I understand that each claim must be evaluated
`
`individually on its merits, and I have done so below. The ‘482 patent includes
`
`independent claims 1, 21 and 41. Claim 1 is reproduced below. The bracketed
`
`letters are added for purposes of cross reference.
`
`A system for providing a dynamically generated application having
`one or more functions and one or more user interface elements;
`comprising:
`[A] a server computer;
`[B] one or more client computers connected to the server
`computer over a computer network;
`
`
`2 Unless otherwise indicated, all citations in Section V are to Ex. 1001/1101.
`
`9
`
`
`
`
`
`[C] a first layer associated with the server computer containing
`information about the unique aspects of a particular application;
`[D1] a second layer associated with the server computer
`containing information about the user interface and functions
`common to a variety of applications, [D2] a particular
`application being generated based on the data in both the first
`and second layers;
`[E] a third layer associated with the server computer that
`retrieves the data in the first and second layers in order to
`generate the functionality and user interface elements of the
`application; and
`[F] a change management layer for automatically detecting
`changes that affect an application,
`[G1] each client computer further comprising a browser
`application being executed by each client computer, [G2]
`wherein a user interface and functionality for the particular
`application is distributed to the browser application and
`dynamically generated when the client computer connects to the
`server computer.
`
`19. Elements A, B, G1 and G2 recite a typical client-server system in
`
`which client computers access and utilize functionality provided by a server
`
`computer over a network. Client-server systems had long been in use for accessing
`
`application UIs and functionality by 1998, and it was commonplace for the server
`
`computer to distribute the application’s UI and functionality to a browser
`
`application executed by the client computer. See, e.g., Ex. 1007/1107 at 30-31, 40
`
`10
`
`
`
`
`
`and 42-43, which describes the use of Java applets in client-server systems in 1996
`
`(Id. at 40) to deliver UI functionality such as petty cash request forms (Id. at 31)
`
`and order entry systems (Id. at 42) from a server to a web browser on a client
`
`workstation (Id.). A Java applet, for example, is a small program that is
`
`downloaded when the client computer connects to the server computer, and is then
`
`executed by the client computer’s browser application to dynamically generate the
`
`UI and functionality for the application encoded in the applet. (Id.) As explained
`
`in ¶ 21 below, other examples of applications, common by 1998, that are
`
`dynamically generated by downloading and executing a program in a browser
`
`application include HTML Web pages. (Id.)
`
`20. Elements C, D1, D2, E, and F recite typical components of a multi-
`
`layered application development architecture, such as the classic model-view-
`
`controller (MVC) architecture described in Section IV above. Element C (the
`
`“first layer”) contains “information about the unique aspects of a particular
`
`application,” and corresponds to the application-specific “model” component of
`
`the MVC architecture. Element D1 (the “second layer”) contains “information
`
`about the user interface and functions common to a variety of applications,” and
`
`corresponds to the reusable-across-applications “view” component of the MVC
`
`architecture. Element E (the “third layer”) corresponds to the controller
`
`component; and Element D2 (together with Element E) recites how an application
`
`11
`
`
`
`
`
`is generated based on these layers. Element F corresponds to the change
`
`management and notification layer of the MVC architecture.
`
`21. A POSA would have understood that an “application” was a program
`
`executable by a computer to do something useful other than maintaining the
`
`computer itself. See, e.g., the definitions of “application” in the 1997 edition of
`
`Webster’s New World Dictionary of Computer Terms (Ex. 1011/1111, p. 30) (“A
`
`program that enables you to do something useful with the computer, such as
`
`writing or accounting (as opposed to utilities, programs that help you maintain the
`
`computer)”) and the 1998 edition of Barron’s Dictionary of Computer and Internet
`
`Terms (Ex. 1012/1112, p. 22) (“a computer program that performs useful work not
`
`related to the computer itself. Examples include word processors, spreadsheets,
`
`accounting systems, and engineering programs. Contrast UTILITY; OPERATING
`
`SYSTEM.”). As another example, a web page (e.g., encoded in HTML or Java)
`
`meets these definitions and is an example of an application.
`
`22. The term “layer” is not defined in the ‘482 patent. I understand that
`
`the standard for claim interpretation in inter partes review proceedings is the
`
`broadest reasonable interpretation (“BRI”) consistent with the specification, and
`
`that the BRI for a term like “layer” that is not defined in the specification is the
`
`plain and ordinary meaning of the term. I also understand that the Patent Owner
`
`12
`
`
`
`
`
`has suggested in another proceeding3 that a “layer” is “one or more functionally or
`
`logically related software components.” This interpretation is reasonable in view
`
`of how the term would have been ordinarily and customarily understood by a
`
`POSA. It is also consistent with the specification (e.g., 9:33-48; 12:13-16:65)
`
`which discusses layers that are functionally or logically related software
`
`components. I have therefore applied this interpretation in analyzing the claims
`
`herein.
`
`23. Element F recites “a change management layer for automatically
`
`detecting changes that affect an application.” “Change management” and “change
`
`management layer” are not terms that would have had an established meaning to a
`
`POSA outside of their use in the ‘482 patent. Therefore, I look to the specification
`
`of the ‘482 patent to provide context for how the terms should be interpreted. The
`
`description of the change management layer in the patent’s specification (16:17-
`
`46) provides examples of the functionality of detecting changes that affect an
`
`application, but does not define or further describe the term “change management
`
`layer” itself. A POSA therefore would have understood “change management” to
`
`be a mere label for this particular layer which is defined by the claim language
`
`itself. That is, the “change management layer” is a layer (one or more functionally
`
`
`3 CBM2014-00168
`
`13
`
`
`
`
`
`or logically related software components) for automatically detecting changes that
`
`affect an application.
`
`24. To summarize, I have applied the following claim constructions when
`
`analyzing the independent claims of the ‘482 patent:
`
`CLAIM TERM
`
`CONSTRUCTION
`
`“application”
`
`“a program executable by a computer to
`
`do something useful other than
`
`maintaining the computer itself”
`
`“layer”
`
`“one or more functionally or logically
`
`related software components”
`
`“change management layer for
`
`“a layer for automatically detecting
`
`automatically detecting changes that
`
`changes that affect an application”
`
`affect an application”
`
`
`
`25.
`
`In addition, the ‘482 patent specification contains explicit definitions
`
`of some terms recited in the claims, including the definitions reproduced below.
`
`For claim terms explicitly defined in the specification, I have applied the
`
`definitions when analyzing the corresponding claim(s).
`
`“A ‘database’ is a collection or group of objects that holds various
`related information items. This information is divided into tables,
`
`14
`
`
`
`
`
`views, columns and rows, and an object is identified by its name
`and/or icon in a database.” (29:50-54.)
`
`“A ‘table’ is a structure that holds data in a database, often as one or
`more two-dimensional structures divided into rows and columns. An
`example of a table is a spreadsheet. A table is often referred to as a
`physical file.” (29:55-58.)
`
`“A ‘view’ is an alternative representation of data in a table and may
`appear as one or more columns and/or one or more rows. The data
`attributes can change according to the format in which a view is
`presented. A view may be an overlay of a table structure but does not
`replace the table. A view is often referred to as a logical file.”
`(29:59-64.)
`
`“A ‘column’ is one or more vertically oriented parts of a (two-
`dimensional) Table and is identified by specifying specific
`information in a table. Each column will have one data type
`(character, decimal, hexadecimal, integer, alpha-numeric, etc.). A
`row-column intersection is often referred to as a field.” (30:7-12.)
`
`“A ‘row’ is one or more vertical parts of a Table and consists of a
`selected sequence of values drawn from one or more columns – one
`value for each column. Row entries are actual data in a table. A row
`is often referred to as a record.” (30:15-18.)
`
`“An ‘intelligent agent’ is a specialized program that makes decisions
`and performs tasks based on predefined rules and objectives.” (20:1-
`3.)
`
`15
`
`
`
`
`
`“An ‘intelligent agent’ is a specialized program that resides on a
`network, or at a server as an applet, and can make decisions and
`perform tasks based on pre-defined rules.” (10:42-45.)
`
`“A ‘trigger event’ is an action performed by a user of the system that
`initiates another action or set of actions.” (30: 35-36.)
`
`“A ‘query’ is a request to select, format and process/analyze one or
`more rows of data in a table and can operate on one or more tables. A
`query must specify (1) where the requested data are stored, (2) what
`are the common elements, if any, of the tables and/or views to be
`searched, (3) what data item(s) (usually, one or more columns) the
`user wishes to select, and (4) what criteria are applied to a data item.
`A query provides reporting Capability and processing/data analysis
`capability, using spreadsheets and other tools.” (30:19-27.)
`
`VI. CLAIMS 1-59 ARE UNPATENTABLE IN LIGHT OF THE PRIOR
`ART IDENTIFIED IN RPX’S PETITIONS
`26.
`
`I have been asked to provide my opinion concerning whether claims
`
`1-59 of the ‘482 patent are unpatentable based on the prior art references identified
`
`in RPX’s petitions. The prior art references I reviewed include:
`
`EXHIBIT
`
`PRIOR ART REFERENCE
`
`1004/1104 U.S. Patent No. 6,249,291 (“Popp”)
`
`1005/1105 Srdjan Kovacevic, Flexible, Dynamic User Interfaces for Web-
`
`Delivered Training, Proceedings of the Workshop on Advanced
`
`Visual Interfaces, 1996 (“Kovacevic”)
`
`16
`
`
`
`
`
`
`
`1006/1106 U.S. Patent No. 5,806,071 (“Balderrama”)
`
`1007/1107
`
`Java Complete!, Datamation, March 1, 1996, pp. 28-49 (“Java
`
`Complete”)
`
`1008/1108 E. F. Codd, Does your DBMS run by the rules?, ComputerWorld,
`
`October 21, 1985, pp. 49-60 (“Codd”)
`
`1009/1109 U.S. Patent No. 5,710,900 (“Anand”)
`
`27.
`
`I understand that in an inter partes review proceeding, claim terms
`
`should be given their broadest reasonable interpretation (BRI) consistent with the
`
`specification. In my analysis below and as discussed above, I apply that standard
`
`to the words and phrases of the challenged claims.
`
`28. My opinions on the disclosure of each prior art reference, as relevant
`
`to the limitations of claims 1-59 of the ‘482 patent, are provided below. I also
`
`attach separate claim charts with more detailed explanation as an Appendix to this
`
`Declaration.
`
`A.
`
`Popp Discloses Each Limitation of Claims 1, 2, 7-13, 18-22,
`27-33, 38-42, 47-52, and 57-59 of the ‘482 Patent
`29. According to the face of the document, Popp (Ex. 1004/1104)4 is a
`
`U.S. patent that issued on June 19, 2001, from an application that was filed on
`
`September 22, 1995. I have been informed by counsel that it meets the
`
`4 Unless otherwise indicated, all citations in Section VI.A are to Ex. 1004/1104.
`
`17
`
`
`
`
`
`requirements to be prior art to the ‘482 patent. Popp discloses a multi-layered
`
`development architecture for web page applications that incorporates change
`
`management. For example, Popp’s system can be used to provide a dynamic user
`
`interface for an internal application that can respond to user input. (8:24-26.) The
`
`user interface is in the form of a Web page that can present corporate data from a
`
`database and can receive user input to modify information in the database. (21:7-
`
`11.) The system maintains separation between the application’s data and
`
`presentation by defining the presentation via an object tree built from shared
`
`components, and by utilizing intermediary objects (context objects) for linking and
`
`pushing data from the database into the Web page presentation. (21:24-35.)
`
`30. After reviewing Popp and claims 1, 2, 7-13, 18-22, 27-33, 38-42, 47-
`
`52, and 57-59 of the ‘482 patent, it is my opinion that a POSA would understand
`
`Popp to disclose every limitation of these claims. The basis for my opinion and the
`
`details of my analysis are provided below.
`
`i.
`
`Claim 1: “A system for providing a dynamically generated
`application having one or more functions and one or more
`user interface elements; comprising:”
`31. Popp discloses a system for providing a dynamically generated
`
`application having one or more functions and one or more user interface elements.
`
`(3:55-59 (“[T]he present invention is used with an application on the server side of
`
`the connection to dynamically generate Web pages. The Web pages contain
`
`18
`
`
`
`
`
`application information and provide the ability for the user to specify input.”).) A
`
`Web page dynamically generated by Popp’s system is an application as recited in
`
`claim 1, i.e., a program executable by a computer to do something useful other
`
`than maintaining the computer itself. (See ¶ 21 above.) The Web page is a
`
`program written in a language such as HTML or Java, which is executable by a
`
`computer’s browser to do useful things such as displaying information to a user,
`
`eliciting and receiving input from the user, etc. (2:25-3:3; 7:45-49 (“[T]he present
`
`invention can be used to access a Web page (e.g., an HTML Web page) that is
`
`dynamically generated using complex queries (or other data retrieval mechanisms)
`
`to retrieve data and dynamically generate an HTML page using complex logic.”);
`
`11:13-17.) A POSA would understand that a Web page creatable by Popp’s
`
`system can include executable code in any of a variety of programming languages
`
`in addition to HTML and Java mentioned by Popp, such as Javascript, VBScript,
`
`Python, CSS, etc.
`
`32. While Popp uses the term “application” to refer to a program on the
`
`server that generates Web pages (i.e., application 214), it is the Web page
`
`generated by application 214 that corresponds to the “dynamically generated
`
`application” recited in the ‘482 patent. Both are “applications” as the term is used
`
`in the ‘482 patent, and the Web page is dynamically generated. Direct quotations
`
`from Popp use the term “application” to refer to the internal application 214.
`
`19
`
`
`
`
`
`However, in my analysis, I refer to application 214 as Popp’s “internal
`
`application,” and to Popp’s Web page as corresponding to the ‘482 patent’s
`
`claimed “application.”
`
`33.
`
`In Popp, the dynamically generated Web page provides a user
`
`interface for interacting with an internal application that stores data in an external
`
`data source. (8:24-28 (“[U]sing the present invention an internal application can
`
`provide a dynamic user interface that can respond to user input. Further, an
`
`internal application is able to access an external data source to store the
`
`application’s data.”).) An example described in Popp is an Automobile Shopper’s
`
`application that provides a series of Web pages to facilitate the selection and
`
`purchase of an automobile from information in a database. (9:4-10:28.) Each
`
`dynamically generated Web page has one or more functions (e.g., allowing the
`
`shopper to identify the model, price and type of the car(s) in which the shopper has
`
`some interest (9:29-31); displaying those cars that