Archive for July, 2013

How to Review all Independent Claims in 15 Minutes or Less

July 14, 2013 Comments off

I am very often asked to review and comment on patents in 15 minutes or even less. In those cases I normally am not requested to provide too much detail due to lack of time, but of course clients still want relevant feedback about each patent. Clients will typically indicate what aspects they want detailed, but in any case there really is one overarching question — that is, “How likely is use of this patent?” To arrive at an answer (such as an estimated probability), an analyst must first ascertain what the key elements and limitations are, and should do so not only for claim 1 or the shortest independent claim, but for all independent claims. From that assessment, the analyst can then focus on one independent claim for providing comments, though sometimes it’s best to indicate differences in claim scope that could impact assessments.

When I tell other analysts that one really should review all independent claims, even in a 15-minute review, often the response is that I’m crazy. And perhaps I am, and in fact it wasn’t that long ago that I said that 15 minutes wasn’t long enough to analyze all independent claims in a patent. But it bothered me because of all the times that I saw that the most relevant claim was not actually claim 1 (supposedly the “representative” claim) or even the shortest claim. So what could be improved to allow for a fuller review in just 15 minutes, or even less? Disclaimer: this technique will not work for outliers like this exceptional patent application, which has 7,215 claims:!

The answer for me, which I wish to share with you, is the use of software tools — for now my favorite combination is Google Patents (in a particular format) and my free Patent Claims Tree Google Chrome extension. Google Patents has been around for years, but for a while I found that many patents were missing, and I preferred the presentation and layout of FreePatentsOnline.  But over time Google Patents improved, and eventually they modified their layout such that I can hardly envision a better format for efficient review of a patent. This format may continue to evolve over time, and perhaps it will even get better, but it certainly is already great — as of this writing, Google Patents has multiple layouts, but the one I particularly like is the format provided for webpages with the following syntax:<patent_number>. Take a look, for example, at: The title, abstract, and relevant metadata are all presented at the very top of the page in a compact and easily-readable view.


Just below that is a set of all images, which can be quickly expanded and perused, and sideways images can be easily rotated. All images can be visually scanned in less time that it takes to open the patent’s PDF file!

Image example

Then perhaps most elegantly, the patent background and the claims are provided in side-by-side columns. The claims are indeed the most important components of a patent because they define a patent’s scope of rights to exclusion, but claims are often worded in manner that can be difficult to comprehend at first glance. Therefore, a quick review of the background section sets the stage for inventive embodiments and helps to scope the claims for a reader. And now this is where the Patent Claims Tree tool for the Chrome browser comes in — with sufficient resolution/zoom, your Chrome browser can simultaneously present the background, claims, and a claims tree with relevant claims metrics, all side-by-side (basically a three-column display):

Three-column display

I find this presentation to be incredibly helpful and fast. The speed at which patent claims can be reviewed using this presentation is key since time is so limited.

With an appropriate input device such as a mouse with a scroll wheel, it is possible to scroll through the claims in Google Patents while the claims tree remains open. Additionally, note all the helpful information presented at a glance in the claims tree: the number of independent claims, which claims are the independent claims, the shortest independent claim, the relative word counts of the independent claims, the type of claim for each independent claim, the relative amount of dependent claims for each independent claim, and which claims use means-plus-function language. Sure, it’s possible to figure all of that out manually, but just that alone would probably take more than 15 minutes by itself.

Those metrics help in determining which independent claim should receive the bulk of your attention. In the example above (I like to use 7,654,321 because it’s a nice number :)), one can quickly determine that in this case there are six independent claims covering a variety of types of coverage, though the “downhole tool” of claim 21 is by far the shortest claim (by about 60 words), so review should probably start there. After reading that claim, if the claim seems to have sufficient coverage, then probably only cursory reviews of the other independent claims are necessary. There are other possible considerations that can be made at a glance as well — e.g., perhaps the client has indicated that it has a threshold for claim word count, so some claims can be discounted rapidly. Or, maybe only claims with a certain type of coverage are desired, and so the claim type can be used to focus on specific claims. In any case, using the three-column presentation, it is normally quite feasible with most patents to have time to read and understand all independent claims, and therefore pick out the best. If you want to find, for example, all method/process claims, this information is there in the tree. Should supplemental background information be needed, it’s right there. Should a figure or two be helpful for understanding scope, it’s simple and speedy to pop them up without a PDF. Should the priority date need consideration, it’s right there above the images.

