Standards Sources

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.

LTE (and LTE-Advanced) air interface (E-UTRA): published by 3GPP:

UMTS/HSPA air interface (UTRA): published by 3GPP:

Wi-Fi (802.11): published by IEEE:

Bluetooth: published by Bluetooth Special Interest Group:

Near Field Communication (NFC): published by NFC Forum:

WiMAX (802.16): published by IEEE:

CDMA2000 (incl. EV-DO, etc.): published by 3GPP2:

Internet communications (e.g., HTTP, SIP, DNS, etc.): published by Internet Engineering Task Force (IETF):

Web application technologies (e.g., HTML, CSS, XML, SOAP, DOM, etc.): published by World Wide Web Consortium (W3C):

SIM/USIM: published by 3GPP:

Mobile device APIs (e.g., device management, M2M, etc.): published by Open Mobile Alliance (OMA):

Published Article: “Three Areas of Intellectual Property You Need to Understand”

Prior to my attendance and panel participation at the SUITS conference in August 2013, TMC published an interview they did with me titled “Three Areas of Intellectual Property You Need to Understand” — this article is available here: Much of what is published there has been covered in earlier posts on this blog, such as in “Clearance Search Review” and “Invention Disclosure Highlights and Considerations”.

However, there is also additional new perspective pertaining to the biggest misconception in terms of how companies can understand, enforce, and protect their patents and intellectual property. This largest misconception in terms of how companies can understand, enforce, and protect their intellectual property is one held by a large portion of companies’ R&D engineering communities – that is, that an inventor’s novel and non-obvious invention is obvious and one that would have been formulated by any other engineer in a similar situation. This misconception leads to many inventions never being considered for patent protection. The issue can at least partially be overcome by continual inventor training to educate engineers to recognize the features of designed products and services that indicate the desirability of protecting aspects of these designed products and services with patents. This training should include information about patents, their history and intent, patentability rules, and examples of patented solutions within the given company’s technology areas. In particular, patent examples often inspire an “aha moment” within engineers that lead them to become prolific inventors and patent protectors.

Capturing and analyzing encrypted HTTPS communications

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.

HttpFox Firefox browser add-on
HttpFox Firefox browser add-on

Below is a screen shot of HttpFox in action — it has captured several HTTPS communications with a website, including a highlighted GET method to obtain some JavaScript:

HttpFox HTTPS Capture
HttpFox HTTPS Capture

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.


How to Review all Independent Claims in 15 Minutes or Less

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

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.

Citing reference sources

When claim charting, it is important to provide details on where reference information can be found for quoted text, screenshots, and the like. While there are many different accepted formats for citing reference sources (e.g., Oxford, Harvard, MLA, IEEE, etc.), I do not specifically prefer one over another, and I don’t actually use any of these in my claim charts. What is key, at the most basic level, is to be sure to include sufficient details such that a reader can easily find the source information in the cited reference. And product information needs to be specific enough to help a client determine the amount of product exposure a patent read provides — that is, some versions of a product may use a patented claim while another version may not.

I find it rare to actually cite a book, magazine, or other printed reference nowadays — instead, in claim charts I usually include screenshots captured from one of a few types of references: websites, soft copies of user manuals (e.g., in PDF), and/or products. Because websites and user manual soft copies can  be referenced by a unique web address (aka Uniform Resource Locator, URL), I typically include only these URLs without also indicating an author or title. This is because normally the source information is gathered from a target vendor’s own website, which I find to be preferable to information from third party websites — you want to hear it straight from the target source, if you can. Normally claim charts are reviewed and used by a client in a fairly timely manner, so it is not typical that the URL would change or “break” in the interim, but in any case I recommend including a date of retrieval to indicate when the URL still included the information provided in the associated screenshot. A reader who tries to use the URL but does not see the information provided in the associated screenshot will quickly realize that something changed. In that case, it is often still possible to find the original information by using the Internet Archive’s “Wayback Machine”.

Regarding screenshots or photos of products, again it is imperative to include enough source information that fully delineates the product manufacturer, model, hardware version (if any), firmware version (if any), and software version (if any). Additional information may also be needed to adequately characterize the product — for example, an underlying operating system (including version) on which product software runs or a web browser in which a web application is run. Again, it is worthwhile to include a date of capture in case something later changes (e.g., web applications are often modified without a clear user-apparent version distinction). Consider this example: “Screenshot of the Doofenshmirtz Awesominator Web App running in Google Chrome browser on Windows 7 Professional SP1 operating system (captured June 24, 2013).”

