[p2patent-developer] use case updates / screen designs on the way

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eric,

My thoughts in response to your equestions below in line.

On 11/25/06, Eric Hestenes <erichestenes at vikiwi.com> wrote:

> > Under 1, where the user selects which claims for which the prior art
> > is relevant, the graphical display should differentiate between
> > independent claims and dependent claims.
> Where do we get the information about dependent/independent claims?

There are probably several ways to identify the independent claims.
One way to identify dependent and independent claims would be to run a
parser over the claims in the patent application.  Any claim that
references another claim is a dependent claim.  Dependent claims
usually begin with something like "The system of claim 1 ..."


> >> c. If we search for matching prior art, what happens if the only
> >> difference is the list of claims? Do we create a new prior art
> >> reference?
> >If the only difference between two pieces of prior art is in the
> >claims, then that means the two specifications are identical.  If the
> >two specifications are identical, you would use the document with the
> >earlier priority date as a prior art reference.
> For this situation, I imagined that the dates could also be the same  (e.g.
> for an issued patent).  So we could have two pieces of prior art from two
> contributors, with the same issued patent, and the only differences between
> them are the reference author's selection of relevant claims, and also any
> commentary they may have  provided would be different.  If we keep multiple
> references to a single issued patent, it dilutes the ratings "votes" on
> each. So it is not clear how we should deal with this.

If you have multiple entries that are essentially to the same
reference and are concerned about diluting ratings "votes", you have
the options of keeping the multiple entries, merging them, or deleting
all except one.  If you delete all except one, you lose information so
that is the worst alternative.  That leaves merging them into one
combined entry or maintaining multiple entries as plausible
alternatives.  This might come down to a trade-off as to how complex
it would be to merge them into a combined entry without losing any
information versus maintaining multiple entries and risking some vote
dilution.

Tom


[Index of Archives]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux