Applying First principle thinking for invalidating a software patent
If you have ever received a software patent for invalidation that has claims like a “computer command” that comprise –
1) DOM index value,
2) DOM property name, and
3) DOM property value in the web page being rendered for “synchronization testing and analysis”.
…you know it is not going to be an easy game. It is going to be a challenge.
You can’t kill software patents easily. Software applications are often examined in light of previously filed patent documents, and product literature. Prior art may also exist in previously built software applications, but it is difficult and time-consuming to test all such applications and get into their codebase. Well you can’t find softwares using your keywords.
Therefore, when dealing with software patents, patent examiners do not have time to examine the claims against the full scope of the prior art. The search gets limited to the patents and product literature available digitally. Well, it’s not their fault. Reviewing all software applications in 3-4 days time that they get for searching, is practically impossible. So they do what they can do best in the limited time available.
However, when the patent case is in court, invalidating the patent is super important. In such cases, we always keep this strategy of testing the software applications and exploring the codebase in our arsenal. People say it’s impractical and a waste of time, since many old software applications do not work in the latest operating systems (Windows, Linux, Mac), but we have been able to get results by using this strategy.
This is a post where we want to share one such case where our job was to invalidate a patent that was related to “software code” for testing websites.
“We have changed all the names, technologies, mappings, and patent numbers without losing the context of what happened in the project so that we can tell the story without missing any important parts.”
The Journey of Invalidating a Software patent
Recently, we received an invalidation search request from Matthew, a senior litigator who represents one of the top US software development companies as a defendant. His client got sued on a patent assigned to one of their competitors.
The matter of concern was that the subject patent claimed a real “software program” i.e., code or set of instructions for testing websites.
You cannot find prior art for such patents by performing a mere keyword-based search because keywords are very particular regarding codes. Thus making it a tough one!
Today we’d like to tell you how we cracked this case.
Introduction to the case
In simpler words: The patent was about a “command” that would check and match the following
1) DOM index value,
2) DOM property name, and
3) DOM property value in the web page being rendered for “synchronization testing and analysis”.
We won’t lie – when we received the case, we immediately knew this was going to be a tough nut to crack.
Challenge we faced
While working on this software-based patent, we observed that the claim was describing a series of steps (aka “code”) for synchronization testing. It was difficult to identify the prior-art that could disclose the same series of steps using traditional search strategies. The keywords-based search logic was failing.
We started with patent search, filtering through the results, trying to find any patent that is describing this process or include a code that achieve the same functionality of testing. But, none of the results were even closely related to the search, and we found ourselves in a rut.
So, we decided to scale up and start tracking similar kinds of work in the non-patent literature (NPL) assuming there was a vast literature available that talks has code for testing. For that matter, we jotted down a few possible directions (approaches) where we could get the lead. These were –
- System Prior-art
- Articles/ Blogs/ Research Papers
- Manuals of system prior-art
- Online testing websites: With similar function (during the period of our invention i.e. 2007)
- Internet Archive (Wayback machine): To back-track recent online websites/tools
We conveyed the same to Matthew and gave him our reasons for following this direction. Once Matthew was onboard with the plan, we began our search.
Using First principle thinking
We divided the claim into small “fundamental elements”. The fundamental elements like testing of a website, DOM elements, property values, attributes, source code, API, etc.
We then brainstormed the concept with our in-house software development team to gain their expertise in this domain of software testing. Our aim was to figure out which kind of software may use similar fundamental elements (sub-codes).
This started our investigative research to find the prior-art
Executing a couple of strategies based on sub-codes (such as Functional testing, synchronization) got our hands on a document – FunFX A Framework for Functional Testing of Flex Applications (Motzfeldt, NTNU) [1].
It appeared to be a pretty close prior-art in the first look itself. So we started with a deeper analysis.
During our analysis of FunFX, we encountered that it consisted of long pieces of code. We did a quick review to understand what the code was doing and concluded that this can become a relevant piece of art.
We were positive that the route we were on could be fruitful. We shared this with Matthew in the interim call and got a thumbs up from his side. Now, what happened next was the coolest part of this project.
The next step involved deciphering the FunFX code.
This was the most crucial step and a turning point for us. In this step, we again called for our experts (the in-house PDT Team) to discuss and dissect this code the same way we did for the original code. Following this dissecting process, we could interpret the claimed elements in this code (Listing 11.23). This is how we dissected each element of the code corresponding to the claimed features.
This was exactly similar to the interpretation of the claimed code and its functionality. We had found our first prior art.
We now decided to look for a system prior-art that may be using a similar code. System prior art would make Matthew’s position stronger.
We remembered our software team suggesting a few tools for software testing which they used in their day-to-day work like Selenium, etc. which could become a good source of prior art.
By simply entering a couple of key terms (such as SQA testing tools) we got a list of online testing tools.
Guess the first tool to appear in our search?
So without further thought, we decided to dig into it, to find more evidence, keeping the cut-off date (2007) in mind.
Finding an online testing website and a paper on the same before our cut-off date
We started looking for any document, research paper, or manual that could be used as evidence to break down the functionality of selenium software. We wanted to get inside this software.
We came across the manual Automating Functional Tests Using Selenium which disclosed the testing process of Selenium.
Here, we found one piece of “code” ( picture below). We used our previous knowledge to dissect and understand the code elements. And guess what! It disclosed the similar functionality of a “code” for software testing of websites.
And just like that, we landed on our second prior art.
After reaching this point, our observation was that there should be more such things out there. For researchers mapping out technology evolution, can help visualize who was doing what at a certain period. Therefore, after identifying good art from Selenium, we had to find other sources that could act as prior art.
One reason we kept looking was that we had so far found codes that matched only our interpretation of the ‘subject code’ – we had to make a strong argument for Matthew!
And with that thought, we decided to explore further.
WayBack Machine helped us back-track the online testing website
We spent time going through the old tools (using fundamental key terms) that were providing website testing as a service. One of the tools that came up in our search was soft.com.
On analyzing the website it appeared to be relevant and had proof of existence, i.e., 1992-2021 [mentioned at the bottom of web page]. The problem here was that we were unable to back-track to the older version (before 2007) of this website.
But that was a no-brainer; we immediately checked the previous versions of this website over the Wayback Machine and found the proof in the year 2007. Bang on!
An older version of soft.com as eValid was available on May 10, 2007 (before our cut-off date June 2007). The 2007 version had a list of articles under the section Web Quality News (WQN) Blog.
In the published articles was our breakthrough- an article published on 30 May 2007 (New AJAX Synchronization Support Commands)
While reading the description of this article we came across a Playback Synchronization on DOM Elements command description published on 07 March 2007.
Finally, we made our journey to the exact “command” we were looking for!
The above “command” was the exact piece of “code” that was claimed in the subject patent and was pre-published evidence of the same.
It had everything that was required to invalidate the subject invention.
We finally landed on our third bang-on result using Wayback Machine. We shared the search results with Matthew and got this response (over a call) –
“Thank you GreyB for your hard work. The results are promising! Please share the charts for the same”.
And that’s how we cracked and invalidated the software patent.
Conclusion:
As researchers, we need to know that there are a few technologies where keyword-based search fails and a set of rules for finding prior-art won’t be useful. Software patents come under that category.
However, if you can make a mental model and break down what you are trying to locate, it can help you reach the hidden prior art, even if it’s not accessible to Google.
We share many such experiences, strategies, and wins. If you are a curious reader, you can find ’em all here – Prior art Searches that guarantee results.
While dealing with the case above, we witnessed the need to plan out-of-the-box strategies to tackle software-related patents. And that’s exactly what we did to find a bang-on result.
Want us to crack a Software Patent for you? We are just a message away:
Authored By: Akshay Vashishtha and Ankush Samyal, Prior Art Team.
