Badges [ 7 ] [-]
Memberships [ 1 ] [+]
Activity Stream [+]
Ideas Contributed [ 13 ] [+]
When making priority claims using WebADS, the order the priority claims are input seems to be unrelated to the order in which they populate the resultant WebADS aia0014 form. That is, if five priority claims are listed in order 12345, they might come out as 31452. This has already presented problems in at least one case, where the (long and complex) priority chain in the as-filed ADS came out totally jumbled, causing ...more »
The last update to the Application Data Sheet (aia/0014) broke the XML import/export functionality. Please bring that back.
Currently, whenever the Examiner cites references, you have to manually hand-key them into an IDS form for submission in other cases. As the form we see in PAIR is obviously auto-generated, or at least all info contained therein is stored separately - see as proof the 'Download References' functionality - give us the option to download e.g. XML data for all references cited that can be imported directly into an IDS. ...more »
If you download the XML data for a number of applications at once (e.g. for everything under a given customer number), you get significantly less data for each application than if you pulled the XML data for each application separately. Let there be an option to pull the complete XML data for multiple applications at once, please (and preferably all applications at once).
You can see 180 days of history for status changes, but only 90 days for outgoing correspondence, which makes it much harder to do a sanity check for anything that might have slipped by.
On EFS receipts where payment is made by deposit account, the "Authorized User" field in the payment section of the receipt is blank. Looking back at old EFS receipts, this has evidently been the case since at least 2009, though we never noticed until now.
Instead of all the radio buttons for various search functions in the public-PAIR-like section of PAIR, it would be significantly better if the search function were simply smart enough to distinguish between the various types of numbers. The various case numbers are deliberately different for just this reason, and I would think it should be fairly simple to implement.
In PAIR, the ability to download XML data for a customer number is useful, but two suggestions: 1) Have an option to get data from all your customer numbers at once; and 2) include in the XML an indicator of current status. It already lets you filter on application status ('all', 'new', 'pending', 'issued', 'abandoned', 'other') - simply include this status tag in the download.
Carl Oppedahl has done a much more thorough treatment of the topic at http://blog.oppedahl.com/?p=208; in short, though, a major fault in EFS should not be able to knock out EFS-Contingency as well.
This is a tiny tweak that would make things easier - currently, the dropdown menu to classify the files you're uploading is sorted alphabetically, but in a case-sensitive ordering. For example, in the petitions block of descriptions, there's a set of descriptions starting with 'Petition For', followed by a set of descriptions starting with 'Petition for'. Make the sorting case-insensitive instead, please.
It says somewhere that you can set how long you want to stay logged in to PAIR before the system boots you for inactivity, but this has never been true. Let this be customized, preferably with an option for 'never'?
Reactions to the recent updates to the PAIR front page have been extremely mixed, but one thing is abundantly clear: people want different things to be immediately available on the PAIR splash page. I know some people who never search by docket number, only by application number; personally, the only search options I usually care about are correspondence and docket number. So why not make the splash page customizable, ...more »