UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`WTS Paradigm, LLC,
`
`Petitioner
`
`v.
`
`EdgeAQ, LLC,
`
`Patent Owner
`
`
`
`Case IPR: Unassigned
`
`Patent 7,805,461
`
`
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 7,805,461
`
`
`
`
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`United States Patent and Trademark Office
`P. O. Box 1450
`Alexandria, VA 22313-1450
`
`
`

`
`Table of Contents
`
`I. MANDATORY NOTICES (37 CFR § 42.8) ................................................. 1
`II. GROUNDS FOR STANDING AND IDENTIFICATION OF
`CHALLENGE (37 CFR § 42.104) ................................................................. 1
`A.
`Standing And Statutory Grounds For Each Claim ............................... 1
`B.
`Claim Construction .............................................................................. 3
`C. How The Claim Is Unpatentable .......................................................... 3
`D.
`Evidence Supporting Challenge ........................................................... 4
`III. THERE IS A REASONABLE LIKELIHOOD THAT THE
`CHALLENGED CLAIMS ARE UNPATENTABLE ................................... 4
`A. Description Of The Alleged Inventions ............................................... 4
`B. Ground 1: Claims 1–11 Are Unpatentable Under 35 USC § 103
`By The Combination of Greef, Bader, and Weida ............................... 7
`1.
`Background on the claimed subject matter ................................ 7
`2.
`Greef nearly anticipates the Challenged Claims ........................ 9
`3.
`In view of the prior art, Greef renders the Challenged
`Claims obvious ......................................................................... 12
`a.
`Greef recognizes an issue with its system’s
`identification of attributes and proposes one
`solution .......................................................................... 12
`Bader teaches an alternative solution: prompting
`the user to identify attributes ......................................... 12
`Bader and Greef teach that prompting the user to
`identify attributes can rely on an indirect
`identification .................................................................. 17
`d. Weida teaches that user input should occur via
`predefined questions ...................................................... 19
`The Challenged Claims are obvious .............................. 21
`e.
`The combination of Greef with Bader and Weida
`discloses every limitation of Claim 1 ...................................... 22
`The combination of Greef with Bader and Weida
`discloses every limitation of Claims 2–5 ................................. 40
`
`b.
`
`c.
`
`4.
`
`5.
`
`
`
`
`
`i
`
`
`
`

`
`Table of Contents
`(continued)
`
`
`
`6.
`
`7.
`
`The combination of Greef with Bader and Weida
`discloses every limitation of Claim 6 ...................................... 47
`The combination of Greef with Bader and Weida
`discloses every limitation of Claims 7–11 ............................... 51
`C. Ground 2: Claims 1–11 Are Rendered Unpatentable Under 35
`USC § 103 By The Combination of Greef, Weider, Bader, And
`Altman ................................................................................................ 57
`1.
`The combination of Greef with Bader, Weida, and
`Altman renders the Challenged Claims obvious ..................... 57
`The combination of Greef with Bader, Weida, and
`Altman discloses every limitation of Claims 1–11 .................. 59
`IV. CONCLUSION ............................................................................................. 60
`
`2.
`
`
`
`
`
`ii
`
`
`
`

`
`
`Exhibit List (37 C.F.R. §42.63(e))
`
`Exhibit No. Brief Description
`
`1001
`
`1002
`
`1003
`
`1004
`
`1005
`
`1006
`
`1007
`
`1008
`
`1009
`
`1010
`
`1011
`
`1012
`
`1013
`
`
`
`
`
`
`
`Declaration of Deborah McGuinness
`
`Curriculum vitae of Deborah McGuinness
`
`Declaration of Louis A. Klapp
`
`U.S. Patent No. 7,805,461 (“the ’461 Patent”)
`
`U.S. Patent No. 6,397,221 (“Greef”)
`
`U.S. Patent No. 6,810,401 (“the ’401 Patent”)
`
`Fikes & Kehler, The Role of Frame Based Representation in
`Reasoning, Communication of the ACM, Volume 28, Number 9
`(September 1985) (“Fikes”)
`
`Excerpts from Alison Cawsey, The Essence of Artificial Intelligence
`(1998) (“Cawsey”)
`
`U.S. Patent No. 6,108,670 (“Weida”)
`
`U.S. Patent No. 5,953,726 (“Carter”)
`
`U.S. Patent No. 5,467,471 (“Bader”)
`
`U.S. Patent No. 6,442,566 (“Altman”)
`
`Wright et al., A Knowledge-Based Configurator That Supports
`Sales, Engineering, and Manufacturing at AT&T Network Systems,
`AI Magazine (Fall 1993) (“Wright”)
`
`iii
`
`
`
`

