Skip to end of metadata
Go to start of metadata

Summary

The Third Session of the DAS Working Group held from July 12 to 14, 2011 in WIPO gave the mandate to the International Bureau to implement the extension and improvements of DAS as summarized in the Summary by the Chair (Document WIPO/DAS/PD/WG/3/7).

The requirement specifications relating to the extension and improvements of DAS (2.0) is posted in this page for reviews by the DAS Consultative Group.
Some changes relating to DAS exchange betwwen Offices over the TDA/PDX and PCT-EDI protocols will be required to support Route D. Proposal for changes in TDA/PDX will be discussed through the TDA forum. PCT-EDI related changes are discussed below.

Review of DAS 2.0 requirements specification

The requirements specification was finalized and posted on April 10, 2012 with the revision 2.4 (version with tracking changes). It includes a few minor corrections by removing two inappropriate descriptions of ACL. The specifications (revision 1.0) of the DAS 2.0 Applicant Portal was made available.

Proposed implementation timelines from 2012 to 2013

The International Bureau would like to propose the following revised timelines for the implementation DAS 2.0. Current participating Offices are welcome to comment on the proposed timelines and on the migration plan of each inividual Offices.

System Component

Specifications Review

Office and End-user Testing

Production Release

Route D migration in respect of DAS TDA/PDX (e.g. 1.7.3) for patent applications only A new change request to add a dasRegister operation needs to be raised in the TDA forum.

June 29, 2012

2013

2013

Route D migration in respect of DAS PCT-EDI protocol for all types of applications including (Industrial Designs, Patents, Trademarks and Utility Models)

February16, 2012

from March 1, 2012 to June 22, 2012

July 1, 2012

Account-based Applicant portal for Industrial Designs, Patents and Utility Models applications (Trademark applications are not supported by the portal)

February 16, 2012

September 2012

When Route C Offices migrate to the new Route

The proposed change and schedule support backward system compatibility for Routes "A" and "C" Offices and would allow the Offices to implement the changes at their own pace.

Improvements released in January 2012

The following changes were released in January 2012.

Security Improvements

DAS security improvements to add cross-check of the priority filing date were released in January 2012 and supported by exchange via TDA/PDX 1.7.2 and PCT-EDI.

System Component

Office Testing

Production Release

DAS upgrade to TDA/PDX 1.7.2

from September 12, 2011 to December 28, 2011

January 4, 2012

DAS PCT-EDI changes to generate error code ='-4' in response due to mismatch of priority filing date (library-transaction-v1-2.dtd)

from October 24, 2011 to December 28, 2011

January 4, 2012

The proposed change and schedule support backward system compatibility for "Route A" Offices and would allow the Offices to implement this upgarde individually.

Change in Priority Request function

The security improvement brings in an additional check to ensure correctness of the priority filing date, if it is provided by the requesting Office (OSF) during the Priority Document request. 

The current Route C Offices (JP, KR and US) would be moving to a new version TDA/PDX 1.7.2 starting next year (04-JAN-2012) to implement this cross-check as OFF whenever applicable and to supply the priority filing date as OSF.

The change taking into account comments posted by the JPO on November 11, 2011 will be made as follows:

In respect of priority documents held in WIPO for current Route A Offices (AU, ES, DK, FI, GB, IB, SE), the following conditions apply:

- DAS holds the priority filing date with the priority document, the DAS core system will perform the cross check:

  • (a)  - If the OSF supplies a wrong priority filing date, retrieval will not be allowed and the OSF will receive an appropriate response error specific to protocol TDA (i.e. status 13) or EDI (error -4).
  • (b) - If the OSF does not provide any priority filing date, no cross check will be performed by DAS.

