`
`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 speci