Trials@uspto.gov
`571-272-7822
`
`
`
`
`
`Paper No. 7
`Filed: May 11, 2016
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`WTS PARADIGM, LLC,
`Petitioner,
`
`v.
`
`EdgeAQ, LLC,
`Patent Owner.
`____________
`
`Case IPR2016-00199
`Patent 7,805,461 B2
`____________
`
`
`
`Before JAMESON LEE, LYNNE E. PETTIGREW, and
`JOHN F. HORVATH, Administrative Patent Judges.
`
`HORVATH, Administrative Patent Judge.
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`
`I. INTRODUCTION
`
`A. Background
`WTS Paradigm, LLC (“Petitioner”) filed a Petition (Paper 1, “Pet.”)
`to institute inter partes review of claims 1–11 of U.S. Patent No. 7,805,461
`B2 (Ex. 1004, “the ’461 patent”). EdgeAQ, LLC, (“Patent Owner”) filed a
`Preliminary Response (Paper 6, “Prelim. Resp.”).
`Upon consideration of the Petition and Preliminary Response, we are
`persuaded, under 35 U.S.C. § 314(a), that Petitioner has demonstrated a
`reasonable likelihood that it would prevail in showing the unpatentability of
`claims 1–11 of the ’461 patent. Accordingly, we institute an inter partes
`review of these claims.
`
`B. Related Matters
`Petitioner identifies the following as a matter that could affect, or be
`affected by, a decision in this proceeding: WTS Paradigm, LLC v. EdgeAQ,
`LLC, Case No. 3-15-cv-00330 (W.D. Wis.). Pet. 1. Patent Owner identifies
`the same matter. Prelim. Resp. 1.
`
`C. Evidence Relied Upon1
`
`Reference
`
`Greef
`
`Weida
`
`Bader
`
`US 6,397,221
`
`US 6,108,670
`
`US 5,467,471
`
`Issue Date
`
`May 28, 2002
`
`Aug. 22, 2000
`
`Nov. 14, 1995
`
`Exhibit
`
`Ex. 1005
`
`Ex. 1009
`
`Ex. 1011
`
`US 6,442,566
`Altman
`
`1 Petitioner also relies upon the Declaration of Deborah McGuinness (Ex.
`1001).
`
`Aug. 27, 2002
`
`Ex. 1012
`
`2
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`
`
`D. The Asserted Grounds of Unpatentability
`Petitioner asserts the following grounds of unpatentability:
`
`Reference(s)
`Greef, Bader, and Weida
`Greef, Bader, Weida, and Altman
`
`Basis
`§ 103(a)
`§ 103(a)
`
`Claims Challenged
`1–11
`1–11
`
`
`
`II. ANALYSIS
`
`A. The ’461 Patent
`The ’461 patent relates to a database induction process for creating a
`frame-based knowledge tree using a processor-based system. Ex. 1004,
`2:45–48. A frame based knowledge tree is a tree-like structure or graph,
`where each node of the tree is known as a frame. Id. at 1:38–40. Each node
`or frame of the tree contains a set of attributes or slots that characterize the
`frame. Id. at 7:57–62. The characterizing slots can be single slots (i.e., a
`single attribute having one or more values), compound slots (i.e., two or
`more attributes and allowable combinations of their attribute values), or
`conditional slots (i.e., a slot whose value determines which of several sub-
`trees to include in the frame based knowledge tree). Id. at 7:62–8:10. Frame
`based knowledge trees can be used, for example, to illustrate product
`information such as the makes, models, types, features, options, and
`limitations of different products or services available from one or more
`vendors. Id. at 1:18–23.
`
`3
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`
`Figure 4 of the ’461 patent is reproduced below:
`
`
`Figure 4 is an illustration of a frame based knowledge tree. Ex. 1004, 6:63–
`64. The tree contains two nodes 400 and 405, referred to as feature frames 1
`and 2, where each node is characterized by an attribute (e.g., attributes 410
`and 415, respectively) of a product that is represented by the knowledge tree,
`and each attribute can have any of n unique values. Id. at 6:67–7:1.
`The database induction process uses one or more user interfaces that
`allow an induction module to create the frame based knowledge tree from
`user input and product information stored in one or more vendor databases.
`Ex. 1004, 2:52–56, 2:65–3:1.
`
`4
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`
`Figure 2 of the ’461 patent is reproduced below:
`
`
`Figure 2 is a screen shot of a user interface used in the database induction
`process described in the ’461 patent. Ex. 1004, 2:15–17. The induction
`process can be interactive, automatic, or both. Id. at 5:41–50, 5:65–6:18. In
`interactive mode, the induction process presents a user with a list of product
`attributes (i.e., available questions 200), receives a user selection and
`ranking of product attributes (i.e., split questions 201), and generates the
`frame based knowledge tree to reflect the user’s selection and ranking of
`attributes. Id. at 5:41–47, 5:65–6:1, 6:19–46. In automatic mode, the
`induction process receives user generalization and optimization criteria, and
`generates the knowledge tree from product attribute data based on the
`received criteria. Id. at 5:47–56. Generalization and optimization criteria
`can include domain knowledge (e.g., typical attributes used to characterize a
`given product or product type) or the maximum number of attributes that are
`
`5
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`permitted to characterize a single node or frame in the frame based
`knowledge tree. Id. at 6:47–7:35, 8:11–29.
`Claims 1 and 6 of the ’461 patent are independent claims. Claim 1 is
`representative of the challenged claims, and is reproduced below. Other
`challenged claims depend directly or indirectly from claim 1 or claim 6.
`1. A database processing system comprising:
`
`an induction module configured to:
`
`i.) access specification data for at least one
`product from one or more vendor databases,
`
`ii) identify attributes of the specification data
`to be inducted into a frame-based knowledge tree by
`querying the one or more vendor databases table for
`the specification data regarding the attributes, and
`
`iii) determine a location within the frame-
`based knowledge tree to place any inducted
`attributes of the specification data, and further
`configured to present pre-defined questions about
`the specification data to a user to identify a set of
`SQL queries to be answered to construct the frame
`based knowledge tree;
`
`a processor dimensioned and configured to enable
`user interaction with the induction module such that
`a frame-based knowledge tree is automatically
`constructed with the specification data in response
`to the user interaction, wherein the interaction
`comprises receiving input answers from the user in
`response to the pre-defined questions about the
`specification data provided to the user.
`
`Ex. 1004, 11:29–52.
`
`
`
`6
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`
`B. Claim Construction
`The Board interprets claims of an unexpired patent using the broadest
`reasonable interpretation in light of the specification of the patent in which
`they appear. See 37 C.F.R. § 42.100(b); In re Cuozzo Speed Techs., LLC,
`793 F.3d 1268, 1275–79 (Fed. Cir. 2015), cert. granted sub nom. Cuozzo
`Speed Techs., LLC v. Lee, 136 S. Ct. 890 (Mem.) (2016). Consistent with
`the rule of broadest reasonable interpretation, claim terms are given their
`ordinary and customary meaning, as would be understood by one of ordinary
`skill in the art in the context of the entire disclosure. See In re Translogic
`Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). Only those terms that are
`in controversy need to be construed and only to the extent necessary to
`resolve the controversy. See Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`200 F.3d 795, 803 (Fed. Cir. 1999).
`1. frame or frame-based knowledge tree
`Petitioner asks us to construe the term “frame” to mean “a structured
`representation of an object or a class of objects.” Pet. 3. Petitioner contends
`this construction is consistent with how the term is used in the ’461 patent
`and in US 6,810,401, which is incorporated by reference into the ’461
`patent, and with how the term would have been understood by a person of
`ordinary skill in the art at the time of the invention. Id.
`Patent Owner argues that because the term “frame” only appears in
`the claims as part of the larger “frame-based knowledge tree,” Petitioner’s
`proposed construction should be rejected as not having been made in the
`context of the claims. Prelim. Resp. 5. Patent Owner further argues no
`construction is needed for the term “frame-based knowledge tree” because
`its meaning is adequately explained in the Specification. Id. at 6.
`
`7
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`Alternatively, Patent Owner argues the term “frame-based knowledge tree”
`should be construed to mean “a model of knowledge in a tree-like structure
`where each node of the tree is known as a frame.” Id. Patent Owner does
`not request construction for any other term.
`We agree with Patent Owner that because the term “frame” only
`appears in the claims as part of the larger “frame-based knowledge tree,”
`only the latter term should be construed. The ’461 patent discloses
`modelling “product knowledge in a tree like structure where each node of
`the tree is known as a frame,” and where each node “inherits properties from
`its parent node(s).” Ex. 1004, 1:38–43. The ’461 patent further discloses
`generating a product knowledge tree “made up of several nodes where each
`node is represented by a frame,” where “[e]ach frame contains a set of
`attributes that specializes the frame,” and where “[e]ach frame may also
`have any number . . . of child frames.” Id. at 7:57–61.
`Accordingly, for purposes of this Decision, we construe a “frame-
`based knowledge tree” to mean “a tree-like graph used to hierarchically
`represent the attributes of an object, where each node of the graph is
`characterized by one or more object attributes.” This construction is not
`only consistent with how the term is used in the Specification, and in US
`6,810,401, which is incorporated by reference into the Specification, see Ex.
`1004, 1:38–46; Ex. 1006, 4:67–5:3, but is also consistent with how the term
`was used by persons of ordinary skill in the art at the time of the invention.
`See Ex. 1007, 1; Ex. 1008, 5.
`
`8
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`
`2. presenting pre-defined questions about specification data to
`a user to identify a set of SQL queries to be answered to
`construct the frame-based knowledge tree
`Neither party requests an explicit construction for this term.
`Petitioner’s mapping of the prior art implicitly construes the term to mean
`presenting a user with a list of product attributes whose selection permits the
`determination of SQL queries needed to populate the frames of a frame-
`based knowledge tree that is constructed based on the user’s selections. See
`Pet. 27–29, 35–38. Patent Owner’s argument that although Bader teaches
`selecting keywords from a relational database to form a hierarchical
`database based on the selected keywords, Bader “show[s] nothing to indicate
`that pre-defined questions about specification data are being presented to a
`user to identify a set of SQL queries to be answered,” implicitly construes
`the term to mean identifying a pre-defined set of SQL queries based on the
`user’s answers to pre-defined product attribute questions. Prelim. Resp. 10.
`We determine that construction of this term is necessary for purposes of this
`Decision.
`As discussed above, the Specification of the ’461 patent discloses
`presenting a user with a list of available questions 200 to identify product
`attributes to be included in a product knowledge tree. See Ex. 1004, 4:60–
`67, Fig. 2. The list of questions can be, for example, “all of the questions
`that are generally asked in a particular industry to describe a certain
`product.” Id. at 9:9–11. Each question can address “a different attribute of
`the product.” Id. at 9:11–13. Each question can be presented by prompting
`the user to: “[p]lease select your [attribute].” Id. at 9:11–25. A user,
`presented with a list of product attributes (available questions 200), can
`select and optionally rank them (e.g., using “move up” and “move down”
`
`9
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`controls) to determine a ranked list of product attributes (split questions
`201). Id. at 5:62–6:11, Fig. 2. The ranked list of product attributes is then
`used to generate a product knowledge tree by splitting the tree into separate
`nodes, where each node is characterized by one or more product attributes.
`Id. at 5:41–47, 6:19–24, 7:45–61. Once the nodes of the product knowledge
`tree are determined from split questions 201, SQL queries needed to
`populate each node with the product attributes characterizing that node are
`determined. Id. at 9:43–52, Fig. 5. For example, to populate the nodes of
`the product knowledge tree shown in Figure 6, which was generated by
`asking a user to select and rank a product’s color, size, and shape attributes,
`the SQL queries shown in Figure 5 are determined. See id. at Figs. 5 and 6.
`Accordingly, for purposes of this Decision, we construe “presenting
`pre-defined questions about specification data to a user to identify a set of
`SQL queries to be answered to construct the frame-based knowledge tree” to
`mean “presenting a user with a list of product attributes whose selection
`permits the determination of SQL queries needed to populate the frames of a
`frame-based knowledge tree that is constructed based on the user’s attribute
`selections.”
`C. Alleged Obviousness of Claims 1–11 Over Greef. Bader, and
`Weida
`Petitioner alleges claims 1–11 of the ’461 patent are unpatentable over
`the combination of Greef, Bader, and Weida. Pet. 7–56. We have reviewed
`the Petition and Patent Owner’s Preliminary Response, and are persuaded
`that Petitioner has demonstrated a reasonable likelihood of establishing the
`unpatentability of claims 1–11 over the combination of Greef, Bader, and
`Weida.
`
`10
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`
`1. Overview of Greef
`Greef discloses “computer software programs for generating frame-
`based, hierarchical databases from tabular arranged product data conforming
`to generic relational database formats.” Ex. 1005, 4:30–34. An example of
`product data conforming to generic relational database formats is shown in
`Figure 17 of Greef, which is reproduced below.
`
`
`
`Figure 17 is an illustration of tabularly organized camera product data. Id. at
`7:3–5.
`Greef automatically identifies category and sub-category information
`from the product data, e.g., by identifying “class” and “type” attributes from
`column headers in the product table, and automatically uses that information
`to generate a “frame-based, hierarchical structure for the data.” Ex. 1005,
`29:59–30:3. For example, Figure 18, reproduced below, shows a frame-
`based knowledge tree automatically generated from the camera product data:
`
`11
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`
`
`Figure 18 is a frame-based, camera product knowledge tree. For product
`tables lacking “class” and “type” column headers, Greef discloses
`identifying product category and sub-category information from a term
`reference look-up. Id. at 30:32–41.
`
`In addition to generating a product knowledge tree from category and
`sub-category information, Greef discloses generating such a tree from a pre-
`existing product data hierarchy. See Ex. 1005, 12:1–10, 14:35–42, Figs. 2,
`3, 5.
`2. Overview of Bader
`Bader discloses a computer based system “for converting a database
`that is maintained as relational to one that is hierarchical,” and for creating a
`tree showing the structure of the hierarchical database. Ex. 1011, 3:34–37,
`12:26–31. For example, Bader discloses converting company information
`
`12
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`that is maintained in a relational database table into a hierarchical database
`having the tree structure shown in Figures 14a and 14b. See id. at 11:48–
`12:40, Figs. 12, 14a, 14b.
`Bader converts a relational database to a hierarchical database by
`receiving user selected attributes or keywords from the relational database
`table. Ex. 1011, 11:53–60. These user selected attributes are the elements
`upon which the hierarchical database and its tree structure are generated. Id.
`For each selected attribute, the number of unique attribute values is
`determined from the relational database table, and attributes having fewer
`unique attribute values are placed at higher levels in the hierarchical
`database and its tree structure. Id. at 11:61–67.
`3. Overview of Weida
`Weida is a continuation-in-part of US 5,953,726 (“Carter”), and
`incorporates the contents of Carter by reference. Ex. 1009, 1:12–17. Carter
`discloses a graphical method for adding, deleting or modifying hierarchical
`relationships in a multiple inheritance concept hierarchy, i.e., in a frame-
`based knowledge tree. Ex. 1010, Abstract, 1:30–45. Carter’s method
`involves operations that are performed by both a user and a computer. Id. at
`6:42–45. For example, in a computer knowledge tree, when a user deletes a
`color attribute from a higher level node (e.g., a computer node), the
`computer prompts the user with a query box asking whether the deleted
`attribute should be moved to the children of that higher level node (e.g.,
`mobile and desktop nodes). This is shown, for example, in Figure 27 of
`Carter, which is reproduced below.
`
`13
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`
`
`Figure 27 is an illustration of a query screen presented to a user to prompt
`the user whether to move an attribute deleted from a parent node to the
`children of that parent node. Id. at 3:49–50, 6:59–65.
`4. Comparison of Claims 1–11 to the Combination of Greef, Bader,
`and Weida
`Claim 1 requires a database processing system that includes an
`induction module configured to (i) access specification data for at least one
`product from one or more vendor databases, (ii) identify attributes of the
`specification data to be inducted into a frame-based knowledge tree by
`querying the one or more vendor databases table for the specification data
`regarding the attributes, and (iii) determine a location within the frame-based
`knowledge tree to place any inducted attributes of the specification data.
`Ex. 1004, 11:29–40.
`Greef teaches a computer-implemented method for converting product
`data stored in a relational database into a frame-based product knowledge
`tree. See Pet. 30; Ex. 1005, 29:25–31, Title, Abstract. Greef teaches
`generating the product knowledge tree by accessing product data from one
`
`14
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`or more vendor databases, identifying product attributes to be inducted into
`the product knowledge tree, and determining the location for those attributes
`in the product knowledge tree. See Pet. 22–27, 31–35, Ex. 1005, 29:25–
`32:65, Figs. 17–20.
`Claim 1 further requires the induction module be configured to
`present pre-defined questions about the specification data to a user to
`identify a set of SQL queries to be answered to construct the frame based
`knowledge tree. Ex. 1004, 11:41–44. As discussed in § II.B.2 supra, we
`have construed this term for purposes of this Decision to mean “presenting a
`user with a list of product attributes whose selection permits the
`determination of SQL queries needed to populate the frames of a frame-
`based knowledge tree that is constructed based on the user’s attribute
`selections.”
`Greef teaches identifying the category and sub-category information
`needed to generate the product knowledge tree from “class” and “type”
`column headers in the product table, or alternately, by reading a term
`reference look-up. See Pet. 9, 12; Ex. 1005, 29:8–14, 29:59–30:3, 30:33–42.
`Bader teaches identifying the category and sub-category information needed
`to generate a tree representing data in a relational database from user
`selected attributes (i.e., column headers in the relational database table). See
`Pet. 12–15, 35–38; Ex. 1011, 11:53–12:40; Figs. 12, 13a–e, 14a–b,
`15a–b. Weida, via its incorporation of Carter, teaches adding, deleting, or
`modifying the contents of a knowledge tree by asking a user pre-defined
`questions. See Pet. 20–21, Ex. 1009, 1:12–17, Ex. 1010, 6:42–45, 6:59–65,
`Figs. 2, 27.
`
`15
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`
`Petitioner identifies several reasons why a person of ordinary skill in
`the art would have found it obvious to modify Greef, based on the teachings
`of Bader and Weida, to present a user with pre-defined questions about
`product data to identify a set of SQL queries to be answered to construct the
`frame based knowledge tree as required by claim 1. For example, Petitioner
`alleges a person skilled in the art would have recognized the impracticality
`of depending on a term reference lookup to identify category and sub-
`category information when “class” and “type” column headers are missing
`from a product table (as taught by Greef), and would have further recognized
`that this problem could have been solved by prompting a user to select data
`attributes to make those identifications (as taught by Bader). See Pet. 15;
`Ex. 1001 ¶¶ 54, 59–61. Petitioner also alleges a person skilled in the art
`“would have known that asking the user to identify the attributes on which
`the hierarchy should be based would have supported potential customization
`of the hierarchy to suite [sic] the intended use.” Id. Petitioner further
`alleges that it would have been obvious to a person skilled in the art to
`prompt the user to identify product attributes by asking the user pre-defined
`questions (e.g., “Select the highest-level attribute”), because “[s]uch a means
`for soliciting user input was well known and would have been no more than
`a routine, predictable modification to Greef.” Pet. 19–20; Ex. 1001 ¶ 69.
`For example, Petitioner’s expert declares that Weida teaches one example of
`soliciting user input via pre-defined questions, and that a person skilled in
`the art would have known that input for the Greef system, as modified by
`Bader, “could be sought by presenting predefined questions asking the user
`to make selections via a graphical user interface, just as in Weida/Carter.”
`Ex. 1001 ¶ 69. In addition, Petitioner alleges that “[i]n order to construct the
`
`16
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`frame-based knowledge tree based on the user’s input, the system needs to
`pull data from the table that corresponds to the user’s input,” and that a
`person skilled in the art “would almost certainly have used SQL queries to
`interact with the table (in building the hierarchy) because it was the industry
`standard at the time of the claimed inventions.” Pet. 28–29; Ex. 1001 ¶¶ 71,
`106.
`
`Claim 1 further requires a processor configured to enable user
`interaction with the induction module, where the user interaction comprises
`receiving input answers in response to the pre-defined questions about the
`specification data, and to automatically construct a frame-based knowledge
`tree with the specification data in response to the user interaction. Ex. 1004,
`11:45–52.
`Greef and Bader both teach computer-implemented methods for
`automatically constructing a tree structure representing data stored in a
`relational database. See Pet. 13, 29–30; Ex. 1005, 28:43–53, 29:25–31; Ex.
`1011, 1:8–9, 3:34–37. Greef teaches automatically generating the tree by
`identifying category and sub-category information from “class” and “type”
`column headers in a relational database table or by reading a term reference
`lookup. See Pet. 9, 12, 29–30; Ex. 1005, 29:8–14, 29:59–30:3, 30:33–42.
`Bader teaches automatically generating the tree by identifying category and
`sub-category information from user selected data attributes (i.e., column
`headers in a relational database table). See Pet. 12–15, 29–30, 35–38; Ex.
`1011, 11:53–12:40; Figs. 12, 13a–e, 14a–b, 15a–b. As noted supra,
`Petitioner has identified several reasons why a person of ordinary skill in the
`art would have found it obvious to modify Greef’s computer-implemented
`method, based on the teachings of Bader, so that Greef’s processor
`
`17
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`automatically constructs the frame-based knowledge tree from the product
`data in response to user interaction in the form of answers to pre-defined
`questions about the product data as required by claim 1. See Pet. 15, 19–20;
`Ex. 1001 ¶¶ 54, 59–61, 69.
`Similarly to claim 1, discussed above, Petitioner identifies teachings
`in Greef and Bader corresponding to the limitations in claims 2–11, and
`provides reasons why a person of ordinary skill in the art would have
`modified Greef based on the teachings of Bader to arrive at the subject
`matter of claims 2–11. See Pet. 40–56.
`Patent Owner argues that, although Bader “describes a process for
`converting from a relational database to a hierarchical database with user
`selection of keywords from the relational database,” this description fails “to
`indicate that pre-defined questions about specification data are being
`presented to a user to identify a set of SQL queries to be answered.” Prelim.
`Resp. 10.
`We are not persuaded by Patent Owner’s argument. As discussed in
`§ II.B.2 supra, we have construed “presenting pre-defined questions about
`the specification data to a user to identify a set of SQL queries to be
`answered to construct the frame-based knowledge tree,” for the purposes of
`this Decision, to mean “presenting a user with a list of product attributes
`whose selection permits the determination of SQL queries needed to
`populate the frames of a frame-based knowledge tree that is constructed
`based on the user’s attribute selections.” For example, the Specification
`discloses prompting the user with pre-defined questions of the form “Please
`select your [product attribute].” Ex. 1004, 9:9–25. “[T]he user’s response to
`the prompt regarding the [product] attribute . . . splits the knowledge tree
`
`18
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`into . . . different frames . . . off of the root frame.” Id. at 10:29–33. “If the
`user has specified splitting attributes, then the module 120 queries the
`vendor’s database tables for unique values associated with that new node,”
`i.e., the new frame off the root node. Id. at 7:51–54. The induction module
`does this by identifying (i.e., determining) “the set of SQL queries that
`require responses in order for the frame based knowledge tree to be
`constructed.” Id. at 9:43–47.
`Bader teaches receiving user selected data attributes (i.e., relational
`database column headers), and using the user selected attributes to construct
`a tree representing the data stored in the relational database. See Ex. 1005,
`11:53–12:40. Petitioner alleges it would have been obvious to a person of
`ordinary skill in the art at the time of the invention to modify Greef, based
`on the teachings of Bader, to prompt a user to select data attributes to
`identify the category and sub-category information upon which Greef’s
`product knowledge tree is generated because doing so would have been
`more practical than reading a term reference lookup as taught by Greef, and
`would have allowed Greef’s product knowledge tree to be customized for
`different purposes. See Pet. 15; Ex. 1001 ¶¶ 54, 59–61. Petitioner further
`alleges the means for soliciting such user input (e.g., asking a user to select
`from a list of product attributes presented on a display) were well known in
`the art at the time, and that modifying Greef to incorporate such means
`would have been no more than routine and predictable. Pet. 19–20; Ex.
`1001 ¶ 69. For example, Petitioner alleges Weida teaches a method for
`doing so. Pet. 20–21; Ex. 1001 ¶ 69. Finally, Petitioner alleges that it would
`have been obvious to a person or ordinary skill in the art at the time of the
`invention that Greef’s modified system would need to pull data from the
`
`19
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`relational database corresponding to the user’s selected input in order to
`construct the frame-based knowledge tree, and would have used SQL
`queries to pull the data because it was the industry standard at the time of the
`claimed inventions. See Pet. 28–29; Ex. 1001 ¶¶ 71, 106.
`Patent Owner argues the Petition “improperly contains substantive
`argument based on Carter . . . which is not identified as part of any of the
`proposed rejections,” and that although “Petitioner asserts that Carter is
`incorporated by reference in Weida, . . . no relevant portion of Carter is
`reproduced or set forth in Weida.” Prelim. Resp. 10.
`We are not persuaded by Patent Owner’s argument. Weida
`incorporates Carter by reference, effectively making Carter “part of [Weida]
`as if it were explicitly contained therein.” Advanced Display Systems, Inc. v.
`Kent State University, 212 F.3d 1272, 1282 (Fed. Cir. 2000). 2 Weida’s
`incorporation language broadly states: “The contents of the above identified
`[Carter] application are hereby incorporated by reference.” Ex. 1009, 1:12–
`
`2 Moreover, even assuming Weida does not properly incorporate Carter by
`reference, we would find on this record that Petitioner has demonstrated a
`reasonable likelihood of establishing the unpatentability of claims 1–11 over
`Greef, Bader, and Weida based solely on the disclosures in Greef and Bader.
`See In re Bush, 296 F.2d 491, 496 (CCPA 1961) (finding the Board can
`sustain a finding of unpatentability based on fewer than all of the references
`stated in the grounds of unpatentability); see also Application of Boyer, 363
`F.2d 455, 458 n.2 (CCPA 1966). Petitioner contends a person skilled in the
`art, modifying Greef based on the teachings of Bader to ask a user to select
`the product attributes to be used to construct a knowledge tree, would have
`known to ask pre-defined product attribute questions. Pet. 19–20; Ex. 1001
`¶ 69. Petitioner relies on Weida/Carter simply to substantiate that
`contention. Pet. 19–20; Ex. 1001 ¶ 69.
`
`
`
`20
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`18. Our reviewing Court has found such broad incorporation language
`effectively incorporates the entire contents of a referenced document. See
`Harari v. Lee, 656 F3d. 1331, 1335–1336 (Fed. Cir. 2011) (finding the
`entire contents of two applications were incorporated “by the broad and
`unequivocal language: “The disclosures of the two applications are hereby
`incorporate[d] by reference.”).
`
`Patent Owner also argues the Petition fails because Weida/Carter
`“addresses modification of an existing hierarchical database, not the creation
`of one,” and fails to indicate “that pre-defined questions about specification
`data . . . are being presented to a user to identify a set of SQL queries to be
`answered to construct a frame-based knowledge tree.” Prelim. Resp. 11.
`We are not persuaded by Patent Owner’s arguments. Petitioner does
`not rely on Weida for creating a frame-based knowledge tree. Rather,
`Petitioner relies on Weida for presenting a user with pre-defined questions
`about specification data, see Pet. 19–21, and relies on the combination of
`Greef, Bader, and Weida for doing so to identify a set of SQL queries to be
`answered to construct a frame-based knowledge tree. See Pet. 27–29.
`“Non-obviousness cannot be established by attacking references individually
`where the rejection is based upon the teachings of a combination of
`references.” In re Merck & Co., Inc., 800 F.2d 1091, 1097 (Fed. Cir. 1986).
`Rather, “[t]he test for obviousness is what the combined teachings of the
`references would have suggested to one of ordinary skill in the art.” In re
`Young, 927 F.2d 588, 591 (Fed. Cir. 1991). As to Patent Owner’s argument
`that the combination of Greef, Bader, and Weida fails to disclose presenting
`a user with pre-defined questions about specification data to identify a set of
`SQL queries to be answered to construct a frame-based knowledge tree
`
`21
`
`

`
`IPR2016-00199
`Patent 7,805,461 B2
`
`above, we addressed that argument supra, and are not persuaded for the
`reasons discussed there.
`Patent Owner further argues the Petition “improperly contains a
`citation to Altman (Ex. 1012), Petition at 38, which is not included in the
`first proposed combination of prior art,” i.e., Ground 1. Prelim. Resp. 11.
`We are not persuaded by Patent Owner’s argument. Although the
`claim chart provided in § III.B.4 of the Petition (supporting the challenge of
`claim 1 on Ground 1) contains a citation to Altman, see Pet. 38, Petitioner
`cites Altman merely as evidence su