An API is an abstraction, and as such cannot be patented. There’s nothing novel or interesting in an object method call or a function.

wrt point A..

A patent can say that to provide “a certain type of result to users”, you take these 3 steps.

Step one is to “convert seconds since epoch into year, mo, day so that” …(vague description here without actual algorithm but very precise semantics of end result).

Step two ….

Now, if you “provide a certain type of result to users” and to carry that out you “convert seconds since epoch into year, mo, day so that” along with the other 2 steps then you are in violation.

The “algorithm” violated was the larger level one that didn’t specify in full detail how to do the date conversion [this is related to your point B].

Now, how do I link this to what I am talking about?

When you use a particular API, it might be common use to carry out these three steps. There might even be three such functions that people will use whenever they want to “provide a certain type of result to users”.

This is related to why I mentioned the sort example based on primitives. If you use that API, you will likely use all the 3 components, and these could violate a patent at that higher level (to build a sort).

In OOP, this can boil to 3 method calls perhaps.

In fact, instantiating an object, by default, might already carry out all of the steps for you but one, so that you would be in violation by calling that one method to do date conversion (at least if you didn’t change the defaults).

This is why early in this thread I was referring to “security feature X”. There is a higher level alg that is being violated. If you use these API as intended, you will likely violate such a patent that implements security feature X in such and such a way (to match the semantics for the API).

And do note that we don’t need more than one function call, eg…

Remember the general but explicit steps in the patent can be implemented behind the scenes by a single function call as per the semantics of that function call.. eg, update some other object and do X or Y other thing as side effects. ..Now if you violate a patent that does all of these side effects, you are screwed.

So when we define (high level) semantics for a function, those semantics can be violations of a patent claim that patents those semantics. [And if we change the semantics to avoid violation, we break the app in the general case.]

Look at this patent, claim number 1 http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=29&f=G&l=50&co1=AND&d=PALL&s1=software&OS=software&RS=software

It is vague, yet it does specify something. In fact, all the claims (as I see as I skim) are vague in many ways. Yet this was granted a patent.

You don’t have to be precise to the last drop by any means.

You can match (high-level) semantics of a function so that these satisfy at least one claim from a patent. … see that patent link above. It is vague in many ways.

This patent does not specify how to perform that calculation. That patent covers a wider scope and this date function is a part of it.

It doesn’t matter the scope of the overall patent. If it doesn’t specify how to do something, that “something” – whatever it is – isn’t covered by the patent. That’s point A.

Point B: even if it does specify how to do it, that also doesn’t mean for sure that the specific implementation it mentions is covered. Take the de facto example, the patent on a rubber-curing process. Individual parts weren’t novel; the collective was.

I skipped this section because I didn’t understand what you meant. Can you clarify (so I can respond properly)?

An API can be of something like computing the date (output: year, month, day) from an integer representing the number of seconds since some epoch. That has very precise semantics. Those semantics do not describe an algorithm, as you stated; however, any algorithm that implements this functionality will violate a patent that stated that we have a framework and within that framework, the year, month, and day will be calculated from the number of seconds since some chosen epoch.

This patent does not specify how to perform that calculation. That patent covers a wider scope and this date function is a part of it. If you rely on a particular framework (eg, some subset of dotnet) that is described by that patent and you calculate the date accordingly, you are in violation.

A patent that simply says “year, month, and day are calculated from seconds such that year, date, and month are that many seconds from Jan 1, midnight….” likely would have tons of prior art; however, a patent with larger scope can leave the smaller details undefined and overall have these claims (which include extra context) have no prior art.

Are you people saying that all patents specify all potential algorithms coverable within to full detail? Of course, not. There are varying levels of detail that different patents get into wrt it’s various components…or so that is the impression I have gotten. Are there disagreements?

Look up the Freetype case for working around an aggressive patent through reworked internal semantics.

The hypothetical patented quicksort algorithm can be described at a (high) level that would cover “quicksort” as defined in textbooks, assuming of course that such a thing as “quicksort” has been defined universally. Thus you couldn’t change the implementation to something non-infringing without implementing something else.

Alright, let me check wikipedia…

From wikipedia: http://en.wikipedia.org/wiki/Quicksort

>> Quicksort sorts by employing a divide and conquer strategy to divide a list into two sub-lists.

>> The steps are:

1. Pick an element, called a pivot, from the list.
2. Reorder the list so that all elements which are less than the pivot come before the pivot and so that all elements greater than the pivot come after it (equal values can go either way). After this partitioning, the pivot is in its final position. This is called the partition operation.
3. Recursively sort the sub-list of lesser elements and the sub-list of greater elements.

>> The base case of the recursion are lists of size zero or one, which are always sorted.

So however you implement quicksort (and wikipedia does give a pseudocode example which follows these steps quoted), you would have to implement this algorithm or else you would not be implementing quicksort. Thus if this algorithm (these very steps as described on wikipedia) were patented, you could not implement quicksort.

You could implement some other sort with good average case running time, but it would not be as per this process here described.

Now, I already said that quicksort is not a good example because alternative sorts would still yield suitable results in just about all cases. But we can find many other API such that changing semantics would break apps.. or do you people not think so?

An API includes a very weak semantic that gives you an idea of what the function does. But it doesn’t give you any idea of the actual semantics of the function: it’s not telling you what the code is actually doing, just what the results are.

A patent is the complete opposite. It says “here is a way of solving this problem” – in other words, I know what results I want, I just don’t know how to do it.

wikipedia disagrees: http://en.wikipedia.org/wiki/API

>> The software that provides the functionality described by an API is said to be an implementation of the API. The API itself is abstract, in that it specifies an interface and the behavior of the identifiers specified in that interface; it does not specify how the behavior may be implemented.

Did you get that? “interface and ..behavior”.

Also, if I had been wrong, I’d just change terminology because the fact remains that a function comes with associated API. You can’t separate the two and have something meaningful.

But, I don’t have to worry about changing terminology since wikipedia appears to agree with my usage of API.

An API means predicted data in, predicted data out. Nobody says your qsort() needs to use a patent-infringing implementation internally. It doesn’t even necessarily need to implement a quicksort, as long as it gives the same data

Do you really think MS have patented, say, using Gnome Data Access 2.0 (as Mono’s ADO.NET implementation does), for example? The point AlexH has been trying time and time again to make is that an API itself can’t infringe a patent – only a specific method application – and that specific method can easily not be what was originally planned as a “patent trap”

>> An API is just a group of words.

Not at all. An API implies some semantics.

I think you’re confusing “what an API is” with “why you use an API”. Semantics aren’t part of an API.

In terms of what patents cover and what they cost, there is a lot better information out there via Google than I could supply here.

How frequently in the FOSS world do people have to go back and design around patents after they have written code? I’m sure there are real costs. What if instead of this simply affecting some obscure algorithm once every blue moon, the patents get pressed against common API?

Which API might be most vulnerable?

create a library call named qsort which implements the quicksort algorithm as per above claim.

You can’t patent “foosort();” you can patent “foosort(); by using this algorith” – and even that’s pretty tenuous

Can you clarify what you mean (ie, shed light on the grayness)?

Not at all. An API implies some semantics.

Why are you even saying the foo example makes sense?

BTW, anyone now the cost for submitting a patent? [I'm assuming bypassing attorneys is allowable. Also, ignore research costs, etc.]

If it was possible, somebody would have done it by now. But there is no such example. Patent law just doesn’t cover specific embodiments: it covers methods of doing things. An API is just a group of words. They’re totally different.

If you do, then you are stuck in the sense that you can no longer adhere to the documented semantics for foo without violating the claim.

Now, how do you fix all the lines of code where foo was already used? If you change the semantics of foo’s implementation, the apps could break. If you don’t change it, you are in violation?

Changing some types of semantic information may not matter in practice, but in other cases it certainly can matter. Eg, implementing a bubblesort behind quicksort would violate the defined semantics. In this case, the application may not suffer, but in other cases it may. Generally, the type of sort should not matter, but other functions besides sort methods can prove problematic. I want to give a clear example where being forced to change semantics to something outside of a violated claim would break applications.

In order to avoid prior art, the patent can become more specific in detail arbitrarily approaching the API.

If you use the API, as the API is intended to be used, you would be violating one or more claims of the patent. Semantics of the API implement one or more of the patent claims.

This issue is special because writing any old patent is not going to approach an API in all likelihood unless you design the patent with the API in mind. However, if an API exists, prior art exists; hence, you’d have to write the patent before the API exists but knowledgeable of such an API.

Make sense?