throwawaykf

Yes, it literally covers something as specific as creating "event objects" out of touch inputs and interpreting them as either zooming or scrolling gestures.

Minority Report is not sufficient prior art because:

1) It does not include a touch-sensitive display,

2) its user input is not "points applied to the touch-sensitive display" that it does not have,

3) it is wholly non-enabled (at least in the movie) which is why it does not teach, as far as we can tell, create "event objects" in response to user input,

4) and though it may depict scrolling gestures and pinching gestures in various scenes, it does not teach how to determine whether an input is a scroll or a pinch (which this patent proposes doing by differentiating the number of points in the touch input).

But why even worry about fictional, non-enabled prior art when people have found specific prior art to (temporarily) invalidate these claims?

1) Pretty much each and every action has a fee attached [1].

2) Each rejection has a 3 - 6 month time limit to be responded to.

3) Most applicants will fight every rejection to preserve their rights.

4) Granted patents have (admittedly higher [3]) fees due only every 3, 7 and 11 years, whereas patents in prosecution typically have fees due every 3 - 6 months. However, granted patents are not guaranteed to be renewed, which means their contribution is reduced [4, 5].

So if you want to talk perverse incentives, the USPTO actually have greater incentive to issue more rejections and collect frequent short-term fees on applicant responses, than they do to issue patents and collect infrequent long-term fees on renewals.

[1] http://www.uspto.gov/web/offices/ac/qs/ope/fee031913.htm

[2] http://www.uspto.gov/web/offices/ac/qs/ope/fee031913.htm#mai...

[3] http://www.patentlyo.com/patent/2010/06/patent-maintenance-f...

[4] http://btlj.org/data/articles/20_04_02.pdf

[5] http://www.uspto.gov/about/stratplan/ar/2011/mda_06_01_03.ht...

I think this is one reason that most examiners (at least IME) have their default mindset to "Reject! Reject! Reject!" Also, this is why something like Ask Patents is invaluable to even the odds.

I don't agree with the quantitative approach, but I can't help think that technology can help. Google has already (in my opinion) helped the PTO greatly narrow claims the past decade; similar technology can help even more.

I have some background in NLP. And I know it's surprisingly effective when it comes to domains with specific jargon (cf. Watson and medical language). I've lurked long enough to know some here (such as VanL) have already experimented in this area. Personally, I have toyed with the idea of constructing parse trees out of multiple technical texts and claims, "normalizing" them using ontologies, and trying to find matches (i.e. prior art) using various tree-matching algorithms. I have a feeling it would be very effective. (Maybe Google already does this!)

But that does not address the problem of identifying patents that are quantitatively invalid but qualitatively valuable. To me, that is the more important long-term problem.

Let me clarify: people think they are crap for the wrong reasons, such as vastly overestimating the scope of the claims. But they are (IMO) still mostly crap because they are ridiculously narrow and not necessarily clever... Yet they are still valid because that's what the patent system is tuned to.

I have said this before in other comments -- the way patents are examined is mostly quantitative: find enough pieces of prior art where enough snippets of texts cover the text of the claims, and you have a rejection. No thought is given to the quality of the claims. For instance, I'd wager the RSA patent (which even the most die-hard anti-patent folks typically admit is novel) would not be granted today because each aspect of the claims is mentioned somewhere in the prior art. It is the combination of steps which is novel. Yet todays examination process would shoehorn the claims into a ridiculously narrow set of steps that (the attorneys hope) would still typically be infringed.

Examination these days is a mechanical process whereby examiners just try to find enough references with language in them to cover all steps in a claim to issue an easy rejection. (Yes, the "rubber stamp" is more likely used to reject rather than allow.)

So how do you try to qualitatively judge a patent when you have only a few hours appreciate all the prior art out there and appreciate what is being claimed and to do so?

The answer is, you can't; the only way to have a scalable process is to issue actions on a quantitative basis rather than a qualitative one.

As I said, it's a difficult, almost philosophical question.

A few comments on this article:

1) This is a very unusual case; most answers (and almost all questions) from "lay engineers" completely misunderstand the scope of the patent, since they don't even know what claims are. And even if they do, they are very lax at interpreting claims. And even then, most posters frequently misunderstand the terms used (case in point, Spolsky's very post! https://news.ycombinator.com/item?id=6084884). All this leads them to post irrelevant prior art.

That does not mean there are no useful answers at all; there are, but they mostly come from people who are somewhat versed in patent law (such as agents, lawyers and examiners). Some re-wording of claims, such as what Micah Seigel does in his posts, helps, but for the proportion of useful answers to go up, we need more education about how patents work for this to be useful. It's really not that hard; heck I did it!

2) It's wayyy too soon for a victory lap because that was only the first non-final rejection, for which a response has already been filed. Statistically, this application will undergo 2.5 more rejections [1] and (based on my guestimate) at least one Request for Continued Examination (RCE) before being abandoned or (more likely considering the applicant) issued with much narrower claims.

3) Patents are worded so not (primarily) to be obfuscating, but rather because of legal, technical and some silly historical reasons. For instance, pronouns are very rarely used because any indefiniteness can be cause for invalidation. Obfuscation will not help much, because you are not trying to get it past lay engineers, but patent examiners, who have a technical background and are (usually) adept at reading patentese. Complaining about how hard it is to read patents is like a Blub programmer complaining about Lisp. You simply need to learn the language to appreciate what you are reading.

4) Most "software" patents (which can't even be cleanly categorized as such) are not crappy, at least with respect to all other patents. There are studies presenting this view [2, 3], but it's also based on my experience having read hundreds of patents. Almost none are revolutionary, but just as few are really as bad as the media portrays. The PTO has gotten pretty good at finding prior art (interestingly around the same time Google came around), and the really broad patents are dying out.

The "crappy software patents" view is common mostly because tech media routinely publishes uninformed (or disinformed? [4]) rhetoric, mostly because they garner some easy rageviews, and audiences accept it without critical thought. I do think the bar for non-obviousness should be different, but solving that is a difficult, almost-philosophical problem.

5) In response to various comments on this thread regarding pay-for-prior art schemes, initiatives such as Article One Partners already exist.

I am not a patent lawyer or an agent, but I believe in the patent system, as I have actually worked for the mythical small-guy firm that was ripped off by the big guys and almost died, but eventually prevailed with patents. You don't hear these stories much because typically the small guys don't have the PR budget for it [4]. (And also because many of those with patents turn to trolls, who like to keep a low profile.)

I have only recently become personally invested in the patent system, but I want all inventions, including mine, to be truly novel and worthwhile. And I want people to get off their butts and do something rather than complain about patents on HN. This is why I support Ask Patents.

[1] http://www.uspto.gov/dashboards/patents/main.dashxml [2] http://papers.ssrn.com/sol3/papers.cfm?abstract_id=650921 [3] http://papers.ssrn.com/sol3/papers.cfm?abstract_id=970083 [4] http://www.paulgraham.com/submarine.html

Don't count on it:

http://www.theverge.com/2013/3/4/4054634/musics-pay-what-you...

Everything is a filter bubble.

Even then, you are not strict enough in your interpretation of the claims. This patent covers nothing more than tallying the number of times multiple players select a given attribute for their characters in an MMO. That is it. Whether you read it as a (patentese-speaking) engineer or a lawyer, that is literally it. (Unless it gets to a jury, in which case, all bets are off...)

That is why, IMO, it is a silly patent, and why I think it should have very limited negotiating leverage. Unfortunately, the current legal system does not differentiate between "infringing" and "infringing on a nigh-useless feature", and if a lawsuit is involved it is already too expensive to argue this difference. (For the legal-minded around here, from a pseudo-lawyer perspective, I think Rule 11 could use a little tweaking.)

All the other comments in this thread talking about the merits of this patent are absolutely baseless because the posters don't even know what claims are. Yet, this is the type of rhetoric that drives patent-related discussions on online forums these days. Why should anyone, least of all "your congress-critters", bother listening to you when you all literally don't know what you are talking about?

Some other points I'd like to address:

1. You say you could pose the problem to 5 engineers and get a solution -- but what if the problem itself is non-obvious? As an engineer, can you acknowledge that it's not always the solution that is clever, but the phrasing of a problem in a certain way, or heck, even the discovery of a problem, that leads to a solution? If so, where does "implementation" end and "invention" begin?

2. If you think getting a patent should be exponentially difficult these days, congratulations, you have what you wish for! The way prosecution goes these days, it is almost quantitative, whereby almost any combination of snippets of text in any publication anywhere in the world could be used to show obviousness, it is very difficult to get patents, regardless of the merits. The game now is not to claim "real" inventions, but something narrow enough that combinations of prior art do not "make obvious" yet something that somebody else will stumble upon inadvertently. Which is how you get stupidly narrow patents like this one... which people still end up infringing!

The patent system is a bit of a mess, but for many different reasons than what most here think.

So, yes, my comment was a reaction to the general level of discourse on patents beyond just this specific one, but I would not call it knee-jerk. Case in point: the sibling comment to yours.

