Details:
Ex parte Hofstee
Appeal 2009006207; Appl. No. 10/763,079; Tech. Center 2400
Decided: February 24, 2011
The Applicant was directed to secure electronic communications. Original claim 22 recited
22. A computer program product for secure communications, the computer program product having a medium with a computer program embedded thereon, the computer program comprising:When this claim was rejected under § 101, the Applicant amended to add "computer readable":
22. A computer program product for secure communications in a message source, the computer program product having a computer readable medium with a computer program embedded thereon, the computer program comprising:The Examiner then gave a § 112 First, Enablement rejection, alleging that "the Applicant fails to sufficiently point out or describe computer readable media." The Applicant appealed this rejection, along with prior art rejections.
In the Appeal Brief, the Applicant pointed to the following passage in the specification as evidence of enablement:
It is further noted that, unless indicated otherwise, all functions described herein may be performed in either hardware or software, or in some combinations thereof. In a preferred embodiment, however, the functions are performed by a processor such as a computer or an electronic data processor in accordance with code such as computer program code, software, and/or integrated circuits that are coded to perform such functions, unless indicated otherwise.The Applicant also argued that:
[C]omputer readable media, such as floppy disks, magnetic tape, hard disk drives, random access memories, flash memories, optical disks, and the like are so notoriously well-known that a person of ordinary skill in the art would not require any undue experimentation to store computer code that performs the functions described in the instant specification onto a computer readable medium.The Board reversed the rejection because the passage quoted above from the Applicant's specification disclosed "at least one embodiment of a medium as an integrated circuit coded to perform functions." The Board noted that enablement did not require a specification to disclose what is well known in the art (Lindemann Maschinenfabrik GmbH v. American Hoist & Derrick Co., 730 F.2d 1452, 1463 (Fed. Cir. 1984)), and that "omission of minor details does not cause a specification to fail to meet the enablement requirement." Genentech, Inc. v. Novo Nordisk, A/S, 108 F.3d 1361, 1366 (Fed. Cir. 1997).
My two cents: The Applicant was smart to focus on "undue experimentation," since the Examiner did reject under Enablement rather than Written Description. By its very nature, enablement is about what a POSITA knows and what a POSITA understands from Applicant's specification. In the computer and electronics arts, the amount of detail required about specific implementation mechanisms is relatively low. You don't need much detail about processors, logic circuits, memory, and storage. As long as enough detail is present about the claimed functions, a POSITA can generally figure out how to implement that functionality on the appropriate hardware or software platform. So it didn't surprise me that the Board reversed this Enablement rejection.
Now, had this been a § 112 First rejection under Written Description, the story would be different. In that case, the Board is less likely to be persuaded with arguments about what a POSITA knows, because the focus is instead on what the inventor possessed.
Examiners are sometimes sloppy about the distinction between Enablement and Written Description. (As is the Board ... see BPAI confuses enablement and written description.) For this reason, I read all § 112 First and Second rejections very carefully. I've even seen an Examiner throw in § 101, Enablement, Written Description, and indefiniteness, giving essentially the same explanation for all.
"Examiners are sometimes sloppy about the distinction "
ReplyDeleteThey're not "sometimes sloppy" about it in the compooter arts. Nobody over there even understands w t f either of them are about. Period. Otherwise, nearly every CRM claim would get a 112 1st WD for a failure to show one of these "specially programmed ICs" or whatever other medium they were claiming and that nearly always happens because the invent ard doesn't know w t f such a specially programmed IC would look like, what so ever, and even if they did they never show it in the app.
I assume when you say "show what a specially programmed IC looks like" you really mean "disclose some details of the specially programmed IC". Surely we're not talking about drawings here.
DeleteIf so, "details" sounds more like Enablement, not WD. WD is about possession. Why do you take the position that a simple statement "can be implemented in hardware or integrated circuit or specialized logic" is not sufficient to show POSSESSION? My position is that such statements *do* show possession.
"Surely we're not talking about drawings here."
DeleteDrawings would surely help. Just like they do for all other "so small you can't see it" inventions. They would be one way of "showing". But I would accept other forms of showing. I'm not unreasonable in that regard what so ever.
"If so, "details" sounds more like Enablement, not WD. "
It shouldn't, because you'd not be facing an enablement rejection. You'd be facing a 112 1st. So, you should, as I'm always reminding you, keep focused on what issue would be or is before you.
"WD is about possession"
Exactly, so what happens in other arts when you try to submit a functionally recited genus of structures without showing a dam one or at least specifying how they are all interrelated and bring about the function?
112 mo fin first. Every fin time. Lackin' on possession.
And just because you choose to use functional language does not let you off this hook of needing to show possession of the whole scope of the claim, including, mind you, the species within a functionally recited genus. Which seems to have been ignored by the office since Ariad officially laid down that we're talking about possession. Because hey, everyone knows 112 1st possession doesn't apply to CRM claims! Hur hur hur.
"Why do you take the position that a simple statement "can be implemented in hardware or integrated circuit or specialized logic" is not sufficient to show POSSESSION?"
Because a similar statement in any other art is ALWAYS, I repeat, ALWAYS deemeed to be insufficient. And according to even the biggest of the software ta rds around they don't want special treatment for their art. So I say, fine, you won't get any. Go ahead and do just like everyone else in the world does when they want a functionally recited genus of a gazillion species. Describe the relationship between them that results in the functionality and also go ahead and show us a representative sample of the species that suffices to show possession of all the species.
No. Special. Treatment.
> Which seems to have been ignored by the office since Ariad
Delete>officially laid down that we're talking about possession.
>Because hey, everyone knows 112 1st possession doesn't
>apply to CRM claims! Hur hur hur.
This post is about WD in the context of CRM claims. But it seems like your criticism applies to all types of claims.
Is it your position that most "computer" applications should receive Written Description rejections for all types of amended claims, not just CRM claims? Such that you'd give a WD rejection when the Applicant amends to add "computer" to a method or system claim? On the grounds that the Applicant claimed a system involving a computer and functional language, but didn't show possession of the whole scope of the claim?
I refer to "amended claims" since originally filed claims get a presumption of WD, and thus typically don't trigger WD rejections. But maybe you'd give WD rejections for originally filed claims that recite a computer?
"Otherwise, nearly every CRM claim would get a 112 1st WD for a failure to show one of these 'specially programmed ICs' or whatever other medium they were claiming and that nearly always happens because the invent ard doesn't know w t f such a specially programmed IC would look like, what so ever, and even if they did they never show it in the app."
ReplyDeleteSo a prima facie case of lack of written description support can be established by a failure to show what a claimed feature "would look like"?
Lulz. You continue to get dumber and dumber. Simply amazing.
"So a prima facie case of lack of written description support can be established by a failure to show what a claimed feature "would look like"? "
ReplyDeleteOr otherwise describe it in terms of what it IS. And, not only that, it happens all the time in other arts.