This approach works quite well for me, and I bet that it will for you too. I am now quite confident in performing 15-minute patent reviews for most technology areas with which I am familiar. There are exceptions of course, but the techniques and software described above have greatly expedited my reviews, making 15 minutes much more comfortable than they used to feel.

If you have additional efficiency tips, please share them in the comments.

Claims tree

Wireless packet capture and analysis

July 3, 2013 Comments off

Update (Sep 14, 2017): As of Windows 10, you no longer need to use the relatively complex VirtualWiFi solution described in the original post below. Instead, the “Mobile hotspot” solution provides a much more straightforward technique to set up a connection through your computer for Wireshark packet capture of IP traffic traversing through the computer.

Update (Sep 21, 2017): Additionally, see this later post about capturing Wi-Fi data frames in a passive over-the-air manner.


Fairly often when performing patent analysis, particularly when creating claim charts mapping one or more patented claims against a target product or service, I find it helpful to capture and analyze packets sent from a wireless device. Internet Protocol (IP) packet capture when using a personal computer, such as a Windows or Mac computer, is relatively straightforward using a packet capture tool. I have been using Wireshark (formerly Ethereal) for years as my preferred packet capture tool, although there are certainly other available options from which to choose, both paid and free.

Packet capture for packets sent to and from other wireless devices such as smartphones and tablets is not so straightforward, therefore I provide below details of a solution that I leverage so that you can take advantage of this approach as well during your patent analysis. The high-level summary of this solution is to set up a Windows OS computer to use Wireshark to capture packets on a virtual Wi-Fi adapter — see this Microsoft explanation of the solution, termed VirtualWiFi, which I can confirm works for me with Windows 7. Credit goes to Eric Geier for documenting how to set up virtual W-Fi adapters here.


1. In a command prompt (“cmd”), enter the following to set up your hosted network connection: netsh wlan set hostednetwork mode=allow ssid=YourVirtualNetworkName key=YourNetworkPassword  — You can set up your SSID (YourVirtualNetworkName) and password (YourNetworkPassword) as you wish, though of course you’ll need to know these when you try to connect from your wireless device that you’re testing.

Packet capture - step 1

2. Before enabling the virtual hosted network, configure the physical network adapter to share its Internet access using the Internet Connection Sharing (ICS) feature of Windows. To enable ICS, open the Network Connections window, then right-click the network adapter that is actually connected to the Internet and select Properties. Then select the Sharing tab, check the “Allow other network users to connect through this computer’s Internet connection” checkbox, choose the hosted network connection (that you enabled in step #1) from the drop-down listbox, and click OK.

Packet capture - step 2a Packet capture - step 2b

3. In the command prompt, enter the following to start your hosted network connection: netsh wlan start hostednetwork

Packet capture - step 3

4. Open Wireshark and select Capture->Interfaces, and select the adapter for your physical network connection and click Start. You can confirm that you have the correct adapter through comparison of MAC addresses, though the easiest solution is probably just to watch the packet count of adapters when using the target wireless device — the adapter with corresponding increases in packet count is the one to use.

Packet capture - step 4

5. Connect to the new hosted Wi-Fi network with the target wireless device and execute the desired application, website, service, etc. on the target device being tested and step through whatever sequence for which you wish to analyze the corresponding packets.

6. Once done with testing and recording, select Capture->Interfaces->Stop in Wireshark to stop packet capture.

7. You will then have a set of packets to analyze, and you’ll need to determine the IP address of the wireless device being tested. There are many different considerations here as far as best approaches to walk through the packet data, such as filtering, stream following, searching, exporting, etc., so I suggest that you reference the documentation that Wireshark provides here.

8. Disable the hosted network through entering the following command in the command prompt: netsh wlan stop hostednetwork

If at any time during the steps above you wish to see the current status of the hosted network, such as the MAC addresses of connected devices, enter the following command in the command prompt: netsh wlan show hostednetwork

Packet capture - show network

Once you have performed steps 1-2 above, on system reset the hosted network will not automatically start up, so you would need to execute this command again: netsh wlan start hostednetwork. In fact, once steps 1-2 have been performed once, from then on you should not have to perform them again for subsequent testing — you can start at step 3.

I hope you enjoy your wireless packet capturing and analysis!

Synopsis Under IP/Patents Telecom Sourcing (SUITS) Conference

I will be speaking in conference sessions at the Synopsis Under IP/Patents Telecom Sourcing (SUITS) Conference held in Las Vegas August 27-29 — these sessions are breakouts from the ITEXPO, touted as “The World’s Communications Conference and Expo”: and

If you are attending the conference, and would like to meet, let me know.

Categories: Analysis Tags: ,