Archive for the ‘Claim Charting’ Category

Intrinsic and Extrinsic Evidence for Claim Construction

February 10, 2014 Comments off

Patent claim construction involves an analysis of intrinsic evidence primarily, and then extrinsic evidence as needed.

Intrinsic evidence includes the following, in this priority order: patented claims, patent specification, and prosecution history. With regard to the prosecution history, this includes not only the prosecution history of the reviewed patent, but also the prosecution histories of all US family members — that is, prior related US applications, prior related CIPs, related US siblings, related US children, and related US grandchildren. For prosecution history review, focus is placed on office actions and office action responses, and reviews look for the possible presence of two types of estoppel: 1) Argument-based prosecution history estoppel where the applicant explicitly indicates claim interpretation through arguments made in office action responses; and 2) Amendment-based prosecution history estoppel where a narrowing amendment is “made for a ‘substantial reason related to patentability’ when the record does not reveal the reason for the amendment.” (Festo) 

Extrinsic evidence includes, for example: dictionaries and expert / inventor testimony. Extrinsic evidence may be considered to inform claim construction based upon the intrinsic evidence, but in most situations intrinsic evidence alone suffices to construe claims, and in many cases it is improper to rely on extrinsic evidence at all.

Wireless packet capture and analysis

July 3, 2013 Comments off

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!

Citing reference sources

June 24, 2013 Comments off

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!

Considering Kind Codes when Analyzing non-US Patents

February 15, 2013 1 comment

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:, retrieved Feb 15, 2013):

GB patent kind code "A" claims

GB patent kind code “A” claims

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.

Patent Analyst Venn diagram

October 1, 2012 1 comment

Below is a Venn diagram I created in order to highlight some of the various differences in skills, knowledge, background, personality, and common responsibilities between a patent analyst role and a few related professions such as patent attorney, engineer/scientist, and patent paralegal.  The diagram is neither scientific nor comprehensive, and some overlaps are likely skewed percentage-wise. Also, of course some folks have multiple roles/skills (e.g., a patent paralegal with an engineering degree) – but the diagram is nonetheless fairly representative.  The point of view is from a patent analyst perspective, though personally I perform tasks as both a patent analyst and a registered US patent agent.  Additionally, differences exist between corporate and law firm professionals and between employees at larger versus smaller entities.

Example differences and overlaps:

1. A patent analyst needs to have a solid mix of technical expertise and patent knowledge and should also have an up-to-date awareness of the market and vendors in one or more technology areas, and a patent analyst needs to be able to perform detailed investigations to determine mappings of patent claims to corresponding products/solutions such as through reverse-engineering, product utilization, and/or documentation review.

2. A patent analyst and a patent attorney both need to understand the fundamentals of patents, such as patenting requirements, relevant dates, claim scope and language.  Both may be required to perform patent-related searches such as patentability, freedom to operate, invalidity, state-of-the-art, etc., and may be asked to review the potential relevance of a patented claim on one or more target products/solutions.

3. A patent analyst, a patent attorney, and an engineer/scientist each needs to have a solid background and understanding of one or more technology areas.  A patent practitioner, such as a patent attorney or a patent agent, must possess sufficient scientific and technical training such as having earned a Bachelor’s degree in a recognized technical subject.

4. A patent analyst and an engineer/scientist must both have a solid understanding of one or more technology areas.

5. A patent analyst, a patent attorney, and a patent paralegal must each have a fundamental understanding of patents, such as patenting requirements and relevant dates, though a patent paralegal does not need to understand the intricacies of claim language, and a patent analyst does not need to know the details of interaction with a patent office.

6. An engineer/scientist usually also has responsibility to manage and/or design and/or develop a technical product or solution.

7. A patent attorney additionally has a law degree and has passed a territorial law bar exam along with a patent bar exam and can represent clients in court and with the USPTO, and a patent attorney can provide legal opinions (such as patent non-infringement or invalidity).  Note that in the US a patent agent has passed the USPTO patent bar exam and can represent clients for patent application prosecution work with the USPTO, but cannot provide any other legal representation or provide legal opinions.  A patent attorney (or patent agent) can draft, file, and prosecute patent applications.

8. A patent attorney and a patent paralegal must both have a sufficient understanding of the main bureaucratic aspects of patent prosecution with one or more patent offices.

9. A patent paralegal often has a more detailed knowledge of the finer details associated with interaction with patents offices than might a patent attorney, and a patent paralegal works under the supervision of a patent attorney to assist with preparing and filing necessary patent-related documents.  A patent paralegal often possesses detailed knowledge of docketing software used to track patent assets.

Technology Areas

September 14, 2012 Comments off

Below are example technology areas in which I perform patent analysis.

Mobile Technologies:
Mobile devices, mobile user interface, location-based services, navigation guidance, mobile social networking, mobile advertisements, mobile messaging, smart cards, near field communication (NFC)

Web Applications:
HTML, XML, XSLT, CSS, JavaScript, PHP, MySQL, SQL, RSS/ATOM, AJAX, web services, web servers, web television, data visualization/reporting

Mobile Application Platforms:
Android, J2ME, BlackBerry, iOS, BREW

Data Communications:
IP, TCP, HTTP, UDP, Ethernet traffic analysis, DNS, data link control, packet switching, circuit switching, routing protocols, SIP

SMS, instant messaging, electronic mail, MMS

Wireless Communications:
3GPP (UMTS and LTE), 3GPP2, IEEE 802.11 (Wi-Fi)

cryptography, e-commerce

Embedded systems, RTOS, C, Java, Perl, Visual Basic, Object-Oriented Design