This is almost exactly what I'm currently coding in a side project in order to dynamically load different parts of a game when necessary instead of front-loading it all at once.
This is just another example of an obvious method to solve a problem that any developer will come up with as soon as they need to solve that problem.
It's also an extremely narrow patent; the only claims that are likely to be accepted only cover web applications, and the later claims only cover programs written in Javascript. If you can successfully convince people that your game is not a web application, or if it is not written in Javascript, this patent may not even apply to you.
My program is a web app, and it is written in JS. The code in the application looks remarkably similar to my own.
The major difference is they're looking for a new version of software that exists on the client while mine looks to see if a certain module/game is loaded in the client and then loads it in if it's not already present.
This is not novel. This is not innovative. It is a relatively obvious method for dynamic code loading over the web that any intermediate programmer could have arrived at independently.
No one could argue that the patent office never lets through a patent that claims obvious subject matter. Mistakes get made, and bullshit patents issue.
In general though, the examiners I have dealt with are more likely to advance bullshit rejections than issue bullshit patents.
There's some jabber in here about being filed as an international patent, or having a separate international filing, or something like that. Could someone with a patent background clarify this?
When was this patent filed? Was it filed Jan 24, 2012 and the international patent filed Feb 22, 2001? If so, why does the "Publication Classification" section show a date of (2006.01)?
If this patent was filed in 2006 (which is unlikely but I can't tell), then these might not count as prior art.
Oh, I'm sure you could, but most don't seem to bother because it would be too specific and might possibly make it easy to create a workaround to the patent. Why be specific to control a small part when you can be general and control the majority?
I don't think this is true in general. Most patents I have read have had very detailed descriptions of the invention. In fact, it is to the patentee's benefit to be as detailed as possible in describing the invention. It will be harder for people to claim you didn't invent something if you have completely described it in your patent.
In contrast, what is actually claimed (that is, the bounds of the legal right to exclude that a patent grants), is typically made as broad as possible. Claims will be included that are both broad and narrow, so that if the patent is ever used in court, and the broad claims are knocked out by some new prior art, there are still narrower claims that can be asserted.
In general, the patentee should describe every version of the invention they have conceived of, in as much detail as possible, so as to support both broad and narrow claims. If the description is not specific, it is generally for lack of time or money on the part of the patentee or inventor, and it results in a weaker patent.
I would agree with regular, every day patents describing mechanical inventions and the like. But show me software patents that show the actual code involved in producing the result. From what I've seen they usually have drawings showing the method and/or result. They do not show how it works.
It would be like a patent for a hand gun that has exterior drawings of the gun, a hand holding the gun/pulling the trigger, and then showing the bullet coming out of the barrel. No explanation of how the inner mechanism itself works. Therefore any other gun that works in a similar exterior manner but has a completely different inner mechanism would violate the patent.
That's my understanding of how most software patents are done.
I really feel like there is an educational opportunity for the HN community about patents. We frequently have these articles where the title of the patent is copy pasted into a submission to generate the largest amount of hysteria possible. Then the HN community completely ignores the fact that a) the titles are misleading and b) the titles are meaningless in terms of patent protection.
Based on the claims, they are patenting a system for updating client side web server applications. The system attaches source code information to JavaScript object in order to be able to determine the version of source code that generated the objects. The system attempts to provide a way for web applications to update client side code in a browser using the source code the objects were derived from as a way to continue operation without restart.
Now, I'm not saying that is novel. What I'm saying is that there are a lot of presumptions that happen before people even get to the claims. Typically, I encourage people to read the claims first, then work their way back through the rest of the application. Without knowing the claims, there is no way to know what they think is protectable.
This isn't a justification of the system. I think (software) patents and the patent system are incredibly broken. Thats not a reason to be unfamiliar with the systems. Know your enemy.
reply
THIS IS NOT A PATENT. This is what's known as a pre-grant publication. This application has been filed, but it has not yet been examined. Chances are quite low that it will issue as a patent in its current form.
Yes, the claims are broad... but this is just a published app, not a patent.
I'm really curious which claims will stand if it's accepted. Obviously not claim 1, but maybe some of the others could look novel enough from a patent examiner's point of view.
Doesn't Rails do this already? What other prior art could a prosecutor show?
Did you read the patent? This one only applies to web applications and many of its claims are Javascript specific (which is pretty narrow for a patent, but that's how it was written).
Erlang is great, but depending on which claims are accepted, it probably can't count as prior art here.
There's also some secret sauce in here about hot patching JS objects and annotating JS objects with information about which source files they came from.
39 comments
[ 3.4 ms ] story [ 81.1 ms ] threadThis is just another example of an obvious method to solve a problem that any developer will come up with as soon as they need to solve that problem.
We'll have to see.
(IANAL)
The major difference is they're looking for a new version of software that exists on the client while mine looks to see if a certain module/game is loaded in the client and then loads it in if it's not already present.
In general though, the examiners I have dealt with are more likely to advance bullshit rejections than issue bullshit patents.
Plus every app that has ever had to solve this problem. There is nothing non-obvious in this patent.
When was this patent filed? Was it filed Jan 24, 2012 and the international patent filed Feb 22, 2001? If so, why does the "Publication Classification" section show a date of (2006.01)?
If this patent was filed in 2006 (which is unlikely but I can't tell), then these might not count as prior art.
In contrast, what is actually claimed (that is, the bounds of the legal right to exclude that a patent grants), is typically made as broad as possible. Claims will be included that are both broad and narrow, so that if the patent is ever used in court, and the broad claims are knocked out by some new prior art, there are still narrower claims that can be asserted.
In general, the patentee should describe every version of the invention they have conceived of, in as much detail as possible, so as to support both broad and narrow claims. If the description is not specific, it is generally for lack of time or money on the part of the patentee or inventor, and it results in a weaker patent.
It would be like a patent for a hand gun that has exterior drawings of the gun, a hand holding the gun/pulling the trigger, and then showing the bullet coming out of the barrel. No explanation of how the inner mechanism itself works. Therefore any other gun that works in a similar exterior manner but has a completely different inner mechanism would violate the patent.
That's my understanding of how most software patents are done.
Based on the claims, they are patenting a system for updating client side web server applications. The system attaches source code information to JavaScript object in order to be able to determine the version of source code that generated the objects. The system attempts to provide a way for web applications to update client side code in a browser using the source code the objects were derived from as a way to continue operation without restart.
Now, I'm not saying that is novel. What I'm saying is that there are a lot of presumptions that happen before people even get to the claims. Typically, I encourage people to read the claims first, then work their way back through the rest of the application. Without knowing the claims, there is no way to know what they think is protectable.
This isn't a justification of the system. I think (software) patents and the patent system are incredibly broken. Thats not a reason to be unfamiliar with the systems. Know your enemy. reply
Yes, the claims are broad... but this is just a published app, not a patent.
Doesn't Rails do this already? What other prior art could a prosecutor show?
Erlang is great, but depending on which claims are accepted, it probably can't count as prior art here.
There's also some secret sauce in here about hot patching JS objects and annotating JS objects with information about which source files they came from.
(IANAL)