`Boundary Solutions Inc. v. CoreLogic, Inc.
`
`
`
`
`
`
`
`
`
`
`
`CoreLogic Exhibit 1035
`CoreLogic, Inc. v. Boundary Solutions, Inc.
`Trial IPR2015-00228
`
`Page 1 of 38
`
`
`
`
`
`
`
`I.
`
`INTRODUCTION
`
`1.
`
`I have been asked by counsel for Boundary Solutions Inc. (“BSI”) to analyze
`
`and opine on issues related to claim construction of U.S. Patent No. 7,092,957, 7,499,946, and
`
`8,065,352, (collectively “Patents-in-Suit”) in this case.
`
`II.
`
`
`
`QUALIFICATIONS
`2.
`My name is William Huxhold, and I am a Professor at the University of
`
`Wisconsin – Milwaukee in the Department of Urban Planning. Details of my professional
`
`qualifications and background are set out in my curriculum vitae, a copy of which is attached as
`
`Exhibit A.
`
`3.
`
`I hold B.S. and M.S. degrees in Industrial Engineering and Engineering
`
`Management (Public Administration emphasis).
`
`5.
`
`I have been involved in the study, construction, implementation and operation
`
`of Geographic Information Systems (GIS) for over 40 years.
`
`6.
`
`For the time I expend on this case, I am currently being compensated at a rate
`
`of $275/hour. My compensation is not in any way dependent on the outcome of the dispute.
`
`7.
`
`I have considered the Patents-in-Suit and their file histories for the purposes of
`
`providing my technical expert opinion regarding the meaning of certain claim terms. The
`
`patents generally relate to design, construction, updating and operation of a national parcel
`
`boundary map database designed to serve maps over computer networks in an efficient and
`
`effective manner. Because of my background, training, and experience, I am qualified as a
`
`technical expert in the technical areas relevant to these patents.
`
`
`
`III. MATERIALS REVIEWED FOR INFRINGEMENT OPINION
`
`8.
`
`To prepare this report, I reviewed the Patents-in-Suit; the prosecution history of
`
`the patents and including certain references cited therein; and extrinsic evidence as detailed
`
`below. Through my work in the field, I have also examined various textbooks, patents, and
`
`publications in existence before the Patents-in-Suit that inform my opinions. While I have
`
`reviewed a number of materials, the materials I have relied upon in rendering my opinions
`
`- 1 -
`
`Page 2 of 38
`
`
`
`
`
`disclosed in this report are set forth in Exhibit B.
`
`9.
`
`I reviewed the definitions for the identified terms proposed by Boundary
`
`Solutions and I agree with them.
`
`IV.
`
`
`FIELD OF THE INVENTIONS
`
`10.
`
`The Patents-in-Suit describe the solution to a particular set of problems that
`
`GIS organizations faced in the assembly and presentation of the voluminous data from many
`
`sources that was needed to provide systems that could exactly identify property locations by
`
`their actual parcel boundaries. In particular, in the United States, many counties (usually in
`
`their tax assessor’s office) had developed databases which could display parcel maps for their
`
`own counties. While there was much discussion of standards and data formats to be used for
`
`this work, the counties had not designed their database to work in concert with each other, and
`
`they had, in fact, used a wide variety of GIS data and database formats.
`
`11.
`
`As described in the patents, digital maps generally combine both spatial
`
`(geographic) data and non-geographic information. The geographic data describes points, lines
`
`and areas. The non-geographic data, often referred to as “attributes” are information associated
`
`with a geographic feature. In this case, parcels, can have many attributes, such as owner name,
`
`address, type of building structure, assessed value, year built, land use restrictions and the like.
`
`Two basic means of storage had developed for GIS data. The data could be stored directly in
`
`files that the GIS system software would load for each project. Alternatively, the data could be
`
`stored in a relational database, where a series of tables contained the information in “records”
`
`and the tables could be flexibly joined for particular queries (searches). In any case, many
`
`aspects of the collection of the data (its sources, forms, and currency), the types of analysis that
`
`were expected, and the storage and operation of the system impacted the design of the system.
`
`V.
`
`
`
`CLAIM CONSTRUCTION
`
`12.
`
`I am informed that terms in patent claims must be construed as a first step in
`
`analyzing whether a claim is infringed and/or whether the claim is invalid. I am further
`
`informed that patent claims must be construed the same way for infringement and invalidity
`
`- 2 -
`
`Page 3 of 38
`
`
`
`
`
`analyses. I understand that claim construction starts with the plain language of the claims, and
`
`that the meaning of claim terms may be informed by referring to the specification and file
`
`histories.
`
`13.
`
`It is my understanding that disputed claim terms should be interpreted using
`
`their plain and ordinary meaning to one of skill in the art at the time of the invention (i.e., the
`
`date the earliest supporting priority application was filed, namely January 18, 2002 for these
`
`patents), unless the inventor acted as his or her own lexicographer, redefined a well-known
`
`term of art, or disclaimed certain subject matter. I also understand that the specification plays a
`
`significant role in claim construction, and that the claims must be read in view of the
`
`specification of which they are a part. I also understand that the specification may reveal a
`
`special definition given to a claim term by the patentee that differs from the meaning it would
`
`otherwise possess, and that in such cases the special definition (“lexicography”) governs. I
`
`further understand that subject matter can be disclaimed from the scope of a claim term if there
`
`is a clear and unambiguous disavowal of that subject matter. I further understand that the
`
`prosecution history of the patent should also be considered, and that it provides evidence of
`
`how the U.S. Patent and Trademark Office and the inventor understood the patent.
`
`14.
`
`I further understand that the claim language (in the context of non-means plus
`
`function claiming) is to be viewed from the perspective of a person of ordinary skill in the art at
`
`the time of invention. A person of ordinary skill in the relevant art of the Patents-in-Suit at that
`
`time would have had a Bachelor’s degree or higher in, GIS engineering with at least 5 years of
`
`academic or industry experience in GIS database design. When analyzing the disputed claim
`
`language, I apply this standard to reach my conclusions.
`
`V.
`
`
`
`PATENTS-IN-SUIT OVERVIEW
`15.
` On August 15, 2006, United States Patent No.7,092,957, (“the ‘957 patent”)
`
`entitled “Computerized national online parcel-level map data portal” was duly and legally
`
`issued.
`
`16.
`
` On March 3, 2009, United States Patent No. 7,499,946, (“the ‘946 patent”)
`
`- 3 -
`
`Page 4 of 38
`
`
`
`
`
`entitled “Computerized national online parcel-level map data portal” was duly and legally
`
`issued.
`
`17.
`
` On November 22, 2011, United States Patent No. 8,065,352 (“the ‘352
`
`patent”) entitled “Computerized national online parcel-level map data portal” was duly and
`
`legally issued.
`
`18.
`
`The ’957, ‘946, and ‘352 patents (“Patents-in-Suit”) are directed to methods for
`
`the online delivery of parcel-level maps and linked attribute data. The ‘957 and ‘946 patents
`
`covers methods for retrieving geographic parcel boundary polygon maps and associated parcel
`
`attribute data linked to a non-graphic database. The ‘352 patent covers methods for retrieving
`
`and displaying geographic parcel boundary polygon maps.
`
`19.
`
`The patents are all in the same family sharing a common specification. For this
`
`discussion I use line and column cites to the ‘957 patent. The patents relates to a computerized
`
`National Online Parcel-Level Map Data Portal (NPDP). The patents states that while “hundreds
`
`of local governments have finished digitizing their parcel maps, a single national parcel map
`
`source (portal) does not exist. The National Online Parcel-Level Map Data Portal (NPDP)
`
`remedies this problem by providing the first national repository of parcel data.” Id., 1:26-31.
`
`As described throughout the specification the construction, maintenance, operation of the
`
`database present a series of technical challenges, including the large number of data sources
`
`each having prepared their data in varying formats and according to their own styles and
`
`inconsistent forms. Id., 7:31-54; 12:9-15. The national repository is assembled by collecting the
`spatial data from local municipal sources primarily county property assessor’s offices. Id.,
`
`Abstract, 1:49-59, 3:42-53, 4:8-17. “Typically this is a countywide parcel map (parcel polygons
`
`geocoded with APNs) provided by a single taxing authority.” Id., 7:56-58. The patents describe
`
`specifics of the NPDP that “optimizes online delivery of parcel-level maps and linked attribute
`
`data” by inter alia “managing a database of assembled and current vector based parcel data in a
`
`spatial format (GIS) that enables geocoded parcel boundaries to be linked to property tax
`
`records, and maintains relationships with “individual property assessor’s offices” to obtain
`
`- 4 -
`
`Page 5 of 38
`
`
`
`
`
`updates assuring “a sustained and expanding flow of increasingly competent content.” Abstract.
`
`20.
`
`This process is further described in reference to Figure 5 of the patents:
`
`The specification explains:
`
`
`
`FIG. 5 is an illustration of the process for establishing ongoing data
`acquisition and maintenance operations needed to build, maintain and
`improve the public domain content of the NPDP, along with commercially
`supplied data sets and the national street centerline map as described
`above.
`
`Data must first be obtained from the public sector, step 301. Through a
`sustained program, all property tax assessment agencies are contacted, and
`metadata profiles of parcel map GIS databases recorded along with terms
`and conditions for data acquisition. Each county is requested to submit in
`digital format a copy of their jurisdiction wide parcel boundary map,
`complete with tax number geocodes for each parcel.
`
`11:55-12:1.
`
` 21.
`
`Further, the NPDP “is developed in a manner that “accommodates easy
`
`updating of both the graphic and the non-graphic database since a central value of the NPDP is
`
`its currency” (8:11-13) and “expedites the ultimate self-updating of the spatial data by the
`
`sponsoring agency” (12:19-21).
`
`22.
`
`The patents next describe in detail a process of “normalizing” data received
`
`- 5 -
`
`Page 6 of 38
`
`
`
`
`
`from the counties using a common data protocol, called the “NPDP protocol.” The common
`
`spatial data protocol is described in the specification as a series of operations applied to the raw
`
`parcel-level map data from “multiple sources” to prepare the data for loading into the national
`
`database. Id. at 12:15-19. (“As the data is found or made compliant with NPDP specifications,
`it is loaded in step 304 onto the server in a directory that has the same FIPS number as the
`
`jurisdiction in which the NPDP data sponsor is located.”); id. at 3:14-19 (“The first, NPDP
`
`warehousing, is the gathering and storing of parcel-level map data from multiple sources
`
`formatted to a single protocol suitable for online access and use. “); id. at 4:8-11 (“The digital
`
`assemblage of parcel-level databases from all the sponsoring agencies is stored in a server
`system according to a standard protocol. The process begins with the acquiring of the raw
`
`parcel-level data from various data sponsors.”)
`
`23.
`
`In addition, the database is optimized to deliver online maps with parcel level
`
`information and associated non-geographic attribute data. The patent describes retrieving a
`
`parcel level map based on a requested address of a parcel. Id., 1:65-2:1, 2:63-65, 4:52-56. In
`
`some claims, a lookup table (e.g., a jurisdictional lookup table “JLT”) is searched to identify,
`
`the state and county (“the pertinent county”) in which the parcel is located. Id., 8:26-30, 9:12-
`
`28. In other claims, a directory is accessed, and the non-graphic database stored in the county
`
`directory is searched for a record having a matching address value. Id., 2:1-2, 8:30-33, 9:23-30,
`
`9:57-61. Finally, in all cases, the server searches “a multi-jurisdictional parcel map database” or
`
`“a portion of a multi-jurisdictional database” using a “jurisdictional identifier.” If the record is
`
`identified, the APN is used to access a graphic database containing the selected parcel and
`adjacent parcels within a prescribed search radius of the selected parcel. Id., 2:1-7, 3:56-63.
`
`These parcels may be displayed to form the parcel level map, with the selected parcel in the
`center of the screen displayed as a highlighted polygon. Id., 2:1-7, 4:61-63. The parcel’s linked
`
`tax record can also be displayed. Id., 4:63-64.
`
`VI.
`
`
`DISPUTED CLAIM TERMS TO BE CONSTRUED
`
`
`
`- 6 -
`
`Page 7 of 38
`
`
`
`
`
`Claim Term
`
` “associated parcel attribute data linked
`to a non-geographic database” (claim 1
`of ’957 patent; claims 1 and 20 of ’946
`patent)
`
` “applications program” (claim 1 of
`’957 patent; claims 1 and 20 of ’946
`patent)
`
` “multiple jurisdictional [digital parcel
`map] databases”
`
`(claim 1 of ’957 patent; claims 1 and 20
`of ’946 patent)
`
` “jurisdictional database” (claim 1 of
`’957 patent; claims 1 and 20 of ’946
`patent;
`
`claim 7 of ’352 patent)
`
` “normalized to a common [spatial]
`data protocol” (claim 1 of ’957 patent;
`claims 1
`
`and 20 of ’946 patent; claims 1, 9 and
`12 of ’352 patent)
`
`
`
`BSI Proposed Construction and Supporting
`Evidence
`
`BSI’S PROPOSED CONSTRUCTION
`
`Plain and Ordinary Meaning; No construction is
`necessary.
`
`BSI’S PROPOSED CONSTRUCTION
`
`Plain and Ordinary Meaning; No construction is
`necessary.
`
`BSI’S PROPOSED CONSTRUCTION
`
`Parcel map databases supplied by two or more
`sponsoring jurisdictions
`
`BSI’S PROPOSED CONSTRUCTION
`
`a parcel map database supplied by sponsoring
`jurisdictions
`
`BSI’S PROPOSED CONSTRUCTION
`
`a set of one or more automated and/or semi-
`automated processes applied to data and data updates
`supplied by sponsoring jurisdictions using a set of
`rules or procedures in order to transform the data for
`use in the multi-jurisdictional database.
`
`EXTRINSIC EVIDENCE
`
`Encyclopedia of Geographic Information Science,
`Sage Publications, 2008, at pages 320-321.
`
`“jurisdiction look up table” (claim 1 of
`’957 patent, claims 1 and 21 of ’946
`patent)
`
`BSI’S PROPOSED CONSTRUCTION
`
`Plain and Ordinary Meaning; No construction is
`necessary.
`
`
`
` “jurisdiction” (claims 1 of ’957 patent; BSI’S PROPOSED CONSTRUCTION
`
`- 7 -
`
`Page 8 of 38
`
`
`
`
`
`Claim Term
`
`claims 1, 20 and 21 of ’946 patent)
`
`
`
` “[numerical] jurisdictional identifier”
`(claim 1 of ’957 patent; claims 1 and 21
`of ’946 patent; claims 1, 9, 12, and 20
`of ’352 patent)
`
`“fill” (claim 1 of ’957 patent; claims 1
`and 20 of ’946 patent)
`
`BSI Proposed Construction and Supporting
`Evidence
`
`In claim 1 of the ‘957 patent and claims 1 and 21 of
`the ‘946, the term used in the claim is “selected
`jurisdiction.” The term does not appear in claim 20
`of the ‘946 patent.
`
`Plain and Ordinary Meaning; No construction is
`necessary.
`
`BSI’S PROPOSED CONSTRUCTION
`
`a [numerical] code for identifying a jurisdictional
`database.
`
`BSI’S PROPOSED CONSTRUCTION
`
`Completely or almost completely occupy a space
`
` “highlighted” (claim 1 of ’957 patent;
`claims 1 and 20 of ’946 patent; claims 4
`and 5 of ’352 patent)
`
`BSI’S PROPOSED CONSTRUCTION
`
`Plain and Ordinary Meaning; No construction is
`necessary.
`
`“the parcel is displayed to the center of
`the screen” (claim 5 of ’957 patent;
`claim 5 of ’946 patent)
`
`“scale selection mode” (claim 8 of ’957
`patent; claim 8 of ’946 patent)
`
`
`
` “specialized fields” (claim 13 of ’957
`patent; claim 13 of ’946 patent)
`
`
`
`BSI’S PROPOSED CONSTRUCTION
`
`Plain and Ordinary Meaning; No construction is
`necessary.
`
`BSI’S PROPOSED CONSTRUCTION
`
`Plain and Ordinary Meaning; No construction is
`necessary.
`
`BSI’S PROPOSED CONSTRUCTION
`
`Plain and Ordinary Meaning; No construction is
`necessary.
`
` “ornate” (claim 12 of ’957 patent)
`
`BSI’S PROPOSED CONSTRUCTION
`
`Plain and Ordinary Meaning; No construction is
`necessary.
`
`- 8 -
`
`Page 9 of 38
`
`
`
`
`
`Claim Term
`
` “multi-jurisdictional [digital parcel
`map] database” (claims 1, 3, 7, 8, 9, 10,
`11, 12, 14,
`
`19, 20, 21, 22, 23 of ’352 patent)
`
`“service area directories corresponding
`to multi-jurisdictional service areas”
`(claims 1, 11, 23 of ’352 patent)
`
` “portion” (claim 20 of ’946 patent;
`claims 7, 8, 9, 19, 20, 21 of ’352 patent)
`
`
`
` “index of jurisdictional databases”
`(claim 7 of ’352 patent) / “index of a
`multijurisdictional digital parcel map
`database” (claims 9, 19, and 20 of ’352
`patent)
`
`“spatial query” (claim 20 of the ’946
`patent)
`
`“involving, as needed, city, state, zip
`code and Assessor's Parcel Number”
`(claim 20 of the ’946 patent)
`
`“surrounding parcels”
`
`(claims 1, 9 and 12 of the ’352 patent)
`
`“client computer”
`
`(claim 1 of the ‘352 patent)
`
`BSI Proposed Construction and Supporting
`Evidence
`
`BSI’S PROPOSED CONSTRUCTION
`
`A database consisting of multiple jurisdictional
`databases supplied by sponsoring jurisdictions.
`
`BSI’S PROPOSED CONSTRUCTION
`
`subsets of information in a database describing
`individual land parcels within geographic areas,
`corresponding to one or more jurisdictional areas,
`arranged with reference to a catalogue or listing of
`resources
`
`BSI’S PROPOSED CONSTRUCTION
`
`Plain and Ordinary Meaning; No construction is
`necessary.
`
`BSI’S PROPOSED CONSTRUCTION
`
`Plain and Ordinary Meaning; No construction is
`necessary beyond that provided in other
`constructions.
`
`A request for information that includes the selection
`of geographic features based on a location or spatial
`relationship. Other non-spatial attributes may be
`included in the query.
`
`Plain and Ordinary Meaning. No construction
`necessary.
`
`Plain and Ordinary Meaning. No construction
`necessary.
`
`Plain and Ordinary Meaning. No construction
`necessary.
`
`- 9 -
`
`Page 10 of 38
`
`
`
`
`
`
`
`24.
`
`Having reviewed the Patents and file histories, it is my opinion that the
`
`constructions proposed by Boundary Solutions reflect how one skilled in the art would have
`
`understood the disputed patent claim terms as of January 2002.
`
`25.
`
`For those terms that Boundary Solutions argues are “plain and ordinary”
`
`meaning, it is my opinion that one skilled in the art after reading the specification and file
`
`history would not interpret those terms any differently from the lay understanding of the words.
`
`I understand that CoreLogic contends that five of those terms are ones that the Court should
`
`construe. In the following paragraphs, I provide the reasons why I think the terms do not have
`
`the meanings claimed by CoreLogic.
`
`26.
`
`CoreLogic interprets “associated parcel attribute data linked to a non-geographic
`
`database” to mean “parcel information (e.g. tax and building data) that is stored in a database that
`
`does not contain information describing the shape of the parcel.” My understanding of this is that
`
`CoreLogic argues that non-geographic attribute information must be stored in a separate database
`
`from the parcel boundary data. This term appears in the preamble of claim 1 of the ‘957 patent as
`
`follows: “An interactive computer implemented method for retrieving geographic parcel
`
`boundary polygon maps and associated parcel attribute data linked to a non-graphic database,
`
`wherein the data is acquired electronically.” First, I presume that “describing the shape of the
`
`parcel” is meant to mean having the vectors and coordinates that define the location of the
`
`parcel. Even with that clarification, CoreLogic’s construction adds a requirement that I do not
`
`think is needed. Specifically, nothing in the claim language requires physical “linking” To me,
`
`reading the patents as a whole, the language of the claim covers the situation where non-
`
`geographic information may appear in a table in a relational database linked to another table in
`
`the same database that has the vectors and coordinates information that defines the shape of the
`
`parcel boundary polygon. In other words, “linking” can be logical, rather than physical and thus
`
`- 10 -
`
`Page 11 of 38
`
`
`
`
`
`requires no specific storage arrangements. While a relational database may be stored together, it
`
`still involves the “linking” of a non-geographic database (the attribute information) to geographic
`
`information. In fact, the graphic database described in the patents always includes at least one
`
`piece of non-geographic information, the parcel’s APN, which in turns links to the other non-
`
`geographic data.
`
`27.
`
` Throughout the patent, the process of bringing the geographic and non-
`
`geographic information into the single location “server” or “portal” is described. Indeed, in a
`
`non-limiting definition, the specification defines the NPDP as “National Online Parcel-Level
`
`Map Data Portal, as “an internet warehouse that optimizes online delivery of parcel-level maps
`
`and linked attribute data.” 2:32-34. The specification further describes a specific embodiment
`
`where the graphic and non-graphic database are maintained in a single database. 3:44-48. (“This
`
`non graphic database is associated, parcel by parcel, with the graphic database, stored in the form
`
`of a single DBMS file, the records either generated by public providers or by commercial sector
`
`sources.”). The specification further explains that having both geographic and non-graphic data
`
`stored in a single database allows for standardized APN geocodes to work. 3:49-55 (“This
`
`configuration of graphic boundary segments and textural attribute assignments makes automated
`
`search of a digital spatial database possible. When a tax record with matching address values is
`
`found, the APN in the attribute table's index field is used to access the graphic database (all the
`
`parcel boundary segments) to find all boundary segments with this matching geocode.”) A
`
`DBMS was well known in the art. One typical definition is: “A database management system
`
`(DBMS) is system software for creating and managing databases. The DBMS provides users and
`
`programmers with a systematic way to create, retrieve, update and manage data.”
`
`http://searchsqlserver.techtarget.com/definition/database-management-system. The conception of
`
`- 11 -
`
`Page 12 of 38
`
`
`
`
`
`the NPDP as including linked tables, as opposed to hyperlinks which might take one to an
`
`entirely different database, is clearly seen in the specification’s description of the response to a
`
`user’s entry of an address:
`
`In an embodiment of the invention, as part of the basic function, an end
`user seeking only a subset of parcel-level data, enters a street address
`including the city, state, street name and/or the number of the desired
`parcel into a window displayed on a computer screen. According to the
`state entered, a folder is electronically accessed containing all spatial data
`files for that state including supporting tax record databases for each
`agency for which there is stored spatial data.
`
`If there is an address match, the pertinent parcel displays as a highlighted
`polygon in the center of the screen along with surrounding parcels. In
`addition, the parcel's linked tax record is displayed.
`
`4:47-59. If a separate database, or a separate server, was to be accessed to obtain the linked tax
`
`record, such a process would have been described. It is also clearly shown in an excerpt
`
`describing the location of both the graphic data and the Parcel Record Attribute Database
`
`(PRAD). The patent describes that the “(PRAD) 104 serves as the above non-graphic database.”
`
`8:13-14.
`
`7:55-61.
`
`Each jurisdictional directory at a minimum contains a graphic database
`derived from public sector sources. Typically this is a countywide parcel
`map (parcel polygons geocoded with APN s) provided by a single taxing
`authority, and provided in SHP-ESRI Arc View native spatial data file
`format. Most often, this file will contain a polygon for every parcel in the
`county.
`
`When the user selects a desired jurisdiction (city, township, town,
`administrative area or other place name), the FIPS number of the county in
`which the jurisdiction is located is retrieved from JLT 102. This FIPS
`number is used to access the NPDP county directory named by a matching
`FIPS number. The non-graphic database (Parcel Record Attribute
`Database-PRAD) located in this directory is searched in step 104 in the
`selected jurisdiction.
`
`9:23-30. If the PRAD resides in the same directory as the parcel boundary data, they perforce are
`
`- 12 -
`
`Page 13 of 38
`
`
`
`
`
`in the same database. These embodiments suggest that parts of the database, such as tables of tax
`
`and building attributes within a relational database are “non-graphic databases,” that are linked to
`
`“geographic parcel boundary polygon maps and associated parcel attribute data.” Nonetheless,
`
`they may not be “stored in a database that does not contain information describing the shape of
`
`the parcel” as required by CoreLogic’s construction.
`
`27.
`
`CoreLogic interprets “applications programs” as “a program that displays maps
`
`and accesses a parcel database.” While I agree that these are applications programs, it may be
`
`that different applications access the database and display the map. It also may be that the
`
`application may have many other functions, such as a web browser that might not be considered
`
`as a program “that displays maps and accesses a parcel database.”
`
`28.
`
`CoreLogic interprets “jurisdiction look up table” to mean “a single tabular file
`
`containing the following fields: state, jurisdiction, county name, county FIPS number, accuracy,
`
`publication date, percent complete, ortho scale, ortho resolution, and update frequency.” The
`
`term “look up table” is one well know in the art. It need not be a single tabular file and it
`
`certainly does not need to contain specific specified fields. My reading of the specification is
`
`that the patentee was describing a particular embodiment of the invention in the portion relied
`
`upon by CoreLogic. This is made clear by the use of capitalization, the reference to the
`
`patentee’s own particular implementation, the NPDP, and the reference to an element of an
`
`illustrative figure, Fig. 2, of the NPDP Standard Feature Operation. 8:25 (“Jurisdiction Lookup
`
`Table (JLT) 102”); 9:14 (“NPDP Jurisdiction Lookup Table (JLT) 102)”.
`
`29.
`
`CoreLogic interprets “jurisdiction” to mean “a named territory, e.g. city,
`
`township, town, administrative area or other place name.” To me, the plain and ordinary
`
`meaning of the term “jurisdiction” refers to a governmental entity that is responsible for a
`
`- 13 -
`
`Page 14 of 38
`
`
`
`
`
`geographic area. “A named territory” could refer to jurisdictions that the patentee does not
`
`appear to intend. For example, in my opinion, one skilled in the art would not refer to a zip code
`
`as a jurisdiction, there is no governmental entity responsible for a zip code – the U.S. Postal
`
`Service maintain zip code maps to speed delivery of mail. The reference to administrative area or
`
`other place name seems incongruous as well. While the patent specification uses those
`
`examples, my opinion is that reading the patent as a whole shows that the term “jurisdiction”
`
`should bear its ordinary meaning. It appears to me that the reference to other place names is a
`
`reference to the fact that a user might want to search on place names that either do not have a
`
`specific address, or can be identified without reference to the address. For example, one might
`
`search a San Jose map by inputting San Jose State University. In general street mapping
`
`applications such as Bing or Google maps these place names, often called “Points of Interest.”
`
`Such a search is equivalent to an address search using a city and state name in that the software
`
`would likely locate the university address; then input San Jose, California into the “jurisdiction
`
`look up table.”
`
`30.
`
`The primary reference to “jurisdiction” appears in connection with the jurisdiction
`
`look up table. That table is described as having as an input an address, which includes a city (or
`
`town or township) name and a state name (these items described as “values”), and having as an
`
`output a “[numerical] jurisdictional identifier” used to find the portion of the database in which
`
`to search for the appropriate parcels to display. (“The JLT makes it possible for the state and
`
`jurisdiction values stated in an address entry transaction to be used to determine the pertinent
`
`county in which it is located. Hence, by the table also containing the county's FIPS number, the
`
`appropriate county directory is automatically accessed for data retrieval purposes.”). Indeed, the
`
`patentee wasfocused on local jurisdictions, contrasting states and jurisdictions: “The end user
`
`- 14 -
`
`Page 15 of 38
`
`
`
`
`
`first enters the street address number, street name, city name and state name into a provided data
`
`entry window, step 101. This same process can also be done using pick lists in which the user
`
`first selects a state and a jurisdiction from displayed pick lists. Given the user selected
`
`jurisdiction, a street pick-list display appears. The user then selects street name and street
`
`numbers from additional pick-list displays.” 9:3-10. In my opinion, the “selected jurisdiction”
`
`referenced in the second phrase, must include both a city and state name. Similarly, in another
`
`expcert:
`
`When the user selects a desired jurisdiction (city, township, town,
`administrative area or other place name), the FIPS number of the county in
`which the jurisdiction is located is retrieved from JLT 102. This FIPS
`number is used to access the NPDP county directory named by a matching
`FIPS number. The non-graphic database (Parcel Record Attribute
`Database-PRAD) located in this directory is searched in step 104 in the
`selected jurisdiction. … Upon selection of desired street name, PRAD is
`queried to identify all street address numbers assigned to the selected
`street name (within the selected jurisdiction).
`
`
`9:23-36. Since the selected jurisdiction is singular, it cannot be interpreted as both the
`
`state and the city within it.
`
`31.
`
`CoreLogic argues that “highlighted” means “changing the color of the
`
`parcel polygon to a brighter or different color from surrounding parcels also displayed.”
`
`While the specification gives these examples, I read them to not define the term; they just
`
`provide examples of how to highlight a parcel. In my opinion, one skilled in the art
`
`would read the claims should be read with the term’s ordinary meaning. First, the
`
`specification explains the purpose of highlighting is simply to allow the user to identify
`
`the property of interest. Abstract (“A user enters a street address into an appropriate
`
`screen window to call up and view road right-of-ways, all parcel boundaries and the
`
`"exact" address location as a highlighted parcel area.”) The portion of the specification
`
`- 15 -
`
`Page 16 of 38
`
`
`
`
`
`on which CoreLogic relies relates to an embodiment of the invention, specifically the
`
`patentee’s own system, the NPDP. 2:58-63 (“If there is a match, the NPDP displays the
`
`road right-of-ways, all parcel boundaries within a select distance, the "exact" address
`
`location highlighted, the pertinent parcel polygon changing the color to a brighter or
`
`different color from surrounding parcels also displayed.”)
`
`32.
`
`CoreLogic proposes that “index of jurisdictional databases” / “index of a
`
`multijurisdictional digital parcel map database” be construed as “a single tabular file containing
`
`identifiers of jurisdictional databases.” CoreLogic cites the following in support of this
`
`construction: ’957 patent at 7:23-30; 8:25-32 and 02/03/2006 Remarks (’957 file history) at 12.
`
`None of the excerpts refer to an index or indices, except to the extent of describing the
`
`jurisdiction look up table as indexed for identification of the pertinent jurisdictional database.
`
`The only reference to a single tabular file is in connection with the jurisdiction look up table,
`
`which as I mentioned above, was simply an illustrative example. One definition of a database
`
`index is a “data structure that improves the speed of data retrieval operations on a