Dear All,

Many thanks to the JPO for the comments provided on November 11, 2011 and please find enclosed the comments from the IB in its role as a depositing and accessing Office:

DAS 2-0 Business Requirements v1 PCT comments.doc.

Change in Priority Request function

In relation to the proposals posted above under the heading "Change in Priority Request function", the International Bureau in its role as depositing and accessing Office offers the following comments:

(i) - Shall we put a restriction in the upload operation so that the priority filing dates are always provided and the system generates error if it is not the case.

This should be the aim. P-docs should never be made available before a filing date has been alloted so it is desirable and should be possible to make this mandatory. However, the restriction should not be put in place until OFFs are able to adjust their systems to ensure that the filing date is included with the upload or document registration.

(ii) - If we don’t implement the restriction for registering the priority document with its filing date (like the current situation), there are cases where the priority filing dates are not provided and therefore cross-check cannot be performed by DAS.

This is true, but less important once the access code is able to be used as a "check digit". Consequently, assuming that OSFs can begin new route retrieval sufficiently soon, migrating all OFFs to the new route should be a higher priority, since at least in the case of the existing Route A Offices, we believe that this would be possible independent of needing to wait for changes to OFF systems.

(iii) - Would there be cases where the priority filing dates get changed after DAS registration? If so, there should be a provision for the OFF to update the date record in DAS. The DAS system should notify OSFs which have already retrieved successfully the priority document about the date change. This is unlikely to happen because within the time window when a correction of the priority filing date may be made (e.g. two months) there would be no retrieval.

There are a surprisingly large number of cases where there is a difference between the date indicated by the applicant as a priority date and the date which appears on the priority document. The differences may sometimes be accounted for by an actual change in filing date, but could also be the result in errors by the OFF in producing the p-doc or errors and misunderstandings by the applicant at the OFF or the applicant at the OSF. Consequently, we believe:

• yes, there should be a mechanism for the OFF to update or correct the filing date for a p-doc and to pass that information on to any OSF which has downloaded a copy of the document.
  
• since the access code should in itself provide sufficient protection against accidental download of the wrong priority document, a mismatch in date should return a special error code which alerts the OSF to the fact that the document is available to them but that the dates do not match. The OSF should then be able to retrieve the p-doc by sending the request again, without including the "incorrect" filing date. The document should not be sent at the first step to reduce the risk that a warning of mismatched dates is overlooked.

Dear all, Firstly, we do apologize for the delay in our answer.

In relation to the proposals "Change in Priority Request function", the OEPM would like to share with the group the following comments:(i) - Shall we put a restriction in the upload operation so that the priority filing dates are always provided and the system generates error if it is not the case.
We have no problem to provide DAS system with this data and we think we feel more confortable if it is checked upon reception. Tests are needed to make the OFF aware of the message generated and proceed to send the complete set of data.

(ii) - If we don’t implement the restriction for registering the priority document with its filing date (like the current situation), there are cases where the priority filing dates are not provided and therefore cross-check cannot be performed by DAS.

We fully agree with the comments made previously by Mr Richardson.

(iii) - Would there be cases where the priority filing dates get changed after DAS registration? If so, there should be a provision for the OFF to update the date record in DAS. The DAS system should notify OSFs which have already retrieved successfully the priority document about the date change. This is unlikely to happen because within the time window when a correction of the priority filing date may be made (e.g. two months) there would be no retrieval.

In the case of the OEPM, these cases are extremely rare, but we endorse WIPO's opinion.

Thanks and regards,

Gerardo Penas

Dear all,

In response to the comments from WIPO IB and the OEPM, the JPO considered DAS 2.0 business requirements further and would like to comment on it.

Please find the attached file below:

 20111228_DAS_2_0_JPOcomments_2.doc

Dear all,

The EPO would like to present you with its comments on the WIPO DAS 2.0 Business Requirements v1.0 dated 22/09/2011.
They are reflected in the attached files. Due to the fact that I can not create a link to the attached documents, please consult the Attachments section. The files are named as follows.

[edited by IB to insert links to file] 

File1- DAS_2.0_Requirements_revEPO_13-01-2012.doc

File2- Summary EPO position on DAS 2.0_13012012.docx

Thank you for your consideration.

Rachid

Dear all,

