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.
For the past few years I have enjoyed attending the European Patent Office’s (EPO) annual Patent Information Conference, which is held in a different European city each year. In 2015 it was based in Copenhagen, and in 2016 it was held in Madrid. This year (2017) it is held in Sofia, Bulgaria. There are several training sessions along with discussion rounds covering a variety of topics, such as patent-related searches, freedom to operate assessments, patent analytics, patent asset monitoring, and of course patent information and evaluation tools. As described in an earlier post about European patents, as a US-based patent analyst I find it beneficial to continue to stay informed about the latest developments in European patent law and data. This annual conference provides me with the opportunity to learn, and I also have met many great patent professionals at these conference events. Additionally, there are dozens of excellent exhibitors showing off their latest patent information and analysis software and services.
Europe is my home away from home, and I love spending time there and exploring new cities, as well as learning from peers. This conference is also relatively inexpensive compared to most patent conferences in the US.
Please let me know if you plan to attend this year’s (or any future year’s) EPO Patent Information Conference, and I can plan to meet you for a chat.
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.
More and more web applications typically encrypt communications with a user browser using Transport Layer Security (TLS), making determination of how the web application works more difficult. However, as part of patent analysis it can be quite helpful to peek into client-server communications to better ascertain how functionality works.
Packet capture tools such as Wireshark capture all Ethernet communications at a network adapter, and so cannot see inside encrypted packets like TLS packets used for securely transferring data via Hypertext Transfer Protocol Secure (HTTPS). TLS encrypts packets using symmetric cryptography between communication counterparts, so that unless you’re the NSA it should be challenging to be a “man-in-the-middle” and read the communications in the clear. For this reason, what is needed is insight at a counterpart endpoint, and in the client case for a web application this is the web browser. The web browser itself obviously must be able to encrypt and decrypt communications with a web application server, so it is here that one can capture and analyze HTTPS packets in plaintext format.
There are a variety of browser-specific add-ons that are available to capture and present sent and received HTTPS communications in plaintext format. One example that I have found helpful is HttpFox, an extension for Mozilla-based browsers such as the Firefox browser. HttpWatch is another solution that works for Firefox and on iOS devices (iPhone, iPad) as its own browser.
It should be noted that while browser extensions such as HttpFox are helpful for capturing and analyzing secure encrypted communications with browsers, these are not helpful for decrypting communications to/from other client applications because these other applications are TLS counterpart endpoints that are using cryptography without providing insight into the communications.