- DAS does not hold the priority filing date with the priority document, the DAS core system will not perform this cross check.

 The IB would like to suggest the following for your consideration:

  • (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.
  • (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.
  • (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. 

With regard to priority documents held in Route C Offices (JP, KR and US), the following conditions apply:

- If DAS holds the priority filing date, the cross-check as mentioned in (a) and (b) apply

- If DAS does not hold the priority filing date, the cross-check will be performed by the depositing Office.

Comments made by Offices have been included in the revised versions of the requirements specification of DAS 2.0.


  • No labels

19 Comments

  1. Dear all,

    The JPO immensely appreciate the efforts by WIPO IB. The JPO agrees with the basic direction of DAS 2.0 proposal.

    Please find our commnets on the requirement specifications in the attached file below:

    DAS_2_0 JPOcomments.doc

  2. 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.

  3. 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.
  4. 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

  5. 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

  6. 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

  7. 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.
  8. 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.

  9. 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

     No

    Subject

    Comment

    KIPO-1

    Extension

    KIPO will support for patent and utility models via DAS 2.0.
    (In order to implement the adoption of TM and design, KIPO needs an internal review considering discussions in WIPO IB)

    KIPO-2

    Improvements

    1. KIPO supports the new route in that it simplifies the system from the applicants’ viewpoint.
    2. KIPO agrees that the new route provides the required levels of security and confidence in the system.
    3. KIPO agrees the removal of the concept of “publicly available”.  
    4. To enhance the simplicity of new system, it should guarantee the security only with default setting without the using of applicant portal.

    KIPO-3

    Operation of the new route under DAS 2.0

    KIPO will issue the AC as an OFF.
    (KIPO currently uses Route C and issues the AC.)

    KIPO-4

    Transition Requirements

    1. KIPO wants to adopt the DAS 2.0 soon. However, there may be some delays due to the budget limitation.(KIPO will check the schedule plan for DAS 2.0.)
    2. KIPO will issue the AC as an OFF, and notify it to applicant and also to DAS through metadata.
    3. To accept the AC from applicant, KIPO needs to check related internal regulations and change format, program and required messages.

    KIPO-5

    Security Mechanism

    1. KIPO understands the existing route and the new route will co-exist for the transition period. And in KIPO, the ACL will be managed by applicants during the transition period.
    2. After KIPO adopt the DAS 2.0, KIPO will check the AC and the priority filing date without ACL.

    KIPO-6

    Register a Priority Document

    1. KIPO as an OFF will not store the priority document on DAS. And the priority document will be provided to DAS in response to its request. (as Pdresponse for the Pdrequest)
    2. KIPO agrees to create the unique messages for each error to allow the problem to be understood and resolved more efficiently.
    3. KIPO agrees that the code generated should consist of exactly 4 alphanumeric characters, case insensitive [0...9,a..z]. (Currently KIPO generates the AC with 10 alphanumeric characters.)
    4. KIPO will issue the AC only to the applicant who requests it through electric and/or paper form.
    5. KIPO agrees that once the AC is issued, it will not be changed in its lifetime.)
    6. KIPO will cross-check the priority date on the Pdrequest message from DAS. So, KIPO need not notify the changed priority date to DAS, right?

    KIPO-7

    Applicant Portal

    1. KIPO does not set the default ACL.
    2. As OFF, KIPO will provide the AC to applicant and DAS at the same time.
    3. As OFF, KIPO will cross-check the AC with the Pdrequest message.
    4. If KIPO receives the unique error message, KIPO will notify it to applicant and/or the agent.
    5. If the applicant portal is operated based on the account, AC should not be used for password.

    KIPO-8

    Issues

    1. KIPO needs the detail description for the e-handshake replacing the AC regeneration.
    2. In order to secure the budget, KIPO needs the detail description of new TDA protocol to adopt the DAS 2.0.
    3. For the accelerated adoption of DAS 2.0, KIPO needs to be informed on the schedule and other offices’ plan.
  10. 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.

  11. 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.

  12. 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

  13. 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

  14. 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

  15. 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?
    1. Dear Colleagues,

      Thank you for the USPTO comments.

      The IB understands that the USPTO comments #1 to #4 do not require further clarification.

      Following clarifications are in response to other USPTO comments:

      #5. The IB is in agreement that in the business requirements specification, it is necessary to mention the need of implementing the DAS registration operation which should contain the minimal set of application details including IP type, priority office code, priority application number, priority application filing date and access code if it is generated by the OFF. If the access code is to be generated by WIPO-DAS, the applicant’s email address must be provided as part of the registration metadata. But other implementation details should be covered by the specific exchange protocol specifications such as TDA 1.7.3 or PCT-EDI for DAS.

      #6. The IB confirms that the registration details mentioned above will remain confidential and will only be made visible to applicants who associate the document in his/her WIPO account via the DAS applicant portal. For that, he/she will need to provide the matching information: priority application number including office code, priority application filing date and access code.

      #7. As per business requirement, paragraph #2 on page 14 specifies the required details. Specific element used in PDRequest will be discussed in the TDA 1.7.3 specification and the IB has made some suggestions in this regard.

      #8. Assuming that the right applicant has successfully associated the document with his/her WIPO account via the DAS applicant portal, the suggested messages (e.g., “Application number and filing date mismatch” and “Application number and access code do not match”) on page 12 and 14 are intended to inform him/her about an Office attempting to retrieve the document but it failed. It is important to inform the applicant or the OSF of what went wrong in a retrieval attempt to clearly identify the problem. In this context, this confidentiality issue does not apply.

      On the other hand, if the same mismatch occurs while the applicant attempts to associate the document with his/her account, it would be appropriate to make the message more generic as suggested.

      #9 in the current exchange protocol TDA 1.7.2 and PCT-EDI for DAS, the OSF information is provided by DAS to the OFF. Especially for TDA PDRequest, the element requestor/role contains the two letter office code of the OSF, the element requestor/iid contains ‘IB’ if the request is sent by WIPO-DAS and the element requestor/orgname contains the two letter country code of the OFF.

      #10 The IB is in agreement with the USPTO proposal to register all published US applications. But we understand that even tough the application is published, the retrieval access is still based on the matching access code and priority filing date.

      #11 Because this is specific to the TDA protocol, the IB would like to discuss it in the TDA 1.7.3 specification. However, we would like to suggest for tracking purposes that WIPO-DAS  would issue a distinct ACK-ID for each dasregister operation.

      Best Regards

  16. 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,

  17. 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

    1. Dear Colleagues,

      The IB would like to thank all Offices for providing comments on the revision 2.3 of the DAS requirements specification.

      The IB would like to add the following clarification in response to the JPO comments in this regard.

      #1 and #2 The IB is in agreement with the JPO comments to add a note to the specification to indicate the possibility for OSFs to receive from applicants old access code having a maximum of 10-digit alphanumeric characters

      #3 The IB would like to avoid adding too many details in the requirements specification relating to the technical implementation by offering either an upgraded version of the current Applicant Portal without making use of user account or the new Applicant Portal which requires WIPO account creation. Before commencing operation with the new Applicant Portal, the IB would need to initiate automatic WIPO account creation based on all registered email addresses, which would request those email address owner to set their account password.

      It is noted that the old and new access codes are designed for different purposes: the old one is considered as a kind of password used to manage ACL whereas the new one becomes simply a check digit.

      The IB would like to make a clear cut-off from (i) the transitional period which requires the use of old access codes to setup ACL for routes A and C Offices, to (ii) all Offices operating under the new Route without making use of the ACL.

      To this end, the IB would upgrade the current Applicant Portal to offer minor enhancement relating to the management of ACL as described in “Create and/or Change Access Control List (during the transition period)”. After all Offices migration, there will be no need to manage ACL the new portal becomes much simpler and access codes are made visible to WIPO account holders.

      #4 The IB would remove the description of default ACL.

      #5 Please refer to the clarification provided in #3.

      Thank you for your understanding