`
`
`
`In accordance with 35 U.S.C. § 311 Petitioner WTS Paradigm, LLC
`
`(“WTS”) respectfully requests inter partes review (“IPR”) of Claims 1–11 of U.S.
`
`Patent No. 7,805,461 (“the ’461 Patent”), attached hereto as Exhibit 1004.
`
`I. MANDATORY NOTICES (37 CFR § 42.8)
`WTS is the real party-in-interest for Petitioner. EdgeAQ, LLC (“EdgeAQ”)
`
`has asserted the ’461 Patent in a pending patent infringement lawsuit, WTS
`
`Paradigm, LLC v. EdgeAQ, LLC, No. 3:15–cv–00330 (W.D. Wis.). This case may
`
`affect, or be affected by, decisions in this proceeding.
`
`WTS provides the following designation of counsel, to which all
`
`correspondence should be addressed (WTS consents to service by email):
`
`Lead Counsel
`Michael Jaskolski (Reg. No. 37,551)
`michael.jaskolski@quarles.com
`QUARLES & BRADY LLP
`411 East Wisconsin Avenue, Suite 2400
`Milwaukee, Wisconsin 53202
`Telephone: (414) 277-5711
`Fax: (414) 978-8711
`
`Backup Counsel
`Louis A. Klapp (Reg. No. 73,603)
`louis.klapp@quarles.com
`QUARLES & BRADY LLP
`300 North LaSalle Street, Suite 4000
`Chicago, Illinois 60654
`Telephone: (312) 715-2712
`Fax: (312) 632-1948
`
`II. GROUNDS FOR STANDING AND
`CHALLENGE (37 CFR § 42.104)
`A.
`Standing And Statutory Grounds For Each Claim
`Petitioner certifies that the ’461 Patent is available for inter partes review
`
`IDENTIFICATION OF
`
`having been filed on April 10, 2007, and that Petitioner is not barred or estopped
`
`from requesting this inter partes review.
`
`1
`
`

`
`
`
`WTS requests IPR of Claims 1–11 of the ’461 Patent (the “Challenged
`
`Claims”). IPR of the Challenged Claims is requested in view of the following:
`
`Ground
`
`1
`
`2
`
`Proposed Statutory Rejections for the ’461 Patent
`Claims 1–11 are obvious under 35 U.S.C. § 103 in view of the
`combination of U.S. Patent No. 6,397,221 to Greef et al. (Ex. 1005,
`“Greef”), U.S. Patent No. 5,467,471 to Bader (Ex. 1011, “Bader”) and
`U.S. Patent No. 6,108,670 to Weida et al. (Ex. 1009, “Weida”)1.
`Claims 1–11 are obvious under 35 U.S.C. § 103 in view of the
`combination of Greef, Bader, Weida, and U.S. Patent No. 6,442,566 to
`Altman et al. (Ex. 1012, “Altman”).
`
`Greef, Bader, Weida, and Altman are all prior art under 35 USC § 102(b)
`
`because they are patents that issued more than one year prior to the filing date of
`
`the application to which the ’461 Patent claims priority (December 5, 2003). Greef
`
`issued on May 28, 2002 (Ex. 1005), Bader issued on November 14, 1995 (Ex.
`
`1011), Weida issued on August 22, 2000 (Ex. 1009), 2 and Altman issued on
`
`August 27, 2002 (Ex. 1012).
`
`
`1 Weida’s disclosures include the disclosures of U.S. Patent No. 5,953,726 to
`
`Carter et al. (Ex. 1010, “Carter”), which Weida incorporates by reference.
`
`2 Carter, which Weida incorporates by reference, is also prior art under 35 USC §
`
`102(b) because it is a patent issued on September 14, 1999 (Ex. 1010).
`
`2
`
`

`
`
`
`B. Claim Construction
`In accordance with 37 C.F.R. § 42.100(b), the challenged claims must be
`
`given their broadest reasonable interpretations. For clarity, the term “frame” means
`
`a structured representation of an object or a class of objects. (Ex. 1001,
`
`McGuinness Decl. ¶ 35.) This is consistent with how the term is used in the patent.
`
`(Ex. 1004, ’461 Patent at 1:37–52 (describing role of frames in representing
`
`attributes of objects).) This is also consistent with how the term is used in the ’401
`
`patent, which is incorporated by references into the ’461 patent. (Ex. 1006, ’401
`
`Patent at 4:67–5:3 (“Frame Engine 104 represents knowledge in a hierarchical tree-
`
`like structure. The nodes of the tree are generally called “frames” (e.g.,
`
`corresponding to product categories)”.) This is also consistent with how the term
`
`would have been understood by a person of ordinary skill in the art at the time of
`
`the claimed invention. (Ex. 1001, McGuinness Decl. ¶¶ 33, 35; Ex. 1007, Fikes at
`
`904 col.2 (“a frame provides a structured representation of an object or a class of
`
`objects”); Ex. 1008, Cawsey 180 (“Frame: Record-like structure used to represent
`
`knowledge. A frame is used to represent simple facts about an object or class as
`
`slots and slot values, and inheritance used to make inferences.”).)
`
`C. How The Claim Is Unpatentable
`A detailed explanation of how the Challenged Claims are unpatentable is
`
`provided in Section III.
`
`3
`
`

`
`
`
`D. Evidence Supporting Challenge
`An Appendix of Exhibits is attached. Relevance of the evidence, including
`
`identifying the specific portions of the evidence that support the challenge, may be
`
`found in Section III. WTS submits a declaration of Deborah McGuinness in
`
`support of this Petition in accordance with 37 C.F.R. § 1.68. (Ex. 1001, “Decl.”.)
`
`III. THERE
`IS A REASONABLE LIKELIHOOD THAT THE
`CHALLENGED CLAIMS ARE UNPATENTABLE
`A. Description Of The Alleged Inventions
`The Challenged Claims involve taking data stored in a database table and
`
`rearranging it into a hierarchical structure (a “frame-based knowledge tree”) based
`
`on input received from user. (Ex. 1001, Decl. ¶¶ 26–29.) The independent method
`
`claim, Claim 6, requires the following:
`
`A method of automatically constructing a frame-based knowledge
`tree, the method comprising:
`
`identifying a plurality of attributes within a vendor database to be
`inducted into a frame-based knowledge tree by querying at least one
`vendor-supplied product knowledge database table for data regarding
`the attributes;
`
`presenting pre-defined questions about the data to a user to identify a
`set of SQL queries to be answered to construct the frame-based
`knowledge tree;
`
`automatically determining respective locations of the plurality of
`attributes within the frame-based knowledge tree based upon input
`
`4
`
`

`
`
`
`answers received from a user regarding the data, wherein the input
`answers are provided in response to the pre-defined questions about
`the data provided to the user; and
`
`inserting at least one of the attributes into the frame-based knowledge
`tree based on the determined respective locations, whereby the frame-
`based knowledge tree is constructed.
`
`(Ex. 1004, ’461 Patent at 12:13–31.)
`
`The specification explains the claimed invention using the example of a
`
`table containing eight different products defined by three different attributes: color,
`
`size, and shape:
`
`TABLE 1A is an exemplary product data table that contains specific
`product data for eight different products. Each row defines a separate
`product. Each of the eight products have features that fall under the
`same three attributes. In this example, the first attribute is color, the
`second attribute is size and the third attribute is shape. For example,
`the first product listed is red, is small and is in the shape of a circle.
`The second product listed is blue, is small and is in the shape of a
`square, and so on.
`
`
`
`5
`
`

`
`
`
`(Id. at 8:38–60.) The claimed invention takes the product data from this tabular
`
`organization and converts into a hierarchical organization:
`
`
`
`(Id. at 10:7–50, Fig. 6.)
`
`The process of converting the data from a table to a tree involves asking for,
`
`and receiving, input from a user. The products in Table 1A theoretically could have
`
`been arranged in any one of several different hierarchies. For example, although
`
`Figure 6 shows that the data is organized first by color, then by size, then by shape
`
`(i.e., color is the highest-level node and shape is the lowest-level node),
`
`conceivably the data could have been organized, for example, first by size, then by
`
`shape, then by color. (See Ex. 1001, Decl. ¶ 28.) The patent explains that the
`
`decisions about where in the tree (i.e., highest-level node, middle-level node,
`
`6
`
`

`
`
`
`lowest-level node) each attribute (i.e., color, size, shape) should be located are
`
`based on instructions received from a user:
`
`In one embodiment, an interactive (i.e., manual) knowledge tree
`construction may be utilized, where the user interface 100 prompts
`the user with a series of questions requiring the user to select from a
`list of product attributes, the answers to which determine the order,
`and manner in which the attributes are added to the frame based
`knowledge tree. In another embodiment, automatic construction
`(described below) may be utilized, where the process of knowledge
`tree construction is automatic based on user specified generalization
`and optimization criteria.
`
`(Ex. 1004, ’461 Patent at 5:41–50.) 3 Once the user’s instructions are known, the
`
`process creates the SQL queries that pull the data out of the table and place it in the
`
`correct location in the tree. (Id. at 9:43–52.)
`
`The content of each Challenged Claims is discussed in more detail in each
`
`Ground presented below.
`
`B. Ground 1: Claims 1–11 Are Unpatentable Under 35 USC § 103 By
`The Combination of Greef, Bader, and Weida
`1.
`The ’461 Patent describes the claimed inventions as an improvement over a
`
`Background on the claimed subject matter
`
`prior-art system in which a human user assembles information (specifically,
`
`
`3 All emphasis added unless otherwise noted.
`
`7
`
`

`
`
`
`information about configurable products) into a tree organization. (Ex. 1001, Decl.
`
`¶¶ 22–24.) After collecting the information from a variety of sources, the user of
`
`the prior art system rearranges the information into the tree organization—what the
`
`patent calls, “a frame based knowledge tree.” (Ex. 1004, ’461 Patent at 1:33–37,
`
`1:53–58.) The user alone—i.e., not any logic embedded within the computer—
`
`decides where each piece of information is stored in the tree. (Id. at 1:38–52.) That
`
`is, the user of the prior art system—not the computer—determined his or her
`
`preferences for organizing the tree (e.g., placing parameters with many possible
`
`values closer to the root of the tree). (See id. at 1:30–2:8.) And, the user—not the
`
`computer—determined how to place the information into the tree in a manner
`
`consistent with his or her preferences.
`
`According to the ’461 Patent, the alleged invention improves upon this prior
`
`art system by having a computer automatically perform some of the tasks
`
`previously performed by the user. In particular, the ’461 Patent explains that, in its
`
`system, the user should still indicate certain preferences about the organization of
`
`the tree, but thereafter, the computer should automatically construct the tree
`
`consistent with the user’s preferences. (Id. at 1:66–2:8.)
`
`Although not discussed in the ’461 Patent’s discussion of the prior art, prior
`
`art systems existed where the computer performed functions that would otherwise
`
`8
`
`

