throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`
`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
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket