Auto correcting semantic code errors by executing code snippets and seeing which ones produce no errors

Question

To be fair, I think this is a ridiculously better software patent than any of the other ones I've seen, but I bet there is prior art for it.

The first claim:

1. A method for correcting semantic errors in code in an integrated development environment, said method comprising the steps of:

• inputting, using a code editor, code being developed in an integrated development environment;
• identifying, in a syntax tree constructed for said code inputted, one or more nodes containing semantic errors pertaining to use of a third-party library;
• displaying one or more suggestions for correcting said semantic errors identified for a node in said syntax tree containing said semantic errors, wherein said one or more suggestions include one or more executable code snippets associated with one or more collaboration records located for a chosen node from the syntax tree;
• selecting at least one executable code snippet from said one or more executable code snippets displayed for correcting said semantic errors identified for said chosen node, wherein said at least one executable code snippet comprises a primary executable code snippet and a secondary executable code snippet;
• executing, by a computer, the primary executable code snippet;
• and in response to the primary executable code snippet failing to correct said semantic errors identified for said node chosen, automatically executing the secondary executable code snippet.

My non-legalese summary:

Finding semantic code errors in a syntax tree, picking up two likely corrections based on a body of previous code, and compiling and executing the snippets to see if they correct the semantic error.

Answer 1

I've looked through the full application, and it clearly was written to be completely unintelligible, which is not what patents are supposed to be for. As a practitioner skilled in the art, I still have no clue what they're getting at with the last three bullet points, or what properties something would need to constitute prior art. Here's a fairly typical sentence from the so called "summary":

In an embodiment, the identifying step further includes the step of providing a collaboration datastore for storing the one or more collaboration records containing respective invocations for identifying the one or more nodes containing the semantic errors, where a collaboration record includes one or more properties and where a respective invocation of the respective invocations includes a type of invocation and one or more parameters.

That clearly was written by someone trying to obscure, not someone trying to communicate. For that reason alone, this application should be rejected.

Doing a lot of reading between the lines, I think the original idea is supposed to be something like this: you have multiple developers working on the same code and submitting fixes to bugs. When two different developers submit fixes for the same bug, it automatically tries both of them (perhaps running a unit test?) and accepts whichever actually fixes it. But that's just a guess. The application certainly doesn't say anything like that. It also keeps jumping between two seemingly separate ideas and confusing them with each other: interaction with the user, and automated error correction. For example, the third bullet point in claim 1 speaks of "displaying one or more suggestions" to the user, indicating this is an interactive feature and the user will be selecting one of them. But the remaining bullet points somehow jump to an automated system where the computer selects among various alternatives in an automated way with no user interaction required. So which is it actually doing? That's impossible to determine from the claim as written.

Answer 2

This may not be a complete answer, but your summary:

Finding semantic code errors in a syntax tree, picking up two likely corrections based on a body of previous code, and compiling and executing the snippets to see if they correct the semantic error.

sounds exactly like the "auto correct" behavior that MS Word exhibits. For example, typing "teh quick brown fox" will result in an automatic change of "teh" into "the". An error was found in the current line, the most likely correction was selected based on regular language rules (code), and the word was replaced to correct the error. While this does not correct programming code, or test by executing corrections; it does the same process as described above within the scope of a text document.

Answer 3

I'm not clear on what the last three bullet points are getting at - it might be clearer if I read the whole patent. But the rest sounds very similar to the automatic error checking found in many IDEs (such as Intellij IDEA). In particular:

• You enter code.
• It parses your code and generates a syntax tree for it.
• It identifies semantic errors related to third party libraries. In the case of IDEA, that largely means the standard Java class libraries. For example, it will detect if you call toUpperCase() on a String and forget to assign the result to something, or call read() on an InputStream and don't check the return value to see how much was actually read. It knows these are common mistakes.
• It often will offer suggestions for how to fix the error.

Answer 4

executing, by a computer, the primary executable code snippet; and in response to the primary executable code snippet failing to correct said semantic errors identified for said node chosen, automatically executing the secondary executable code snippet

This portion perfectly describes the ColdFusion error handling. ColdFusion is a web application server, that supports its own programming language CFML.

From the book Mastering ColdFusion 4 - Jun 1, 1999 (the oldest edition of documentation I could find online). Google: http://books.google.com/books?id=ItBQAAAAMAAJ Amazon: http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=0782124526

The book describes the error handling functionality of the tag CFCATCH. I will paraphrase here, relating prior art to the quoted segment above. Google in-book search for CFCATCH shows part of the content.

A block of programming code is encapsulated in a CFTRY tag set. Any errors that occur in the primary executable code within this segment is intercepted - thereby preventing a program crash. At the bottom of the CFTRY code block, the tag CFCATCH can be used in response to error conditions to catch programming errors. Secondary executable code is placed within the CFCATCH tag encapsulation. CFCATCH supports several parameters which allow you to use multiple iterations to catch different error conditions, with new code to be executed for each node that could have failed. Each CFCATCH block can execute alternate programming code in lieu of the original error causing code (node), thereby self correcting the behavior of the overall program.

Every high level programming language has this kind of exception handling, maybe worded differently but the concept is definitely prior art.

Answer 5

I realise it might be veering slightly off topic (patent law), but having done a fair bit of programming (both in IDEs in high-level languages and in assembly-language) I question how beneficial the try-to-execute methodolgy can really be:

• Almost any high-level-language code which parses and compiles is likely to be successfully executable (as long as the variables/pointers/functions it uses are valid at the time of execution). What kind of additional programming errors will this method actually detect?
• What if the programmer hasn't yet written the surrounding code which defines the 'environment' of the code which is being entered/edited?
• What if the code path is heavily depended on some 'live' data stream which is not available when the code is written/in the IDE? (I acknowledge that for reliability and security a program which takes input data really ought to be robust against any corrupt or malicious data)

Maybe it's my lack of imagination, but I'm struggling somewhat to visualise circumstances when this try-to-execute would be of great benefit.

Maybe I'm mistakenly interpreting the use-case as a check-as-you-type, when this was not implied?

And of course the danger of any kind of 'auto-correct' is that it silently 'corrects' things to something other than the author's intention!

Answer 6

Also sounds like what T9 Predictive Text is doing on old feature phones for text messages. I.e. based on the keys typed predicting the word which the user is trying to enter, and if multiple words matches allowing the user to select the word from a list which matches the intent.