About Intellectual Property IP Training IP Outreach IP for… IP and... IP in... Patent & Technology Information Trademark Information Industrial Design Information Geographical Indication Information Plant Variety Information (UPOV) IP Laws, Treaties & Judgements IP Resources IP Reports Patent Protection Trademark Protection Industrial Design Protection Geographical Indication Protection Plant Variety Protection (UPOV) IP Dispute Resolution IP Office Business Solutions Paying for IP Services Negotiation & Decision-Making Development Cooperation Innovation Support Public-Private Partnerships The Organization Working with WIPO Accountability Patents Trademarks Industrial Designs Geographical Indications Copyright Trade Secrets WIPO Academy Workshops & Seminars World IP Day WIPO Magazine Raising Awareness Case Studies & Success Stories IP News WIPO Awards Business Universities Indigenous Peoples Judiciaries Genetic Resources, Traditional Knowledge and Traditional Cultural Expressions Economics Gender Equality Global Health Climate Change Competition Policy Sustainable Development Goals Enforcement Frontier Technologies Mobile Applications Sports Tourism PATENTSCOPE Patent Analytics International Patent Classification ARDI – Research for Innovation ASPI – Specialized Patent Information Global Brand Database Madrid Monitor Article 6ter Express Database Nice Classification Vienna Classification Global Design Database International Designs Bulletin Hague Express Database Locarno Classification Lisbon Express Database Global Brand Database for GIs PLUTO Plant Variety Database GENIE Database WIPO-Administered Treaties WIPO Lex - IP Laws, Treaties & Judgments WIPO Standards IP Statistics WIPO Pearl (Terminology) WIPO Publications Country IP Profiles WIPO Knowledge Center WIPO Technology Trends Global Innovation Index World Intellectual Property Report PCT – The International Patent System ePCT Budapest – The International Microorganism Deposit System Madrid – The International Trademark System eMadrid Article 6ter (armorial bearings, flags, state emblems) Hague – The International Design System eHague Lisbon – The International System of Appellations of Origin and Geographical Indications eLisbon UPOV PRISMA Mediation Arbitration Expert Determination Domain Name Disputes Centralized Access to Search and Examination (CASE) Digital Access Service (DAS) WIPO Pay Current Account at WIPO WIPO Assemblies Standing Committees Calendar of Meetings WIPO Official Documents Development Agenda Technical Assistance IP Training Institutions COVID-19 Support National IP Strategies Policy & Legislative Advice Cooperation Hub Technology and Innovation Support Centers (TISC) Technology Transfer Inventor Assistance Program WIPO GREEN WIPO's Pat-INFORMED Accessible Books Consortium WIPO for Creators WIPO ALERT Member States Observers Director General Activities by Unit External Offices Job Vacancies Procurement Results & Budget Financial Reporting Oversight

WIPO 서열 검증기 작업 매뉴얼

WIPO Sequence Validator (이하 '검증기' 또는 '도구'로 칭함)의 주요 목적은 각 특허청 (IPOs) 에 WIPO ST.26 형식의 XML 파일을 검증하기 위한 웹 서비스를 제공하여 XML 파일이 WIPO 표준 ST.26을 준수하는지 확인하는 것입니다. WIPO Sequence 데스크탑 응용 프로그램을 사용하여 작성된 서열목록은 WIPO ST.26을 준수하지만, 사용자는 XML을 생성하기 위해 가장 적합하다고 생각하는 도구를 사용해도 됩니다.

이 문서의 목적은 다음 섹션에서 자세히 설명하는 도구의 빌드, 배포, 설정 및 파일 사용자 시스템에 대해 설명하는 것입니다.

본 매뉴얼은 3.0.0 버전에 한해 유효합니다.

1. 워크플로우

이 도구는 다음과 같은 네 가지 사용 사례를 제공합니다:

  1. WIPO ST.26 파일의 검증.
  2. 실행 중인 검증 상태 요청.
  3. 환경설정 파일 업데이트 (특허청 관리자만 해당).
  4. 검증 프로세스 완료 시 검증 프로세스 결과가 포함된 콜백 엔드포인트 호출.

참고: 이 콜백 엔드포인트는 Validator의 범위를 벗어납니다.  엔드포인트를 설정하는 것은 이 서비스를 개발하고 설정하는 각 특허청의 책임입니다.

WIPO ST.26 서열목록의 검증을 위해 이 도구는 폴더 구조에 있는 XML 인스턴스를 사용하여, 검증 프로세스를 실행하고 검증 결과가 포함된 검증 보고서를 생성합니다. 선택 사항으로, 콜백 엔드포인트를 호출하여 이 검증 보고서를 반환합니다.

검증기의 주요 워크플로우는 다음과 같습니다:

  • 각 특허청 IT 시스템에서 XML 파일은 기본설정인 "받은문서" 폴더 또는 원하는 지정 폴더에 저장됩니다.
  • 특허청 시스템은 파일의 검증을 요청하는 HTTP Post를 시작합니다. 환경 설정에 따라, 특허청 시스템은 파일의 "전체" 또는 "형식" 검증을 요청할 수 있습니다. "형식" 검증 프로세스는 ST.26 파일이 XML 파일인지 확인하고 ST.26 DTD와 비교하여 파일의 유효성을 확인합니다. "전체" 검증 프로세스는 "형식" 검증 프로세스를 수행할 뿐 아니라 ST.26 의 내용에서 파생된 업무 검증 규칙에 따라 ST.26 파일을 검증합니다.

참고: "형식" 검증 프로세스는 동시에 수행될 수 있으므로 온라인 제출 접수 시스템에만 사용할 것을 권장하는 반면 "전체" 검증은 시간이 훨씬 더 소요되기 때문에 배치 프로세스에 사용하는 것을 권장합니다.

  • 검증이 완료되면, 파일이 "형식" 검증을 통과했는지 여부와, 특허청 IT 시스템이 "전체" 검증을 선택한 경우 추가로 업무 규칙 검증 프로세스가 올바르게 시작되었는지 여부를 나타내는 응답이 제공됩니다.
  • 검증기가 "전체" 검증을 수행 중인 경우, "Inbox" 폴더에서 XML 파일을 검색하여 비즈니스 규칙 검증 처리를 시작한 후 다음을 수행합니다:
  • 검증기는 지정된 "출력" 폴더에 XML 보고서 파일 ("검증 보고서")을 생성하고 검증된 WIPO ST.26 XML 파일을 "보낸문서" 폴더로 이동합니다.
  • 업무 규칙 검증 처리가 완료되면, 콜백 엔드포인트가 구성된 경우 검증기에서 호출되고, 검증 처리와 관련된 부가적인 정보가 요청에 추가됩니다. 요청의 구조와 일부 샘플 데이터는 아래 섹션 2.2에 제공됩니다.
  • 콜백 엔드인트는 응답으로 빈 코드 또는 성공 코드를 반환해야 합니다 (오류 없음). [참고: 이 단계는 외부 웹 서비스가 가능해졌고 호출이 검증기에서 구성된 경우에만 실행됩니다.] 검증기와 콜백 엔드포인트 간의 연결도 필요합니다.  위에서 언급한 바와 같이, 외부 웹 서비스는 검증기의 일부를 구성하지 않으며 아래 명시한 계약에 따라 각 특허청이 개발 및 구성해야 합니다.
  • 특허청 시스템은 "Report" 폴더에서 검증 보고서를 검색할 수 있습니다.

2. 배포

1단계: 유형 선택하기

앞서 살펴본 바와 같이, 검증기는 두 개의 바이너리 형식 중 하나로 제공됩니다: 웹 서비스로서 실행될 수 있는 JAR 파일 형식 또는 Tomcat 서버에서 실행될 수 있는 WAR 파일 형식. 특허청이 검증기를 배포하려는 인프라 유형에 따라, 특허청은 두 유형 중 한 유형의 바이너리의 선택을 선호할 수 있습니다.

검증기로서 제공되는 2개의 바이너리는 다음과 같습니다:

  • 바이너리 SpringBoot JAR: 이 바이너리는 실행 가능한 JAR 파일입니다. 이를 실행하기 위해서는 Java 17이 설치되어 있어야 합니다.
  • War 패키지 바이너리: 이 바이너리는 Servlet 컨테이너 상에 배포하기 위한 것입니다. Spring Boot 3.1.0 및 Servlet Spec 4.0.1 과 호환되는 Tomcat 10과 같은 응용 프로그램 서버가 필요합니다.

다음 섹션은 Spring Boot app 또는 Java 응용 프로그램 서버 내의 WAR로 검증기를 배포하는 방법을 자세히 설명합니다.

Spring Boot JAR에는 임베디드 서버가 포함되어 있어 별도의 서버 없이도 검증기 API를 배포할 수 있습니다. 이는 IT 인프라 차원에서 구성 및 배포를 크게 간소화합니다.

임베디드 서버를 실행하려면, 이미 Java 17이 서버에 설치된 상태에서 다음 명령을 실행하십시오.

java -jar wipo-sequence-validator.jar

Java가 UTF-8의 사용을 보장하지 않으므로, 시스템 속성 “file.encoding”이 "UTF-8"로 설정되어야 합니다. 기본적으로 서버는 8080 포트에서 실행되며, 포트를 변경하려면 아래와 같이 “--server.port” 명령줄 옵션을 추가하십시오. 다음을 포함하여 수행할 수 있습니다:

java -D"file.encoding=UTF-8" -jar wipo-sequence-validator.jar –-server.port=<port-number>

검증기 API는 JAR 파일을 배포한 후 Swagger UI 를 통해 액세스할 수 있으며, 특허청은 이 단계에서 다음과 같이 변경하십시오: [host-name] 을 반드시 서버 호스트 이름으로 대체하십시오.

 http://[host-name]:8080/wipo-sequence-validator/swagger-ui/index.html

검증기 API는 다음 엔드포인트에서 액세스할 수 있습니다:

  • GET Method: 
    http://[host-name]:8080/wipo-sequence-validator/api/v2.0/status/validationId
  • POST Method: 
    http://[host-name]:8080/wipo-sequence-validator/api/v2.0/validate

기본적으로 검증기는 Java Virtual Machine (JVM) 기본 메모리 설정을 사용합니다. 기본 최대 힙 크기는 사용 가능한 실제 메모리의 1/4입니다. 최대 힙 크기를 수정하려면, 명령줄을 사용하여 실행할 때 “-Xmx” 옵션을 사용해야 합니다.

java -D"file.encoding=UTF-8" -Xmx[size]-jar wipo-sequence-validator.jar

예를 들어 운영 체제에서 관리하는 서비스로 검증기를 설치하여 운영 체제 시작과 함께 실행을 지원할 수도 있습니다. WIPO Sequence에서 지원하는 모든 플랫폼, 즉, Windows, Linux 및 Mac OS에 대해 이러한 방식으로 Spring Boot JAR 파일을 구성할 수 있습니다:

다음 안내서 는 각 운영 체제별로 JAR 파일을 실행하는 시스템 서비스를 생성하는 방법에 대한 세부 사항을 제공합니다. 또한 서비스의 다양한 옵션과 응용 프로그램의 실행을 구성하는 방법에 대한 정보를 제공합니다.

제공된 두 번째 바이너리 유형의 경우, WAR 패키지는 Apache Tomcat 10과 같은 기존 Java 응용 프로그램 서버에서 배포될 수 있습니다. 참고: Servlet 4.0.1과 호환 가능한 컨테이너가 필요합니다.

다음 지시 사항은 Tomcat 응용 프로그램 서버용입니다. 여기서,

$TOMCAT_ROOT

는 Tomcat 서버의 루트 폴더를 가리키며, 이 값은 파일 경로의 관련 값으로 대체되어야 합니다.

  • 서버 중지:
    $TOMCAT_ROOT\bin\catalina.bat stop
  • war 복사
    $TOMCAT_ROOT\webapps\wipo-sequence-validator.war
  • 서버 시작:
    $TOMCAT_ROOT\bin\catalina.bat start
참고: Java가 UTF-8 사용을 보장하지 않으므로, 시스템 속성 "file.encoding"은 응용 프로그램 서버 시작 시 "UTF-8" 로 설정되어야 합니다. 이 작업은 다음을 포함하여 수행됩니다: -D"file.encoding=UTF-8"

검증기 API는 위에 표시된 것처럼 Swagger UI를 통해 액세스할 수 있습니다:

http://host-name:8080/wipo-sequence-validator/swagger-ui/index.html

검증기 API는 다음 엔드포인트에서 액세스할 수 있으며, 여기서 [host-name]을 서버 호스트 이름으로 대체해야 합니다:

  • GET 방법:
    http://[host-name]:8080/wipo-sequence-validator/api/v2.0/status/validationId
  • POST 방법:
    http://[host-name]:8080/wipo-sequence-validator/api/v2.0/validate 

기본적으로 서버는 포트 8080에서 실행됩니다. 이를 다른 포트로 변경하려면 여기에 제공된 지침에 따라 Tomcat 구성 파일을 수정해야 합니다:

https://tomcat.apache.org/tomcat-10.0-doc/config/index.html

기본적으로 검증기는 JVM 기본 메모리 설정을 사용합니다. 기본 최대 힙 크기는 사용 가능한 물리적 메모리의 4분의 1입니다.

최대 힙 크기를 수정하려면 에 표시된 대로 명령줄을 사용하여 실행할 때 "-Xmx" 옵션을 사용해야 합니다.

2단계: 폴더 시스템 설정

검증기에서 사용하는 파일 시스템의 구조는 5개의 주요 폴더로 구성됩니다:

  • "받은 문서" 폴더: 이 폴더는 검증을 위해 특허청에서 WIPO ST.26 파일을 제공하는 로컬 폴더입니다.
  • - "처리" 폴더: 이 폴더는 "받은 문서"에 있는 파일을 처리하는 동안 일시적으로 통과하는 로컬 폴더 입니다. 이 폴더에는 두 개의 하위 폴더가 있습니다:
    • "전체 검증" 폴더: 전체 검증을 대기 중인 파일을 저장합니다.
    • "형식 검증" 폴더: 형식 검증을 대기 중인 파일을 저장합니다.
  • "보낸 문서" 폴더: 검증이 완료되면, 응용 프로그램은 이 로컬 폴더에 WIPO ST.26 파일의 소스를 저장합니다.
  • "보고서" 폴더: 이 폴더는 검증 결과가 검증 보고서 파일에 저장되는 로컬 폴더입니다.
  • "매개변수" 폴더: 이 폴더는 비동기 심층 검증 프로세스에 대한 매개변수를 제공하기 위해 검증 요청의 모든 검증 매개변수가 포함된 JSON(.json) 파일이 있는 로컬 폴더입니다.

파일 시스템 구조의 예는 다음과 같습니다:

폴더 구조 설정 예시

3단계: 테스트

검증기 서비스 테스트는 다음 단계에 따라, postman을 사용하여 수행할 수 있습니다:

    • postman 응용 프로그램을 열고 새로운 요청을 생성합니다.
    • 요청 본문 정보를 추가합니다: postman_testing
    • "보내기"를 클릭한 후, 응답은 다음과 같아야 합니다: postman_response

3. 요청

콜백 엔드포인트 요청

검증 요청이 완료되면, WIPO 서열 검증기는 콜백 엔드포인트 요청에 필요한 매개변수가 포함된 JSON 파일을 생성합니다. 요청에는 파일 위치 및 유효성 검증 절차를 자세히 설명하는 다음 매개변수가 포함되어야 합니다:

{ "currentApplicationNumber": "string", "currentSEQLVersionNumber": "string", "patentApplicationNumber": "string", "seqlInputLocation": "string", "verificationReportOutputPath": "C:/temp/st26/reports/", "nameFile": "valid2Warning.xml", "type": "FULL" }

검증 요청의 "seqlInputLocation" 필드는 검증할 XML 서열 목록의 경로를 표시하도록 설정해야 합니다.. 특허청에서 이 필드를 빈 칸으로 남겨두면 이 도구는 기본 "Inbox" 폴더에 위치한 파일명 "nameFile"을 사용하여 XML 파일 검증을 시도합니다. "nameFile" 매개변수는 검증할 서열 목록 파일을 식별합니다.

요청 내의 "verificationReportOutputPath"는 도구로 생성된 검증 보고서 (.xml)의 파일 위치를 제공합니다. 사용자가 입력란을 비워 두거나 유효하지 않은 파일 경로를 입력하면, 검증 보고서는 기본 "보고서" 폴더에 저장됩니다.

