It can be somewhat tricky to accurately estimate when an issued US patent should expire. Nowadays, there are plenty of software solutions that automatically perform this calculation so you don’t have to. For example, AcclaimIP provides the calculated patent expiration date. But if you do not have access to such a solution, fear not — you need not calculate the expiration manually. The USPTO provides a Microsoft Excel spreadsheet called “Patent Term Calculator” with associated instructions — you just need to find the indicated information and input it into the spreadsheet to have the expiration date calculated.
According to the USPTO:
The United States Patent and Trademark Office does not calculate expiration dates for patents. In response to patent owner and public inquiry, the USPTO is providing a downloadable patent term calculator as a resource to help the public estimate the expiration date of a patent. The calculator can be used to estimate the expiration dates of utility, plant, or design patents. The calculator contains prompts to enter specific information related to the patent in order to help in estimating expiration dates. [Link]
Today I published a new Chrome browser extension called “Google Patents Widescreen” that makes Google Patents (patents.google.com/patent/) much more readable. The left-side search column is hidden, the text area is widened, and images are provided at greater resolution for readability.
A resolution width of 1920 works very well, though all narrower widths also provide improved readability.
Once it’s installed in Chrome, you don’t need to do anything — all Google Patents patent pages (with this syntax: patents.google.com/patent/) will automatically be modified for alternate presentation.
Here’s the different in presentation from the normal view versus the extension’s enhanced view:
Patent analysis often involves investigating how a particular solution functions in order to determine the potential for use of a given patented claim, and sometimes this investigation entails analyzing wirelessly-communicated data.
In an earlier post I described how to capture IP packets sent to/from wireless devices by using a Windows OS computer as a wireless hotspot together with Wireshark, a packet capture and analysis software tool. While that technique works well for capturing and analyzing IP packets communicated between a wireless device on the wireless LAN (WLAN) and a remote server, that technique does not capture lower-level point-to-point MAC frames communicated between devices on the WLAN, such as between the hotspot computer and a wireless device or between two wireless devices connected to the WLAN.
Within a WLAN, devices do not need to leverage transport or network packets (e.g., TCP/IP) to communicate with one another since they are on a shared medium and so can use the data link instead. To capture the frames sent on the shared wireless medium, there is another process I can recommend. This process provides for capturing communicated frames, such as between a computer application and a smartphone on the WLAN. The guidance below presumes that you have permission to capture wireless frames transmitted over the wireless network.
Fire up an unencrypted IEEE 802.11g wireless access point on a channel that is free or the least crowded. The “g” aspect is important, because newer protocols such as “n” and “ac” complicate capture due to variables like channel width and spatial streams. Having the access point be passcode-free and unencrypted is important as well because it allows for reading frames in the clear (presuming no other encryption is used for the transported data), though it is possible to use Wireshark to decrypt encrypted channels if you know the credentials — this is not covered herein.
Boot Kali Linux on a computer. Kali is a Linux distribution with tools built in for performing penetration testing.
Connect a wireless adapter that support IEEE 802.11g along with “monitor mode.” An example is Panda’s PAU05 300Mbps Wireless 802.11n USB Adapter — I have found that this particular adapter works well. Some other monitor mode wireless adapters that may function well are listed here and here.
Once you have captured the sequence of data you wish, discontinue the capture and open the resulting “PCAP” file in Wireshark, which is conveniently preloaded in the Kali Linux distribution. In Wireshark you can analyze the data there.
Obviously much more could be written about each of the tools and protocols above, and indeed, books have been written about each. However, here you have a short list of high-level steps to perform for passive Wi-Fi data sniffing, along with a complete set of the hardware and software you will need.
For potential future discussion is packet capture in a wired network, such as via Ethernet.
In my patent analysis practice, I continue to see an increase in requests to review European (EP) patents. This is likely due to a variety of reasons, including case law decisions in the United States in recent years, along with the promise of a European Unified Patent Court (UPC). In any case, I find it advantageous as a US-based patent analyst to be familiar with European patent practice because there are many differences from US practice, and of course there are different resources available for European patent review.
For example, while Google Patents provides support for EP patents, there is additional information available from European Patent Office (EPO) websites such as Espacenet (technical information) and European Patent Register (legal information, like the USPTO’s Public PAIR). And once a European patent is granted, it is currently enforced in each separate designated contracting state (nation) after validation procedures (such as providing language translations); renewal fees are also thereafter paid to each contracting state. This makes determining current status more difficult — one must determine in which nations the granted patent is enforceable (a topic for a future blog post).
UPDATE (Sep 25, 2017): The “Google Patents Images” Chrome browser extension only works if there are images available to load. It appears that all the latest patents no longer have images available. Therefore, I now find myself using the new Google Patents instead to be able to see the images. Because of this I have created another Chrome browser extension, “Google Patents Widescreen,” to offer better readability of the new Google Patents presentation.
In a previous post about expedited single-patent analysis I discuss how much I enjoy the layout format of the version of Google Patents available at the URL syntax of https://www.google.com/patents/patent_identifier. I continue to use this site for reviewing patents in my daily work.
There is also a newer version of Google Patents available at the URL syntax of https://patents.google.com/patent/patent_identifier. This newer version of Google Patents has a variety of improvements over the previous version, such as detailed search capability, patent expiration information, and claim text search term highlighting. The image viewer is also different, though not necessarily better, depending upon the circumstances (as detailed below).
That said, for several reasons I find myself continuing to prefer the previous version of Google Patents, which as of this writing is still available. These reasons include issues with the newer version, which were communicated to the Google Patents development team in 2016, albeit to no reply as of this writing:
Unnecessary Search Column: It would be helpful to be able to collapse the left-most column containing the search fields. Often, when one is reviewing a particular patent, there’s no desire to perform more searches. I admit that I sometimes work from a Chromebook with an 11-inch display, so having that left column go away would provide more precious real estate for the specification content, or possibly allow for images to be shown on the right side.
Small Images Viewer: For the drawings/images/figures, they are presented in a very small area when using a smaller display device, especially when centered with the rest of the content. I often cannot sufficiently see them and therefore must open them in a new window. While it’s often helpful to be able to see the images while still viewing the rest of the content, it would be beneficial to be able to open the set of drawings in a superimposed pop-up like is done for the legacy Google Patents — in this way a new window/tab is not needed, and one can scroll through all the figures quickly, all while being able to sufficiently see them.
Less-Accessible Metadata: It would be better to include the “Also Published As” information in the top metadata box instead of linking to a full list at the bottom of the page. The preexisting Google Patents solution has a collapsed list of related patents, and this would be the preferable solution for ease and speed of use. Or even a hover or pop-up box with the information would be helpful. Searchers and analysts very often need to see what family members there are, particularly US family members, and so having to go all the way to the bottom of the page to see this very important metadata is counter-intuitive and slow.
Much Slower Page Load Time: Beyond viewing the information, the speed of loading of a single newer Google Patents page is now painfully slow, especially as compared to the loading of the earlier version. And the newer pages will not completely load until after a browser tab/window is put into focus, as opposed to the legacy version which loads without being in focus. The newer pages have a title of “Result” on the browser tab until viewed.
The first issued US patent with broken figure images is 8,856,962 — all patents before that patent work OK. The first broken US pre-grant publication is 2014/0304877, while the first broken US design patent is D715016.
The patent claims tree Chrome browser extension I created in 2012 provides a patent claims tree for a given patent document, and it has become fairly popular, with several hundred users as of this writing. The tool is available at the Chrome Web Store, and is described in more detail here and here.
I have created additional Chrome browser extensions that I have found helpful and that you can use during patent analysis. One provides USPTO patent assignments for any selected text, such as a selected company name. This solution allows you to quickly look up any US patent assignments for a given company name in the USPTO patent assignment database.
UPDATED (May 22, 2017): The other links from a selected patent or patent application identifier on any webpage to the corresponding Google Patents page.
The patent claims tree Chrome browser extension I created in 2012 provides a patent claims tree for a given patent document, and it has become fairly popular, with several hundred users as of this writing. The tool is available at the Chrome Web Store, and is described in more detail here.
I have recently made a couple of improvements to the tool for EP and WO (PCT/WIPO) patent document handling. For one, claim tree creation is now supported for both EP and WO patent documents on Google Patents. Additionally, rudimentary support for German and French for EP patent documents in Google Patents has been added. While the claim type is not handled for German and French, claim tree creation is now provided. Additionally, it should be noted that Google Patents provides kind code B (i.e., issued patent) claims text for EP patents (while Espacenet does not as of this writing — the kind code B issued claims are only available in a PDF file). See this other PatentAnalyst blog post regarding consideration of kind codes for EP patent documents.
The screenshot below shows a claims tree for an issued EP patent viewed in Google Patents. Noteworthy is that not all formats of multiple dependent claims are fully handled in the Patent Claims Tree tool. These types of claims are more common in EP patent documents than in US patent documents.
I spend a fair amount of my time reviewing wireless air interface and data communications inventions, and so I often need to reference appropriate related standards and specification documents. Below is a very partial list of wireless and general data communications standards and specifications along with their associated website links. I hope you find these references helpful and that these hasten your standards document searches.
In my patent analysis work, I am sometimes asked to review patent documents from jurisdictions other than the US, such as from Europe (EP) and the United Kingdom (GB).
A common error I have encountered when analysts in the US look at patent documents from other jurisdictions is that they review the wrong version of a patent document, thereby wasting their own and their client’s time. Counter to the USPTO’s practice of separate pre-grant patent application publication and granted patent numbering schemes (11-digit and 7-digit, respectively), many other jurisdictions use the same number for both published patent applications and granted patents. The way that these other jurisdictions’ patent offices (such as the EPO and UK IPO) represent the difference in the patent document identifier is through the use of a “kind-of-document code”, which is a one- or two-character suffix that follows the patent document number — e.g., GB2172127A vs GB2172127B.
For another example, EP patent applications are represented with a trailing “A” kind code, while granted EP patents are represented with a trailing “B” kind code. For EP patent documents, an “A1” indicates a European patent application published with a European search report, and a “B1” indicates a “European patent specification (granted patent)”. There are several other kind codes for each of the “A” and “B” kind code sets — for more details, see the EPO’s kind code help page. The USPTO has its own comparable US kind code list, and the World Intellectual Property Organization (WIPO) additionally has a comprehensive guide to patent kind codes.
The specific error that I have witnessed from a few other patent analysts is that they spend time reviewing the claim set of a published EP or GB patent application (i.e., kind code “A”) instead of reviewing the claim set of the associated granted EP or GB patent (i.e., kind code “B”). Obviously analysis on an originally-filed or still-pending set of claims is likely to not be helpful for a client because the client wants to know how relevant the issued claims are, and the issued claims are very likely to represent some, if not many, modifications from the original claim set. The claims normally differ between these two, potentially substantially, so when analysts map or otherwise analyze “A” claims the work is probably incomplete and/or inaccurate. Part of the problem is that search tools such as Espacenet default to showing the “A” claims, even when the “B” version has been selected. To get to the “B” version of the claims, one must explicitly select such. The kind code B claims are only available in a PDF image at Espacenet and the UK IPO.
UPDATE: However, thanks to Google, this doesn’t mean that I have to OCR them and/or type them in when filling out reviews. Google Patents has support for EP and WO patent documents, including the claims. Google Patents provides kind code B claims in a textual format for simple copy-and-paste, and the Patent Claims Tree tool for the Chrome browser will parse these textual claims and provide a claims tree.
See the example screen shot below showing selection of the “B” kind code of a particular granted GB patent GB2172127, with the “A” kind code claims displayed instead — note that the indication of this is rather subtle (source: http://worldwide.espacenet.com/publicationDetails/claims?CC=GB&NR=2172127B&KC=B&FT=D&ND=4&date=19881012&DB=EPODOC&locale=en_EP, retrieved Feb 15, 2013):
Therefore, when performing patent analysis on non-US patents, it’s best to understand and leverage the kind code to ensure that you are reviewing the appropriate set of claims.