Wednesday, July 21, 2010

BPAI says "assigning an id to each of a plurality" does not imply ids are different (Ex parte Jourdan)

Takeaway: The Examiner interpreted "assigning an identification number to each of a plurality of micro-operations" as reading on assigning the same identifier to all operations. The Board agreed with this construction, finding that the claim does not require assignment of a separate or unique identifier. Don't assume that if you claim multiple instances of a widget those multiple instances will be interpreted as being different.


Details:
Ex parte Jourdan
Appeal 2008-005499, Appl. No. 10/676,310, Tech. Center 2100
Decided July 19, 2010

The claims were directed to microprocessor technology, and specifically, to multiple branch paths in a microprocessor. The Applicant attempted to distinguish the reference by arguing that "Sharangapani teaches a single assignment to a group of instructions rather than an assignment to 'each of a plurality of micro-operations'." The Applicant further argued that "the cited claim language as a whole explicitly requires that a separate ID is assigned to each of a plurality of micro-operations."

The Board found:
Here, claim 1 does not require that the ID assigned to each operation be "separate" i.e., unique. We refuse to read such a requirement into the representative claim. Assigning the same ID to each micro-operation in one of the reference's instruction streams is enough to anticipate the disputed limitations.

My two cents: This is an example of what I call devious claim construction: the Examiner/Board interpreted the claim in a way that is unconventional, but is perhaps not as unreasonable as it appears at first glance, once you've heard the explanation.

I can think of various ways to express the feature of assigning different identifiers.
  • #1: assigning a different identifier to each of a plurality of micro-operations
  • #2: assigning each of a plurality of different identifiers to each of a plurality of micro-operations
  • #3: assigning a different one of a plurality of identifiers to each of a plurality of micro-operations
  • #4: assigning a different identifier of a plurality of identifiers to each of a plurality of micro-operations
  • #5: uniquely assigning an identifier to each of a plurality of micro-operations
I think #1 may be broader than #2, because #2 may be interpreted as 1:1 correspondence between ids and ops. In other words, #1 definitely allows 5 identifiers and 4 ops, leaving one identifier unused. Where with #2 the accused infringer might argue that in such a case, "each" of the 5 identifiers was not assigned.

Some would say that #3 limits you to a single identifier per operation, but that there is no such limitation in #1 or #2 (one vs. a).

#2, #3 and #4 may be more convenient if you want to refer later in in the claim to the plurality of different identifiers. Some Examiners may tell you that there is no antecedent basis for the plurality of different identifiers in the #1.

I don't like #5 because I think the accused infringer will argue that "unique" is way more narrow than "different." As in, "unique across all the world and across all time." On the other hand, "differently assigning" just sounds kinda funny. But in some scenarios, modifying the verb (assigning) rather than the noun (identifier) might give you different scope.

Related Posts: I see the basic issue here as a variation on "ambiguous relationships between elements", which I posted about here.

10 comments:

  1. I wonder where mah homeboy 101 is in this case that obviously preempts the abstract idea of assigning an ID to each of a plurality of micro-operations to identify a branch path to which the uop belongs, determing whether one or more branches are predicted correctly, determining which of the one or more branch paths are depending on a mispredicted branch, and determining whether one or more of the plurality of uops belong to a branch path that is dependent on the mispredicted branch based on their assigned IDs.

    ReplyDelete
  2. Based on the BPAI decisions that I read and the patents that issue every Tuesday, 101 rejections are arbitrary and capricious.

    ReplyDelete
  3. Agreed. The recent Bilski decision doesn't help alleviate the arbitrary and capricious rejections either.

    ReplyDelete
  4. Doesn't prosecution history estoppel apply here? Even though the claim may be read broadly, doesn't the applicant's statement narrow the possible construction?

    ReplyDelete
  5. >narrow the possible construction?

    In what context?

    If you're talking about litigation, then absolutely the Applicant has disclaimed some claim scope by making arguments about "separate IDs".

    But prosecution disclaimer doctrine applies only to issued patents. Broadest Reasonable Interpretation -- the claim construction standard for prosecution -- considers only the claim language and the spec. See MPEP 2111.01.

    ReplyDelete
  6. Karen,

    Thanks.

    I was not aware that prosecution history estoppel (or prosecution disclaimer doctrine) is inapplicable during prosecution.

    ReplyDelete
  7. Karen,
    The headline for this post is misleading. The claims says "to identify the branch" (IIRC). That changes everything. You are no longer identifying "the" micro-op but rather its predicted branch path.

    ReplyDelete
  8. >The headline for this post is misleading.

    Stepback, thanks for the feedback, but I disagree. My post was not about the construction of "to identify the branch", or what was identified, or even whether or not the reference taught the feature.

    My post was instead about the narrower question of whether AN ID TO EACH was interpreted as SAME IDs or DIFFERENT IDs. The question of what exactly what "each" refers to is not relevant to this point.

    I think the headline accurately conveys my point.

    ReplyDelete
  9. Karen,

    See the latest post-Bilski logic at:
    http://des.uspto.gov/Foia/ReterivePdf?system=BPAI&flNm=fd2009006026-07-23-2010-1

    Ex parte FRANK S. CACCAVALE
    Appeal 2009-006026

    ReplyDelete
  10. @stepback: thanks for the post-Bilski link. I'm working on another post.

    ReplyDelete