As US patent practitioners know very well, the chief database used by USPTO personnel to carry out most patent prosecution (including design patent prosecution) is called IFW (image file wrapper). Some nameless person at the USPTO made a decision back when IFW was being designed a decade ago, to make this a database in which no color or grayscale drawing would be displayed clearly. Instead any color or grayscale drawing will get blurred, often to the point of unrecognizability.
Which then raises the question, how may a member of the public obtain a PDF copy of an issued US design patent that shows the actual color or grayscale drawings instead of the blurred non-color drawings of IFW?
In this blog article I will tell you how you can obtain a PDF of an issued US design patent that faithfully reproduces the color or grayscale drawings. To do a good job of explaining this, I must first provide a bit of background as to an image formatting concept called “halftoning” (Wikipedia article).
Any normal industrial design drawing that is stored in a computer file will store the image as “pixels” (a term which comes from “picture element”). Each pixel will be defined in the computer file by some number of bits (a term which comes from “binary digits”). For a color drawing in 2019 that will be viewed by a human eye, almost always the pixel will have its color defined by 24 bits. The 24 bits are allocated eight at a time to communicate the level of color of each of three colors (red, green, blue). A first eight of the bits communicate how much red is in the pixel, with 256 possible amounts of red ranging from none to a fully saturated red. A second eight of the bits communicate how much green is in the pixel, with 256 possible amounts of green ranging from none to a fully saturated green. The remaining eight bits communicate how much blue is in the pixel, with 256 possible amounts of blue ranging from none to a fully saturated blue. The number of possible distinct colors for each pixel is 2563 which is 16,777,216 possible colors. A computer geek will say that such an image has “a color depth of 16,777,216” or “24 bits per pixel”.
You might wonder “why three?” Why is three the correct number of colors to use in a computer file that stores a human-readable image that is in color? Why not two or four or some other number? And I answer that question here. The answer turns, depending on which school of paleoanthropology you follow, on either the skills for identifying ripe fruit around ten million years ago, or the skills for selecting a potential date in a singles bar around ten million years ago. You can read a fascinating lecture by Richard Feynman in which he explains how the three colors work.
The other possibility in 2019 is that the computer file is trying to store “grayscale” rather than full color. (And no, we are not here discussing the imagined skin disease from Game of Thrones.) In the case of grayscale, each pixel will have its content defined by 8 bits. This means that each pixel of the drawing has a value between 0 and 255. 0 is white and 255 is black. The other 254 values are various shades of gray. The number 128 is about half way between white and black. A computer geek would say that there are “eight bits per pixel” or “a color depth of 256”.
We then turn to the unfortunate decision made a decade ago by some nameless person at the USPTO, namely that the IFW database would store its images using “a color depth of two”. The idea was that each pixel is assumed to be either pure black or pure white in color. The IFW system only stores images in which each pixel has only two values — 0 or 1. 0 is white and 1 is black. Each pixel is either pure white or pure black. A computer geek would say that there is “one bit per pixel”.
Having made this decision to permit only the use of a single bit to communicate the color of each pixel, how might the USPTO take an image file that was e-filed by an applicant (which has a more normal eight or 24 bits per pixel) and somehow “flatten” it into the single bit per pixel? Some computer programmers, when faced with this problem, might arrive at a very simple algorithm: for each pixel, work out whether it is closer to black or closer to white. If it is closer to black, replace the 8 bits or 24 bits with a single bit that is a “1”. If it is closer to white, replace the 8 bits or 24 bits with a single bit that is a “0”.
But that is not the path that the USPTO chose. The USPTO chose to do “halftoning”.
When an applicant files a drawing at the EFS-Web system (at the USPTO) that contains grayscale or color, the EFS-Web system ruins the drawing. The EFS-Web system does what is called “halftoning” (Wikipedia article). The EFS-Web system will take a group of pixels that are in color or various shades of gray, and will replace that group with some group of pixels each of which is pure white or pure black. The EFS-Web system turns each such pixel either “on”or “off” so that the entire group of pixels adds up to about the same percentage of blackness or whiteness as the original set of pixels. The result of course is that the information content of each pixel gets blurred into many adjacent pixels. The overall result is that the IFW drawing is very blurry when compared with the original drawing as filed.
A century ago or even as recently as half a century ago, the halftoning was often a necessary evil. Most printing technologies that were in use 50 or 100 years ago were technologies that either transported ink from point A to point B or did not transport ink from point A to point B. For each spot on the piece of paper where printing is taking place, either the spot got ink on it or the spot did not get ink on it. Through the use of halftoning, a fairly workable image with gradations of gray or color could be successfully printed on a page even though at any given spot the situation was a “yes or no” thing with either ink being deposited or ink not being deposited.
Fifty years ago, or even twenty years ago, computer data storage was extremely expensive. A decision to store eight bits per pixel instead of one bit per pixel required spending eight times as much money on some very expensive hard disk drives. A decision to store 24 bits per pixel instead of one bit per pixel required spending 24 times as much money on some very expensive hard disk drives.
But now in 2019, data storage costs are only a fraction of a percent of what they were ten or twenty years ago. In 2019, a system designer will not choose to store one bit per pixel for a human-readable image as a way of saving money, because it does not save much money these days.
Back to halftoning. Here are images from an actual issued design patent that our firm obtained for our client Lenovo, that issued this past Tuesday. This first image shows a portion of a figure, the way we e-filed it.This image shows that same portion of the figure, the way it looked after the USPTO carried out its halftoning for storage of the image in IFW.
You can easily see that the halftoning degrades the image quality. And this leads to a very poor quality image in the PDF of the issued design patent as it appears in the PatFT database on the USPTO web site, as you can see here. Which brings us to the main point of today’s article, namely that the USPTO will sometimes preserve the original drawings as filed in a special database called SCORE (also called “supplemental content”). If you are very lucky, when the USPTO issued your design patent, the USPTO may have made use of the SCORE drawings rather than the IFW drawings. If so, then the USPTO will have stored that PDF in the Supplemental Content system. To obtain the good quality PDF, go to PAIR and click on “Supplemental Content”. You will reach a page like this where you should click on “US Patents w/color”:You will then reach a page like this where you should click on “Down-load”:
You will then have a good quality PDF of the granted US design patent.
So the main point is that for a US design patent, if the drawings are simple black and white line drawings, then you may be happy with the PDF that you can get from the PatFT database. But if the drawings have any gray scale or color, you will almost certainly prefer to get your PDF from SCORE.
Here are some examples:
- the above-mentioned Lenovo patent the way it comes from PatFT
- the above-mentioned Lenovo patent the way it comes from SCORE.
Here is a color design patent that issued this past Tuesday on a Hague filing:
- the way it comes from PatFT
- the way it comes from SCORE.
(It is this patent that provided the image at the top of this blog article.) Note that the former is about one megabyte in size, while the latter is about 5.6 megabytes in size. This particular case came to the USPTO from the Hague system, but similar degradations can happen with ordinary domestic US design patent filings.
What experiences have you had with USPTO’s halftoning? Please post a comment below.
Well said Carl! Two comments.
As to the storage cost issue, the cost for the quality color SCORE images per image, given the current cost of about $0.20 per Gigabyte of SSD storage, is roughly (4 Meg for 3 images, so roughly 1 meg per image/page; which gives a cost of 20 cents for 1000 images or) .02 cents per image/page. Assuming I carried my zeros properly. So the difference in cost per image/page, even at current consumer storage prices, is less than 0.02 cents per image.
As to SCORE, not all patent practitioners appreciate that not all documents containing drawings that are filed electronically in patent files in the USPTO are saved in SCORE, or what steps are required to take advantage of SCORE. The USPTO’s new notice, “LEGAL FRAMEWORK FOR PATENT ELECTRONIC SYSTEM,” October 23, 2019 provides the most recent guidance on what filed documents will and what will not be stored in SCORE. See specifically sections “B4. The Official Record of Documents Submitted via EFS-Web” and “K2. Document Description for Photograph and Drawings.”
Just a small mistake in the fourth paragraph, 24 bits gives more possibilities than 65536. That would be 16 bits. 24 bits gives 16777216 possible colors..
It is such a treat to have such alert readers. Thank you. I have corrected this number in the article.
I’m so happy to have found this, but so sad that I did just six months before DOCX implementation. Nonetheless, thank you, Carl! You are an invaluable resource!
When filing an application (design or utility) with pdf files, the PTO’s software can take a nice, sharp line drawing, decide that there’s color or greyscale in the drawing, and then proceed to ruin it by halftoning it. You then get a notice to correct the drawings, and have no idea what the problem is, since the pdf that you filed looks perfectly good on your monitor.
I believe that a pdf file may have flags in it that indicate something other than black and white. The solution is to “print to pdf” – use the print command, then instead of selecting a printer, select the pdf creation option. Be sure that any color selections that might be available specify b&w. The created pdf can be filed via EFS without suffering degradation.