At least your take on it is more in tune with reality than the common misconception that patents cover "abstract ideas". The law views abstraction differently than we do(and really, even the Supreme Court doesn't know how to define it other than "we know it when we see it."

However, I'd like to know: what exactly is it that you think this patent covers, and what about it do you find "unbelieveable"? Not that this is a stellar patent, but from most of the comments on this thread, it is amply clear most here don't know how patents work.

Back then my conclusion was that actual voice / video traffic was still direct P2P, although it kept connections open to other IPs, probably for signaling/stun/relaying. I haven't had a chance to run the test again because, well, I'm on a mobile device :-)

But my bigger point was that on a forum ostensibly for hackers, there should not be so much speculation and innuendo about something that can be pretty easily tested.

http://arstechnica.com/security/2013/05/think-your-skype-mes...

I cannot understand why none of the alarmist articles about Skype (some even by so-called "cypherpunks") has ever even bothered to run such a simple check.

FWIW, I ran my own simple test using netstat when Skype first centralized the supernodes. I walked away satisfied when I still saw primarily P2P activity during voice/video calls to an IP that belonged to the remote party. (It used UPnP port forwarding to traverse the NAT/firewall, if anybody is curious.) But then, I'm the trusting kind and dug no further. And it's been a couple years since. If there truly are "hackers" on here, I encourage them to try their own experiments and share them.

I comment very infrequently, but only use throwaway accounts as a personal policy based in part on HN-the-community's response to my opinions and HN-the-website's aggressive response to downvotes. (I'm actually re-using a previous throwaway because my last throwaway was autodead-on-arrival. Flagged IP maybe?)

Anonymity is not really the point; In fact, there are HN members who might figure out my identity simply because they were directly involved in these experiences.

The SRE anecdote may seem unbelievable, but why would this have been the case with multiple Google SREs? I did not imply that their work at Google consists of waving a magic wand and things getting done; it's more likely that the basic building blocks of Google's infrastructure are very powerful, and you don't have to worry about a bunch of things that other SREs have to. "Nice libraries and tools" is an understatement. Seems it's not only that they are reliant on $ProprietaryTechnologyG, they could not explain how $ProprietaryTechnologyG works or even describe alternative methods they'd use instead.

On the other hand, it is possible that it's only been the lesser SREs that have been interviewing around.

Also: The two Googlers I talked about (one of whom has been there longer than you, if I remember your HN comment history correctly), are doing very interesting work, and are very happy at their jobs. As a disclaimer, I know one well and the other I met only once. Nonetheless, they, in no unclear terms, said what I paraphrased and quoted above.

I didn't mean to imply that the stack was made so huge to keep unhappy employees in. In fact, I did not mean to imply any intent at all. However, as you said, since employees are not forced to understand it, most of them don't, and this becomes just another factor to consider when thinking of changing jobs. Not knowing the whole stack is perfectly fine, but when critical pieces have no comparable equivalent in the outside world, your skills become less transferable. (Plus, you might not feel like leaving all that good stuff behind!)

As I said in another comment upthread, the "proprietary stack" aspect at Google seems to be more pronounced than at other companies like Microsoft. I mean, come on, it's a commonly accepted fact that it takes a year to become productive after you start at Google. What reasonable conclusion about the stack can one draw from that?

1. At another large (but not XXL) "Internet" company, none of the Google SREs have made the SRE hiring bar, precisely because half their answers to "How would you solve problem XYZ?" are "Oh, I'd just use $ProprietaryTechnologyGHJ", to which the response is, "Well, but we don't have $ProprietaryTechnologyGHJ", to which the response is "Uhhh..."

2. Of the couple Google (non-SRE) software engineer interviewees I am directly aware of, nobody has made it through either, partially for similar reasons (reliance on opaque external services). To be fair, their other shortcomings were more significant.

3. One Googler that I know confided that they are terrified of leaving Google, because they wouldn't (paraphrasing) "know how to code in the outside world."

4. Yet another Googler I talked to said that their stack is unimaginably huge, and nobody knows how all of it works, which was (quoting) "probably by design." Make of that what you will.

I guess it's a viable strategy, but nobody likes it when it's done to them.

Edit: An early example of a mechanical "algorithm" patent - http://www.google.com/patents/US3765263

In this case, that happens to be preventing poor passwords. That is a concrete, real-world problem, requiring practical solutions, which these patents purport to provide (probably) novel, non-obvious variations of. For example, one of the less "decent" patents uses (what seem to be) bloom filters to track and test for poor passwords. This does not mean all uses of bloom filters are covered by it. The claims specifically cover the method of using bloom filters to test for bad passwords.

Really, it becomes clear what is covered when you simply read the claims.