"api.URL" 속성이 구성된 경우 검증기는 검증 결과를 지정된 URL이 있는 엔드포인트로 보내려고 시도합니다.

검증기와 통신하기 위해 콜백 엔드포인트는 이 웹 서비스 계약(YAML)을 준수해야 합니다.

또한 요청은 이 구조를 갖는 JSON 객체여야 합니다:

{ "currentApplicationNumber": "string", "currentSEQLVersionNumber": "string", "elapsedTime": 0, "endTime": "string", "errorSummary": [ { "dataElement": "string", "detectedSequence": "string", "index": 0, "key": "string", "locmessage": "string", "params": { "additionalProp1": "string", "additionalProp2": "string", "additionalProp3": "string" }, "paramsForXML": [ { "key": "string", "value": "string" } ], "reportValue": "string", "sequenceIDNumber": "string", "type": "string" } ], "httpStatus": "string", "parentApplicationNumber": "string", "parentSEQLVersionNumber": "string", "processID": "string", "seqIDQuantity": 0, "seqInputQuantity": 0, "seqlType": "string", "startTime": "string", "totalErrorQuantity": 0, "totalWarningQuantity": 0, "verificationReportOutputPath": "string"

이것은 검증기를 호출한 외부 엔드포인트로 보낼 JSON 객체의 예시입니다:

{ "processID": "1608194222169dvVE", "seqlType": "ST.26", "httpStatus": "SUCCESS", "currentApplicationNumber": "string", "currentSEQLVersionNumber": "string", "parentApplicationNumber": "string", "parentSEQLVersionNumber": "string", "verificationReportOutputPath": "C:/temp/report.xml", "startTime": "2020-12-17 09:36:54.000000", "endTime": "2020-12-17 09:37:26.000607", "elapsedTime": 32607, "totalWarningQuantity": 1, "totalErrorQuantity": 2, "seqInputQuantity": 3, "seqIDQuantity": 3, "errorSummary": [ { "index": 0, "reportValue": "", "type": "WARNING", "params":com.wipo.st26.ipotool.models.ServiceRequest@5887858, "key": "X_EARLIEST_PRIO_APPLICATION_ID_MISSING", "locmessage": "Earliest priority application information is absent. It must be provided when a priority claim is made to an earlier application.", "detectedSequence": "", "dataElement": "PROPERTY_NAMES.EARLIEST_PRIORITY_APPLICATION" }, { "index": 0, "reportValue": "-", "type": "ERROR", "params": {}, "key": "INVENTION_TITLE_MISSING", "locmessage": "The invention title is missing. At least one invention title must be entered.", "detectedSequence": "", "dataElement": "PROPERTY_NAMES.INVENTION_TITLE_BAG" }, { "index": 1, "reportValue": "-", "type": "ERROR", "params": {}, "key": "INVENTION_TITLE_MISSING", "locmessage": "The invention title is missing. At least one invention title must be entered.", "detectedSequence": "", "dataElement": "PROPERTY_NAMES.INVENTION_TITLE_BAG" } ] }

4. 보고서

검증 보고서

WIPO 서열 생성된 검증 보고서는 XML 형식이며, 선택적으로 WIPO 서열에서 사용되는 것과 동일한 스타일시트를 사용하는 HTML 형식이며, 루트 레벨에서 표시되는 속성은 다음과 같습니다:

  • "applicationNumberText": 이 서열 목록과 연관된 응용 프로그램
  • "productionDate": 검증이 수행된 날짜
  • "filingDate": 출원일
  • "softwareBuildVersion": 검증에 사용되는 검증기의 버전
  • "softwareVersion": 서열 목록을 생성하는 데 사용된 WIPO 서열 버전
  • "sourceFileName": XML 인스턴스를 나열하는 서열의 이름

검증 보고서를 생성하는 데 사용되는 템플릿, 또는 XSD는 다음과 같습니다:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <VerificationReport productionDate="YYYY-MM-DD" sourceFileName="[ST.26 filename]"> <VerificationMessageBag> <VerificationMessage> <Severity>[ERROR | WARN | XML_WARN | XML_ERROR]</Severity> <DataElement>[ST.26 element]</DataElement> <DetectedSequence>[Sequence ID]</DetectedSequence> <DetectedValue>[value]</DetectedValue> <MessageKey>[Message key]</MessageKey> <ParameterBag> <Parameter key="param key">Param value</Parameter> <ParameterBag> <LocalizedMessage> [Localized message] </LocalizedMessage> </VerificationMessage> ... </VerificationMessageBag> </VerificationReport>

표시된 심각도와 관련하여 다음 분류를 참고하십시오:

  • ERROR - '전체' 검사 중 반환된 오류
  • WARNING - '전체' 검사 중 반환된 경고
  • XML_ERROR - '형식' 검사 중 반환된 오류
  • XML_WARN - '형식' 검사 중 반환된 경고

검증 후, 하나 또는 두 가지 형식으로 생성된 검증 보고서는 기본적으로 "verificationReportOutputPath" 에 위치합니다.

./temp/st26/reports/[verificationID]/

아래 리소스 에서 XML 형식의 검증 보고서 예시를 확인할 수 있습니다.

5. 구성

기본 설정

검증기는 속성 파일을 사용하여 구성됩니다. 기본값은 *게시된 application.yml에서 찾을 수 있습니다.

제공된 매개변수의 값을 수정하려면, 대체 "application.yml" 파일을 사용해야 합니다. Springboot 문서에 자세히 설명된 대로 몇 가지 옵션이 있습니다.

구성 파일의 경로와 이름은 이 도구를 시작할 때 명령줄에 매개변수를 설정하여 지정할 수 있습니다:

  • JAR 배포의 경우:
    java  -jar -Dspring.config.location= <PATH_TO_FILE>  wipo-sequence-validator.jar
  • Tomcat에 WAR을 배포하려면 CATALINA_OPTS에 다음 항목을 추가해야 합니다:
    • Windows :
      set SPRING_CONFIG_ADDITIONAL-LOCATION=-Dspring.config.location=<PATH_TO_FILE>
    • Linux :
      export SPRING_CONFIG_ADDITIONAL-LOCATION="-Dspring.config.location=<PATH_TO_FILE>

WAR 배포를 사용하는 경우 새로운 "application.yml" 파일을 웹 애플리케이션의 "WEB-INF/classes" 폴더에 복사할 수도 있습니다.

"application.yml 파일"에서 HTML 보고서 생성을 활성화 또는 비활성화 할 수 있습니다. 보고서 생성을 활성화하려면 "true" 값을, 비활성화하려면 "false" 값을 입력합니다. 이 보고서의 내용은 'ServiceRequest'의 "errorSummary" 필드 내에 있는 콜백 엔드포인트로 전송됩니다.

검증 규칙 VXQV_49

사용자가 VXQV_49 규칙을 활성화하려면 optionalEnglishQualifierValue 값을 true로 설정할 수 있으며, optionalRuleType 값을 'ERROR' 또는 'WARNING'으로 업데이트하여 규칙의 심각도를 설정할 수 있습니다.

환경설정을 사용하여 VXQV_49를 켜기/끄기

Healthpoint

검증기는 응용 프로그램의 상태에 대한 기본 정보를 제공하는 /health 엔드포인트가 있습니다. 상태 엔드포인트를 탐색하려면 다음 URL을 열어야 합니다:

http://localhost:8080/wipo-sequence-validator/actuator/health

엔드포인트에 다음 내용이 표시되어야 합니다:

  • 응용 프로그램이 정상적으로 작동하는 한 상태는 UP입니다.
  • 데이터베이스와의 연결 또는 디스크 공간 부족 등의 문제로 인해 응용 프로그램이 비정상적인 상태인 경우 DOWN으로 표시됩니다.

상태 엔드포인트는 단순한 UP 또는 DOWN 상태만 표시합니다. application.yml 파일의 다음 속성은 상태 점검 프로세스의 일부로 확인된 모든 상태 표시자의 상태를 포함한 전체 세부 정보를 제공합니다.

응용 프로그램 YML 파일에서 healthcase 엔드포인트 설정하기

이제 상태 엔드포인트에 상태 점검 프로세스의 일부로 실행되는 DiskSpaceHealthIndicator의 세부 정보가 포함됩니다.

상태 엔드포인트는 다음과 같이 표시됩니다

상태 엔드포인트 출력
새 application.yml 파일에 설정된 속성을 적용하려면 검증기를 다시 시작해야 합니다.

현지화된 메시지

검증기는 10개의 공식 PCT 언어(아랍어, 중국어, 영어, 프랑스어, 독일어, 포르투갈어, 일본어, 한국어, 러시아어, 스페인어) 각각으로 현지화된 메시지를 검증 보고서 등을 통해 제공할 수 있습니다.

기본적으로, 이러한 메시지는 영어로 제공됩니다. 이러한 메시지를 다른 언어로 제공하도록 검증기를 구성하려면 application.yml 파일의 validator_locale 매개 변수를 적절한 언어 코드로 설정해야 합니다.

사용자 정의 생물명

특허청이 원래의 사전 정의된 생물명 목록에 포함되지 않는 자체 사용자 정의 생물명을 포함하려면, "alternativeResourceBasePath" 폴더에 "custom_organism.json" 이라는 새 파일을 생성하여 사용자 정의 생물 목록을 제공할 수 있습니다. 이 파일은 다음 구조와 같아야 합니다:

참고: 사전 정의된 생물명 목록과 달리, 모든 생물은 알파벳 문자별로 JSON 파일로 분리되지 않고, 단일 JSON 파일에 포함되어 있습니다.

대체 DTD 버전

기본적으로, 검증기는 최신 버전의 ST.26 DTD를 참조합니다. WIPO 서열 검증기의 현재 버전은 WIPO ST.26 DTD 버전 1.3을 기반으로 합니다. 이 최신 버전의 ST.26 DTD 사본은 소스 코드의 “/src/main/resources” 폴더에 있는 검증기 라이브러리에 포함되어 있습니다 (이는 JAR 또는 WAR 파일 내에서 참조되는 정의된 파일 경로입니다). 동일한 폴더에서 "catalog.xml" 파일에 참조됩니다.

검증 중에는 XML 파일의 DOCTYPE 선언에 설정된 DTD 버전이 사용됩니다. 먼저, "publicId"는 사용할 DTD 파일의 위치를 식별하는 데 사용됩니다. "publicId"가 카탈로그에 포함되어 있지 않은 경우, 시스템은 Java 프로세스가 실행되고 있는 루트 폴더에서 DTD 파일을 찾으려고 시도합니다.

이전 버전의 ST.26 DTD를 참조하는 WIPO ST.26 파일을 검증할 수 있으려면 검증기가 이 ST.26 DTD 파일을 사용할 수 있어야만 알맞은 검증을 수행할 수 있습니다. 이를 달성하기 위해 위해 두 가지 다른 접근 방식이 있습니다:

    1. JAR 파일의 압축을 풀고 추가 또는 대체 ST.26 DTD 파일에 대한 참조를 "src/main/resources" 폴더에 포함시킵니다. "catalog.xml"을 수정하고 추가 ST.26 DTD에 대한 새 항목을 추가하거나 기존 항목을 편집합니다. 예:
catalog.xml 파일 예시
  1. JAR 파일을 수정하는 대신, 다음 단계를 따라야 합니다:
    (i) "catalog.xml" 복사하기 및 모든 DTD를 로컬 폴더에 저장합니다;
    (ii) "catalog.xml"이 추가적인 ST.26 DTD에 대한 참조를 포함하도록 수정합니다;
    (iii) 실행 시 이 Java 시스템 속성을 설정합니다: "xml.catalog.files=<path_to_catalog.xml>"

Windows용 Tomcat에서는, 다음 환경 변수를 추가하여 이 작업을 수행할 수 있습니다:

환경 변수 설정
중요: 다른 버전의 ST.26 DTD를 포함하면 참조된 ST.26 DTD에 대해 XML 파일의 '형식' 검증이 가능하지만 '전체' 검증은 검증 규칙을 구현하기 위해 소스 코드를 변경해야 할 가능성이 있습니다. 따라서 여러 DTD를 사용하는 것은 '형식' 검증을 수행할 때만 사용하는 것이 좋습니다.

6. 리소스

다음 리소스는 특허청에 유용할 수 있습니다: