Filed on behalf of: Versata Development Group, Inc.
`
`Paper __
`
`By: Nancy J. Linck, Lead Counsel
`Martin M. Zoltick, Backup Counsel
`Rothwell, Figg, Ernst & Manbeck, P.C.
`607 14th St., N.W., Suite 800
`Washington, DC 20005
`Phone: 202-783-6040
`Facsimile: 202-783-6031
`E-mail: nlinck@rfem.com
`mzoltick@rfem.com
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`SAP AMERICA, INC. ET AL.
`Petitioner
`
`v.
`
`VERSATA DEVELOPMENT GROUP, INC.
`Patent Owner
`
`Case CBM20 12-00001 (MPT)
`Patent 6,553,350
`
`DECLARATION OF MATTHIAS LIEBICH
`
`VERSATA EXHIBIT 2091
`SAP v. VERSATA
`CASE CBM2012-00001
`
`
`
`Paper __
`
`By: Nancy J. Linck, Lead Counsel
`Martin M. Zoltick, Backup Counsel
`Rothwell, Figg, Ernst & Manbeck, P.C.
`607 14th St., N.W., Suite 800
`Washington, DC 20005
`Phone: 202-783-6040
`Facsimile: 202-783-6031
`E-mail: nlinck@rfem.com
`mzoltick@rfem.com
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`SAP AMERICA, INC. ET AL.
`Petitioner
`
`v.
`
`VERSATA DEVELOPMENT GROUP, INC.
`Patent Owner
`
`Case CBM20 12-00001 (MPT)
`Patent 6,553,350
`
`DECLARATION OF MATTHIAS LIEBICH
`
`VERSATA EXHIBIT 2091
`SAP v. VERSATA
`CASE CBM2012-00001
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`The undersigned, Matthias Liebich, does hereby declare and state as follows:
`
`1.
`
`I make the following declaration based upon my knowledge and
`
`belief.
`
`I.
`
`Background and Qualifications
`
`2.
`
`I earned a Diplom-Betriebswirt degree in Business Administration,
`
`with an emphasis on Trade, from the Berufsakademie Karlsruhe, in Karlsruhe,
`
`Germany, in 1991.
`
`3.
`
`I have been working as a business software consultant on SAP-related
`
`projects since 1991. During that time, I have developed an expertise in several
`
`SAP modules, including R/2 RV (Sales and Distribution), Release 4.3H-4.3J and
`
`R/3 SD (Sales and Distribution), MM (Materials Management) and FI (Financial),
`
`Release 2.1D – ECC6.0. I am also a certified SAP SD consultant in R/3 3.0 Sales
`
`and Distribution (SD). In addition to my functional SAP experience I also have
`
`experience in SAP development (ABAP, DDIC). Besides my hands-on experience
`
`in these modules of SAP I have particular expertise with the pricing condition
`
`technique of the SD module.
`
`4.
`
`Some of the companies for which I have consulted on SAP-related
`
`projects include The Coca Cola Company, Smith & Nephew, Georgia-Pacific
`
`Corporation, James River Corporation, Siemens Medical Systems, Sara Lee
`
`Corporation and Hercules Corporation.
`
`
`
`2
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`I have authored 15 articles about SAP, and served as Associate Editor
`
`5.
`
`for Logistics and Pricing, for ERPtips magazine (formerly SAPtips magazine), a
`
`leading SAP-related magazine with worldwide distribution.
`
`6.
`
`I am the author of “The Ultimate SAP Pricing Guide,” a book that
`
`explains how pricing works in SAP.
`
`7.
`
`Further aspects of my qualifications, background, and experience are
`
`outlined in my curriculum vitae attached as Appendix A to my declaration.
`
`II. The Patent Involved in This Proceeding
`
`8.
`
`I am informed that the Patent Trial and Appeal Board (Board) granted
`
`a petition by SAP seeking covered business method review of U.S. Patent No.
`
`6,553,350 (the ‘350 patent; SX 1001), filed on February 19, 1999 as U.S. Patent
`
`Application Ser. No. 09/253,427, which was a continuation of U.S. Patent
`
`Application No. 08/664,837, filed on June 17, 1996, now U.S. Patent No.
`
`5,878,400 (the ‘400 patent).
`
`9.
`
`I am informed that the ‘350 patent lists Thomas J. Carter of Austin,
`
`TX as the inventor and Trilogy Development Group, Inc. (Trilogy), of Austin, TX
`
`as the original assignee.
`
`10.
`
` I am informed that the current owner of the ‘350 patent is Versata
`
`Development Group, Inc. (Versata).
`
`
`
`
`
`3
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`
`III. Status as an Independent Expert Witness
`
`11.
`
` I have been retained in this matter by Rothwell, Figg, Ernst &
`
`Manbeck, P.C. of Washington, D.C. (Rothwell Figg) to provide various opinions
`
`regarding the ‘350 patent. I am being compensated at my usual rate of $350 per
`
`hour, plus expenses, which is my standard consulting fee, for my work in this
`
`matter. My compensation is not dependent on the outcome of this matter or on any
`
`of the opinions I provide below.
`
`12.
`
` I have had no previous contact with Rothwell Figg or with the
`
`attorneys handling this proceeding.
`
`13.
`
` I have had no previous contact with the inventor of the ‘350 patent,
`
`Trilogy, or Versata. With respect to SAP, I have worked with consultants from
`
`SAP on various client projects, attended SAP training classes at SAP in Germany
`
`and here in the U.S., and attended transportation demonstrations at SAP’s
`
`headquarters.
`
`IV. Materials Reviewed
`
`14. In performing the analysis that is the subject of my testimony, I
`
`reviewed the ‘350 patent and its file history, as well as the file history of the related
`
`‘400 patent, and various publically-available documents from the litigation in the
`
`U.S. District Court for the Eastern District of Texas involving the ‘350 patent,
`
`styled Versata Software, Inc. v. SAP America, Inc., Civil Action No. 2:07-cv-153
`
`
`
`4
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`(the district court litigation). I have also reviewed: (1) the Petition for Post-Grant
`
`Review of the ‘350 patent (Petition), the Declaration of Michael Siegel, Ph.D.
`
`(Siegel Dec.), and the exhibits referred to in the Siegel Dec.; (2) Patent Owner
`
`Versata’s Preliminary Response; (3) the Decision – Institution of Covered
`
`Business Method Review (Institution Decision); and (4) the Transcript of the
`
`March 1, 2013 Deposition of Michael Siegel, Ph.D. and the exhibits referred to in
`
`the deposition transcript. Additionally, I have reviewed the R/3 2.2 Online
`
`Documentation CDs (SX 1017) and documents that I obtained from searching the
`
`Internet about SAP’s R/3 system. All of the materials that I considered are listed
`
`in Appendix B. I have also taken into account my own knowledge of pricing, in
`
`general, and the pricing functionality of SAP’s SD module in particular, gained
`
`from over 20 years of experience in the field of computerized business systems and
`
`software, including its pricing functionality.
`
`V.
`
`The Problems Addressed By The ‘350 Patent
`
`15. Sometime prior to June 1996, Mr. Carter, like many other people in the
`
`pricing industry, recognized that the pricing software available at that time,
`
`including the pricing condition technique of the SD module of SAP’s R/3 system,
`
`suffered from significant performance disadvantages.
`
`
`
`5
`
`
`
`
`
`Case CCBM2012-000001
`
`
`U.S. Pateent No. 6,5533,350
`
`
`fically, Mr. Carter reccognized thhat the prioor art requuired “a
`
`
`
`
`
`6. Specif
`1
`
`
`
`
`numberr of price addjustment tables andd a number
`
`
`
`
`
`
`
`
`
`applicabble price addjustmentss.” SX 10001, col 2:5
`
`
`
`
`
`
`
`
`
`of databasse queries tto retrieve
`
`
`
`7-59.
`
`
`
`using the aabove
`
`
`
`its shortcoomings, succh as thosee
`
`
`
`
`
`
`
`17. Priorr to June 19996, I had ppersonal ex
`xperience
`
`
`
`
`
`
`
`
`
`mentionned prior art R/3 systtem and cann attest to
`
`
`
`
`
`
`
`
`
`recognized by Mr. Carter.
`
`
`
`
`
`18.
`
`
`
`
`
`
`
`
`
`
`
` I preesent beloww an exampple pricingg scenario tto illustratee the identiified
`
`
`
`
`
`
`
`problemm - - i.e., thhat the R/33 system reequired a nnumber of ttables and
`
`
`
`
`
`
`
`
`
`
`
`a number
`
`of
`
`
`
`queries to obtain aapplicable pricing infformation.
`
`
`
`
`
`
`
`9.
`1
`
`
`
` In thhis pricingg scenario, the seller iis a merchaant of commputer
`
`
`
`
`
`
`
`
`
`
`
`process
`
`
`
`
`ing units (CCPUs) andd has numeerous differrent CPUss that it sellls. The CP
`
`
`
`
`
`
`
`
`
`Us
`
`
`
`can be aarranged inn a hierarchhy, such ass the followwing hierarrchy.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`FIGURRE 1
`
`6
`
`
`
`
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
` When determining the final price of a particular CPU, the seller
`
`20.
`
`would like to apply a discount to the base price of the particular CPU, where the
`
`amount of the discount depends on the particular CPU. Specifically, in this
`
`scenario, the seller would like to have a particular discount amount that applies to
`
`all CPUs (e.g., 10%), a more specific discount amount that applies to 486 CPUs
`
`(e.g. 15%), and an even more specific discount amount for 486/x CPUs (e.g., 25%)
`
`because the seller’s inventory is overflowing with 486/x CPUs.
`
`21.
`
` I will now describe the customary and routine way in which the
`
`seller would use the prior art pricing condition technique of the R/3 system to
`
`implement such a pricing scenario.
`
`22.
`
` The seller would create a pricing procedure that identifies the
`
`components (called “condition types”) that are to be taken into account when
`
`determining the final price of a product. In this example, the pricing procedure
`
`would, at a minimum, identify (1) a first condition type (C1) for the product’s base
`
`price and (2) a second condition type (C2) for the discount to apply to the
`
`product’s base price.
`
`23.
`
` The seller would specify one or more condition tables for each
`
`condition type via its assigned access sequence. A condition table is a table used
`
`by the pricing condition technique to query the database for particular pricing
`
`information (a.k.a., “condition records”). For simplicity, we will assume that there
`
`
`
`7
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`is one condition table for the product base price condition type, which condition
`
`table is used by the pricing condition technique to identify and retrieve a product’s
`
`base price.
`
`24.
`
` For the discount condition type (C2), however, there must be a
`
`condition table for each of the different discounts - - i.e., there must be at least
`
`three condition tables, one condition table for the general CPU discount (10%), one
`
`condition table for discounts based on CPU type (e.g., the 15% discount applicable
`
`to any 486 CPU), and one condition table for product specific discounts (e.g., the
`
`25% discount for the 486/x CPU). In other words, there must be a condition table
`
`for each level of the CPU product hierarchy, and, as shown above, the CPU
`
`product hierarchy includes three levels: a product level, a first product group level
`
`immediately above the product level (i.e., a CPU type level), and a second product
`
`group level immediately above the first product group level (i.e., a product type
`
`level).
`
`25.
`
` Each condition type (C1 and C2) is associated with an “access
`
`sequence” that specifies the order in which the pricing condition technique will use
`
`the condition tables associated with the condition type via the access sequence to
`
`search for applicable pricing information (“condition records”).
`
`26.
`
` An access sequence can operate in two modes: a first mode in which
`
`every condition table in the access sequence is used to search for condition records
`
`
`
`8
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`and a second mode in which the pricing condition technique will stop searching for
`
`condition records as soon as a valid condition record is found. This second mode
`
`is referred to as the “exclusive” mode.
`
`27.
`
` For the first condition type (base price), the access sequence is quite
`
`simple because there is only one condition table for that condition type. Thus, it
`
`does not matter whether the access sequence operates in the exclusive mode or not.
`
`28.
`
` For the second condition type (discount applied to base price), the
`
`routine and customary way to configure the access sequence is to have it operate in
`
`the “exclusive” mode and to list the condition tables in the access sequence from
`
`most specific to least specific, as illustrated in the figure below. The reason it is
`
`routine and conventional to use access sequences in the “exclusive” mode is
`
`because, in the non-exclusive mode, the pricing condition technique performs
`
`several queries that are completely unnecessary for determining the product’s price
`
`and, in addition, decrease system performance. In fact, SAP issued a notice to its
`
`users advising them to use access sequences in “exclusive” mode with multiple
`
`condition tables – so-called “cascading access.” VX 2087, p. 3.
`
`
`
`9
`
`
`
`
`
`Case CCBM2012-000001
`
`
`U.S. Pateent No. 6,5533,350
`
`
`
`
`
`
`
`
`
`FIGURRE 2
`
`
`
`
`
`
`
`
`
` Givven the scennario wherre the selleer would likke to have
`
`
`
`
`
`a particulaar
`
` 2
`
`29.
`
`
`
`discounnt amount tthat appliess to all CPUUs (e.g., 1
`
`
`
`
`
`
`
`
`
`0%), a moore specificc discount
`
`
`
`
`
`specific amount that appliees only to 4486 CPUs (e.g. 15%)), and an eeven more
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`discounnt amount tthat appliess on for 4886/x CPUs
`
`
`
`
`
`
`
`
`
`
`
`
`
`(e.g., 25%%), and usinng the acceess
`
`
`
`sequencce shown aabove in thhe exclusivee mode, thhe followinng steps woould occur
`
`
`
`
`
`to
`
`ers a
`
`
`
`
`
`
`
`
`
`
`
`determine the corrrect discouunt amountt to apply wwhen a cusstomer ord
`
`
`
`
`
`
`
`
`
`
`
`
`
`Pentiumm/x CPU:
`
`
`
`(1) the prricing conddition technnique will
`
`
`
`
`
`
`
`first use CCondition TTable 1 (i.ee.,
`
`
`
`
`
`
`
`thee conditionn table listeed first in tthe access
`
`
`
`
`
`
`
`sequence)
`
`
`
`to query thhe
`
`
`
`
`
`
`
`
`
`
`
`database to ddetermine wwhether thhere is a prooduct speccific discouunt
`
`
`
`
`
`
`
`condition reccord for thee Pentium//x CPU;
`
`
`
`
`
`
`
`
`
`(2) becauuse there iss no such pproduct speecific discoount condittion recordd,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`thee pricing coondition teechnique wwill next usse the Conddition Tablle 2
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`(i.ee., the nextt listed conndition tablle) to querry the databbase again
`
`
`
`
`
`
`
`
`
`
`
`to
`
`
`
`10
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`determine whether there is a discount condition record defined for
`
`Pentium CPUs; and
`
`(3) because there is no such CPU type specific discount condition record
`
`for Pentium CPUs, the pricing condition technique will next use the
`
`Condition Table 3 to query the database again to determine whether
`
`there is a discount condition record defined for CPUs in general - -
`
`because there is such a general CPU discount condition record, the
`
`pricing condition technique will retrieve the pricing information
`
`(i.e., the CPU discount value of 10%) from the database.
`
`30.
`
` As the above simple example demonstrates, and as was the case in
`
`most scenarios based on my experience, the prior art pricing condition technique of
`
`the R/3 system requires a number of tables and a number of queries to obtain
`
`pricing information. This is disadvantageous because there is generally an inverse
`
`relationship between performance and the number of tables that need to be
`
`accessed – i.e., more tables, less performance.
`
`31.
`
` In my experience as a SAP pricing consultant, prior to June 1996,
`
`users of the SAP R/3 pricing condition technique frequently complained about its
`
`performance issues, particularly the fact that the R/3 pricing condition technique
`
`required the use of many tables and queries.
`
`
`
`
`
`11
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`VI. The Solution Described and Claimed in the ‘350 Patent
`
`32.
`
` The ‘350 patent’s solution to the above identified problems entails
`
`configuring a pricing software, installed on a computer with access to a data
`
`source, such that when the pricing software is asked to determine price adjustments
`
`for a particular product and a particular purchasing organization (“purchaser”), the
`
`pricing software:
`
`(1) retrieves from the data source:
`
`(i) a pricing adjustment applicable to the product;
`
`(ii) a pricing adjustment applicable to the purchaser;
`
`(iii) a pricing adjustment applicable to one or more organizational
`
`groups, within a hierarchy of organizational groups, above the
`
`particular purchaser;
`
`(iv) a pricing adjustment applicable to one or more product
`
`groups, within a hierarchy of products groups, above the
`
`particular product; and
`
`(2) determines the price of the product using pricing information
`
`applicable to the one or more identified organizational groups and the one or more
`
`identified product groups according to the hierarchy of product groups and the
`
`hierarchy of organizational groups. See e.g., SX 1001, figures 15A-15C; col. 3:45-
`
`65; 18:53-19:53; 21:63-22:12.
`
`
`
`12
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
` Configuring the pricing software to determine the product price
`
`33.
`
`“according to the hierarchy” enables one to configure the inventive pricing
`
`software to retrieve the applicable pricing information using fewer queries than the
`
`prior art. For instance, as little as one query can be used to retrieve pricing
`
`adjustments applicable not only to the product, but also to each product group
`
`above the product in the hierarchy of product groups.
`
`34.
`
` Fewer queries are needed because, by determining the price in
`
`accordance with the hierarchy, one may retrieve in as little as one query all of the
`
`pricing adjustments, and, then, one may order the pricing adjustments in
`
`accordance with the hierarchy. After the pricing adjustments are ordered in
`
`accordance with the hierarchy, the pricing software can simply use the pricing
`
`adjustment associated with the lowest level in the hierarchy (i.e., the most
`
`restrictive pricing information) in calculating the price. This obviates having to
`
`create separate tables for each level of the hierarchy, which means that fewer
`
`queries are needed.
`
`35.
`
` This is best illustrated with a specific example. I will use the simple
`
`pricing scenario described above to illustrate the advantages of the invention --
`
`advantages that are magnified as the pricing scenario becomes more complex and
`
`takes into account additional customer-specific discounts as well as product-
`
`specific discounts. In this pricing scenario, the seller applies a discount to the base
`
`
`
`13
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`price of a particular CPU, where the amount of the discount depends on the
`
`particular CPU being purchased. Specifically, in this scenario, the seller would
`
`like to have a particular discount amount that applies to all CPUs (e.g., 10%), a
`
`more specific discount amount that applies to 486 CPUs (e.g. 15%), and an even
`
`more specific discount amount for 486/x CPUs (e.g., 25%).
`
`36.
`
` When a purchaser requests a quote for a particular CPU (e.g., a
`
`486/x CPU), the pricing software implementing the invention could, in a single
`
`query from a data source that stores, for example, a single table, obtain: (i) the
`
`discount value, if any, applicable to the first level of the hierarchy; (ii) the discount
`
`value, if any, applicable to the second level of the hierarchy; and (iii) the discount
`
`value, if any, applicable to the third level of the hierarchy.
`
`37.
`
` In this particular example, three discount values would be obtained
`
`from the database: (i) a 10% discount applicable to all CPUs; (ii) a 15% discount
`
`applicable to any 486 CPU; and (iii) a 25% discount applicable to the 486/x CPU.
`
`38. After obtaining the discount values, the pricing software then
`
`determines the price “according to the hierarchy.” That is, for example, the pricing
`
`software may “sort the pricing information according to ... the hierarchy of product
`
`groups,” SX 1001, 21:23-25, and “eliminate any of the pricing information that is
`
`less restrictive,” SX 1001, 21:26-27. Doing this would result in the pricing
`
`
`
`14
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`software using the 25% discount by eliminating the 10% and 15% discounts from
`
`the price calculation.
`
`39.
`
` As another example, using the same pricing scenario, when a
`
`purchaser requests a quote for the Pentium/x CPU, the pricing software could, in a
`
`single query from a single table, obtain: (i) the discount value, if any, applicable to
`
`the first level of the hierarchy; (ii) the discount value, if any, applicable to the
`
`second level of the hierarchy; and (iii) the discount value, if any, applicable to the
`
`third level of the hierarchy. In this particular example, one discount value would
`
`be obtained from the database - - the 10% discount applicable to all CPUs. This
`
`further demonstrates that, by enabling the pricing software to obtain in one access
`
`all of the relevant price adjustments, the solution claimed in the ‘350 patent
`
`provides a significant and distinct advantage over, at the least, the prior art R/3
`
`pricing condition technique (which, in my experience, was the routine and
`
`conventional way to perform pricing at the time of the invention).
`
`VII. Patentability of Claims 17 and 26-29 Under 35 U.S.C. § 101
`
`A. Requirements for Patent-Eligibility Under 35 U.S.C. § 101
`
`40.
`
` I have been advised that, under 35 U.S.C. § 101, the proper analysis
`
`of each claim must begin with an inquiry into whether the claim describes one of
`
`the statutory categories of invention - - that is, a “machine,” “manufacture,”
`
`“composition of matter,” or “process.”
`
`
`
`15
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
` I have been advised that the term “process” is defined in 35 U.S.C. §
`
`41.
`
`100(b) as “process, art or method, and includes a new use of a known process,
`
`machine, manufacture, composition of matter, or material.”
`
`42.
`
` I have been advised that, if the claim is in one of the statutory
`
`categories above, the next question is whether any of the narrow judicially-created
`
`exceptions to patent eligibility applies. I am informed that there are three specific
`
`exceptions to § 101’s broad patent-eligibility principles: ‘laws of nature, natural
`
`phenomena, and abstract ideas.’
`
`43.
`
` I understand that, if a claimed invention falls within a statutory
`
`category, and falls outside the three exceptions, the analysis ends: the claim meets
`
`the threshold test of § 101 and claims patent-eligible subject matter. I further
`
`understand that only the third exception is relevant here, and it renders ineligible
`
`any claim that is directed to nothing more than an “abstract idea.”
`
`44.
`
` I have been advised that, in evaluating whether a claim meets the
`
`requirements of 35 U.S.C. § 101, the claim must be considered as a whole to
`
`determine whether it is for a particular application of an abstract idea, physical
`
`phenomenon or law of nature, and not for the abstract idea, physical phenomenon
`
`or law of nature itself. I understand that the patentability of a claim depends on the
`
`particular limitations – all of the limitations – of that claim. In this regard, I have
`
`been advised that a claim may not be stripped down to some supposed “‘essential’
`
`
`
`16
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`element, ‘gist,’ or ‘heart’ of the invention,” but rather must be viewed as a whole,
`
`with all of its limitations given effect.
`
`45.
`
` I have also been advised that abstract ideas have been defined as
`
`concepts or truths which are not ‘useful’ from a practical standpoint standing
`
`alone, i.e., they are not ‘useful’ until reduced to some practical application. I
`
`further understand that, it is irrelevant that a claim may contain, as part of the
`
`whole, subject matter which would not be patentable by itself, because the
`
`determinative inquiry is whether the claim as a whole is directed to statutory
`
`subject matter. I am advised that inventions incorporating and relying upon even a
`
`well-known abstract idea do not lose eligibility because several steps of the process
`
`use that abstract idea.
`
`46.
`
` I have been advised that a claim embodying a specific, practical
`
`application of an abstract idea or improvements to technologies in the marketplace
`
`would not be considered an abstract idea. I understand that a claim that is limited
`
`to a particular practical application of a judicially recognized exception is eligible
`
`for patent protection. I am further informed that a “practical application” relates to
`
`how a judicially recognized exception is applied in a real world product or a
`
`process, and not merely to the result achieved by the invention. When subject
`
`matter has been reduced to a particular practical application having a real world
`
`use, the claimed practical application is evidence that the subject matter is not
`
`
`
`17
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`abstract (e.g., not purely mental) and does not encompass substantially all uses of
`
`(i.e., preempt) a law of nature, a physical phenomenon or abstract idea.
`
`47.
`
` I have been advised that, to be considered patent eligible, a claim
`
`incorporating an abstract idea should also include other elements or a combination
`
`of elements sufficient to ensure that the claimed invention does not preempt all
`
`uses of the abstract idea, thereby inhibiting use of the abstract idea in the making
`
`of further discoveries.
`
`48.
`
` I have also been advised that, under the so-called “machine or
`
`transformation” test, a claimed method is not considered an abstract idea if it is tied
`
`to some structure, such as a machine, or if it effects a transformation of a statutory
`
`class of invention. I understand that the machine-or-transformation test is merely
`
`one of several factors to consider and not the sole test for deciding whether or not a
`
`claimed invention is drawn to an unpatentable abstract idea.
`
`49.
`
`I have been further advised that when a computer is programmed to
`
`perform certain steps – i.e., programmed to perform particular functions pursuant
`
`to instructions from program software -- it in effect becomes a special purpose
`
`computer -- i.e., a particular machine with a particular purpose.
`
`50.
`
` In my opinion, claims 17, 26, 27, 28 and 29 of the ‘350 patent satisfy
`
`the requirements for patent eligibility under 35 U.S.C. §101, for the reasons set
`
`forth below.
`
`
`
`18
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`B. Claim 17 Is A Statutory Process Under 35 USC § 101
`
`51. Claim 17 of the ‘350 patent is directed to “[a] method for determining
`
`a price of a product offered to a purchasing organization.” For convenience, the
`
`text of claim 17 is reproduced below:
`
`
`17. A method for determining a price of a product offered to a
`purchasing organization comprising:
`arranging a hierarchy of organizational groups comprising a
`plurality of branches such that an organizational group below a
`higher organizational group in each of the branches is a subset of
`the higher organizational group;
`arranging a hierarchy of product groups comprising a plurality of
`branches such that a product group below a higher product group
`in each of the branches is a subset of the higher product group;
`storing pricing information in a data source, wherein the pricing
`information is associated, with (i) a pricing type, (ii) the
`organizational groups, and (iii) the product groups;
`retrieving applicable pricing information corresponding to the
`product, the purchasing organization, each product group above
`the product group in each branch of the hierarchy of product
`groups in which the product is a member, and each organizational
`group above the purchasing organization in each branch of the
`hierarchy of organizational groups in which the purchasing
`organization is a member;
`sorting the pricing information according to the pricing types, the
`product, the purchasing organization, the hierarchy of product
`groups, and the hierarchy of organizational groups;
`eliminating any of the pricing information that is less restrictive; and
`determining the product price using the sorted pricing
`information.
`
`
`
`
`
`19
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
` I have been advised that the Board interpreted the meaning of certain
`
`52.
`
`claim terms as follows:
`
`
`
`Claim Term
`
`Meaning
`
`sorting the pricing
`information
`the pricing information that is
`less restrictive
`
`pricing types
`
`pricing information
`
`
`
`the pricing information is
`ordered
`less specifically applicable to a
`product, a purchasing organization,
`an organizational group or a product
`group
`a class or category of pricing
`adjustments
`information related to pricing
`
`53.
`
` I have been advised that the Board rejected the District Court’s
`
`construction of the terms “pricing adjustments” and “pricing information.” For
`
`purposes of my analysis in this Section VI, I am using the Board’s interpretation of
`
`the claim terms.1 With regard to the other language of the claims, I understand that
`
`in this proceeding the Board has taken the position that the claims should be given
`
`
`1 In Section IX below, I provide my opinion regarding the proposed constructions
`
`that were not adopted by the Board and the impact they have on patent eligibility
`
`under §101.
`
`
`
`20
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`the broadest reasonable interpretation in light of the specification. Thus, for
`
`purposes of my opinion, that is the interpretation I have given them.
`
`54.
`
`In my opinion, claim 17 of the ‘350 patent is clearly directed to one of
`
`the statutory classes of invention under 35 U.S.C. § 101. As I noted above in
`
`Section V, one of the statutory classes of invention is “process,” and the definition
`
`of the term “process” in 35 U.S.C. § 100(b) is a “process, art or method.” Since
`
`claim 17 recites a “method,” i.e., “[a] method for determining a price of a product
`
`offered to a purchasing organization,” there is no doubt that claim 17 is directed to
`
`a statutory class of invention under 35 U.S.C. § 101.
`
`C. Claim 17 Is Not Directed to an Abstract Idea
`
`55.
`
`I have been advised that the Board considered the concept of
`
`“arranging customer and product data into hierarchies” as being an unpatentable
`
`abstract idea. Institution Decision, at p. 30. SAP and Dr. Siegel evaluated “[t]he
`
`concept of arranging customer and product data into hierarchies” and “the
`
`calculation of product prices using ‘abstracted’ numbers,” as abstract ideas. See
`
`Petition, p. 17; and SX 1005, §§ 44-45, 49.
`
`56.
`
`In my opinion, when claim 17 is considered as a whole, as I
`
`understand it must be for purposes of evaluating patentability under § 101, it is
`
`clear that the claim includes additional meaningful limitations to ensure that the
`
`patent in practice does not amount to a patent upon any abstract idea alone. Only
`
`
`
`21
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`the first two steps of claim 17 involve arranging customer and product data into
`
`hierarchies - - the alleged unpatentable abstract idea. Claim 17 includes several
`
`other specific steps, not addressed by SAP in its Petition, by Dr. Siegel in his
`
`Declaration or by the Board in its Institution Decision, which, when the claim is
`
`considered as a whole, in my opinion are sufficient meaningful limitations to
`
`ensure that claim 17 is not merely claiming the use of customer and product
`
`hierarchies to determine a product price.
`
`57.
`
`In particular, the last five steps of claim 17 - - i.e., the storing,
`
`retrieving, sorting, eliminating, and determining steps - -define a specific, practical
`
`and advantageous way to determine a product price using hierarchical groups of
`
`customers and products. For example, the storing step requires pricing information
`
`to be stored in a data source, such as a database, and to be “associated, with (i) a
`
`pricing type, (ii) the organizational groups, and (iii) the product groups.” Also, the
`
`retrieving step requires “pricing information corresponding to the product, the
`
`purchasing organization, each product group above the product group in each
`
`branch of the hierarchy of product groups in which the product is a member, and
`
`each organizational group above the purchasing organization in each branch of the
`
`hierarchy of organization groups in which the purchasing organization is a
`
`member” to be retrieved. In addition, the sorting step requires sorting the pricing
`
`information “according to the pricing types, the product, the purchasing
`
`
`
`22
`
`
`
`Case CBM2012-00001
`U.S. Patent No. 6,553,350
`organization, the hierarchy of product groups, and the hierarchy of organizational
`
`groups.” Among other things, these other steps are meaningful because they
`
`provide for functionality that, for example, enables the reduction of the number of
`
`tables, and thus the number of queries, needed to determine a product price when
`
`using hierarchies. This in turn enabled a significant performance advantage for
`
`computers running software embodying the invention of the ‘350 patent.
`
`58. Dr. Siegel refers to claims 17 and 26-29 and alleges that these claims
`
`include abstract ideas and routine, conventional, and well-known activities added
`
`to abstract ideas. SX 1005, ¶¶ 44-49. However, he did not address the specific
`
`steps required by claim 17 in his opinion and did not identify any elements of
`
`claim 17 as abstract ideas or routine, conventional or well-known. See, e.g., VX
`
`2090, pp. 76-82. It appears that Dr. Siegel did not consider the separate steps
`
`required in the claimed method and the meaning to a person of ordinary skill in the
`
`art. VX 2090, p. 90, ll. 9-24.
`
`59. When Dr. Siegel was questioned about the specific steps required by
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
