Examiner affidavit of personal knowledge

I've seen plenty of file histories where the Examiner says an element is known or well-known instead of providing a reference, and the Applicant responds by saying "since the Examiner appears to be relying on personal knowledge, Applicant demands that the Examiner provide an affidavit attesting to these facts."

According to some practitioners, this is a good strategy to force the Examiner to provide a reference, because Examiners don't want to be bothered with an affidavit. Since I'm as annoyed as the next guy by allegations that elements are "known", "well-known," "notoriously well-known," and "extremely well known," I was curious to know a) the legal basis for the demand for an affidavit and b) whether or not it's a good way to force the Examiner to provide a reference.

37 CFR 1.104(d)(2) really does say that the Examiner must provide an affidavit when relying on personal knowledge:

When a rejection in an application is based on facts within the personal knowledge of an employee of the Office, the data shall be as specific as possible, and the reference must be supported, when called for by the applicant, by the affidavit of such employee, and such affidavit shall be subject to contradiction or explanation by the affidavits of the applicant and other persons.

I found a few instances where this "personal knowledge" issue has been raised at the BPAI. Only one of these Board decisions said that the Examiner should have provided an affidavit, and in this one the Examiner really did state that the element came from "facts within his personal knowledge". The other cases were found to be instances of Official Notice, and in most of them the Examiner made the Official Notice explicit.

Takeaway: The rules for traversing Official Notice are very specific, and not doing so properly is an admission that the element is known. So, instead of arguing "Examiner didn't provide a reference, so must have been relying on personal knowledge," it seems much more productive to instead assume that the Examiner is invoking Official Notice when no reference is provided, and to properly traverse the Official Notice. Sure, there are decisions where the Board treated the real issue as Official Notice rather than personal knowledge, and didn't punish the Applicant for not properly traversing — but why rely on the Board's generosity?

Here's a Summary of the Board's findings on the "personal knowledge" issue.

Ex parte Hull: The Examiner really did use personal knowledge! The final Office Action said: "The examiner has personal knowledge...In September, 1998, the examiner cut hyperlinks from a web browser and pasted said hyperlinks into an email. While composing an email message in Microsoft Outlook within the Windows operating environment, the examiner cut URLs of online documents from Internet Explorer and pasted them into said email message. Thus, the limitation of Claim 59 reads on this personal knowledge of the examiner." The Applicant argued that it was improper to reject a claim based on personal knowledge. The Board found in favor of the Applicant: "Therefore, we decline to consider the examiner’s personal knowledge as evidence because the examiner has failed to provide an affidavit or declaration setting forth specific factual statements with an explanation to support the finding of record."

Ex parte Trans Texas Holding Corp.: The Examiner didn't use the magic words "Official Notice" but the Board read it that way. The first Office Action alleged that "the deposit account being secured by property of the institution" was "implicit" in the reference "because this was a well-known method of running a bank." The Applicant responded by disagreeing that this was well-known, referencing the "personal affidavit" rule, and requesting that the PTO "make of record whatever evidence it might have in this regard." The Board found that the request for a personal affidavit "is clearly inappropriate because the examiner is relying not on personal knowledge but on the general knowledge of persons having ordinary skill in the banking art that it was standard practice to provide security for deposit accounts."

