Patent Searching: Solving Multiple Mazes at the Same Time

While there are various types of patent searches, all of them have something in common – you are looking for result(s) that read on some IP document (invention disclosure, application, patent or set of patents and their claims). While conceptually a simple exercise, anyone experienced in search understands the complexity of the process.
 
One can think of the task to finding “good prior art” as a maze – you read the source document carefully and then begin your search. In rare cases, you follow a single path, maybe you hit a few dead-ends, but you eventually navigate to the Holy Grail of prior art and you are done. If only it were so simple.
 
Fact is, patent search and analysis is multi-dimensional, or for the purposes of discussion here: multi-threaded. In other words, you begin your search and inevitably you realize you can’t follow a single path of inquiry – you HAVE to branch your analysis. If you think about it as a chart of relevant results, maybe graphed by concept or technical area, you will often see there are more than one disparate “humps” in the data. And this is where your search begins to branch.  Perhaps a better way to explain is simply to do away with the "search" nomenclature and replace the word with: investigation.  What investigator follows ONLY their first lead and solves the case?
 
 
There are several challenges with this – one is the simple fact that as humans, we can only do so many things at once and we have a hard time keeping other stuff clear in our head as we tackle one of many tasks. In other words, as soon as I know I need to branch, I am left with a conundrum of keeping track and the workflow associated with following my path and ensuring I return to all other paths (and it can branch further along the way...). Using software or browsers, this is often difficult and people resort to opening multiple instances, taking notes, or trying to organize and pull together disparate threads after the fact.
 
While there is no “silver bullet” to this challenge, one of the techniques we have adopted allows for more naturally “keeping track” in one place – giving the searcher both a visual record of all their searches, but also a single jumping off point from which to launch those pathways of investigation.
 
I’ll return to a simple example I used for another article on search iteration:
 
 
 
This simple search matrix shows the output of a relatively natural evolution of a search strategy:
 
  • Begin your search relatively broadly
  • Look for categories/classifications that are most relevant to your topic
  • Refine with category/classification or keywords
  • Review your results again and repeat process
 
Along the way, you branch your lines of inquiry, ultimately leading to relevant prior art (or not). Chances are, if you are doing a patent search, it isn’t your first and it isn’t your last – and often searchers specialize, so they become more and more “in tune” with technologies that they are assigned. This is where some of these matrices, specifically the categorization or class breakdown of various technologies can be hugely valuable as reusable tools.
 
But for the moment, the main point is that as you build the matrix, iterate your search, view search results, it is ALL at your fingertips in one place. And as you start to drill down into reading the patents, you can start that directly from the matrix. You discover a new line of inquiry in your search? No problem, add a row (or column, depending on how you structure) and keep going.
 
While in many ways the matrix feature was built to support landscaping techniques, it has great applicability as a sort of “Visual Search Report.” We continue to extend this capability and are working towards greater workflow integration with the patent reading and documentation process, but we think this overall conceptual technique could replace the repeated serial searching model in the future.
 
Erik Reeves
 
 
 
For reference, here were search iterations from the above example:
 
Queries:
 
Q1: Bicycle pedal:                 bicycle pedal
 
Too narrow? Too broad? Perhaps both? Let’s start with a strategy to broaden this first, leading to Q2:
 
Q2: Pedal:                              pedal
 
Definitely too broad for my particular inquiry, but this gives me a good sense of scale and how narrowing affects this, leading to more details integrated into the search strategy in Q3:
 
Q3: Pedal Contraint1:           pedal AND (hydrophobic OR tread)
 
Now we are getting somewhere, but this is still perhaps a bit too broad if we want to review these (however, we might take a peak at the list and just see how the first few look in likely classification areas). We narrow it further, leading to Q4:
 
Q4: Pedal Contraint2:           pedal AND (hydrophobic OR tread) AND (slip OR friction OR water OR wet) AND (foot OR shoe)
 
Once again, narrows nicely and in reviewing a few results, this is starting to look pretty on target (we can always check the other previous iterations to make sure we aren’t missing anything). We narrow further so we can ensure proper time to review the most relevant documents, leading to Q5:
 
Q5: Pedal Contraint3:           pedal AND (hydrophobic OR tread) AND (slip OR friction OR water OR wet) AND (foot OR shoe) AND (carbon)