Claimable Aspects of Software-Implemented Business Methods AndrewChin.com April 3, 2003 Patent Pending

Claimable Aspects of Software-Implemented

Business Methods

AndrewChin.comApril 3, 2003

Patent Pending

Claimable Aspects of Software-Implemented Business Methods

2

Problems

• Validity– Neglect of non-patent prior art– Diverse classification of

analogous patent prior art

• Valuation– Rapid product innovation– Claims directed toward novel

features as seen from inventor’s perspective

– Can we do better?

Formal vs. Informal Claim Limitations


4

Formal Claim Limitations

• Logical/mathematical constraints on software design and implementation

• Programmer’s perspective


5

Examples

• “calculating a difference between two summations of corresponding multiple samplings; and determining whether an absolute value of the calculated difference equals or exceeds a predetermined value”

• “said linear combination has weighting coefficients that depend upon the sine and cosine of said horizontal angle along said preselected path”


6

Informal Claim Limitations

• Steps of a user-system interaction

• User’s perspective


7

Examples

• “facilitating annuity purchaser entry of quote solicitation information used by the annuity providers to establish a quote for an annuity”

• “transacting a purchase of the product in response to a user approving the purchase price”

• “maintaining a purchase history for the product”


8

The Waterfall Model

ApplicationDescription

RequirementsSpecification

SystemDesign

Product

Initiation

Analysis

Design

Implementation

Operations and Management

Specification

Design


9

The Waterfall Model

ApplicationDescription

RequirementsSpecification

SystemDesign

Product

Initiation

Analysis

Design

Implementation

Operations and Management

Informal

Formal

Validity IssuesRelating to Formal Claims


11

Turing Machines

• Tape• Head• Alphabet• States• Next-move function


12

Church’s Thesis

• Every machine computation is equivalent to a Turing machine computation– Not provable, but every known

digital computer and model of computation satisfies this thesis


13

Universal Turing Machine

• A Turing machine U that can simulate the behavior of any Turing machine

• Turing machine specifications can be uniquely numbered: T1, T2, T3, …

• U reads the serial number i of a Turing machine on its tape, then simulates the behavior of Ti


14

Obviousness: General Standard

• A claimed invention is obvious if its differences from the prior art “are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which the claimed subject matter pertains.” – 35 U.S.C. § 103


15

Utility: General Standard

• To have patentable utility, it is not necessary for an invention to improve upon the performance of the prior art – Lowell v. Lewis (1817)


16

Obviousness:Genus-Species Analysis

• A claimed species is nonobvious over an encompassing prior art genus only if it has a unique and unexpected advantage or property that distinguishes it over the unclaimed species.


17

Implications of theUniversal Turing Machine• U is a genus prior art reference

– Species are T1, T2, T3, …– No significant utility

• Every formal claim encompasses (an equivalent) of some Ti

• Software prior art references disclose subgenii of U– For U to be analogous, it may be

sufficient for U to contain Ti

– Genus-species analysis


18

Responses

• Be prepared to show that the claimed invention has a “unique and unexpected advantage or property” over the prior art

• Include at least one field-of-use limitation in every claim

• Include limitations directed to algorithmic efficiency

Valuation IssuesRelating to Informal

Claims


20

The Patent Right

• Exclusionary, not exclusive• Monopoly power: “the power

to control prices or exclude competition”

• Few patents actually confer monopoly power


21

Question

• Can a patent claim be drafted with a view to acquiring monopoly power in some market?– Annotated patent claims– Rigorous product market

definition•Limited precedent in caselaw,

secondary literature


22

Antitrust Analysis

• Define a relevant market– Product market– Geographic market

• Determine whether the defendant has monopoly power in the relevant market– Market share– Entry barriers


23

Defining a Product Market• Consider both demand-side and

supply-side substitution that would occur if a hypothetical monopolist raised the (quality-adjusted) price of A– Demand-side: Enough consumers would

switch from A to B to make the price increase unprofitable• B belongs in product market

– Supply-side: Another producer would switch from making C to making A, thereby making the price increase unprofitable• The producer may be identified as a potential

entrant in the product market


24

Overall Approach• Initial product

– Goal: Define the product market in which the initial product competes

– Usually: Defendant’s product

• Demand-side substitutes– Identify other products that are similar

enough to the initial product to take away business

• Supply-side substitutes– Identify other producers that are

capable of producing and selling the initial product (or a substitute) in sufficient volume to take away business


25

Demand-Side Substitutes