Happy citing!

Patent Mining Search

An earlier post provides an overview of the various types of patent-related searches [Link], and another post summarizes some typical high-level steps taken in performance of a patent search [Link]. The following closely follows the overall search process described in the earlier post, but here concentration is on patent mining searches specifically.

A mining search is carried out in order to find and gather related patent assets — mining searches are usually performed for at least one selected technology area. This type of search is often executed on behalf of an entity which owns many patent assets and which may therefore not be fully aware of the scope of their portfolio. The patent assets uncovered in mining searches may then be rated, and these ratings can be leveraged to gather related assets for licensing or divestiture collections, and can also be used for maintenance decisions. Patent mining searching is an iterative process requiring continual refinement throughout searches, and it is often scoped to conclude with a set of a specific number of relevant patents which will then be reviewed in further detail. Sometimes the objective is to find all patents within a given technology area, but normally the objective is to find a specific number of patents within a given time limit. The scope of a mining search is not always limited to one owner’s portfolio, and for acquisition considerations, a mining search may include patents from a set of owners or even from any owner. Sometimes a limitation is put on searches to find only those patents with a specific amount of residual in-force lifetime.

Not all steps below necessarily need to be performed in the order listed, though this order has been shown to work well. Nor do all steps need to be performed at all – in practice, some search refinement often must be skipped due to time constraints. A patent analyst should continually consider the most productive path for gathering the strongest final set of patents based on what is discovered through search results along the way, and based upon given time constraints.

The set through which to search may need to be limited to one or more specific assignees or to one provided patent set.

1. Review technologies and target companies/products associated with the project. This step should definitely be performed first.
2. Formulate keywords and Boolean queries. Be prepared during searches to further refine the keyword set and Boolean queries.
3. Become familiar with patent search software functionality (if needed for the given software).
4. Perform searches using various keywords and Boolean query combinations. Perform first-pass searches using very targeted keywords and Boolean queries so as to find what may be the strongest matches up-front. Using these strong matches, you can leverage these patents to determine relevant patent classification codes and to perform semantic searches later. This step may be considered complete once all technology areas have been sufficiently searched.
5. Search using relevant USPTO/WIPO/EPO classifications (USPC, IPC, CPC). Relevant class codes can be manually determined through selected patents, and some patent search tools will indicate the most prevalent class codes in a patent set.
6. Search using the most relevant and prolific inventors found so far.
7. Search using cites/cited for patent references — reverse and forward citations, respectively.
8. Perform semantic searches using text from some of the best assets. Patent search software tools that provide semantic search functionality are recommended.
9. Know when to stop. This is probably the most difficult step, though budgetary constraints will often dictate this step. One good method to know when to stop is to see how the semantic searches pan out. If results from the semantic searches align well with earlier findings, then consider the search to be complete — if not, and the results appear to open another avenue, then continue refinement and searches until results become much less productive (i.e., the same assets keep showing up and new searches result in little or nothing new), within the budgeted time window.
10. Pre-filter the current asset set to eliminate patents that can quickly be dismissed and to get down to a specified number of results, if any.
11. Consider capturing family members of the most relevant references (siblings, parents, and children). You may wish to skip this step for now and only come back to it in a subsequent phase once most patents have already been filtered out. The reason being that patent families often fall together, and having too many assets in the same family might push out more relevant assets. The risk with not including family members is that a less relevant family member may be filtered out without providing the opportunity to review a well-aligned relative.
12. Collect and output the resulting set for next-stage analysis.


Bottom Line


Bottom line it.


My nature is to study details, and that’s one reason I enjoy patent analysis work so much. Being a detective is exciting, and it’s fun to delve deeply into a patent under review. There are numerous considerations to be made for a patent under review, and each subsequent phase of review entails analyzing additional aspects. Because of this, there is often a lot to say about how one reaches a conclusion and a recommendation for a given patent. Clients often provide a numeric rating system for assets so that they can more easily determine the best patents, filtering out those without as much potential. But even when they don’t use a rating system, clients appreciate a high-level summary of the conclusion and recommendation, and sometimes they do not wish to delve into the details as to why an analyst made the conclusion. So I recommend for verbal feedback to first provide a very short bottom-lined summary, and only go into the associated background details upon request. Additionally, for written communication, give the overarching bottom line up front (e.g., at the top of an email or on the far left of a table), and then subsequently provide supporting details.