The USPTO Would Like to Partner with the Software Community • Hacker News Board

Re: The USPTO Would Like to Partner with the Software Community

#71

Post by fghh45sdfhr3 » Fri, Jan 04, 2013, 9:50 PM UTC

pcl wrote: post #55

iskander wrote: post #41

Earlier quoted context omitted.

>Academia is already facing difficulties in computer science because much of the state-of-the-art research is being done by private companies...As a consequence, there are a number of areas in computer science where the leading academic papers are literally a good half decade behind the state-of-the-art that is buried in NDAs. Can you elaborate on which areas of CS academia you think are more sophisticated in the cor…

From what I understand, a lot of the FPGA and vector calculus stuff that financial-services companies are doing is leaps and bounds ahead of the published materials. But I'm not under NDA in any related projects, so that's just hearsay.

I'm pretty sure we have Wall street quants here, unless one of them offers a convincing argument that yes, they are well ahead of academia, I don't believe it.

In my anecdotal experience, the financial industry is light years behind most post-graduate level mathematicians and physicists. Finanical math is kind of scary for anyone who knows more math than the average banker.

Re: The USPTO Would Like to Partner with the Software Community

#72

Post by wtallis » Fri, Jan 04, 2013, 9:54 PM UTC

bhousel wrote: post #34

powertower wrote: post #28

Earlier quoted context omitted.

Yes, if the solution takes "dozen experts and millions of dollars", it should be possibly patentable. But if the solution is reproducible by an average or good programmer leading by logical steps , then it shouldn't be patentable at all.

The average programmer can't solve fizzbuzz. Therefore anything more complicated than fizzbuzz passes the nonobviousness test and is patentable.

The hypothetical "person having ordinary skill in the art" is presumed to have some actual skill, to be more skilled than a layperson, to have have some actual creativity, and to have an educational background similar to that of active workers in the field. People who merely call themselves programmers without having any significant skill do not count toward determining what the level of "ordinary skill" is.

Re: The USPTO Would Like to Partner with the Software Community

#73

Post by fghh45sdfhr3 » Fri, Jan 04, 2013, 9:55 PM UTC

jackowayed wrote: post #51

iskander wrote: post #41

Earlier quoted context omitted.

>Academia is already facing difficulties in computer science because much of the state-of-the-art research is being done by private companies...As a consequence, there are a number of areas in computer science where the leading academic papers are literally a good half decade behind the state-of-the-art that is buried in NDAs. Can you elaborate on which areas of CS academia you think are more sophisticated in the cor…

Databases. Oracle, Microsoft, etc. have figured out a lot about how to make high-performance query execution engines and transactional storage systems and written about very little of it. Research has caught up some, but it definitely lags.

I am sure they have a lot of tiny performance improvements. But since when is CS research about tiny performance improvements?

It's not like Oracle or anyone else has any secret algorithm which runs in linear time when all of academia only knows of exponential time solutions for the same class of problems.

Re: The USPTO Would Like to Partner with the Software Community

#74

Post by bitwize » Fri, Jan 04, 2013, 9:57 PM UTC

ajb wrote: post #64

"The first topic relates to how to improve clarity of claim boundaries that define the scope of patent protection for claims that use functional language." Or to put it another way, the patent database is a broken datastructure , how do we fix it? I think it's important to take their question seriously, because if we give them serious answers it will bring home why the patent system is more broken for software than f…

Imagine that at a given point in time, the patent database included not just the individual patents, but a '20 questions' style index, whereby any patent could be located.

Makes me think of the old computer game "Animal".

ARE YOU THINKING OF AN INVENTION? y

IS IT RED? n

DOES IT HAVE WHEELS? n

DOES IT RUN ON ELECTRICITY? y

etc.

Re: The USPTO Would Like to Partner with the Software Community

#75

Post by fghh45sdfhr3 » Fri, Jan 04, 2013, 9:58 PM UTC

rayiner wrote: post #56

jberryman wrote: post #45

Earlier quoted context omitted.

I'm interested in a reply to iskander's question as well as some concrete examples of new "computer algorithms... frequently requiring years and millions of dollars".

Think of the algorithms sitting in the base band of your cell phone. They implement things like modulation, hand-offs, power control, etc. E.g. there is some algorithm that controls the transmit power of your device to maintain the minimal transmit power necessary to close the link to the base station while you move around, walk into buildings, etc. There's another algorithm that tries to optimize hand-offs as you go…

All of your examples sound like variations on fundamental CS problems, and most CS undergrads should have been exposed to them and to their solutions.

Are you saying industry is leaps and bounds ahead in the fundamentals of CS theory? Or just that there is a lot of vendor specific detail in the hardware and infrastructure? Because the latter is not CS.

Re: The USPTO Would Like to Partner with the Software Community

#76

Post by danielweber » Fri, Jan 04, 2013, 9:59 PM UTC

Barraketh wrote: post #49

A large problem with software patents is that feature definition and implementation have been rolled into one. Patents were designed to protect implementation - that is, you can't patent having an engine in the car, but you can patent a specific design (implementation) of an engine. In the software world I feel like that distinction has been blurred. Even if we assume that software is patentable, the bounce back effe…

The reason is that all the novelty is in coming up with the feature itself.

This is a very good point. Often times knowing the feature you need to implement is the really hard thing. Once you've decided on that, it's trivial to implement, even if you're the first to do it.

Re: The USPTO Would Like to Partner with the Software Community

#77

Post by wtallis » Fri, Jan 04, 2013, 10:02 PM UTC

fghh45sdfhr3 wrote: post #70

wtallis wrote: post #62

Earlier quoted context omitted.

One area that's heavily under NDA (though perhaps not quite the situation described) is graphics drivers. NVidia and AMD both have high-performance graphics drivers, but the open-source alternatives (reverse-engineered for NVidia, but AMD sponsors their open-source Linux driver) are far behind. They're reluctant to even share hardware specs, let alone the code from their proprietary drivers. Part of the reluctance is…

One area that's heavily under NDA (though perhaps not quite the situation described) is graphics drivers. But that's not because the algorithms are new and awesome, it's mostly just because the exact specs of the hardware are not happily shared. CS research is not about lack of hardware specs. It is also not about protecting someones DRM. It is also not about crappy patents. And it is also not about how easy your pub…

> "But that's not because the algorithms are new and awesome, it's mostly just because the exact specs of the hardware are not happily shared."

No, that doesn't fully explain the situation. They're worried about far more than their competitor knowing how many ALUs are on their GPU. Graphics drivers have to solve several hard problems: optimizations for shader compilers, scheduling, and memory management, and that's before you even get into the graphics-specific stuff. In recent years, GPUs have been one of the most active areas of research into computer architectures. For you to suggest that a modern GPU and its drivers don's embody any hardcore CS research is just plain stupid - if GPUs were simple to build, then Intel would have shipped a good IGP by now.

Re: The USPTO Would Like to Partner with the Software Community

#78

Post by rayiner » Fri, Jan 04, 2013, 10:06 PM UTC

fghh45sdfhr3 wrote: post #75

rayiner wrote: post #56

Earlier quoted context omitted.

Think of the algorithms sitting in the base band of your cell phone. They implement things like modulation, hand-offs, power control, etc. E.g. there is some algorithm that controls the transmit power of your device to maintain the minimal transmit power necessary to close the link to the base station while you move around, walk into buildings, etc. There's another algorithm that tries to optimize hand-offs as you go…

All of your examples sound like variations on fundamental CS problems, and most CS undergrads should have been exposed to them and to their solutions. Are you saying industry is leaps and bounds ahead in the fundamentals of CS theory? Or just that there is a lot of vendor specific detail in the hardware and infrastructure? Because the latter is not CS.

They're not just variations on fundamental CS problems because the complexity of the problem is dominated by physics + hardware + infrastructure. E.g., while most CS undergraduates are exposed to control theory, a power control loop isn't a simple application of a controller. It has to deal with the physics of signal propagation, knowledge of the kinds of environments users encounter, the characteristics of the underlying radio, and the nature of the network infrastructure. All that insight and experimental validation is ultimately packaged as an algorithm (although a very specific and detailed one).

To analogize to another domain: a power control loop in a cell phone base band is as much "just a variation on fundamental CS problems" as is register allocation for a hairy architecture like x86. Yes, graph coloring gives you a conceptual framework to start with, but that gets you 10% of the way to a usable solution.

Re: The USPTO Would Like to Partner with the Software Community

#79

Post by danielweber » Fri, Jan 04, 2013, 10:07 PM UTC

eweise wrote: post #63

rayiner wrote: post #17

Earlier quoted context omitted.

That's one possible narrative. Another would be: The idea that I can be presented with a problem, hire a dozen experts and spend millions of dollars coming up with a solution to the problem, and have someone come along and just copy the solution and use it in their own product to compete with me is horrifying.

The actual technology is only one part of running a successful software business and not the most important from my experience. Just copying someone else's solution does not necessarily mean that you can be as successful as the originator.

The technology may not be the most important thing, but (excepting a few weird industries with significant legacy costs that newcomers can ignore) it's also the advantage the young start-up has against the established company.

Re: The USPTO Would Like to Partner with the Software Community

#80

Post by wtallis » Fri, Jan 04, 2013, 10:07 PM UTC

fghh45sdfhr3 wrote: post #75

rayiner wrote: post #56

Earlier quoted context omitted.

Think of the algorithms sitting in the base band of your cell phone. They implement things like modulation, hand-offs, power control, etc. E.g. there is some algorithm that controls the transmit power of your device to maintain the minimal transmit power necessary to close the link to the base station while you move around, walk into buildings, etc. There's another algorithm that tries to optimize hand-offs as you go…

All of your examples sound like variations on fundamental CS problems, and most CS undergrads should have been exposed to them and to their solutions. Are you saying industry is leaps and bounds ahead in the fundamentals of CS theory? Or just that there is a lot of vendor specific detail in the hardware and infrastructure? Because the latter is not CS.

You seem to be saying that it's "fundamental computer science" to be aware of a problem and the naive ways to solve it, but not fundamental CS to know what methods are actually usable in the real world. That definition may have its merits, but is certainly not appropriate to use in a patent law discussion.