SIPO appreciates the efforts made by WIPO and all the participating Offices. We’d like to share with you SIPO’s comments on DAS 2.0 Requirements, which is expected to be provided much earlier. We are sorry to post our comments so late and I do apologize for any inconvenience this may cause.

1. SIPO supports IB’s proposal for a unified AC format of 4 numeric characters.
2. SIPO agrees with IB’s proposal for taking priority date as mandatory in the registration of p-doc in the future DAS 2.0.
3. In the future DAS 2.0, SIPO plans to issue AC ourselves.
4. SIPO shares the same idea with IB about the necessity of AC re-issuance and suggests that the mechanism of AC re-issuance should be detailed further. For example, whether it should be required that only the original Office which has issued AC has the rights to re-issue AC and to cover the original AC in the DAS system.
5. SIPO would like have a more definitive timetable about the pilot or implementation of DAS 2.0, so that SIPO could access the cost and labor involved in system upgrade.
6. SIPO suggests that the transition period should be shortened as possible as we can, so that the coexistence impact of various routes on applicants and Offices can be minimized.

Dear All,

Thank you very much for all your valuable comments. Please be advised that a revised version 2.0 of the Requirements document is posted for further comments (including a version with tracking changes). I would like to bring to your attention one remaining issue which requires further mitigation.

As suggested in the use-case “De-associate Documents with a WIPO Account” on page 11 of the revised version 2.0 of the DAS Requirements 2.0, it would be possible to deal with transfer of rights by using similar e-Ownership feature of the ePCT system in the Applicant portal. The account holder of a registered application would be able to transfer his application directly to another WIPO account without the need to re-generate a new access code and to notify OSF to which the access code has already been sent for retrieval.

Considering this suggested feature, do we still need an option to re-generate an access code? It would be advisable to avoid introducing additional administrative procedures at the OFF and the OSF to deal with changes of access codes.

Dear all,

KIPO would like to convey appreciations to IB and consultive groups for efforts and constructive comments to improve the DAS.

The following presents KIPO's commnets on the revised DAS 2.0 Requirement.

Thank you for your kind consideration.

Junseok

Dear All,

The EPO would like to thank WIPO and all the offices that are contributing in the definition of the business requirements for the DAS 2.0.

In the attached document, the EPO presents its views about the DAS 2.0 Business Requirements Revision 2.1 dated 2 February 2012.

Summary EPO position on DAS 2.0_rev2.1_final.pdf

Thank you for your consideration.

Dear Colleagues,

WIPO would like to thank you for your effort and valuable comments on the business requirements for the DAS 2.0.

WIPO understands that all current participating Offices namely AU, CN, DK, ES, GB, IB, JP, KR, SE and US do not intend to implement ACL as an optional and additional second level of security when migrating to the new Route. Considering the tight schedule for the development of DAS 2.0, WIPO would prefer revising the specifications by removing ACL related features. This would enable an early finalization of DAS 2.0 business requirements in order to build an initial release of DAS 2.0 without making use of the ACL. 

WIPO would consider the EPO’s proposal to introduce ACL as possible future enhancements. This would give Offices additional time to undertake further analysis and consultations on this matter in order to avoid making the system too complicated for most applicants who might not use it.This proposal to exclude the use of ACL in DAS 2.0 for the time being is based on a result of the internal discussion between WIPO and JPO.

The revised version 2.2 of the DAS 2.0 Requirementsdocument is posted for further comments (including a version with tracking changes)

WIPO would be very grateful if you would provide feedback on this proposal (by Monday March 19, 2012) and we apologize for this short notice.

WIPO woule like also to invite current participating Route A Offices (AU, CN, DK, ES, GB, IB and SE) and Route C Offices (JP, KR, US) to give their respective indicative migration dates. In this regard, WIPO IB aims to commence the new Route operation as of July 1, 2012.

Thank you for your consideration.

Dear Colleagues,

In order to clarify the use of the new access code by removing the need to setup ACL, WIPO would like to share the specifications of the new DAS 2.0 Applicant Portal and would be grateful if you would take it into consideration for review. Consequently, the requirements specification was updated in the review section of this page.

Thank you for your consideration.

Daniel Cheng

Dear all,
 
Thank you for your efforts and contributions in improving DAS specification.
 
Regarding the version of DAS 2.3, SIPO agrees with the removal of ACL and adjustment of AC format. Additionally, SIPO would like to remind that the ACL verification should also be removed in the diagram of use case “retrieve a priority document”.
 
Thanks and regards,
 
WANG Tao

Dear all,

Thank you for your efforts and contributions in improving DAS system.

Following is KIPO's comments on the revised version 2.3 of the DAS 2.0 Requirements.

First, concerning the Access Control Lists (ACL), KIPO agrees to its exclusion in DAS 2.0, as it would improve applicants’ convenience.

For the Access Code (AC), we support the use of the four-digit hexadecimal characters, which is comprised of only six upper-case letters (A to F) and ten numerals (0 to 9). As mentioned in the Technical Specifications (Revision 2.3), it would not matter if the AC would play a role as a check digit rather than a password control code used for managing access authorizations to accessing Offices. It would also have the added benefit of avoiding the risk of transcription errors resulting from characters of similar appearance.

Currently, however, KIPO is using randomly-selected ten-digit alphanumeric characters for the ACC and thus we will need to change our system when the four-digit hexadecimal character ACs are adopted as a new revision 2.3 of the DAS 2.0 Requirements Specifications.

With regard to the Applicant Portal, KIPO also supports the use of passwords for WIPO accounts to be defined by each applicant and be different than the AC above. In this case, there would be no problem with the use of the AC to be shared among multiple co-applicants using the e-handshake of the ePCT system.

In addition, as the Office of Second Filing, KIPO will need to change its business process and related form of receiving the AC from applicants when introducing the new revision of DAS.

Finally, more information concerning the timeline and detailed specification for DAS 2.3 needs to be shared for our internal review and discussion.

Thank you.

Jun

Dear Colleagues,

The USPTO would like to thank you WIPO and all the Offices for the contributions in this requirement effort.  Attached below are the USPTO's comments.  Thank you for your feedback and consideration.

1. USPTO as OFF will support the document exchange for Patent and Design documents.  Please note that our Design document numbers start with “29” series (e.g., 29123456).  In addition, the USPTO supports the xml-tagging for the IP type, e.g., Industrial Design.
2. USPTO will only support gray-scale format (no color) for document exchange, but in the future, the USPTO will strongly consider to be exchanging color documents and drawings.
3. USPTO will not support the document exchange for Trademark documents per DAS 2.0 effort.  USPTO is open for discussion to expand Trademark documents for priority document exchange as a possible enhancement.
4. USPTO as OFF will continue to generate the access code which consists of 4-digit numeric code.  This will be consistent with the current process.
5. Please clarify what data elements are mandatory and optional to perform Registration by the OFF.  Specifically, it is not clear to the USPTO whether Priority Filing Date is mandatory.
6. (Per WIPO):  Please confirm that the metadata sent by the OFF for Registration will remain confidential.
7. Please clarify what data elements are mandatory and optional in the PDRequest sent by the OSF.
8. The proposed new status messages (e.g., “Application number and filing date mismatch” and “Application number and access code do not match”) provide specific details about the document.  Due to the applicant’s confidential policy, the USPTO would like to propose using the existing status message of “Application number does not correspond with bibliographic data.” to satisfy these messages. 
9. Proposal consideration for DAS 2.0 enhancement to identify which OSF (member state) is requesting the document.  This information will be useful to the OFF for tracking and reporting statistic purposes.
   1. As an alternative to the above proposal, the IB could maintain and report on monthly statistics on requests by OSF’s.  For example, the USPTO would receive a report from the IB stating that GB requested 450 documents; FI requested 22 documents, etc.  If the OFF needs additional details about this statistic, the IB will provide additional details.
10. The USPTO accepts an SB39 from applicants who intend to allow the USPTO to make unpublished documents available to Offices of Later Filing.  If an application publishes, but there is no SB39, the USPTO will not have any indication that the document should be registered.  It is the proposal of the USPTO to register all documents that publish and that have not been previously registered.  Does the IB have any concerns with this proposal?
11. The USPTO agrees with the IB proposal for updating the metadata information including, but not limited to priority filing date, after registration.  The USPTO assumes at this change will be recognized as an update request by the IB because the original ACK-ID and Application Serial Number will be provided by the OFF.  Is this assumption correct?

Dear All,