“The outer boundaries of a product market are determined by the reasonable interchangeability of use or the cross-elasticity of demand between the product itself and substitutes for it.”

-- Brown Shoe, 370 U.S. 294, 325 (1962)

(emphasis added)


26

Demand-Side Substitutes• “Interchangeability of use and cross-

elasticity of demand are not to be used to obscure competition but to ‘recognize competition where, in fact, competition exists.’”

-- Continental Can Co.,378 U.S. 441, 453 (citing Brown Shoe)

• Product market boundaries must track areas of effective competition; i.e., “meaningful competition between interchangeable [products].”

-- Id. at 456.


27


• A relevant product market defined around a particular product consists of products that offer:– “[functional]

interchangeab[ility]” and– “meaningful competition”

with the given product.


28

Defining a Software Product

Typically, a software product is defined by reference to accompanying software (code) and documentation, and consists essentially of:

1. A limited license to use the software (according to the documentation); and

2. Technological access to the software for all licensed uses (according to the documentation)

It does not include the software itself!


29

Technological Preconditions

• Use of a software product is subject to technological preconditions– Documented preconditions

•License and documentation– Material undocumented

preconditions•Product reviews•Testing


30

Consumer Demand for Software Products

• A consumer uses a software product by interacting with a system.

• Each interaction embodies a specific user purpose.

Consumer demand for software products = Consumer demand for user-system interactions


31

Software Products and System Behavior

• Software can “call on” any other software that is already present on the system

Every Windows program calls on code in the Windows OS (via the Windows API)


32

Software Products and System Behavior

• A software product supports interactions between the user and the system by allowing the system:– to execute software that accompanies

the software product, and– to call on other software that does not

accompany the software product.During each supported interaction, the

software product assumes responsibility for the system’s behavior by specifying which software is to be executed by the system.


33

Intuition

Software products are constituted by processes, not code.

• Microsoft, FOF 184: “[T]he functionalities of a software product are not provided by the mere presence of code on a computer’s hard drive. For software code to provide any functionalities at all the code must be loaded into the computer’s dynamic memory and executed.”


34

Types of End Uses for Software Products

• Supporting user-system interactions (“tasks”)– Specifying which software is to run on

the system in order to produce system behavior that supports a task

– Subject to documented preconditions, conferring sufficient legal rights and technological access to run this software

• Preinstalling accompanying “platform software” that is required as a documented precondition for the use of another software product


35

Functional Interchangeability

• Two software products are functionally interchangeable for a desired user purpose if each product supports the same interaction that, when viewed from the user’s perspective, embodies the desired user purpose.


36

Describing an Interaction

In the determination of whether software products are functionally interchangeable, the interaction should be characterized so as to:

• embody a specific user purpose• be technology- and

implementation-independent• be complete, meaningful, and well-

defined from the user’s perspective


37

Price Discrimination Markets

• Captive (i.e. inframarginal) buyers to whom a significant price increase could be profitably targeted

• A group of buyers who would not switch to other products, or find other sources, in sufficient numbers to make a “small but significant and nontransitory” price increase unprofitable– Horizontal Merger Guidelines, § 1.12


38

Price Discrimination

• Possible when:– Seller can identify captive buyers,– Seller can discriminate against captive

buyers, and– Arbitrage is difficult


39

End Use Segments

• “Relevant product markets consisting of a particular use or uses”– Horizontal Merger Guidelines §

1.12

• Most common type of price discrimination markets


40

(Quality-Adjusted)Price Discrimination

Markets• Premised on the ability of a (hypothetical) monopolist to discriminate against a particular end use by reducing the quality of its product significantly below a competitive level with respect to that end use only– Difficult with physical products– Relatively easy with information

products• Digital rights management


41

End Use Segments

• Should specifically account for some specific part of the consumer demand for the product

• Complete, meaningful, and well-defined in the eyes of consumers

• Not functionally interchangeable with any other end use or combination of end uses– Nobel Scientific Industries


42

Essential Use CasesAn essential use case is a structured

narrative … comprising a simplified, generalized, abstract, technology-free and implementation-independent description of one task or interaction that is complete, meaningful, and well-defined from the point of view of users in some role or roles in relation to a system and that embodies the purpose or intentions underlying the interaction.”

-- L.L. Constantine & L.A.D. Lockwood,Software for Use 103 (1999)


43

Example 1’

System: ATMUser Purpose: Get cashUser Action System Response

insert card

enter PIN

press key …

read magnetic striperequest PIN

verify PINdisplay menu


44

Example 1

System: ATMUser Purpose: Get cash

