[Patentpractice] venting - failure to download priority document from DAS

[Carl Oppedahl]

It's only sufficient if it is free from real or imagined defect.

Keep in mind the ADS is flattened to a TIF image, and it gets blurred.  
I have a case where a non-defective DAS code became defective when the 
USPTO clerk misread a B as an 8.  This was after the 4-and-16 date.  And 
so the DAS retrieval failed, and from the USPTO's point of view it was 
my fault for providing a defective DAS code.  I had to pay the $400 
petition fee to get forgiveness for failing to provide the electronic 
certified copy within the 4-and-16 time limit.

If I had followed Suzannah's example, I would have filed an interim copy 
before the end of the 4-and-16 period, and this would have saved me $400.

On 5/16/2024 8:32 AM, Randall Svihla via Patentpractice wrote:
>
> See 37 CFR 1.55(i), which says that the DAS code is sufficient.
>
> Best regards,
>
> Randall S. Svihla
>
> NSIP Law
>
> Washington, D.C.
>
> *From:*Patentpractice <patentpractice-bounces at oppedahl-lists.com> *On 
> Behalf Of *Orvis via Patentpractice
> *Sent:* Thursday, May 16, 2024 10:27 AM
> *To:* For patent practitioners. This is not for laypersons to seek 
> legal advice. <patentpractice at oppedahl-lists.com>
> *Cc:* Orvis <orvispc at gmail.com>
> *Subject:* Re: [Patentpractice] venting - failure to download priority 
> document from DAS
>
> The real kicker is the CFR requires an applicant to provide the 
> certified priority document by 4/16 months. The CFR does not say 
> providing a DAS code by then is sufficient.  I would welcome anyone 
> who has comments on the PTO interpreting the providing of a DAS code 
> by then being sufficient.
>
> May 16, 2024 10:15:13 AM Carl Oppedahl via Patentpractice 
> <patentpractice at oppedahl-lists.com>:
>
>     Yes.  It's like there is some weird game of chicken going on. 
>     Suppose WIPO had a price for using DAS, like USPTO having to pay
>     ten dollars to retrieve a PD from DAS.  Then in a weird sick way
>     we could understand the USPTO deciding to slow-walk the retrieval
>     until after some of the events in which the filer might have let
>     the filing go abandoned.  You know, like if on average one out of
>     ten US filings go abandoned before the filing receipt, then they
>     save ten dollars for that one case.
>
>     Except, guess what, WIPO does not charge any money for
>     retrievals.  So that explanation for the foot-dragging does not work.
>
>     What's really going on, I believe, is that even though it would
>     absolutely be the right thing to do, the USPTO software developers
>     have not done the bit of coding for this retrieval to be
>     automated.  This is coding that a handful of competent coders
>     (drawn from this listserv, for example) could do on a weekend, if
>     given pizza and soft drinks, and they would have Saturday
>     afternoon and all of Sunday left over.  But no, the USPTO has not
>     done it.  So this task remains (even after more than a decade of
>     DAS existing) a purely manual task carried out by means of fingers
>     moving on keyboards.
>
>     And so the reason for the foot-dragging is, the USPTO wanting to
>     save the internal labor cost of the fingers on keyboards until
>     after some of the events in which the filer might have let the
>     filing go abandoned.  You know, like if on average one out of ten
>     US filings go abandoned before the filing receipt, then they save
>     the fingers-on-keyboards internal cost for that one case.
>
>     Oh and never mind that if only the USPTO were to incur that
>     one-time cost for coding and automating the retrieval, this would
>     save the recurring cost of the fingers on keyboards.
>
>     And it would serve the paying customers better.
>
>     The USPTO's failure in this area seemingly knows no bounds,
>     because it's not just the foot-dragging result.
>
>     Say you go to ePCT to enter in an application number and DAS
>     access code, for the IB to retrieve some PD. */In real time/* the
>     ePCT system cross-checks the entered application number and DAS
>     code against DAS.  If the user had gotten a digit wrong, the user
>     is told this */in real time./*
>
>     But in the USPTO systems, the USPTO goes out of its way to avoid
>     doing any validation or cross-checking of the PD application
>     number or DAS access code.  USPTO could do this when you load your
>     ADS into Patent Center.  If USPTO were to do this (which costs no
>     money to do in a recurring way, and in fact saves the USPTO money
>     later by averting delays and mistakes and do-overs), this would be
>     applicant-friendly.  But USPTO does not do it.
>
>     On 5/16/2024 6:22 AM, Dan Feigelson via Patentpractice wrote:
>
>         Image removed by sender.
>
>         Filed an application that claims priority only from a non-US
>         application. Foreign priority app is in DAS (I checked with
>         WIPO). Provided the USPTO with the foreign application no. and
>         the DAS retrieval code on an ADS at the time of filing. Got
>         the filing receipt, and it acknowledges the foreign priority
>         claim and that the DAS code was provided, and says that the
>         USPTO "will attempt to electronically retrieve" the priority
>         doc. But of course, the p.d. isn't yet in the electronic file.
>
>         That the PTO waits to retrieve the p.d. is not news, Carl and
>         others have written about it. But it still bugs me: how hard
>         would it be for the PTO to retrieve the document NOW instead
>         of waiting?
>
>         Dan
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oppedahl-lists.com/pipermail/patentpractice_oppedahl-lists.com/attachments/20240516/9c0702ce/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD0001.jpg
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <http://oppedahl-lists.com/pipermail/patentpractice_oppedahl-lists.com/attachments/20240516/9c0702ce/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4514 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://oppedahl-lists.com/pipermail/patentpractice_oppedahl-lists.com/attachments/20240516/9c0702ce/attachment.p7s>