the EPO would like to thank WIPO for this new revision 2.3 of the DAS 2.0 Requirements Specification.

In particular, the EPO welcomes the newly introduced requirement regarding the format of the Access Code, which should be hexadecimal that should reduce transcription errors.

However the EPO regrets that the optional implementation of a default Access Control List (ACL) was removed in this last revision.

The EPO would like to be able to implement such a default ACL for its own implementation of WIPO DAS 2.0 as the default ACL is considered as providing a second-level of security, as well as a means for empowering further the applicant with the possibility to disseminate or not his priority document. Likewise, the EPO may wish at a later date to vary the default ACL from its initial setting.

Within these circumstances, the EPO will regretfully not be in a position to implement WIPO DAS 2.0 as specified in revision 2.3. However, the EPO welcomes the intention of WIPO to implement the default ACL feature as a future enhancement of the WIPO DAS 2.0. The EPO looks forward to being able to participate with the definition of the ACL enhancement in a near future.

Kind regards,

Dear All,

The JPO would like to thank WIPO for its coordination towards implementation of DAS2.0.  Please be informed that the JPO is tentatively scheduled to migrate to DAS2.0 around April, 2013.  We are sorry for our delayed comments, but we would like to indicate the following minor points for the sake of clarification and in order to keep consistency between documents.

1. We have noticed a minor discrepancy as a result of reviewing the recently presented Applicant Portal Functional Specifications.

The Applicant Portal Functional Specifications says, "After migration, the old access codes should be supplied to accessing Offices to retrieve priority documents that were registered by Offices under the old Route A or C."  However, the JPO has so far assumed that even before migration of all the Offices to DAS2.0, access codes under the old Route A or C　are given by applicants to some OSFs which have migrated to DAS2.0 in advance of other Offices and then included in such OSFs’ request messages to DAS when they retrieve a priority document so that the access codes may be used by the DAS System for cross-checking.  Is this the JPO’s assumption right?

This assumption is based on the following ground although it is not explicitly described in the DAS2.0 Business Requirements:

There is a description that "The system displays the access control list and allows the Applicant to add or remove Offices (OSF) from the list. Only participating offices are shown but changes are disabled for Offices which have already migrated to the new Route (e.g. checkboxes being grayed out)." in 2. of the paragraph of Create and/or Change Access Lists on p.12 of the Requirements.

If the aforesaid recognition is wrong, it will become impossible to perform cross-checking by the use of an access code in the DAS System and in consequence, neither security assurance by ACL nor cross-checking with the use of an access code will be provided to applications filed with OFFs under the old Route A or C against accesses by OSFs which have migrated to DAS2.0 ahead of other Offices during the migration period.

If the JPO’s recognition is correct, perhaps it had better be specified in the DAS 2.0 Business　Requirements.  In that case, how about noting that there is a possibility that old access codes (a maximum of 10-digit alphanumeric characters) may be received from applicants by OSFs?

2. The JPO agrees to an idea that access codes should be regarded as check digits rather than passwords.　 During the migration period, however, if implementation of DAS2.0 is premised on the assumption stated in the above 1., access codes which are passwords for log-ons to Applicant Portal in DAS1.0 will play the same role as access codes in DAS2.0 (a kind of check digits rather than a password control code).  The JPO considers it is inevitable.

3. Differences between Applicant Portal 1.0 and Applicant Portal 2.0 are ambiguous. 

 Selection of Priority Document is described in 1. of the paragraph of Create and/or Change Access Lists on p.12 of the Business Requirements document.  This is associated with an idea that there are some connections between accounts and priority documents and resultantly the portal seems to refer to Portal 2.0.  Meanwhile, in 2. of the said paragraph, Access Control List is mentioned.  So the portal also appears to refer to the old Applicant Portal 1.0.

4. SIPO’s comment as of March 23 has made us aware that there is still a description of default ACL in 3. of ISSUES on p.9.  The JPO is afraid that the description has not been deleted by mistake although essentially it should be deleted.

5. On p.2 of the Applicant Portal Functional Specifications, it is written that “After migration, the old access codes should be supplied to accessing Offices to retrieve priority documents that were registered by Offices under the old Route A or C."  We wonder why Applicant Portal 2.0 cannot be implemented prior to migration of all Offices to the new route.

Best regards,

Yoshiaki Kodachi