`
`
`
`have been performed by the human user. (Ex. 1001, Decl. ¶ 25.) Greef and Bader
`
`are examples of such systems. (Id.; see also Section III below.)
`
`2. Greef nearly anticipates the Challenged Claims
` Greef concerns the rearrangement of data from a database table to a frame-
`
`based tree. (Ex. 1001, Decl. ¶¶ 37–40.) It discloses two embodiments: one that
`
`requires relatively substantial user input, and one that requires relatively little user
`
`input. (See Ex. 1005, Greef at Abstract.) This IPR focuses on the second
`
`embodiment, which discloses almost every limitation of the Challenged Claims.
`
`Greef discloses (among other things) that it (1) accesses product data from a
`
`database table; (2) queries the table to identify attributes; (3) identifies preferences
`
`for constructing a frame-based hierarchy of the attributes; and (4) based on those
`
`preferences, determines locations for the attributes in the hierarchy and inserts
`
`them accordingly. (Ex. 1001, Decl. ¶ 38; see also Section III.B below.)
`
`Greef discloses a manner for determining preferences about the hierarchy,
`
`but also flags a potential weakness in its approach. (Ex. 1001, Decl. ¶¶ 48–53.)
`
`Greef looks for certain names in the table’s column headers—in particular columns
`
`named “Class” and “Type—and determines preferences about the structure of the
`
`hierarchy based on those names. (Id. ¶¶ 48–49; Ex. 1005, Greef at 29:8–14, 29:59–
`
`30:3.) For example, Greef determines preferences by looking at the column
`
`headers (attribute names) in the table shown in Figure 17 (reproduced below).
`
`9
`
`

`
`
`
`
`The system knows that (1) “Camera” should exist in a frame closest to the
`
`root of the tree—it is a value of what Greef calls a “category” attribute—because
`
`its associated attribute is titled, “Class” and (2) “Point & Shoot,” “SLR,” and
`
`“Digital,” should appear in frames subordinate to that—they are values of what
`
`Greef calls a “subcategory” attribute—because their associated attribute is titled,
`
`“Type.” (Ex. 1001, Decl. ¶ 49; Ex. 1005, Greef at 29:8–14, 29:59–30:3.)
`
`Thus, because the table used “Class” and “Type” as headers, the computer
`
`can identify preferences for the structure of the hierarchy without explicitly
`
`seeking the user’s input:
`
`Upon closer consider of table 400, it will be appreciated that since
`product attributes that identify category and subcategory such as
`Class and Type are included in the table data, the tabular data contains
`information from which a frame-based hierarchical structure to
`accommodate the product records might be generated.
`
`(Ex. 1005, Greef at 29:8–14; Ex. 1001, Decl. ¶ 49.)
`
`10
`
`

`
`
`
`Additionally, the system identifies “Model Name” as a “suitable identifying
`
`attribute… [for] identifying the respective products.” (Ex. 1005, Greef at 30:44–
`
`47.) As such, the system concludes that frames for the values of “Model Name”
`
`should appear subordinate to those of “Type.” (Id. at Fig. 18; Ex. 1001, Dec. ¶ 50.)
`
`Based on this analysis, Greef determines that the hierarchy should have the
`
`following general structure:
`
`
`(Ex. 1005, Greef at Fig. 18 (cropped); Ex. 1001, Decl. ¶ 51.) Thereafter, based on
`
`these preferences, Greef determines locations for (and inserts) the remaining
`
`attributes “without intervention of the user”:
`
`
`(Ex. 1005, Greef at Fig. 19 (cropped), 29:14–24; Ex. 1001, Decl. ¶ 52.)
`
`11
`
`

`
`
`
`3.
`
`In view of the prior art, Greef renders the Challenged
`Claims obvious
`
`As discussed below, the Challenged Claims are invalid as obvious because a
`
`person having ordinary skill in the art at the time of the claimed invention would
`
`have had reason to design Greef’s system so that it prompted the user with pre-
`
`defined questions to identify which attributes in the table correspond to the
`
`category, subcategory, and/or identifying attributes.
`
`a. Greef recognizes an
`system’s
`its
`issue with
`identification of attributes and proposes one solution
`
`If Greef’s system does not encounter a table with columns labeled as “Class”
`
`and “Type” the system would need an alternative way to identify which attribute
`
`should be treated as the category attribute and which should be treated as the
`
`subcategory attribute. (Ex. 1001, Decl. ¶ 53.) Greef recognizes this and suggests
`
`the system could reference a “look up” to figure out which attributes correspond to
`
`category and subcategory: “if table 400 includes category and subcategory
`
`information under attribute names other than Class and Type, the method would
`
`identify the category subcategory information by comparison to a term reference
`
`look up.” (Ex. 1005, Greef at 30:33–42; Ex. 1001, Decl. ¶ 53.)
`
`b.
`
`Bader teaches an alternative solution: prompting the
`user to identify attributes
`
`A person of ordinary skill in the art would have recognized that Greef’s
`
`system should be designed to present the user with a list of the attributes and ask
`
`12
`
`

