Inefficient search queries will receive the following message:
"This search query exceeds the system complexity limit. Please see the Efficient searching page for more details.”
Inefficient or complex search queries can impact a user.
Search queries that contain the following can increase the wait time to load search results or full text of a document:
- A large number of truncations
- Unmodified wildcards (* or $)
- Wildcards with high numeric modifiers (for example, keyword$10)
- Wildcards used in the left or middle position of a word
- Heavily nested terms or phrases in an L#
Efficient searching using truncation and wildcards
Truncation is a technique used to search keyword variations. Wildcards can be used at the beginning, middle, or end of a search term. Use truncation effectively to retrieve results and load text documents quickly, and to reduce unwanted and redundant wildcards, which can lead to irrelevant search results.
1. Use a limited truncation wildcard with a small numeric modifier: $n
Inefficient
| Wildcard | Results |
|---|---|
| L1: prod$ | 13,460,230 |
| L2: prod$9 | 13,456,533 |
| L3: G06$.cpc. | 2,940,957 |
Efficient
| Wildcard | Results |
|---|---|
| L4: prod$3 | 9,837,851 |
| L5: G06F3/0$4.cpc. | 485,022 |
*Note: The L number represents previously executed (Prior Art) search queries.
2. Use a smaller number of wildcards
Inefficient
L1: (heads-up$ OR head up$ OR HUD) SAME (display$ OR screen$)
Efficient
L2: ((head ADJ up) OR HUD) SAME (display OR screen)
3. Wildcard positioning
Use of truncation in the left or middle creates a more complex query.
Inefficient
L1: $up$display
Efficient
L2: head$1 ADJ up NEAR2 display
4. Short base words
Using truncation with a short base word increases the number of unintended terms and creates a more complex query. Patent Public Search will only support truncation up to 20,000 hits. If the search generates more than 20,000 hit terms, an error message will appear. The Query will have to be modified to work correctly.
If using the $ wildcard, try the search again with a wildcard limited number (e.g., $5) or use a smaller wildcard number (e.g., $2)
Inefficient
L1: comp$
Efficient
L2: comput$3
Intended search terms: “compute” and “computing”
Not intended: “complaint”, “complex ”, “compost”, “composition”, and “compel”
Notes
If you see the error message related to truncation, re-running the query will not work. It will need to be modified before re-executing.
Avoid using unlimited wildcard truncation in CPC searching (e.g. E04$.cpc.) If searching CPC symbols with a wildcard is desired, it is more effective to use limited truncation operators ($n or ?).
Use focused searchable indexes for CPC to reduce the complexity of a query. See the below table of CPC searchable indexes.
CPC searchable indexes
| Field code | Description | Example | Comment |
|---|---|---|---|
| CPCL | Current CPC Subclass | A23B.CPCL. A23?.CPCL. | Use CPCL to search subclass or ? for finding one or more CPC subclasses. |
| CPCI | Current CPC Inventive | A23G9/34.CPCI. A23G9/$2.CPCI. | Use limited truncation at the subgroup level. |
| CPCA | Current CPC Additional | A23B4/16.CPCA. A23B7/1$2.CPCA. | Use limited truncation at the subgroup level. |
| CPC | Current CPC | F28F9/0248.CPC. F28F9/02$2.CPC. | Searches both CPCI and CPCA. Use limited truncation at the subgroup level. |
Search efficiently using terms/phrases and L#s
A search query may consist of any combination of alphanumeric terms/phrases and L#s. These terms/phrases and L#s can be used in a circular logic. Effectively using terms/phrases and L#s can have a performance advantage.
It’s important to note PPUBS does not save a list of documents previously retrieved from a query. Each time a query is referenced PPUBS will expand the query and then execute the query again. See the below examples.
1. Use a limited number of repetitive terms/phrases in a search query
Repeating terms/phrases creates a more complex query.
Inefficient
L1: user ADJ interface
L2: L1 SAME divide
L3: L2 WITH frame
L4: L1 and L2 and L3
PPUBS will execute L4 as:
L4: (user ADJ interface) and ((user ADJ interface) SAME divide) and (((user ADJ interface) SAME divide) WITH frame)
Efficient
L5: (((user ADJ interface) SAME divide) WITH frame)
2. Use a limited number of repetitive L#s in a search query.
Repeating a large number of previous L#s creates a more complex query.
Inefficient
L7: L4 OR L5
L8: L5 OR L7
L9: L8 OR L7
× L10: L4 OR L5 OR L7 OR L8 OR L9
Once fully expanded, the L4 search runs five times and L5 runs seven times
Efficient
L10: L5 OR (H04N19$4 AND (divide WITH frame))
Truncation Limits
Match Limit: If an individual term in a query matches on more than 20,000 hits, PPUBS will not try to run the query.
Inefficient
A$ AND database
Efficient
Algorithm$2 AND database
The term A$ matches more than 20,000 hit terms and the query will not execute.
Combinatorial Limit: When the product of the numeric modifiers exceeds 125, PPUBS will not execute the query.
Inefficient
A$32B$4
Efficient
A32B$4
The numeric modifiers 32 and 4 multiplied together equal 128. This is greater than 125 and the query will not execute.
In order to improve response times and reduce the number of unwanted results, please carefully consider the level of truncation that is needed for each individual term of your search query.