69
PCT/AI/ANF/5
page 31
S Sequence listing
D Drawing page (contains one or more figures per image page and one or more image pages)
F Figure (exactly one figure on exactly one image page)
I Embedded image (one or more image pages)
P Document page
4.3.2 Applicant’s identifier
The applicant’s identifier is determined by the applicant with or without the help of the
filing tool. The name of every file that is part of a submission will begin with the same
applicant’s identifier. Applicant’s identifier might be a name or a docket number or some
other string that has significance to the applicant. An applicant’s identifier is not necessarily
unique to each submission, that is, it might be used for another submission associated with
prosecution of the same application; it could even be used by the applicant for all submissions
for all his applications. The applicant’s identifier is placed first so that in a directory listing,
all the files for a particular submission or application or applicant will sort together.
Example of Applicant Package containing an international application
File
Contents
dupont0340-pkda.xml
Package data
dupont0340-requ.xml
Request
dupont0340-fees.xml
Fee sheet
dupont0340-biod.xml
Biological deposit
dupont0340-decl-000001.xml
First declaration
dupont0340-decl-000002.xml
Second declaration
dupont0340-poat-000001.xml
First power of attorney
dupont0340-poat-I000001.tif
First image of first power of attorney
dupont0340-poat-I000002.tif
Second image of first power of attorney
dupont0340-poat-000002.xml
Second power of attorney
dupont0340-poat-I000003.tif
First image of second power of attorney
dupont0340-lacs-I000001.tif
First lack of signature
dupont0340-lacs-I000002.tif
Second lack of signature
dupont0340-seql.app
Sequence listing (ST.25)
dupont0340-appb.xml
Application
dupont0340-appb-C000001.tif
First chemical structure, TIFF format
dupont0340-appb-C000001.cdx
First chemical structure, ChemDraw format
dupont0340-appb-C000001.mol
First chemical structure, MOL format
dupont0340-appb-M000001.tif
First mathematical formula, TIFF format
dupont0340-appb-M000002.tif
Second mathematical formula, TIFF format
dupont0340-appb-T000001.tif
First table, TIFF format
dupont0340-appb-T000002-000001.tif
Second table, first page, TIFF format
dupont0340-appb-T000002-000002.tif
Second table, second page, TIFF format
4.3.3 Office’s identifier
The office’s identifier is determined by each office with or without the help of their
system. The name of every file should begin with ‘pct | RO-code | IA-number’, for example
‘pctib2004012345’.
68
PCT/AI/ANF/5
page 32
Example of RO Package containing a record copy (pctib2004012345-reco.wsp)
File
Contents
pctib2004012345-pkda.xml
Package data
pctib2004012345-requ.xml
Request
pctib2004012345-rrri.xml
Receiving office information
pctib2004012345-fees.xml
Fee sheet
pctib2004012345-biod.xml
Biological deposit
pctib2004012345-decl-000001.xml
First declaration
pctib2004012345-decl-000002.xml
Second declaration
pctib2004012345-poat-000001.xml
First power of attorney
pctib2004012345-poat-I000001.tif
First image of first power of attorney
pctib2004012345-poat-I000002.tif
Second image of first power of attorney
pctib2004012345-poat-000002.xml
Second power of attorney
pctib2004012345-poat-I000003.tif
First image of second power of attorney
pctib2004012345-lacs-I000001.tif
First lack of signature
pctib2004012345-lacs-I000002.tif
Second lack of signature
pctib2004012345-seql.app
Sequence listing (ST.25)
pctib2004012345-exoc.xml
Ex-officio correction
pctib2004012345-appb.xml
Application
pctib2004012345-appb-C000001.tif
First chemical structure, TIFF format
pctib2004012345-appb-M000001.tif
First mathematical formula, TIFF format
pctib2004012345-appb-M000002.tif
Second mathematical formula, TIFF format
pctib2004012345-appb-T000001.tif
First table, TIFF format
pctib2004012345-appb-T000002-000001.tif
Second table, first page, TIFF format
pctib2004012345-appb-T000002-000002.tif
Second table, second page, TIFF format
5.
TRANSMISSION
The IA package can be transmitted over secure or non-secure channels depending on
the package type. This section includes the protocol to be followed as well as the
package/transmission combinations that are permitted in the Applicant-Office (international
phase), Office-Office, and designated Office communication sectors. While additional sectors
are referred to in this standard (see section 2.3), permissible transmission/package
combinations can be categorized in the three sectors listed above.
5.1 The E-filing interoperability protocol
This section describes both the transmission layer protocol between the clients and the
server as well as providing a definition of the behavior required of both the client and the
server.
The protocol is designed to support HTTP communication over an SSL (or TLS)
Tunnel for all PKI based E-filing solutions and includes the following capabilities:
(a) Enables large applications to be transmitted via multiple HTTP post actions to
address reliability and integrity issues
(b) Efficient error detection and correction
35
PCT/AI/ANF/5
page 33
(c) Enables offices to control optimal transaction size
Note that this is an evolving protocol, with production systems in development at a
number of IP Offices, and further revisions are foreseen.
5.1.1 Principles
The following principles have been adopted for the interoperability protocol:
(a) All communications between client and server is in the form of HTTP post
actions initiated by the client
(b) All post requests and resulting responses use the same transaction management
header followed by an optional data block
(c) All transmissions use the Division mechanism to divide large blobs of data into
manageable chunks with a protocol that allows for retries and pacing.
5.1.2 Application layer protocol for application
At the highest level for application, there are five events that the protocol requires a
client and server to support. These events are:
(a) Begin Transaction
(b) Send Package Header
(c) Send Package Data
(d) Get Receipt
(e) End Transaction
In between the Begin and End Transactions, there are three types of WASP sent
between the client and the server:
(i) The package header contains essential information for initial processing to
identify the submission. It is a WASP containing the package header in XML
format.
(ii) The package data contains the information for submitting application. It is a
WASP consisting of various types of files.
(iii) The receipt is an acknowledgment of the submission. The content of this receipt
(XML data plus an optional human readable certificate in PDF or TIFF format),
which is signed by the receiving Office, is defined in Appendix I.
5.1.2.1
Use of the SSL (or TLS) tunnel for application
These events are all performed within an SSL (or TLS) tunnel that is established
before issuing the Begin Transaction event. The SSL (or TLS) tunnel is built using both client
41
PCT/AI/ANF/5
page 34
and server authentication. The SSL (or TLS) tunnel may be stopped at the end of the
transaction or, if a batch of transmissions is foreseen, the SSL (or TLS) tunnel can be left
open and only stopped when all transmissions are complete. The SSL tunnel uses the SSL
protocol version 3.0.
The Receiving Office (RO) has discretion over which protocol to be used, SSL or
TLS.
When the client authentication is to be conducted by the server, in addition to the
function supported by the SSL protocol version 3.0 (or the TLS protocol) that confirms the
fact that the digital certificate transmitted by the client software is actually issued by the
recognized CA, disconnection of the SSL (or TLS) tunnel may be controlled by the server
based on the following process:
(a) Data of the applicant/representative digital certificate(s) obtained beforehand by
the receiving Office is stored in the server.
(b) At the time of client authentication by the SSL protocol version 3.0 (or the TLS
protocol), the server checks whether the data of the applicant/representative digital certificate
sent by the client software exists in the data previously stored in the server by the above-
mentioned step (a).
(c) If the check result in step (b) is negative, the server disconnects the SSL (or TLS)
tunnel.
In order to carry out the above function, the receiving Office may conduct a
pre-registration process to obtain beforehand the following data, on its own initiative or from
the applicant/representative: (i) data (or updated data) of digital certificate(s) used by the
applicant/representative; and as the need arises, (ii) additional information on the
applicant/representative.
In all cases except where the SSL (or TLS) tunnel is disconnected in the process
described above, the current protocol requires each individual transaction to be acknowledged
by an individual receipt.
5.1.2.2
Application level events for application
Start SSL (or TLS) session (see Figure 5)
Step 0: Begin Transaction
Client action:
Get transaction Information.
Server response:
Return values in the transaction_id and max_division_size
transaction management header elements.
transaction_id is a unique identifier assigned by the server
associating all transactions involved in the submission of an
application.
44
PCT/AI/ANF/5
page 35
max_division_size is the maximum number of bytes permitted
by the server for the size of a division.
Step 1: Send Package Header
Client action:
Send package header
Server response:
a) OK
b) Error (Abort, go back to step 0)
c) Package already received; go to step 3 to get the receipt.
After receiving the last division of the WASP containing the package
header, the server must verify the signature of the WASP. If the signature is
invalid (for instance expired), the Application Response Code (ARC) will
remain OK, but the server will capture the error and provide a message on
the receipt.
Step 2: Send Package Data
Client action:
Send package data
Server response:
a) OK
b) Error (Abort, go back to step 0)
After receiving the last division of the WASP containing the package data,
the server must verify the signature of the WASP and compare the message
digest of the unsigned package against the message digest provided in the
Package Header in Step 1 of the transaction before returning the ARC to the
client. If both conditions are met, the server should return an ARC
indicating OK. If the hash values in package header and the WAD of the
package data do not match, the ARC value should be set to FFF7. If the
signature is invalid (for instance expired), the ARC will remain OK, but the
server will capture the error and provide a message on the receipt.
Step 3: Request Receipt
Client action:
Send request
Server response:
a) OK (Receipt object included in response)
b) Error (Abort, go back to step 0)
Step 4: End Transaction.
Client action:
Send acknowledgment of completion including information
about any client problem to the server.
Server response:
a) OK
b) Error (Client can ignore this response)
61
PCT/AI/ANF/5
page 36
Close SSL (or TLS) session
In all cases of SSL (or TLS) Tunnel, the current protocol requires each individual transaction
to be acknowledged by an individual receipt.
Establish SSL (or TLS)
Client/Server Authentification
Begin
Transaction
1
Send Package
Header
Restart
Transaction
Send
3
Request
Receipt
Transaction
4
End
Transaction
End SSL (or TLS)
Session
User
can ignore
User should
Contact
Support Desk
Check
Return Info
0
Check
Return Info
Check
Return Info
Check
Return Info
1
3
4
Send Package
Data
2
Check
Return Info
OK
Error
Error
OK
OK
OK
Client
Problem
Network
Error
Package Known
New Package
Error
Error
Figure 5 – Application level protocol behavior for application
48
PCT/AI/ANF/5
page 37
5.1.3 Application layer protocol for notification
At the highest level for notification, there are five events that the protocol requires a
client and server to support
9
. These events are:
10
(a) Begin Transaction
(b) Get Package Header (for notification, or dispatch list, or application receipt
list)
11
(c) Get Package Data (for notification, or dispatch list, or application receipt list)
12
(d) Send Receipt Check Notice (for notification, or dispatch list, or application
receipt list)
12
(e) End Transaction
In between the Begin and End Transactions, there are two types of WASP and one
type of C-WASP sent between the client and the server:
(i) The client action package header contains essential information for initial
processing to identify the request for notification. It is a WASP containing the
package header in XML format. (This is applied to request to a server from a
client.)
(ii) The server response package header contains summary information (such as a
dispatch-number and the number of notifications to be sent) on the notification
to be notified. It is a WASP containing the package header in XML format.
(This is applied to response to a client from server.)
(iii) The package data contains the dispatched notification information. It is a C-
WASP that consists of one or more WASP(s).
5.1.3.1
Use of the SSL (or TLS) tunnel for notification
Refer to Section 5.1.2.1, "Use of the SSL (or TLS) tunnel for application."
5.1.3.2
Application level events for notification
Start SSL (or TLS) session (see Figure 6)
9
The Office may inform the applicant of the existence of notifications before these five events, by other means
of communication, such as e-mail.
10
This protocol may be used to transmit the dispatch list, the application receipt list, and the notification.
Transmission of the dispatch list, the application receipt list, and the notification is supported at the discretion
of the Office. The dispatch list contains dispatch numbers corresponding to notifications that the Office has
sent to the applicant. The application receipt list contains application numbers corresponding to application
documents that the Office has received from the applicant.
11
The server uses the value of the“transaction-type” attribute (see section 5.1.4) to identify the type of
document requested, e.g. notification, dispatch list, application receipt list.
43
PCT/AI/ANF/5
page 38
Step 0: Begin Transaction
Client action:
Get transaction Information.
Server response:
Return values in the transaction_id and max_division_size
transaction management header elements.
transaction_id is a unique identifier assigned by the server
associating all transactions involved in sending a notification.
max_division_size is the maximum number of bytes permitted
by the server for the size of a division.
Step 1: Get Package Header
Client action:
Send request for package header (The WASP of package header for
request of notification is contained.)
Server response:
a) OK (The response contains the WASP of package header
containing summary information (such as dispatch-number,
number-of-notification) of notifications.)
12
b) Error (Abort, go back to step 0)
After receiving the last division of the WASP containing the package
header, the server must verify the signature of the WASP. If the signature is
invalid (for instance, due to a signature verification error or validation data
expiration), the application response code (ARC) value is set to FFF6.
If the number of sendable notifications in package header of Server response
is “0(zero)” (there is no sendable notifications), then go to Step 4.
Step 2: Get Package Data
Client action:
Send request for Package data
Server response:
a) OK (The response contains the C-WASP consisted of one or
more WASP(s))
b) Error (Abort, go back to step 0)
Step 3: Send Receipt Check Notice
Client action:
Send Receipt Check Notice
Server response:
a) OK
b) Error (Abort, go back to step 0)
12
If the C-WASP contains multiple WASP, the notice-info of each notification is set in the package header.
12
PCT/AI/ANF/5
page 39
Step 4: End Transaction.
Client action:
Send acknowledgment of completion including information about
any client problem to the server.
Server response:
a) OK
b) Error (Client can ignore this response)
Close SSL (or TLS) session
In all cases of SSL (or TLS) Tunnel, the current protocol requires that, for each transaction,
the client acknowledge the reception by sending Receipt Check Notice to the server.
58
PCT/AI/ANF/5
page 40
Establish SSL (or TLS)
Client/Server Authentification
Begin
Transaction
1
Get Package
Header
Restart
Transaction
Send
3
Send receipt check
notice
Transaction
4
End
Transaction
End SSL (or TLS)
Session
User
can ignore
User should
Contact
Support Desk
Check
Return Info
0
Check
Return Info
Check
Return Info
Check
Return Info
1
3
4
Get Package
Data
2
Check
Return Info
OK
Error
Error
OK
OK
OK
Client
Problem
Network
Error
Not existence
OK (Notification exist)
Error
Error
Figure 6 – Application level protocol behavior for notification
Documents you may be interested
Documents you may be interested