User Intention System Responsibility

identify self

choose

take cash

verify identityoffer choices

dispense cash


45

Example 2System: PCUser Purpose: Perform a Web transaction

User Intention System Responsibility

select Web resourceretrieve Web resource

perceive Web resource

offer choice of Web resources

request Web resource from Web serverreceive Web resource from Web serverpresent Web resource


46

Example 3System: Client-server networkUser Purpose: Purchase an itemPrecondition: Purchaser is a previous

customer about whom information has been storedUser Intention System

Responsibility

identify selforder item

display item

receive requestretrieve purchaser informationgenerate purchase orderfulfill purchase order


47

Reasonable Interchangeability

• “[G]enerally a price differential, even a substantial one, is irrelevant for purposes of determining reasonable interchangeability.”

-- ADM, 866 F.2d 242, 246 (8th Cir. 1988)

Rationale: Price differentials among functionally interchangeable products are usually offset by differences in quality or other consumer preferences– Exceptions: Government price controls

(e.g., ADM); inherent cost advantages (e.g., Consolidated Gas, Alcoa (Rome Cable))


48

Reasonable Interchangeability

• Competitive variables are “the factors that normally determine the choice or preference of the user.”– Pfizer


49

Augmenting the Essential Use Case

• Essential use cases are implementation-independent– Different software products can implement

the same interaction in different ways– Consumers can have economic preferences

regarding these varying implementations

We account for consumer preferences by identifying variables with respect to the performance of system responsibilities that can form a basis for “meaningful competition” among software products.


50

Software Metrics

Preference Metrics Performance Metrics

AffectEfficiency (subjective)HelpfulnessControlLearnability

CompletenessCorrectnessEffectivenessEfficiency (objective)ProficiencyProductiveness


51

ExampleSystem Responsibility

Performance Variables

offer choice of Web resources

request Web resource from Web server

receive Web resource from Web server

present Web resource

search costs; accuracy of presented meta-information

communication costs; transfer of personally identifiable information

communication costs; accuracy of presented meta-information

accuracy of presented information; effects on system resources


52


• Examples:– Shell browsers

• Assume (and delegate) system responsibilities; performance variables are essentially the same as for IE: substitutes, but limited in their ability to compete

– “Browsers for individual internet extensions” (e.g., multimedia players)• Historically, assumed system

responsibilities, but only subject to narrow preconditions: probably not substitutes

• RealOne Player (with built-in shell browser): substitute, but see above


53

Supply-Side Substitutes

• Actual and potential products• All producers who can switch

to making the product• Consider barriers to entry

– Sunk costs of entry and exit that cannot be recovered if entry fails

– Production, distribution, and consumer-acceptance obstacles


54

Structural Barriers to Entry

– Exclusionary preconditions•Proprietary file formats

– Proprietary platform software•“Applications barrier to entry”

– Interference from preinstalled software•Overriding of user’s choice of default

software


55

Summary

1. Define defendant’s product2. List relevant consumer purposes3. Represent as essential use cases4. Identify functionally

interchangeable products5. List competitive variables6. Identify reasonably

interchangeable products7. Identify structural barriers to

entry


56

Product Market Definition

• Essential use case• Preconditions• Ranges of

preference/performance metrics


57

Drafting Claims

• Limitations may include– Interaction steps from the

essential use case (e.g., as steps in a method claim)

– Preconditions (esp. where necessary for enablement)

– Ranges of preference/performance metrics

• May omit or broaden limitations for claims of varying scope


58

Example Essential Use CaseSystem: Client-server network

User Purpose: Purchase an itemPrecondition: Purchaser is a previous

customer about whom information has been storedUser Intention System

Responsibility

identify selforder item

display item

receive requestretrieve purchaser informationgenerate purchase orderfulfill purchase order


59

Example Claim• A method of allowing a user to purchase an

item, comprising:– displaying the item to a purchaser;– allowing the purchaser to identify himself or

herself;– allowing the purchaser to order the item;– receiving a request from the purchaser to

identify himself or herself and to order the item, wherein only one purchaser action is required to cause the request to be received;

– retrieving previously stored information regarding the purchaser;

– generating a purchase order; and– fulfilling the purchase order.


60

Apple Licenses “1-Click”


61

Conclusions

• Validity of formal claims will continue to be relatively uncertain

• Informal claims are more likely to be valuable and less likely to impede programming freedom

Documents

Claimable Aspects of Software-Implemented Business Methods AndrewChin.com April 3, 2003 Patent Pending