`
`
`
`the user to identify which correspond to category and subcategory. (Ex. 1001,
`
`Decl. ¶ 54.) This is taught by Bader. (Id. ¶ 55.)
`
`Bader discloses “a system and method pertaining to hierarchical and
`
`relational databases maintained by a computer.” (Ex. 1011, Bader at 1:8–9; Ex.
`
`1001, Decl. ¶ 57.) Among other disclosures, Bader “teaches a system for…
`
`converting a database that is maintained as relational to one that is hierarchical.”
`
`(Ex. 1011, Bader at 3:34–37.) For example, it discloses converting the database
`
`table in Figure 12 into various hierarchies (id. at Fig. 12; Ex. 1001, Decl. ¶ 57):
`
`
`The construction of these hierarchies occurs in three principal steps. (Ex.
`
`1001, Decl. ¶ 58.) First, the user selects which subset of attributes from the table
`
`(i.e., which attributes among “Department,” “Company,” “Location,” “First
`
`Name,” “Last Name,” and “Children’s Names”) will be used to form the general
`
`structure of the hierarchy.
`
`The preferred system and method for converting from a relational
`database to a hierarchical database is as follows. First, some of the
`
`13
`
`

`
`
`
`attributes or keywords of the relational database (i.e., the column
`headers in FIG. 12) are selected by a user to be the elements on
`which the hierarchy to be created will be based. In the example…
`there are three keywords chosen on which the hierarchy will be based:
`“Department”, “Company”, and “Last Name”.
`
`(Id. at 11:53–60.) Second, based upon the number of unique values for each of the
`
`selected attributes, the ordering of the attributes (“keywords”) within the hierarchy
`
`is determined—i.e., which attribute is closest to the root:
`
`[T]he keyword “Company” is preferably selected as the keyword for
`records at Level 1 of the hierarchy, the keyword “Department” is
`preferably selected as the keyword for records at Level 2 of the
`hierarchy, and the keyword “Last Name” is preferably selected as the
`keyword for records at Level 3 of the hierarchy.
`
`(Id. at 11:61–12:9.) Third, based on the user’s preferences the system places all
`
`remaining attributes within the hierarchy, such as that of Figure 14 (the hierarchy
`
`is spread over two sub-figures, and only Figure 14a is reproduced below):
`
`(Id. at Fig. 14a; see also id. at Fig. 14b, 12:10–40.)
`
`14
`
`
`
`

`
`
`
`Thus, Bader teaches that its system first determines preferences about the
`
`attributes to determine the general structure of the hierarchy and, thereafter,
`
`automatically builds the hierarchy. (Ex. 1001, Decl. ¶ 59.) Additionally, Bader
`
`teaches that, in determining preferences, the system should ask the user to identify
`
`the attributes on which the hierarchy will be based and, of those, which should be
`
`placed closest to the hierarchy’s root (i.e., “Company”), which below that (i.e.,
`
`“Department”), and which is further below that (i.e., “Last Name”). (Id.)
`
`In addition to this explicit disclosure from Bader, a person having ordinary
`
`skill would have had other reasons to present the user with these predefined
`
`questions asking which attributes correspond to category and subcategory. First,
`
`the person would have recognized the impracticality of depending exclusively on
`
`an external lookup functionality when “class” and “type” column headers are
`
`missing. (Ex. 1001, Decl. ¶ 54.) Prompting the user to make selections solves that
`
`problem. (Id.)
`
`Second, the person 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 the intended use. (Id.) As taught by Bader,
`
`different selections by the user will produce different hierarchies, each of which
`
`will have its own advantages and disadvantages. In particular, Bader explains that
`
`different hierarchies can be created from the same tabular data based on the user’s
`
`15
`
`

`
`
`
`selections. (Ex. 1011, Bader at 12:26–40; Ex. 1001, Decl. ¶ 60.) For example,
`
`Bader cites the hierarchy of Figure 15 as an alternative to Figure 14, which,
`
`although based on the same underlying data, is based on different user selections.
`
`(Ex. 1011, Bader at 12:26–40; see also id. at Fig. 15.) Bader teaches that this is
`
`advantageous, as each hierarchy will have benefits for different purposes:
`
`There may be certain advantages or disadvantages to a user in having
`the hierarchy of FIGS. 14a-b or FIGS. 15a-b; thus it is a useful
`capability of the invention to allow a user to choose which
`hierarchical structure is created from the original relational database
`(in this example, the relational database of FIG. 12).
`
`(Id. at 12:35–40; Ex. 1001, Decl. ¶ 60.)
`
`Similar to prompting the user to identify category and subcategory attributes,
`
`person of ordinary skill would have had a reason to prompt the user to indicate the
`
`user’s preference for the identifying attribute (e.g., “Model Name” in Greef’s
`
`example). (Ex. 1001, Decl. ¶ 62.) Greef’s disclosure does not specify how it
`
`determines which of the table’s attributes is selected as the identifying attribute,
`
`only that the determination occurs. (Id.; Ex. 1005, Greef at 30:44–47.) Given that
`
`attributes additional to “Model Name” would be suitable (e.g., “Md. No.” (model
`
`number)), it would have been a simple, predictable modification of Greef to ask the
`
`user to identify which attribute should serve as the identifying attribute. (Ex. 1001,
`
`Decl. ¶¶ 63–65.) Indeed, this is consistent with the teaching of Greef’s first
`
`16
`
`

`
`
`
`embodiment, wherein the user selects the identifying attribute and Greef explains
`
`that there is value in selecting “model number” over some other attribute. (Id.; Ex.
`
`1005, Greef at 18:42–46 (model number selected as identified because it is “likely
`
`to receive recognition across presentation formats”).)
`
`c.
`
`Bader and Greef teach that prompting the user to
`identify attributes
`can
`rely on an
`indirect
`identification
`
`As noted above, a person having ordinary skill in the art would have reason
`
`to modify Greef’s system such that it prompted the user to identify the subset of
`
`attributes on which the hierarchy will be based and their respective levels—that is,
`
`directly ask the user which attributes correspond to “category,” “subcategory,”
`
`and/or “identifying” attributes in the language of Greef. (See Section III.B.3.b.)
`
`Additionally, a person having ordinary skill would also have reason to implement
`
`the prompts to enable indirect selection of attributes. (Ex. 1001, Decl. ¶¶ 66–68.)
`
`The person of ordinary skill would know that—in situations when the user is
`
`unsure which attributes to select—the system should be designed to ask the user
`
`whether the user wants the system to determine this information based on count of
`
`unique values for each attribute, as is taught by Bader. (Id. ¶ 67.) Bader explains
`
`that attributes with few values should be placed toward the top of the hierarchy:
`
`It is preferable that the highest level of the hierarchy to be created
`has the fewest number of unique keyword values, with each next
`
`17
`
`

`
`
`
`subordinate level having the same or the next greater number of
`unique keyword values.”
`
`(Ex. 1011, Bader at 11:61–12:9.) Thus, given Bader’s disclosure that it is desirable
`
`to choose attributes based on number of unique values, a person of ordinary skill
`
`would have a reason to design the modified Greef system such that it asked the
`
`user whether the attributes corresponding to “category,” “subcategory” and/or
`
`“identifying” attributes should be selected by the number of unique values
`
`associated with the various attributes. (Ex. 1001, Decl. ¶ 67.)
`
`Additionally, the person would have had a reason to modify Greef such
`
`that—in situations when the user is unsure which attributes to select—the system
`
`asks the user whether the user wants the system to determine the identity and order
`
`of the attributes on which the hierarchy will be based by deferring to an existing
`
`hierarchy. (Ex. 1001, Decl. ¶ 68.) This is taught by the first embodiment of Greef.
`
`In that Greef embodiment, the user identifies an initial hierarchy (Fig. 3) on which
`
`the final hierarchy (Fig. 5) will be based. (Ex. 1005, Greef at 6:5–25, 12:1–9,
`
`14:35–42.)
`
`(Id. at Fig. 3.)
`
`
`
`18
`
`

`
`
`
`(Id. at Fig. 5.) In particular, Greef explains the following:
`
`
`
`Get Information step 102, itself, includes an initial step 122, at which
`the method asks; i.e., prompts, the user to identify the source of the
`tabular data, and the source of any frame-based, hierarchical
`organizational data to be employed as the starting point for the
`organizational structure that will be fashioned to accommodate the
`tabular data to be imported.
`
`(Id. at 14:35–42.) It would have been a routine, predictable variation of Greef’s
`
`second embodiment to incorporate this teaching from Greef’s first embodiment.
`
`(Ex. 1001, Decl. ¶ 68.)
`
`d. Weida teaches that user input should occur via
`predefined questions
`
`The person of ordinary skill would have known that, in prompting the user
`
`to identify preferences regarding category, subcategory, or identifying attributes,
`
`19
`
`

`
`
`
`the modified Greef system would seek the preferences by asking the user
`
`predefined questions. For example, the person would know to present a screen on a
`
`graphical user interface showing a list of the table’s attributes and asking the user
`
`to “Select the highest-level attribute,” “Select the identifying attribute,” or the like.
`
`(Ex. 1001, Decl. ¶ 69.) Such a means for soliciting user input was well known and
`
`would have been no more than a routine, predictable modification to Greef. (Id.)
`
`Indeed, Weida—via its incorporation of Carter by reference—discloses,
`
`among other things, a system and method for adding, deleting, or modify the
`
`contents of a hierarchy. (Ex. 1010, Carter at Abstract, 1:30–33.) Although
`
`Weida/Carter is “computer automated” (id. at 1:32), its process “is an interactive
`
`one where some of the steps… are performed by the computer, while the
`
`remaining steps are performed by the user in response to interrogations by the
`
`computer.” (Id. at 6:42–45.) Carter’s hierarchy is maintained by “a human agent
`
`using a Graphic User Interface (GUI).” (Id. at 2:30–42.)
`
`When the computer needs input to arrange the hierarchy, Weida/Carter’s
`
`system prompts the user with a predefined question seeking the user’s preferences
`
`via the graphical user interface. (Ex. 1001, Decl. ¶ 69.) For example, when the user
`
`deletes an attribute associated with a frame and indicates that it should be moved to
`
`a sub-frame, the system will ask the user to “Select the target item,” and provide a
`
`list of possible sub-frames for the user to select (e.g., “Desktop,” “Mobile”):
`
`20
`
`

`
`
`
`
`(Id. at Fig. 27, 6:59–65.) Other operations will result in different questions being
`
`asked to the user, such as asking the user to “Select categories to remove” and to
`
`indicate whether an item “is to be copied to or moved to the new parent.” (Id. at
`
`6:42–65, 3:32–50, Figs. 2, 25–27.)
`
`A person of ordinary skill would know that in seeking user input for the
`
`modified Greef system, the input 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, Decl. ¶ 69.)
`
`e.
`Consequently, a person of ordinary skill in the art at the time of the claimed
`
`The Challenged Claims are obvious
`
`invention would have had reason to modify Greef’s system in accordance with
`
`Bader and Weida so as to present the user with predefined questions via a
`
`graphical user interface asking the user’s preference for category, subcategory, and
`
`identifying attributes. (Id. ¶ 70.) As explained in more detail below, such a system
`
`21
`
`

`
`
`
`would have each and every limitation of the Challenged Claims. (See Sections
`
`III.B.4–III.B.7.) Thus, the Challenged Claims are obvious and unpatentable.
`
`4.
`
`The combination of Greef with Bader and Weida discloses
`every limitation of Claim 1
`Preamble [1.0]. Greef discloses a database processing system. (Ex. 1001,
`
`Decl. ¶¶ 79–81.) In particular, Greef discloses the processing of a database of
`
`tabularly organized data so as to convert the data into a hierarchical organization.
`
`Greef
`
`is
`
`titled “Method for Creating and Maintaining a Frame-Based
`
`Hierarchically Organized Databases with Tabularly Organized Data.” (Ex. 1005 at
`
`Title.) Such tabularly