`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`OLD REPUBLIC GENERAL INSURANCE GROUP, INC.; OLD REPUBLIC
`
`INSURANCE COMPANY; OLD REPUBLIC TITLE INSURANCE GROUP,
`INC.; and OLD REPUBLIC NATIONAL TITLE INSURANCE COMPANY,
`
`Petitioner
`
`INTELLECTUAL VENTURES I LLC,
`
`Patent Owner
`
`Case Number: IPR2016—O0020
`
`Patent 6,510,434
`
`Declaration of Dr. Yannis Papakonstantinou
`
`IV I LLC
`Exhibit 2001
`
`
`
`I, Dr. Yannis Papakonstantinou, declare as follows:
`
`Introduction
`
`I.
`
`I am over 18 years of age. I have personal knowledge of the facts
`
`stated in this declaration and could testify competently to them if asked to do so.
`
`2.
`
`I have been retained on behalf of Patent Owner, Intellectual Ventures
`
`I LLC (IV), to provide this declaration in connection with the inter partes review
`
`(IPR) of U.S. Patent No. 6,510,434 (“the ‘434 patent”) assigned Case Number
`
`IPR20l6—OO0l9. Specifically, I have been asked to provide my opinion relating to
`
`an inquiry into the patentability of claims 7, 8, 12 and 14 from the ’434 patent
`
`relative to Okamotod
`
`3.
`
`I am being compensated for my time spent on this matter by
`
`Intellectual Ventures I LLC,
`
`including independent study, document review,
`
`analysis, and writing, at my standard hourly consulting rates. My compensation is
`
`not dependent upon my testimony or the outcome of this or any other proceeding. I
`
`have no financial interest in Intellectual Ventures I LLC.
`
`1 U.S. Patent No. 6,377,946 to Okamoto (“Okamoto” or “EX. 1005”)
`
`2
`
`IV I LLC
`Exhibit 2001
`
`
`
`Qualifications
`
`4.
`
`I am an expert in the field of database information retrieval, including
`
`databases that utilize Extensible Markup Language (XML).
`
`I have decades of
`
`experience in the field of computer databases that began in the early l990’s and
`
`continues to the present day.
`
`In particular I have written a substantial number of
`
`papers as well as given numerous conference talks related to searching for
`
`information in XML databases.
`
`I have given counsel for Patent Owner a true and
`
`correct copy of my curriculum vitae (CV) which I understand will be submitted as
`
`Ex. 2002. A summary of some of my qualifications is presented herein.
`
`5.
`
`I received a Diploma of Electrical and Computer Engineering from
`
`the National Technical University of Athens in Athens, Greece in 1990. In 1994, I
`
`received a M.S.
`
`in Computer Science from Stanford University, and in 1997, I
`
`received a Ph.D. in Computer Science from Stanford University. The title of my
`
`thesis was “Query Processing in Heterogeneous Information Systems.”
`
`6.
`
`I am currently a Full Professor of Computer Science and Engineering
`
`at University of California, San Diego (UCSD).
`
`I have been a professor of
`
`Computer Science and Engineering at UCSD since 1997. Courses I have taught
`
`while a professor at UCSB relevant to this IPR proceeding include “Database
`
`IV I LLC
`Exhibit 2001
`
`
`
`Application Programming” and “Database Systems: Advanced Topics and
`
`Implementation” both of which I designed and introduced into the UCSD
`
`curriculum in 1998.
`
`7.
`
`In addition to my tenure as a professor at UCSD I have provided
`
`technical consulting services to companies such as BEA Corp., Skyler Technology
`
`and Ferring Pharmaceuticals in relation to intellectual property matters and data
`
`integration.
`
`In addition, as indicated in my CV,
`
`I have provided consulting
`
`services in connection with many intellectual property disputes including IPR
`
`proceedings.
`
`I have provided testimony in some of these intellectual property
`
`disputes in which I was involved as an expert.
`
`In one of these disputes I provided
`
`a declaration in support of IV in connection with IPR2015-01481 filed by IBM on
`
`the ‘434 patent.
`
`8.
`
`My research spans database and Internet—related technologies. I have
`
`published over eighty—f1ve research articles in scientific conferences and journals,
`
`given tutorials at major conferences, and served on journal editorial boards and
`
`program committees for numerous international conferences and symposiums.
`
`I
`
`was the co-Chair of WebDB 2002, the General Chair of ACM SIGMOD 2003, the
`
`co—Chair of XIME-P 2004,
`
`the Vice PC Chair for the “XML, Metadata and
`
`IV I LLC
`Exhibit 2001
`
`
`
`Semistructured Data” track of IEEE ICDE 2004 and I will be the Program Co-
`
`Chair of IEEE ICDE 2017. In 1998, I received the NSF CAREER award for my
`
`work on integrating heterogeneous data.
`
`9.
`
`In 2000, I founded Enosys Software, which built the first generally
`
`available distributed XML/XQuery processor for information integration (EII), was
`
`subsequently acquired by BEA in 2003, and its product was sold under the BEA
`
`Liquid Data brand name.
`
`10.
`
`I have held several technical editorial positions for various journals,
`
`such as the IEEE Transactions on Data and Knowledge Engineering. As a
`
`Technical Editor of the IEEE Communication Magazine I was responsible for
`
`making decisions regarding the acceptance or rejection of scientific articles
`
`submitted to the journal in the areas of data and knowledge engineering systems.
`
`11.
`
`I have published the following articles in the field of XML and
`
`databases that span from before the filing date of the ‘434 patent and continue to
`
`the present. A full
`
`list appears in my CV but my publications include the
`
`following: L. Gravano and Y. Papakonstantinou. “Mediating and Metasearching on
`
`the Internet”; In IEEE Data Engineering Bulletin, 21(2), pp. 28-36, 1998; Y.
`
`Papakonstantinou and V. Vassalos “Architecture and Implementation of an
`
`IV I LLC
`Exhibit 2001
`
`
`
`XQuery—based Information Integration Platform” In IEEE Data Engineering
`
`Bulletin, 25(1), pp. 18-26, March 2002; Y. Papakonstantinou et.al., “XML Views,
`
`Queries and Algebra in the Enosys Integration Platform”; Data and Knowledge
`
`Engineering Journal,
`
`44(3): 299-322 (2003); A. Balmin, Y. Papakonstantinou,
`
`“Storing and Querying XML Data Using Denormalized Relational Databases”; in
`
`VLDB Journal 14(1): 30-49 (2005); V. Hristidis, N. Koudas, Y. Papakonstantinou,
`
`D. Srivastava, “Keyword Proximity Search in XML Trees”; IEEE Transactions on
`
`Knowledge and Data Engineering 18(4): 525-539 (2006). I recently presented in
`
`ACM SIGMOD a tutorial on “Semistructured Models, Queries and Algebras in the
`
`Big Data Era”.
`
`12.
`
`I have been involved in research regarding information integration
`
`and retrieval projects that have combined received over $10,000,000 in grant
`
`money from the National Science Foundation and others, most of which I was the
`
`primary investigator of.
`
`13.
`
`I believe my education, research, conferences,
`
`teaching and other
`
`work experiences adequately well qualify me to testify as
`
`to what
`
`the
`
`understanding of one of ordinary skill in the art would have been at the time the
`
`‘434 patent was filed on Dec. 29, 1999.
`
`IV I LLC
`Exhibit 2001
`
`
`
`III. My Understanding of the Obviousness Standard in Determining
`
`Patentability
`
`14.
`
`I understand that a patent claim is not patentable if the claimed
`
`invention would have been obvious to a person of ordinary skill in the art at the
`
`time the application was filed. This means that even if all of the requirements of
`
`the claim cannot be found in a single prior art reference so as to anticipate the
`
`claim, the claim might still be not patentable if the claimed invention would have
`
`been obvious.
`
`15.
`
`To obtain a patent, a claimed invention must have been nonobvious in
`
`view of the prior art in the field. I understand that an invention is obvious when the
`
`differences between the subject matter sought to be patented and the prior art are
`
`such that the subject matter as a whole would have been obvious at the time the
`
`invention was made to a person having ordinary skill in the art.
`
`16.
`
`I understand that to prove that a prior art reference or a combination
`
`of prior art references renders a patent obvious, it is necessary to: (1) identify the
`
`particular references that either alone, or in combination, render the patent obvious;
`
`(2) specifically identify which elements of the patent claim appear in each of the
`
`asserted references; and (3) explain how the prior art references could have been
`
`IV I LLC
`Exhibit 2001
`
`
`
`combined in order to create the inventions claimed in the particular claim at issue.
`
`IV. Basis of Opinion
`
`17.
`
`In forming my opinions expressed in this declaration,
`
`I have
`
`considered and relied upon my education, background, and experience. I reviewed
`
`the Petition filed by Petitioner along with relevant exhibits to the Petition. A list of
`
`reviewed materials that
`
`is most relevant to my opinion is presented below.
`
`I
`
`understand these documents have been or will be submitted as exhibits in this IPR
`
`proceeding with the following exhibit numbers:
`
`Exhibit/Paper
`
`Number
`
`Ex. 1001
`Ex. 1002
`Ex. 1003
`
`Ex. 1005
`
`Document Description
`
`LU.S. Patent No. 6,510,434
`’ The ‘434 Patent File History
`Declaration of Dr. Naughton
`
`U.S. Patent No. 6,377,946 to Okamoto
`
`Paper No. 1
`
`Petition for IPR of the ‘434 patent
`
`Paper No. 8
`
`Patent Trial and Appeal Board Institution Decision
`
`18.
`
`In addition, I understand the time of the invention for claims 1-6 of
`
`the ‘434 Patent is the filing date, December 29, 199.
`
`19.
`
`I have been instructed by Patent Owner’s counsel that for the purposes
`
`of this declaration, I should use the definition of a person of ordinary skill in the art
`
`IV I LLC
`Exhibit 2001
`
`
`
`at the time of the invention as set forth in Dr. Naughton’s declaration. Ex. 1004,
`
`Naughton Decl. at $1 85.
`
`20.
`
`As such, unless otherwise stated, all the opinions I provide in this
`
`declaration are based on the knowledge of a person with “a Bachelor’s degree in
`
`Computer Science or equivalent field and at least one year of experience designing
`
`database systems” as of December 29, 1999.
`
`Overview of the ‘434 Patent
`
`21.
`
`The ‘434 Patent describes a primary goal is “to locate the requested
`
`information as quickly as possible” and it identifies a variety of problems suffered
`
`in prior art that impede this goal. Id. at 1:39-2:24. Problems in the prior art at the
`
`time of the invention to be solved include “eliminate ambiguity in the search
`
`request, focus the search on the most relevant information, perform the search in
`
`the most efficient manner and support searching multiple databases.” Id. at 2:25-
`
`22.
`
`The ‘434 solves the problems that existed in the prior art by “using an
`
`index that includes tags and metafiles to locate the desired information.” Id. at
`
`2:36-39; 4:11-14. Because the index “includes” tags and metafiles one of skill in
`
`the art understands that tags and metafiles are distinct components different from
`
`IV I LLC
`Exhibit 2001
`
`
`
`the index itself. Id. at 7:19-20.
`
`23.
`
`An exemplary index of the ‘434 patent includes three different types
`
`of groupings: domains, categories and terms. Id. at 4:17-33. The index may be
`
`created so that an extensible markup language (XML) tag is associated with each
`
`domain and each category resulting in an XML domain tag and an XML category
`
`tag respectively. Id. at 4:34-39.
`
`24.
`
`As stated in the ‘434 patent a “tag is generally associated with data or
`
`text and conveys information about the data or text.” Id. at 7:20-22. In the context
`
`the ‘434 patent
`
`the tags are associated with domains, categories, and
`
`hierarchies. Id. at 4:34-43 and 7:32-33.
`
`25.
`
`Category tags are generally used to describe information that
`
`is
`
`common to many domains, such as business hours and type of payment accepted.
`
`Id. at 7:40-43. Conversely domain tags are used to describe information that is not
`
`generally considered related. For example, domain tags can be associated with
`
`different lines of business such as Restaurant and Automobile.
`
`Id. at 7:57-60.
`
`26.
`
`This correspondence between tags and metafiles is one of the most
`
`important aspects of a metafile since it is responsible for increasing the efficiency
`
`of the ‘434 Patent’s method. Through this correspondence, the ‘434 Patent does
`
`10
`
`IV I LLC
`Exhibit 2001
`
`
`
`not need to examine every single tag and relationship in the index in response to a
`
`search request. Such a method is quite inefficient and slow since it is likely the
`
`vast majority of tags and relationships stored in an index are wholly irrelevant to
`
`the search request. Rather the method of the ‘434 patent only needs to examine the
`
`relationship information contained in the metafiles that correspond to tags
`
`identified from analyzing the search request.
`
`27.
`
`The ‘434 patent also describes a hierarchy among the list of related
`
`tags in a metafile, which can be established by a hierarchy tag. Id. at 4:42-43 and
`
`8:1-l2. However, it is my opinion that one of ordinary skill in the art understands
`
`hierarchy as used in the ‘434 patent does not refer to a hierarchy between nodes
`
`and sub—nodes of a data graph but rather it exclusively refers to a hierarchy of
`
`priority between tags in a metafile.
`
`The is shown through the ‘434 patent
`
`repeatedly and consistently refers to hierarchy as establishing the order of priority
`
`among the related tags in a metafile to search for the most relevant information and
`
`never referring to a hierarchy established by having domains being groups of
`
`categories. Id. at 2:31-33, 4:42, 8:55-57, 9:42-47, 9:54-56, 11:64-12:8, 8:1—7, 8:55-
`
`57, 9:43-47.
`
`28.
`
`As further evidence the hierarchy that is described in the ‘434 patent
`
`11
`
`IV I LLC
`Exhibit 2001
`
`
`
`is not about domains being above categories is that the ‘434 patent provides that
`
`one of skill in the art can have a hierarchy where a category is above a domain.
`
`In
`
`particular, the ‘434 provides a discussion of Figure 3B showing “to establish a
`
`hierarchy so that <XML Taga> 324 has priority over <XML Tagb> 328” where
`
`<XML Taga> corresponds to a domain and <XML Tagb> corresponds to a
`
`category. Id. at 9:34-54. While this provides an example where a domain is above
`
`a category in the priority hierarchy, the ‘434 Patent goes on to state that as “will be
`
`apparent to those skilled in the art, other tags and hierarchies can be included in the
`
`metafile.” Id. at 9:56-58. One other possible hierarchy to one of skill in the art
`
`based on Figure 3B would be to establish a hierarchy so that <XML Tagb>
`
`corresponding to a category has priority over <XML Taga> corresponding to a
`
`domain.
`
`VI. Claim Construction
`
`Index
`
`29.
`
`I understand the Board adopted a construction of index as “data
`
`structure used to locate information in a database.” PTAB Institution Decision at 7-
`
`8. In my opinion, this construction is inconsistent with the ‘434 patent because this
`
`construction would encompass many data structures that are not an “index”
`
`12
`
`IV I LLC
`Exhibit 2001
`
`
`
`according to the 434 patent.
`
`30.
`
`The ‘434 patent utilizes many different data structures to locate
`
`information stored in the database including metafiles,
`
`tags, and information
`
`requests (also known as search queries). See, e. g., Ex. 1001 at 2:36-39 (metafiles
`
`and tags); Id. at 12:36-52 (information requests). The term “index” as used in the
`
`‘434 patent would lose any reasonable meaning to one of skill in the art if the
`
`metafiles, tags, and information requests in the ‘434 patent were considered an
`
`index.
`
`31.
`
`The ‘434 patent provides some structural requirements of the “index.”
`
`In particular, the 434 patent repeatedly describes the index as a data structure
`
`which “includes tags and metafiles.” Ex. 1001 at 2:36—39 (“The present invention
`
`meets the needs described above by providing a method for locating information
`
`stored in a database using an index that includes tags and metafiles to locate the
`
`desired information”) (emphasis added); 7:18~32 (“The index includes a number
`
`of tags and metafiles associated with the tags”) (emphasis added); 15:4—6 (“In
`
`summary,
`
`the present
`
`invention is directed toward a method for
`
`locating
`
`information stored in a database using an index that includes tags and metafiles”)
`
`(emphasis added); see also id. at 1:25-27; 4:10-13; and Abstract.
`
`13
`
`IV I LLC
`Exhibit 2001
`
`
`
`32.
`
`One of ordinary skill in the art understands the metafiles and tags
`
`described in the ‘434 patent are different data structures than the index. For
`
`example, a tag would only be one of the tags in the index While a metafile would
`
`only include a subset of the tags in the index.
`
`If the metafile of the ‘434 patent
`
`included all the tags of the index, it would defeat the stated purpose the ‘434 patent
`
`because a search using the index would return all records in the database. Thus,
`
`instead of searching the database to locate the most relevant documents, the search
`
`would simply return all documents that are searchable.
`
`33.
`
`One of ordinary skill
`
`in the art would understand the invention
`
`disclosed in the ‘434 patent requires the index include tags and metafiles to
`
`perform the search methods disclosed in the ‘434 patent. Therefore, to make the
`
`constructions adopted by the Board consistent with the description of the invention
`
`in the ‘434 patent as understood by one of ordinary skill in the art at the time of the
`
`invention, the broadest reasonable interpretation of “index” should be modified to
`
`mean “a data structure that includes tags and metafiles to locate the information in
`
`a database.”
`
`34. Metafile
`
`35.
`
`It is my opinion that the term “metafile” as used in the ‘434 patent is
`
`14
`
`IV I LLC
`Exhibit 2001
`
`
`
`not a term of art in the relevant field of the ‘434 patent. The only understanding of
`
`“metafile” to one of ordinary skill in the art is the context provided in the ‘434
`
`patent itself.
`
`36.
`
`The ‘434 patent provides
`
`some structural
`
`requirements of the
`
`“metafile.”
`
`In particular, the ‘434 patent repeatedly describes the “metaf1le’ as
`
`included in the index. Ex. 1001 at 2:36-39 (“The present invention meets the
`
`needs described above by providing a method for locating information stored in a
`
`database using an index that includes tags and metafiles to locate the desired
`
`information”) (emphasis added); 7:18—32 (“The index includes a number of tags
`
`and metafiles associated with the tags”) (emphasis added); 15:4—6 (“In summary,
`
`the present invention is directed toward a method for locating information stored in
`
`a database using an index that includes tags and metafiles.”) (emphasis added); see
`
`also id. at 1:25—27; 4:10-13; and Abstract.
`
`37.
`
`One of ordinary skill
`
`in the art would understand the invention
`
`disclosed in the ‘434 patent requires the metafiles be included in the index to
`
`perform the search methods disclosed in the ‘434 patent. Therefore, to make the
`
`constructions adopted by the Board (PTAB Institution Decision at 7-8) consistent
`
`with the description of the invention in the ‘434 patent as understood by one of
`
`15
`
`IV I LLC
`Exhibit 2001
`
`
`
`ordinary skill
`
`in the art at
`
`the time of the invention,
`
`the broadest reasonable
`
`interpretation of “metafile ” should be modified to mean “a data structure included
`
`in the index comprising additional information about a tag, including related tags.”
`
`VII. Okamoto does not render the claims obvious
`
`Claim 7
`
`38.
`
`I understand the Petitioners have asserted that Okamoto’s structure
`
`index reads on the “index” recited in claim 7 while Ol<amoto’s meta—structure
`
`index reads on the “metafile” recited in claim 7. Petition at 26-29. Okamoto’s
`
`structure index registers the logic structure of nodes from analyzed documents
`
`having the same base document
`
`type.
`
`Ex. 1005 at
`
`l1:22—26. Ol<amoto’s
`
`metastructure index combines all of the structure indexes into a single index by
`
`connecting the structure indexes to a root meta—node. Ex.
`
`lOO5 at 39:14-21 and
`
`Figure 49.
`
`39. Under the broadest reasonable interpretation of “index” or “metafile”
`
`as provided above, where an index includes a metafile, Okamoto’s structure index
`
`would not be understood to one of skill in the art as the “index” recited in claim 7.
`
`In Okamoto the alleged rnetafile includes the alleged index, whereas claim 7 as
`
`properly interpreted requires the index include the metafile.
`
`16
`
`IV I LLC
`Exhibit 2001
`
`
`
`40.
`
`One of ordinary skill
`
`in the art would not understand Okamoto’s
`
`metastructure index to be the “metafile” recited in claim 7 for other reasons.
`
`Okamoto itself refers to the metastructure index as an index created by connecting
`
`other indexes to a root meta—node. Ex. 1005 at 3927-21. Thus rather than
`
`including a subset of the tags of a particular structure index, the metastructure
`
`index includes all the tags of a particular structure index as well as tags from any
`
`other structure indexes connected to the root meta—node.
`
`41.
`
`The only structural difference between the a structure index and a
`
`metastructure index is a metastructure index includes a connection between the
`
`base document type node of the structure index to a root meta node. Ex. 1004 at
`
`39:7-l3; Figure 53. The root meta—node “has information on the number of the
`
`base document elements of a plurality of
`
`structure
`
`indexes
`
`constituting
`
`subelements and the link to each structure index.” Ex. 1005 at 39:38-31. One of
`
`ordinary skill in the art would not read the ‘-434 patent and understand a metafile
`
`would be created by adding information to the index about other indexes.
`
`42.
`
`I also understand that the Petitioners rely on Okamoto’s analysis of
`
`“Aliasz”
`
`search
`
`query to
`
`teach
`
`a
`
`“determination whether
`
`a
`
`first
`
`metaf1le...corresponds
`
`to the first
`
`tag.”
`
`Petition at 29.
`
`In Okamoto,
`
`the
`
`17
`
`IV I LLC
`Exhibit 2001
`
`
`
`“Alias:[element]” structural condition is included in a query by the user to instruct
`
`the search server of Okamoto to search the alias structure index using the element
`
`specified by the alias structural condition. Ex. 1005 at 49:15-65.
`
`If no alias
`
`structural condition is included in the query, then Okamoto would apply the same
`
`search processes as described for the metastructure index. Id. at 59-61.
`
`43.
`
`One of ordinary skill in the art would not understand a determination
`
`of whether the “Alias:[element]” structural condition is present in a query to be a
`
`determination that the alias structure index corresponds to a tag associated with the
`
`element included in the alias structural condition. Okamoto states that step 7101
`
`determines whether an alias is used while in step 7102 the alias structure index is
`
`read and then in step 7103 a mass of context identifiers of the string data meeting
`
`the structural condition is determined. Ex. 1005 at 49:43-58. Thus, at the time of
`
`step 7101 when the determination of whether the “Alias:” structural condition is
`
`present or not is made, the alias structure index has not even been read from the
`
`memory storage area. One of skill in the art understands it is not possible to make
`
`a determination of whether the alias structure index corresponds to a tag before the
`
`alias structure has even been read from the memory storage area.
`
`44.
`
`Similarly, when step 7101 determines the “Alias:” structural condition
`
`18
`
`IV I LLC
`Exhibit 2001
`
`
`
`is not present in the search query, Okamoto will execute steps 5701 and 5702
`
`instead of steps 7102 and 7103. Ex. 1005 at 49:38-42. Step 5701 reads the meta
`
`structure index from the meta structure storage area and in step 5702 a mass of
`
`context identifiers of the string data meeting the structural condition is determined.
`
`Id. at 42:59-63. Thus, at the time of step 7101 when the determination is of
`
`whether the “Aliast” structural condition is present or not is made,
`
`the meta
`
`structure index has not even been read. One of skill in the art understands it is not
`
`possible to make a determination if the meta structure index corresponds to a tag
`
`before the meta structure index has even been read from the memory storage area.
`
`45.
`
`For example, a search for “clause” does not include an alias, so at step
`
`7101 Okamoto will determine the an alias structural condition is not present. At
`
`this time, is not possible for Okamoto’s system to determine if the meta structure
`
`index corresponds to a tag for “clause” because step 5701 has not yet been
`
`executed which reads the meta structure index from the memory storage area.
`
`Indeed, the metastructure index read from memory may have no correspondence to
`
`the search element as shown in the example meta structure index of Figure 65
`
`which has no “clause” node and thus the metafile in Figure 65 would have no
`
`correspondence to a “clause” tag.
`
`19
`
`IV I LLC
`Exhibit 2001
`
`
`
`46.
`
`The determination of whether a search query includes any structural
`
`condition, such as “Type:” or “Aliasz” is performed in step 7101. Ex. 1005 at
`
`49:35-42. The lack of presence of the “Aliasz” structural condition does not cause
`
`or imply the presence of the “Type:” structural condition to one of skill in the art.
`
`Thus a search for “Type:Attribute” converts the search to the Type element
`
`“Journal” because the “Type:” structural condition is present in the search request,
`
`not because the “Aliasz” structural condition is missing from the search request.
`
`47.
`
`Claim 14
`
`48.
`
`I understand that Petitioners have alleged that the second tag recited in
`
`claim 14 is a tag associated with the Journal node depicted in Figure 49 while the
`
`alleged rnetafile recited in claim 14 is the meta structure index. Petition at 28-29
`
`and 35-36. One of ordinary skill in the art would not understand Okamoto to
`
`determine a tag associated with the Journal node, or a tag associated with any other
`
`node, is included in the meta structure index.
`
`49. Okamoto never discloses making such a determination. Nor would
`
`such a determination be useful in Okamoto.
`
`In Okamoto, the meta structure index
`
`includes all of the document elements of the documents stored in the database. Ex.
`
`1005 at 39:1—21
`
`(“a meta structure index for collectively managing all the
`
`20
`
`IV I LLC
`Exhibit 2001
`
`
`
`document elements of the registered documents having various structures”). This
`
`means that every single tag defined in Okamoto’s index is included in the meta
`
`structure index. Since the meta structure index includes every single tag, there is
`
`no need to ever make a determination that the meta structure index includes a tag.
`
`50.
`
`Also, under the broadest reasonable interpretation
`
`of “index” or
`
`“metafile” as provided above, where an index includes a metafile, Okamoto’s
`
`structure index would not be understood to one of skill in the art as the “index”
`
`recited in claim 14 for the same reasons given above for claim 7.
`
`In particular, in
`
`Okamoto the alleged metafile includes the alleged index, whereas claim 14 as
`
`properly interpreted requires the index include the metafile.
`
`VIII. Perjury Statement
`
`I declare that all statements made herein of my knowledge are true, and that
`
`all statements made on information and belief are believed to be true, and that
`
`these statements were made with the knowledge that willful false statements and
`
`the like so made are punishableiby fine or imprisonment, or both, under Section
`
`1001 of Title 18 of the United States Code.
`
`21
`
`IV I LLC
`Exhibit 2001
`
`
`
`Executed on uly 5 , 2016 ingm. 01% CA ,
`
`
`
` " apakonstantinou
`
`22
`
`IV I LLC
`Exhibit 2001
`
`