Ex parte Duck: The Examiner asserted that a feature was "well-known" instead of using the magic words "Official Notice." The Applicant argued that the examiner did not provide either a reference or a personal affidavit in support of this assertion. The Board didn't comment on the appropriateness of an affidavit, but did find that the Examiner's assertion was based on speculation "and thus fails to provide sufficient reasons for finding [the claim to be] obvious." [My take on this: the problem wasn't the lack of an affidavit, it was the type of facts that the Examiner was asserting to be well-known.]

Ex parte Moitra: The first Office Action said: "The Examiner takes official Notice that is is old and well-known in the art to track costs." The Applicant responded by arguing that the Examiner had cited no source for this finding, and alleged that the "Examiner states that this comes from his personal knowledge." The Board found that the requirement for a personal affidavit was inapplicable, because "this section only requires that facts that are within the personal knowledge of the Examiner be supported. The facts taken under Official Notice here were explicitly found to be common knowledge, and were not based on the Examiner’s personal knowledge."

Ex parte Trajkovic: The Examiner took Official Notice that it was well known in the art that windows are represented on the taskbar by icons and that windows were reactivated by activating these icons. The Applicant argued that the Examiner was required to submit a reference or a personal affidavit to establish facts within personal knowledge. The Board found that:

The use of status buttons on the taskbar (or status bar) in a windows environment to represent windows was so notoriously well known that it cannot be seriously in dispute (although it always would be better for an Examiner to provide a reference where it would be easily available). Such status buttons change appearance to indicate the active window and it was well known to reactivate an inactive window by activating a status button. Anyone who used a computer with Microsoft Windows before 2002 would know these facts.

In claim to “A or B”, is B always optional?

Ex parte Buckley
Decided March 10, 2009
(Appeal 2007-3617, Appl. No. 09/941,329, Tech. Center 2100)

I blogged about Ex Parte Buckley earlier (here), discussing a §112 rejection that really turned out to be a claim construction issue: whether “additional” modified one noun phrase, or two. It turns out there was another claim construction issue lurking in this case, one which didn’t get much discussion: when the claim recites “A or B,” is B optional?

The simplistic answer is “The claim uses the alternative so B is optional." But does the word “or” always mean in the alternative? I say No, not always — as usual, it depends on *exactly* what the claim says.

Here's claim limitation at issue: “wherein both the hardware and the software layer of the console device can be accessed without the requirement for an additional hardware dongle or a signal device transmitter.”

The Board agreed with the Examiner that “under the broadest reasonable interpretation of the claim the ‘hardware dongle’ may be read as optional.” (Decision, p. 9.) The Examiner laid out his argument in the Answer:

Additionally, as an alternate argument, Applicant's entire argument is moot in view of the fact that that the limitation requiring access without "an additional hardware dongle" is not even required by the claim when the alternative OR limitation requiring access without an additional signal device transmitter is utilized. Examiner again notes that evaluating this claim in view of the OR conjunction for the purposes of determining patentability requires the claim to be interpreted two ways, 1) wherein both the hardware and software layer can be accessed without the requirement for an additional hardware dongle OR 2) wherein both the hardware and software layer can be accessed without the requirement for an additional signal device transmitter.
(Examiner’s Answer, p. 38, emphasis in original.)

Note the Examiner’s conclusion that the use of “or” signals an alternative. In this case, I say the Examiner is wrong: the negative phrase “without” effectively changes the alternative to a combination. I think the correct claim construction is “both the hardware and software layer can be accessed without the requirement for an additional hardware dongle AND without the requirement for a signal device transmitter.”

To make this point clearer, consider this simpler example: “turning the vehicle without stopping or slowing.” Okay, my example limitation used the word “or” — but surely no one would say that stopping and slowing are alternatives? I think it’s clear that the claim actually requires two things: turning without stopping; and turning without slowing.

I was disappointed to see that the Board agreed with the Examiner on this, though it would have helped if the Applicant filed a Reply Brief to address the point. As a practical matter, it’s probably wiser to amend during prosecution rather than trying to convince the Examiner that “or” doesn’t always mean “in the alternative.” In this case, I would amend to: “wherein both the hardware and the software layer of the console device can be accessed without the requirement for an additional hardware dongle and without the requirement for a signal device transmitter.” Or maybe “wherein each of the hardware and the software layer” — because someone might interpret "both" as requiring simultaneous access?

PTO fixes minor problem with appeal brief rules

Earlier I posted about the BPAI decision Ex parte Ghuman — a precedential one — in which the Board remanded a case back to the Examiner with instructions to cancel claims that were not appealed, for later return to the Board. This is a problem for Appellants because a minor mistake (forgetting to file a concurrent amendment cancelling non-appealed claims) now results in a significant delay in getting the case before the Board.

As one who frequently appeals, I was thrilled to read that the PTO has decided to address this problem by modifying the CFR rules which govern appeals! Under the PTO's proposed new rule, when an Appellant "clearly limits the appeal to fewer than all of the rejected claims", the non-appealed claims are deemed to have been cancelled. The new rule further provides that the Examiner should note the cancellation in the Examiner's answer. Most importantly — and here's the part that overrules Ex parte Ghuman — "an application will not be returned or remanded by the BPAI for correction merely due to a failure of an examiner’s answer to note the cancellation of non-appealed rejected claims."

You can read the proposed rulemaking notice here, and thanks to PatentDocs for reporting this news (here).

Case law you can use: Examiner can't pick and choose unrelated embodiments in a §102

What do you do when an Examiner gives you a §102 rejection that combines completely unrelated teachings in a single reference?

With a §103, at least you can argue why these two pieces are unrelated and thus would not be combined. OK, you're unlikely to convince the Examiner with this argument — but at least it's legally relevant. But "wouldn't make sense to combine" isn't legally relevant to a §102...is it?

Not exactly. But there is another weapon you can use:

The [prior art] reference must clearly and unequivocally disclose the claimed [invention] or direct those skilled in the art to the [invention] without any need for picking, choosing, and combining various disclosures not directly related to each other by the teachings of the cited reference.
In re Arkley, 455 F.2d 586, 587 (CCPA 1972).

Although In re Arkley was a chemical compound case, the Board does ocassionally use it to overturn anticipation rejections in non-chemical cases.

On example is Ex parte Ludwig (Appl. No. 09/812,400). The anticipatory reference taught two embodiments of a tone generator: FIG. 2 was a hardware implementation; FIG. 4 was a software implementation. The Examiner read one claim limitation on a component in FIG. 2 and another claim limitation on a component in FIG. 4. The Board reversed, holding that "the Examiner’s anticipation rejection cannot be based on merely picking and choosing multiple, distinct teachings from Suzuki that could somehow be combined to arrive at the claimed invention. See [Net MoneyIn, 545 F.3d ] at 1371. See also In re Arkley, 455 F.2d at 587. Rather, to anticipate, Suzuki must disclose every recited element arranged as in the claim—which it does not." (Decision, pp. 10-11.)

Another example is Ex parte Sato (Appl. No. 10/791,829). The claims were directed to an electro-deionization apparatus which introduced deionized water from desalting compartments into a specific location in concentrating compartments or allowed concentrated water to flow out of a specific location in the concentrating compartments. The Board overturned the rejection, citing In re Arkley and holding that the "[t]he Examiner has combined the Liang ‘037 Figures 1 and 13 without establishing a direct relation of the relied-upon features." (Decision, p. 5.)

Here's another example: Ex parte Omshehe (Appl. No. 09/954,509). The claims were directed to verifying software licenses when executing software. The anticipatory reference taught two distinct licensing mechanisms. The Examiner relied on one of these mechanisms to teach some claim limitations, then on the other mechanism to teach the remainder of the limitations. The Board reversed the rejection, holding that "such a mix[ing] and match[ing] [of] elements from Redding's two distinct authorization modes is inappropriate for a rejection based on anticipation. Therefore, the Examiner fails to show every element of the claimed invention arranged as in the claims." (Decision, p. 6.) Interestingly, the Board did not cite any caselaw for the proposition that mixing and matching is inappropriate. But clearly In re Arkley is appropriate.

As a final example, look at Ex parte Strongin (Appl. No. 09/825,905). The technology involved (computer processor architecture) is more complicated than I want to get into. But the takeaway is that the Board reversed, citing In re Arkley and stating that "The Examiner is apparently of the opinion that the claimed feature of (1) controlling access to selected information using a first table is taught by Figure 45 of Nozue, and (2) controlling access to selected information using a second table is taught by Figure 24A of Nozue. We find that Figures 24A and 45 depict different embodiments of the Nozue reference." (Decision, pp. 6-7.)

Change in PTO procedure affects RCE processing

Back in October, the Patent Office announced a number of changes to the Examiner count system and docketing system, to go into effect November 15. You can find summaries of these changes at PatentlyO (here) and at Just a Patent Examiner (here).

Like most practitioners, I understand the basics of the count system, but not in enough detail to even begin to understand how these changes will affect my practice. So I'll admit I haven't spent much time thinking about these changes.

The change to docketing of RCEs at the PTO seems easier to understand: in the old days, PTO procedures gave Examiners only 2 months to process an RCE; now, the Examiner has no fixed deadline to process RCEs. Therefore, from what I've read, everyone expects RCEs to start backing up in the queue. In fact, this post at IP Today says the RCE delay could be several months to possibly a year.

I've read some discussion from examiners and practitioners about what all this will mean. (To read for yourself, check out comment threads for the PatentlyO and Just a Patent Examiner hyperlinks above). I was actually surprised that there wasn't coverage about this topic. Guess I was thinking of the continuation rules package back in October 2007, and all the hoopla then.

This change seems to have slipped in under the radar. Then again, it's just a change to internal PTO procedures, whereas the continuation rules package was widely viewed as the biggest change to patent practice in 25 years.

Enablement rejection when problem is complex and disclosure is short

An earlier post introduced Ex parte Rodriguez and discussed the Board's rejection of means-plus-function and apparatus claims. In this post, I'll cover the Board's enablement rejection of the method and computer-readable medium claims.

A claim is enabled when the specification allows a POSITA to "make and use" the claimed invention. Many Examiners and practitioners — and even some BPAI decisions — talk about enablement in terms of "support in the spec." This case is interesting because it uses the proper standard for determining whether claim are enabled: viewing the specification in light of the "Wands factors":

(1) the quantity of experimentation necessary; 
(2) the amount of direction or guidance presented;
(3) the presence or absence of working examples;
(4) the nature of the invention;
(5) the state of the prior art;
(6) the relative skill of those in the art;
(7) the predictability or unpredictability of the art; and
(8) the breadth of the claim.

Even if you've never seen this list before, you can probably guess how the factors work. For example, a spec with working examples (3) balances against unpredictable technology (7), and more disclosure (2) balances against complex technology (5).

The Board found that the three Wands factors relating to the Applicant's spec went against the Applicant:

(1) "the quantity of experimentation necessary" is high;
(2) "the amount of direction and guidance presented" by Appellants is minimal;
(3) there are no "working examples" presented by Appellants in their Specification;
(Decision, p. 42.)

Basically, the Board considered this to be a skimpy disclosure. There are a total of three figures. FIG. 2 is the block diagram that shows the most detail:

FIG. 3 is the only flow chart:

The flow chart doesn't have more than a single block for each step in the independent method claim:

11. A method for automated random verification of structurally variable and complex systems, comprising the steps of:
(A) generating a random system configuration file of said system;
(B) generating one or more parameters of said system in response to said random system configuration file;
(C) generating a system level netlist of said system in response to said random system configuration file;
(D) verifying one or more target modules with said system in response to said system level netlist; and
(E) automatically and randomly adjusting step (D) in response to said random system configuration file.

In the enablement rejection, the Board focused on the disclosure of steps B and C. According to the Summary of Claims in the Appeal Brief, steps B and C correspond to states 208 and 210 in the flowchart, and these steps are performed by the system builder (104 in FIG. 2). However, the Board did not find in the spec any description of how the parameters and netlist were generated.

The spec described, in general terms, what the generated parameters were: system parameters for a particular configuration of the system-under-test. The spec also described the input from which the parameters were generated: a configuration file which described the system in terms of bus functional models, target modules, and their respective interconnections. However, the Board found this basic description of input and output was all that was disclosed.

The spec contained even less detail for step C. The Board noted that the spec did not describe a netlist, but found that a netlist was known in the art to be a data structure which defines connectivity between pins of the various cells of an integrated circuit design. Even so, the Board found that the spec did not describe how to generate the system parameters or the netlist from the claimed inputs:

The Specification does not disclose any specific algorithm that could be implemented on a general purpose computer to provide automated random verification of complex and structurally variable systems." More particularly, Appellants' disclosure lacks even a single embodiment showing how to implement the "system builder" and steps (B) and (C).
(Decision, p. 41.)

Theoretically, a skimpy spec can be outweighed by other factors. Unfortunately, the skimpy spec also included a few statements that went against the Applicant: "factor (4) the nature of the invention" is highly complex as shown by Appellants' description of the significant prior art failings [in the Background] and Appellants' indications [in the Background] that their invention will overcome these failings." (Decision, p. 42.)

Also, factor (8) went against the Applicants: " 'the breadth of the claims" is very broad as it encompasses every way of accomplishing the "generating" results of steps (B) and (C)." (Decision, p. 42.)

The remaining factors were all favorable to the Applicant —less disclosure is required for predictable, well-developed, low-skilled technology:

(5) "the state of the prior art" is well developed as shown by the [reference which we rely on for the meaning of "netlist"];
(6) Appellants contend (without further support) that "the relative skill of those in the art" is high (see Finding of Fact 11 [statement in the spec that functions may be implemented using a conventional computer programmed "according to the teachings of the present specification, as will be apparent to those skilled in the relevant art(s)];
(7) Appellants also contend (without further support) that "the predictability of the art" is above average (see Finding of Fact 12 [statement in the spec that appropriate programming can be applied by programmers "based on the teachings of the present disclosure, as will also be apparent to those skilled in the relevant art(s)."])
(Decision, p. 42.)

When all the factors were considered, the Board found that the method claims were not enabled by the spec. And because the computer-readable medium claims included exactly the same functional language, the same finding applied to those claims as well.

Though the Board considered all the Wands factors, I believe the broad claims and skimpy disclosure were dispositive. Applicant's statement in the Background which described the problem as "complex" was the final nail in the coffin.

The Board strongly criticized the spec for not including "working examples." Unfortunately, the Board did not give any guidance as to what would serve as a "working example" in a software application. Is source code expected? Flow charts for every function? Are block diagrams not enough – or are block diagrams okay if more detail is provided?

I don't know much about this particular area of technology (verification of hardware using software). My sense from having read the spec and file history is that the "system builder" component which the Board focused on – and which had the least detail in the spec – was not the innovative feature. The word "random" appears a lot, and I wonder if the innovation has to do with mixing up the models that are used as input in a random way. If so, perhaps the Applicant could have avoided an enablement rejection by providing more details about the randomization feature. Then if an enablement rejection appeared, the Applicant could offer declaration evidence that a POSITA knows how to generate a netlist from a basic configuration file, and that this basic knowledge coupled with details about the randomizing are enough to practice the method claims.