eService B2B Operations Guide - IP Australia · PDF fileB2B Operations Guide ... • TIBCO...

eService B2B Operations Guide V1.0 October 2015

Contents About this guide ................................................................................................................. 1

Audience ..................................................................................................................... 1 Related documentation ............................................................................................... 1 How to contact IP Australia customer support ............................................................. 1

About B2B.......................................................................................................................... 2 Submitting an IP rights request ....................................................................................... 2 How B2B works .............................................................................................................. 3 What you need to do ...................................................................................................... 4

Maximum transmission and file sizes .......................................................................... 4 Number of requests per batch ..................................................................................... 4 Attachment file types ................................................................................................... 5 Image attachment file requirements ............................................................................ 5

Obtain a transaction id ....................................................................................................... 6 Sample Web Services/HTTP request .......................................................................... 6 Soap response (success) ........................................................................................... 6 Soap response (unsuccessful) .................................................................................... 8

Building a batch (zip) file .................................................................................................... 9 Creating batch request.xml files ..................................................................................... 9

Renewals only .......................................................................................................... 10 All requests ............................................................................................................... 12

Validating the batch request file .................................................................................... 16 Collecting required attachment files .............................................................................. 17 Creating a manifest.xml file .......................................................................................... 17

Sample manifest.xml ................................................................................................. 17 Creating the zip file for B2B .......................................................................................... 19

Managed File Transfer ..................................................................................................... 20 Using the MFT folders .................................................................................................. 20 Understanding the MFT process .................................................................................. 21

Start menu MFT listing .............................................................................................. 22 Testing transactions ......................................................................................................... 23

Transmitting zip files to IP Australia .......................................................................... 23 Testing your own XML files ....................................................................................... 23

Going live ..................................................................................................................... 23 Using B2B ........................................................................................................................ 24

Submitting transactions using B2B ............................................................................... 24 Handling acknowledgements and messages ................................................................ 24

Acknowledgements ................................................................................................... 24 Acknowledgement file examples ............................................................................... 24 Validation response files ........................................................................................... 25

B2B Operations Guide | IP Australia | i

Validation response file examples ............................................................................. 26 Reconciling direct debit information .............................................................................. 29 Scheduling transfers ..................................................................................................... 29 Monitoring transfers ...................................................................................................... 30 Trouble shooting ........................................................................................................... 31

ii | IP Australia | B2B Operations Guide

About this guide This Operations Guide:

• explains how B2B works • provides assistance with XML schema and samples for submitting B2B service requests • provides test procedures • provides guidelines on using B2B

Audience This guide is provided for in-house developers and third party providers who develop and maintain your front-end system to build valid XML requests and create the files for sending to IP Australia via the B2B channel. It assumes knowledge of XML, IT messaging systems, communications and databases.

Related documentation For more information, see the following documents:

• B2B Installation and Configuration Guide • TIBCO MFT Platform Server for Windows User Guide (available from

https://docs.tibco.com/pub/managed-file-transfer-platform-server-for-windows/7.1.1-march-2012/MFT_PS_v7.1.1_for_Windows_User_Guide.pdf

How to contact IP Australia customer support To contact IP Australia customer support, see the Contacts page under B2B on the IP Australia website.

B2B Operations Guide | IP Australia | 1



About B2B IP Australia’s Business to Business (B2B) channel is designed to streamline applications and renewals for intellectual property rights and the accounting processes associated with them. B2B is a system that allows direct electronic lodgement, acknowledgement and fee payment through an electronic file transfer system that allows multiple lodgements to be made in a single transmission.

B2B is designed for annuity and attorney firms who need to process a high volume of applications, renewals and continuations of intellectual property rights. An essential part of this process is the payment of fees to preserve the legal privileges of rights holders. B2B automates this process through direct debit, removing the need to make a separate payment for each lodgement.

Submitting an IP rights request The request submission process has a number of steps.

1. The customer transmits a Web Services/HTTP request across the proxy server to request a transaction id from IP Australia.

2. IP Australia verifies the customer’s user id and returns a transaction id to the customer. 3. Using this transaction id, the customer then builds a zip file that consists of a manifest

XML file, request XML file and any attachments, where:

Component Description

zip file name Constructed from the transaction id

Manifest XML file Contains details of each request and its associated attachments.

Request XML file Contains one or more requests for individual intellectual property rights transactions.

4. After validation, the zip file is placed into a specified folder and processing starts, according to definitions provided in the MFT configuration. This processing includes creating a signed hash file and transferring both the zip file and signed hash file to another folder before transmitting them to IP Australia for processing.

5. When the files are sent, IP Australia: - validates the transmission - sends an acknowledgement message to the customer to indicate the status of the

file transmission - validates the security certificate and requests - calculates a list of detailed costs for each valid request - sends a validation report to the customer to indicate the success or failure of the

processing and the fees charged for each valid request in the batch - sends the requests for processing by IP Australia’s business areas.

This process is illustrated in the diagram on the next page.

2 | IP Australia | B2B Operations Guide

How B2B works


What you need to do The secure transmission between customer sites and IP Australia uses Managed File Transfer (MFT), which is supplied as part of the installation package.

B2B batches must be prepared as service requests in a defined XML format. IP Australia provides XML schema for all available service requests and sample XML requests for the most commonly submitted requests.

You need to develop systems to automate:

• creating XML requests for each of the intellectual property services you wish to use • validating the files • sending a programmed SOAP (Simple Object Access Protocol) Web Services/HTTP

request to request each transmission id. This uses WSDL (Web Services Description Language).

• using a specified file-naming convention based on the transmission id, to produce a single compressed (zip) file that contains: - the request XML file (which can contain multiple requests) - a manifest XML file - any attachments.

When the zip file is placed in the staging folder, MFT handles:

• creating a hash file and signing it using your private key, through the signing batch file • moving the signed hash file and zip file to a folder for transmission • transmitting the signed hash file and zip file to IP Australia for processing • moving files to specific error folders if an error occurs in signing or transmission.

Maximum transmission and file sizes Each batch (or zip file) can have a maximum size of 200 MB, including all attachments (compressed)

Each request within a batch can have a maximum size of:

• 1 MB (uncompressed, without attachments) • 100 MB (uncompressed, including attachments):

Any individual attached file can have a maximum size of 20 MB (uncompressed).

Number of requests per batch For optimal processing, there is a limit on the number of requests that should be effectively included in each batch.

• For Renewals (using the Renewals V1.1 schema), the maximum number of Renewals in each batch file is 600.

• For Request batch files, although multiple service requests within a batch are technically possible, one service request per batch is preferred.

These file limits have been imposed to improve system performance and to improve recovery if an error occurs within the service request xml or file contents. This change brings consistency with other commercial products, improves the speed of processing and makes it easier for you to resubmit if a service request is found to be invalid. Resubmission can be complex and time-consuming if one or more service requests fail in a batch where some service requests are processed successfully.


Attachment file types

The following file formats are valid:

• Word (.doc, .docx) • TXT (.txt) • PDF (.pdf) • TIFF (.tif, .tiff) • JPEG (.jpeg, .jpg) • GIF (.gif) • PNG (.png) • XML (.xml) • MPEG (.mpg) • MP3 (.mp3) • WADs (Wrapped application document file consistent with WIPO standards) • WASPs (Wrapped and signed packages consistent with WIPO standards).

Image attachment file requirements There are a number of requirements for image file names and image quality.

• File names for images must not contain spaces or any foreign characters. • The recommended resolution for an image is 300 dots per inch (dpi). • Resolution for any image file must be greater than 200 dpi but less than or equal to 300

dpi.

There are also restrictions on the content and type of file according to the type of request, as follows:

Patents

• Images and drawings should be in durable, black, dense, uniformly thick and well-defined lines and strokes.

• Greyscale and colouring should not be used.

Trade marks

• PNG (.png) is the preferred file type for all trade mark images • Other files types accepted are TIFF (.tif, .tiff), JPEG (.jpg, .jpeg), MP3 (mp3) and MPEG

(.mpg). • All sound files must be in MP3 (.mp3) format. • All animated files must be in MPEG (.mpg) format. • The preferred size for trade mark images is 4 cm x 3 cm (minimum) and 8 cm x 8 cm

(maximum). • The minimum accepted image size is 4 cm x 2 cm to ensure the features of the trade

mark can be clearly identified. • The maximum allowable size for an image is 29.7 cm x 21 cm. • The colour space of an image must be RGB.

Designs

• PNG (.png) is the preferred file type for greyscale or colour images.


• TIFF (.tif) is the preferred file type for black and white images. • Only PNG (.png), TIFF (.tif, .tiff) and JPEG (.jpg, .jpeg) file types will be accepted for

image files. • Each attached image file should be a single A4 size page (29.7 cm x 21 cm) • The colour space of an image must be sRGB. • For Renewals (using the Renewals V1.1 schema), the maximum number of Renewals

in each batch file is 600. • For Request batch files, although multiple service requests within a batch are

technically possible, one service request per batch is preferred.

Obtain a transaction id To request a transaction id, stream an XML message to IP Australia using a SOAP web services request.

Open the \IPA\B2B test and sample files\Production WSDL folder provided in the IPA.zip file. This folder contains two files:

• TransactionAuthority1.0 Examples.txt – contains examples of Web Services/HTTP requests for:

• SOAP request for a transaction id • SOAP response containing the transaction id • SOAP response if an error occurs • TransactionAuthority1.0.wsdl – contains the WDSL definition.

Note: Use the files in Production WSDL for production use. For testing purposes use the files provided in Test WSDL which uses a specific external user test environment (EUT) at IP Australia, that requires a different set of transaction ids.

Sample Web Services/HTTP request Include your remote user id (supplied by IP Australia) in the <userIdentifier> element.

For example, if your remote user id is “grantTest", stream the following XML to IP Australia:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://services.ipaustralia.gov.au/XMLSchema/WSDL/1"> <soapenv:Header/> <soapenv:Body> <ns:getTransactionIdentifierRequest> <userIdentifier>grantTest</userIdentifier> </ns:getTransactionIdentifierRequest> </soapenv:Body> </soapenv:Envelope>

Soap response (success) If successful, IP Australia sends the transaction id back using SOAP. The transaction id (10 characters, zero-padded) is contained in the <transactionIdentifier> element.

In the following example, the transaction id is "0000010298".


<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:getTransactionIdentifierResponse xmlns:ns2="http://services.ipaustralia.gov.au/XMLSchema/WSDL/1"> <transactionIdentifier>0000010298</transactionIdentifier> </ns2:getTransactionIdentifierResponse> </S:Body> </S:Envelope>


Soap response (unsuccessful) If unsuccessful, IP Australia uses SOAP to return an XML message indicating the fault.

• The reason for the failure is contained in the <messageCode> and <message> elements.

• A stack trace is provided in the <ns2:stackTrace> element to assist with advanced troubleshooting.

For example, if the request for a transaction id fails because the customer has not provided the remote user id, the response is:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode xmlns:tibpfx1="http://schemas.xmlsoap.org/soap/envelope/">tibpfx1:Server</faultcode> <faultstring>A UserId must be provided for the getTransactionIdentifier operation</faultstring> <faultactor>DefaultRole</faultactor> <detail> <ns2:unrecoverableFault xmlns:ns2="xmlns:ns=http://services.ipaustralia.gov.au/XMLSchema/WSDL/1"> <messageCode>M00297</messageCode> <message>A UserId must be provided for the getTransactionIdentifier operation</message> </ns2:unrecoverableFault> <ns2:exception class="... error tracing details ..." xmlns:ns2="http://jax-ws.dev.java.net/"> <message>A UserId must be provided for the getTransactionIdentifier operation</message> <ns2:stackTrace>  </ns2:stackTrace> </ns2:exception> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>


Building a batch (zip) file The next step is to create the full batch (zip) file required for transmission to IP Australia's B2B system. This involves:

1. Creating the batch request file 2. Validating the batch request file 3. Collecting required attachment files 4. Creating a manifest.xml file 5. Zipping all these files into a transaction .zip file with a filename based on the latest

transaction id you obtained via the Web Services/HTTP SOAP request from IP Australia.

Creating batch request.xml files The batch request xml file is an XML file that contains a set of requests or renewals for intellectual property rights transactions in xml format.

• For Renewals (using the Renewals V1.1 schema), the maximum number of Renewals in each batch file is 600.

• For Request batch files, although multiple service requests within a batch are technically possible, one service request per batch is preferred.

XML schema provided by IP Australia contain the definitions for creating the XML request and renewal files. To access these, open the Prepare your B2B system tab and download the XML schema and sample files.

There are two types of batch request XML files for B2B; renewals only and requests.


Renewals only The XML schema for renewals is simpler than the XML request schema, but can only be used for renewals

To use this schema, specify the type of Intellectual Property right you wish to renew. Valid types are:

• PATENTS • DESIGNS • TRADE_MARKS • PLANT_BREEDERS_RIGHTS

Format of renewal.xml The renewal XML file takes a specific format. You can include all types of renewals in a single batch file, up to a maximum of 600 individual renewal requests or 200 MB.

The table describes the requirements for the basic elements in a renewal-only request.

Element name Content to be inserted

Data types Length Number of elements allowed

Required/ Optional

SubmittersOwn Reference (in Request Header) This applies to the whole batch.

An identifier you can use to track the whole batch submitted in this transaction

A string using only characters from the restricted character set. If you wish to include other characters, enclose the whole string within [CDATA].

30 chars max

1 only per batch (that is, per renewal.xml file)

Optional

SubmittersOwn Reference (within each individual IpRightRenewal Request)

An identifier you can use to track a single IP Right Renewal request

A string using only characters from the restricted character set. If you wish to include other characters, enclose the whole string within [CDATA].

30 chars max

1 only in each individual renewal request

Optional

IPRightIdentifier (for each individual IPRrightRenewal Request)

Identifier string provided to you by IPA for the IP right which is to be renewed, IP Australia assumes that this Identifier is correct if it matches a known IP right.

Alphanumeric characters only

100 chars 1 only per individual renewal request item

Required

IPRightBusiness Line (for each individual IPRrightRenewal Request)

The type of IP Right which is being renewed in this individual request

Valid values: DESIGNS PATENTS TRADE_MARKS PLANT_BREEDERS_ RIGHTS

Up to 20 chars (see data types)

1 only per individual renewal request item

Required

SubmitterComment

An area for your own use in relation to an individual renewal request Not normally read by

A string using only characters from the restricted character set. If you wish to include other characters, enclose the

1000 chars max

1 only per individual renewal request item

Optional


Element name Content to be inserted

Data types Length Number of elements allowed

Required/ Optional

IP Australia whole string within [CDATA].

Restricted character set Character types for the renewals schema are restricted to UTF-8 encoding. This is an 8-bit variable-width encoding which maximises compatibility with ASCII.

This can include any combination of any of the following:

• any Unicode 'letter' • any numeral between 0 and 9 inclusive • any Unicode 'punctuation' character • any Unicode 'symbol' • a space, tab, or line break • the characters: '/' (slash), '-' (hyphen), '@' and '.' (full-stop or period).

Note: White space, such as tabs or new lines count towards the size of the contents of key elements. It’s recommended that you create elements such as SubmittersOwnReference in a single line.

Example renewal xml This example shows each of the renewal types in a single batch file.

Note that the namespace used for the ipa-iprights-renewals-Schema.1.1.xsd schema file is for illustration only.

<?xml version="1.0" encoding="UTF-8"?> <tns:IPRightBatchRequest xmlns:tns=http://services.ipaustralia.gov.au/XMLSchema/Common/1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://services.ipaustralia.gov.au/XMLSchema/ Common1../Renewals/ipa-iprights-renewals-Schema.1.1.xsd"> <tns:RequestHeader tns:SchemaVersion="1.1"> <tns:SubmittersOwnReference>BATCH SUBMITTER</tns:SubmittersOwnReference> </tns:RequestHeader> <tns:RequestBody> <tns:IPRightRenewalRequests> <tns:IPRightRenewalRequest> <tns:SubmittersOwnReference>DESIGN SUBMITTER</tns:SubmittersOwnReference> <tns:IPRight> <tns:IPRightIdentifier>the design id</tns:IPRightIdentifier> <tns:IPRightBusinessLine>DESIGNS</tns:IPRightBusinessLine> </tns:IPRight> </tns:IPRightRenewalRequest> <tns:IPRightRenewalRequest> <tns:SubmittersOwnReference>PATENT SUBMITTER</tns:SubmittersOwnReference> <tns:IPRight> <tns:IPRightIdentifier>the patent id</tns:IPRightIdentifier> <tns:IPRightBusinessLine>PATENTS</tns:IPRightBusinessLine> </tns:IPRight> </tns:IPRightRenewalRequest>


http://services.ipaustralia.gov.au/XMLSchema/Common/1

http://www.w3.org/2001/XMLSchema-instance

<tns:IPRightRenewalRequest> <tns:SubmittersOwnReference>TM SUBMITTER</tns:SubmittersOwnReference> <tns:IPRight> <tns:IPRightIdentifier>the trade mark id</tns:IPRightIdentifier> <tns:IPRightBusinessLine>TRADE_MARKS</tns:IPRightBusinessLine> </tns:IPRight> </tns:IPRightRenewalRequest> </tns:IPRightRenewalRequests> </tns:RequestBody> </tns:IPRightBatchRequest>

All requests The other set of schema for B2B XML files supports all intellectual property request types, including renewals, but these have a different structure.

This is a hierarchical structure, starting with the batch request (IPB_B2B_BatchRequest), which identifies the submitter’s identification. Then you identify the type of operation you wish to perform, (IPB_VerbInclude), followed by the type of IP right, then the specific details for each individual request.

The following diagram shows the hierarchy of elements within a request batch file.

Many of the higher level details are relatively static and, once configured for your system, can be used as a form of formal "wrapper" around the more basic constructs needed for individual service requests. However, the wrapper is not universal, and some service requests require more elements than others.

Detailed input for each service request is defined in the XML schema files provided by IP Australia. To access these, open the Prepare your B2B system tab and download the XML schema and sample files.

The following table shows the IP rights request types supported by B2B schema.


Type of request Supported IP rights transactions

BatchRequestHeader Contains batch level details, including a customer-provided reference for the batch

Apply Contains nodes that allow for new intellectual property right applications to be submitted, including: For Patents

• Standard patent applications

• Innovation patent applications

• Provisional patent applications

• Request for a PCT application to enter the national phase For Designs

• Standard design application

• Multiple design application

• Excluded design application For Trade marks

• Standard trade mark application

• Series trade mark application

• Collective trade mark application

• Defensive trade mark application

• Certification trade mark application For Plant breeder's rights

• PBR application (Part 1)

Examine Contains nodes that allow for examination requests to be submitted for patents and designs, including: For Patents

• Full examination

• Examination under the patent prosecution highway (PPH)

• Third-party examination request on an innovation patent

• Re-examination

• Third-party re-examination For Designs

• Owner-requested examination

• Third-party examination request

Register Contains nodes that allow for registration fee payments to be made on a trade mark

Renew Contains nodes that allow for renewal fee payments to be made on a: • Patent (continuation and renewal fees)

• Design

• Trade mark

• Plant breeder's right

General Contains nodes that allow for all other requests to be submitted, including amendments and correspondence

Pay Contains nodes that allow for payment of an outstanding fee to be made, including:

• Paying an outstanding fee related to an IP right


Type of request Supported IP rights transactions • Paying an invitation to pay (for patents and designs)

• Paying an invoice

• Paying any other type of fee


Example XML file

The following example shows the structure of an XML request file. This example shows a new patent application for national phase entry, a request for changing the service address for a trade mark and design renewal.

Note that the namespace used for the IPB_B2B_BatchRequestV1.7.xsd schema file is for illustration only.

<?xml version="1.0" encoding="UTF-8"?> <p:IPBBatchRequest xmlns:bb=http://services.ipaustralia.gov.au/XMLSchema/base/1 xmlns:p=http://services.ipaustralia.gov.au/XMLSchema/Actions/1 xmlns:pat=http://services.ipaustralia.gov.au/XMLSchema/patcomp/1 xmlns:pn=http://services.ipaustralia.gov.au/XMLSchema/applypatent/1 xmlns:gnt=http://services.ipaustralia.gov.au/XMLSchema/generaltrademark/1 xmlns:wp="http://www.wipo.int/standards/XMLSchema/Common/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xsi:schemaLocation="http://services.ipaustralia.gov.au/XMLSchema/Actions/1..\ ..\V1.6\IPB_B2B_BatchRequestV1.7.xsd"> <BatchRequestHeader> <bb:BatchSubmittersOwnReference>BATCH REF</bb:BatchSubmittersOwnReference> <bb:Submitter>BATCH SUBMITTER</bb:Submitter> </BatchRequestHeader> <Requests> <Apply> <ForPatent> <pn:ApplyNationalPhaseEntryAction> <bb:SubmittersOwnReference>PATENT REF</bb:SubmittersOwnReference> <bb:IPRightIdentifier>PATENT ID</bb:IPRightIdentifier> <PatentContacts> <bb:AddressForService> <SubmittersNameAddressIndicator>true</SubmittersNameAddressIndicator> </bb:AddressForService> <bb:AddressForCorrespondence> <SubmittersNameAddressIndicator>true</SubmittersNameAddressIndicator> </bb:AddressForCorrespondence> </PatentContacts> <pat:NPEPCTDetails> <bb:RequestPetition>I acknowledge that I intend to enter the National Phase in Australia</bb:RequestPetition> <bb:PCTApplicationPublished>true</bb:PCTApplicationPublished> </pat:NPEPCTDetails> </pn:ApplyNationalPhaseEntryAction> </ForPatent> </Apply> <General> <ForTradeMark> <gnt:TradeMarkChangeAddressForServiceAction> <SubmittersOwnReference> <bb:SubmittersOwnReference>submitter ref</bb:SubmittersOwnReference> </SubmittersOwnReference> <RequestIPRightDetail> <bb:IPRightIdentifier>trade mark id</bb:IPRightIdentifier>


http://services.ipaustralia.gov.au/XMLSchema/base/1

http://services.ipaustralia.gov.au/XMLSchema/Actions/1

http://services.ipaustralia.gov.au/XMLSchema/patcomp/1

http://services.ipaustralia.gov.au/XMLSchema/applypatent/1

http://services.ipaustralia.gov.au/XMLSchema/generaltrademark/1

<bb:SubmittersOwnReference>ref code</bb:SubmittersOwnReference> </RequestIPRightDetail> <TradeMarkSupportingDocumentsDetail> <Submission> <DocumentType>TradeMarkAttachmentAmendment</DocumentType> <Document> <bb:DocumentFullPathFileName>AMENDMENT.pdf </bb:DocumentFullPathFileName> <bb:DocumentIndicatorOfPhysicalMediaSuppliedSeparately>false </bb:DocumentIndicatorOfPhysicalMediaSuppliedSeparately> </Document> </Submission> </TradeMarkSupportingDocumentsDetail> </gnt:TradeMarkChangeAddressForServiceAction> </ForTradeMark> </General> <Renew> <ForAll> <bb:IPRightRenewalAction> <bb:SubmittersOwnReference>DESIGN REF</bb:SubmittersOwnReference> <bb:IPRight> <bb:IPRightIdentifier>DESIGN ID</bb:IPRightIdentifier> <bb:IPRightBusinessLine>DESIGNS</bb:IPRightBusinessLine> </bb:IPRight> </bb:IPRightRenewalAction> </ForAll> </Renew> </Requests> </p:IPBBatchRequest>

See the schema file, IPB_enumerationsV1.7.xsd for a list of valid values for the elements.

Validating the batch request file You should validate your renewals and requests XML files before you zip them up to send to IP Australia.

Validate using the schema supplied by IP Australia and use it as a local reference when checking your file contents and syntax. To access these, open the Prepare your B2B system tab and download the XML schema files.

There are a number of editors and products available for editing and validating XML files. When validating you need to select the following schema for the different types of batch XML files.

Renewals only ipa-iprights-renewals-Schema.1.1.xsd

All requests IPB_B2B_BatchRequestV1.7.xsd

Note, schema version 1.7 is used in this guide. You should use the current schema version issued by IP Australia.


Collecting required attachment files Ensure that you collect all the attachments that are specified in the requests contained in each batch. These should be filed in a separate folder within the batch file. You must also itemise each separate attachment in the manifest.xml file.

Creating a manifest.xml file The manifest.xml file is used to check and identify the various files included in your zip file. This file must be named: manifest.xml. Attachments should be included in a folder within the batch file.

To obtain a copy of the manifest XML schema, open the Prepare your B2B system tab, download the XML schema files and select the file manifext.xsd.

Sample manifest.xml In the following example manifest.xml file, note that the manifest.xml file does not indicate how many individual requests are contained in the Request.xml file. It indicates a single request file but itemises any attachments. For a request batch, the messageType is IPB_REQUEST. For a renewals batch, the messageType is RENEWAL_REQUEST. In the following example, Attachments is a folder within the request transaction zip file, containing seven files:

• Attachment1.pdf • Attachment2.docx • Attachment3.doc • Attachment4.tiff • Attachment5.png • Attachment6.jpeg • Attachment7.mpg

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <ns0:Manifest xmlns:ns0="http://www.ipaustralia.gov.au/mft/manifest" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ipaustralia.gov.au/mft/manifest file:///d:/V1.7/Manifest.xsd"> <ns0:messageType>IPB_REQUEST</ns0:messageType> <ns0:files> <ns0:file> <ns0:fileName>request.xml</ns0:fileName> <ns0:contentType>text/xml</ns0:contentType> </ns0:file> <ns0:file> <ns0:fileName>Attachments/Attachment1.pdf</ns0:fileName> <ns0:contentType>application/pdf</ns0:contentType> </ns0:file> <ns0:file> <ns0:fileName>Attachments/Attachment2.docx</ns0:fileName> <ns0:contentType>application/msword</ns0:contentType> </ns0:file> <ns0:file> <ns0:fileName>Attachments/Attachment3.doc</ns0:fileName> <ns0:contentType>application/msword</ns0:contentType>


http://www.ipaustralia.gov.au/mft/manifest


</ns0:file> <ns0:file> <ns0:fileName>Attachments/Attachment4.tiff</ns0:fileName> <ns0:contentType>application/tiff</ns0:contentType> </ns0:file> <ns0:file> <ns0:fileName>Attachments/Attachment5.png</ns0:fileName> <ns0:contentType>application/png</ns0:contentType> </ns0:file> <ns0:file> <ns0:fileName>Attachments/Attachment6.jpeg</ns0:fileName> <ns0:contentType>application/jpeg</ns0:contentType> </ns0:file> <ns0:file> <ns0:fileName>Attachments/Attachment7.mpg</ns0:fileName> <ns0:contentType>application/mpeg</ns0:contentType> </ns0:file> </ns0:files> </ns0:Manifest>

Notes: 1. File path names may include either backslash or forward slash separators. 2. Each file path/file name specification must be unique. 3. If file names are the same, store them in a different folder. 4. If the same document is to be used in different service requests, you must include a

separate copy for each request, and locate each copy on a unique file path.

The following example is for a renewals only request. Note the messageType.

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <ns0:Manifest xmlns:ns0=http://www.ipaustralia.gov.au/mft/manifest xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://www.ipaustralia.gov.au/mft/manifest..\ ..\..\..\XSD\Manifest\Manifest.xsd"> <ns0:messageType>RENEWAL_REQUEST</ns0:messageType> <ns0:files> <ns0:file> <ns0:fileName>renewal.xml</ns0:fileName> <ns0:contentType>text/xml</ns0:contentType> </ns0:file> </ns0:files> </ns0:Manifest>


http://www.ipaustralia.gov.au/mft/manifest


Creating the zip file for B2B A transaction file is created as a zipped combination of two XML files and a folder containing attachments.

• manifest.xml lists the contents for the package (the 'manifest'). • The other XML file is a single request or renewal file that includes one or more service

requests) to be processed in the batch (the 'payload'). In every transaction, this file must be named renewal.xml (for renewals only based on schema 1.1) or request.xml for requests or renewals using the current schema. - For Renewals (using the Renewals V1.1 schema), the maximum number of

Renewals in each batch file is 600. - For Request batch files (using the current schema vesion), although multiple

service requests within a batch are technically possible, one service request per batch is preferred.

Assign a file name to the zipped file containing these two files based on the transaction id, for example 0000000987.zip if the transaction is issued by IP Australia is “000000000987”.

The zip file is then ready for processing by B2B.


Managed File Transfer Using the MFT folders

When you install B2B, a number of folders are installed. This section describes how each folder is used in B2B processing.

Folder Contents and use

toIPA

archive Files that have been successfully signed and transmitted to IP Australia are moved here and deleted from the /toIPA/xferFiles or /toIPA/testFiles folder.

failure If a transmission fails, the zip file is moved here and removed from the /toIPA/xferFiles or /toIPA/testFiles folder.

signerror If there is an error in signing, the zip file is moved here and removed from the /toIPA/staging or /toIPA/stagingtest folder.

staging You place zip files here for transmission to the IP Australia production system for processing. Each time a file is placed in this folder, MFT uses the signfile.bat file to create a hash file based on the contents of the zip file, sign it and move the signed hash file and zip file to the /toIPA/xferFiles folder. The unsigned hash file is deleted.

stagingtest You place zip files are here for transmission to the IP Australia test system. They will not be processed by IP Australia apart from a validation service. Each time a file is placed in this folder, MFT uses the signfile.bat file to create a hash file based on the contents of the zip file, sign it and move the signed hash file and zip file to the /toIPA/testFiles folder. The unsigned hash file is deleted.

testFiles MFT transfers the original zip file and a separate signed hash file to this folder from the /toIPA/stagingtest folder. Once files are placed here, MFT sends them securely to the IP Australia test system for validation.

xferFiles MFT transfers the original zip file and a separate signed hash file to this folder from the /toIPA/staging folder. Once files are placed here, MFT sends them securely to the IP Australia production system for validation and processing.

fromIPA

archive Not currently used.

testFiles Receives responses from the IP Australia test system. This includes all acknowledgements and validity reports, regardless of whether the processing was successful or contained errors or warnings.

xferFiles Receives responses from the IP Australia production system. This includes all acknowledgements and validity reports, regardless of whether the processing was successful or contained errors or warnings and correspondence.


Understanding the MFT process The following diagram illustrates the step-by-step sequence for processing a batch request through B2B. The path for production (live) processing only is shown.

Note: For testing, instead of the production folder /toIPA/staging, place files in /toIPA/stagingtest. MFT will process the files and move them to /toIPA/testFiles instead of /toIPA/xferFiles. Files are transferred automatically from there to the IP Australia test environment.


Start menu MFT listing Installing the MFT software creates an MFT Platform Server item in your Windows Start>All Programs menu, with a number of MFT applications.

Use this interface to start and stop the MFT server and perform other administrative functions. See the MFT Platform Server for Windows User Guide for assistance.

Note: When you use the MFT Platform Server Administrator, access it in Administrator mode.

The following example shows the MFT programs from the Windows 7 Start Programs menu.

The presentation will appear differently for Windows 8 or the Windows 12 server, although the same functions are available.


Testing transactions When testing your B2B system, first contact IP Australia to arrange a suitable time to ensure that the test system is available and that staff are available to provide support if you require it.

You can test your own XML files or use the XML files provided for testing purposes by IP Australia.

Transmitting zip files to IP Australia There are four steps to testing your transactions:

1. Create your request XML file and validate it against the B2B schema. 2. Obtain a transaction id for the IP Australia Test system (http://services-

test.ipaustralia.gov.au) 3. Create your zip file containing your manifest.xml, request.xml and any attachments in a

folder. 4. Copy the zip file into toIPA\stagingtest folder.

Note: Use the files provided in Test WSD for all testing as this involves a specific external user test environment (EUT) at IP Australia, which requires its own Web Services/HTTP request.

The file should be transferred to IP Australia within 60 seconds, and IP Australia will send an acknowledgement to confirm its receipt. You can also observe file transfer activity records yourself using the monitoring tools supplied with your software. These are described in the B2B Installation and Configuration Guide.

Testing your own XML files At this stage it is important to test that the XML files that you have created are valid and that they will be processed as required through the IP Australia system.

The IP Australia test environment has a number of IP Right identifiers reserved for testing. These will supplied to you on request so that you can test that the XML you are building is technically sound.

IP Australia is able to trace these transactions through the test system and provide feedback to you.

Going live Advise IP Australia when you intend to go live with B2B in the production environment.


http://services-test.ipaustralia.gov.au/

http://services-test.ipaustralia.gov.au/

Using B2B Submitting transactions using B2B

When the zip file is prepared, place it in your staging folder – toIPA\staging. MFT automatically handles the processing from this stage.

As specified in the batch initiation template in MFT, a separate hash file is created, based on the contents of the zip file, and a copy of the hash file is digitally signed.

The unsigned hash file is discarded and both the signed hash file and the unchanged transaction .zip file are moved automatically to the outbound folder – \toIPA\xferFiles.

The MFT system detects both the transaction file and its signed copy in your outgoing traffic folder and moves them both securely from your machine to IP Australia's site.

A copy of each file successfully moved to IP Australia is stored in an archive folder (\toIPA\archive) on your machine.

If an error occurs in signing or in processing the files, the files are moved to \toIPA\signerror or \toIPA\failure respectively. In this case, a copy is not placed in either the archive folder or the outbound folder.

Handling acknowledgements and messages When IP Australia receives a zip file, it returns an acknowledgement message. This acknowledgement will be placed in the \fromIPA\xferFiles folder.

The acknowledgement file indicates whether the file transfer was completed successfully. It does not indicate that the request was valid or processed. A separate response file, the validation response performs those functions.

Acknowledgements Acknowledgements return one of three different status messages:

SUCCESS Submitted batch file was received successfully. The digital certificate is valid. The XML is well-formed and there were no viruses in the batch file. The file proceeds to validation checking before processing.

ERROR The submitted batch file was not received successfully, a duplicate transaction identifier was used or other issues such as badly-formed XML, an unauthenticated digital certificate, or viruses were detected. All processing ceases immediately.

WARNING A technical error occurred, such as file integrity or possible virus infection. Processing is suspended and additional checks are performed before processing is resumed or abandoned. The transaction will be terminated with an error if:

• if the presence of a virus is confirmed, or

• the digital certificate is unauthenticated, or

• the XML is not well-formed, the transaction is terminated with an error.

• Filenames used for RENEWALS acknowledgements have the format 0000000987-nnn-ACKNOWLEDGEMENT_RESPONSE.xml, where '0000000987' is the transaction id, and 'nnn' is a 3-digit numeral generated by IP Australia.

• Filenames used for REQUEST acknowledgements have the format 0000000987-nnnnn-ACKNOWLEDGEMENT_RESPONSE.xml, where '0000000987' is the transaction id, and 'nnnnn' is a 5-digit numeral generated by IP Australia.

Acknowledgement file examples The first example shows the acknowledgement when the batch file is submitted successfully for the transaction id 0000000987.


<?xml version="1.0" encoding="UTF-8"?> <ns0:acknowledgement xmlns:ns0="http://www.ipaustralia.gov.au/b2b/acknowledgement"> <ns0:messageCode>M00257</ns0:messageCode> <ns0:message>The submitted batch has been successfully received.</ns0:message> <ns0:messageStatus>SUCCESS</ns0:messageStatus> <ns0:transactionIdentifier>0000000987</ns0:transactionIdentifier> <ns0:receivedDateTime>2015-09-04T12:40:29+11:00</ns0:receivedDateTime> <ns0:submittersOwnReference>RefId</ns0:submittersOwnReference> </ns0:acknowledgement>

The next example shows an acknowledgement where an error is detected because the transaction id (0000000987) has already been used.

<?xml version="1.0" encoding="UTF-8"?> <ns0:acknowledgement xmlns:ns0="http://www.ipaustralia.gov.au/b2b/acknowledgement"> <ns0:messageCode>M00194</ns0:messageCode> <ns0:message>The Transaction ID used for this batch has already been submitted and cannot be processed. Please check that you have used the correct Transaction ID before trying to resubmit. Please contact IP Australia for further assistance if you are still unable to submit the batch.</ns0:message> <ns0:messageStatus>ERROR</ns0:messageStatus> <ns0:transactionIdentifier>0000000987</ns0:transactionIdentifier> <ns0:receivedDateTime>2015-09-04T12:40:29+11:00</ns0:receivedDateTime> <ns0:submittersOwnReference>RefId</ns0:submittersOwnReference> </ns0:acknowledgement>

Validation response files The validation process checks the contents of the batch files for compliance with the rules for IP Rights renewals. Those that comply are then assessed for fee calculations.

A validation report file is returned to your \fromIPA\xferFiles folder. For each batch, this report contains itemised fee details and total charges for all fees due for valid service requests. It also includes details of invalid requests which could not be fully processed, with an explanation of why processing failed.

• Filenames for validation response files for RENEWALS have the format 0000000987-nnn-RENEWAL_RESPONSE.xml, where '0000000987' is the transaction id, and 'nnn' is a 3-digit numeral generated by IP Australia.

• Filenames for validation response files for REQUESTS have the format 0000000987-nnnnn- IPB_RESPONSE.xml, where '0000000987' is the transaction id, and 'nnnnn' is a 5-digit numeral generated by IP Australia.

Normally, within a validation report, a batch identification element includes the transaction id with a prefix of 4 alpha characters and a hyphen. For example, in a batch identifier ABCD-0000000987, the 0000000987 is the original transaction id, and the prefix ABCD is generated by IP Australia and can be used for detailed tracking of the transaction processing.

An exception to this rule occurs if all service requests in a batch are invalid. In this case, the transaction id for the batch is included in the report back to you, but there is no batch identifier, as processing of fully-invalid batches is halted before a batch identifier is allocated.

Note: Validation response files for B2B transactions are sent in streaming format which does not include line break formatting. Use a suitable XML formatting utility to view these files more easily if required.


Validation response file examples The first example shows the successful completion of processing a RENEWALS only batch for two trade mark renewals.

<?xml version="1.0" encoding="UTF-8"?> <ns1:IPRightBatchResponse xmlns:ns1="http://services.ipaustralia.gov.au/XMLSchema/Common/1"> <ns1:ResponseHeader> <ns1:SubmittersOwnReference>Opt Ref5</ns1:SubmittersOwnReference> <ns1:BatchValidationResult> <ns1:ResultStatus>SUCCESS</ns1:ResultStatus> <ns1:ResultCode>M00310</ns1:ResultCode> <ns1:ResultText>The results in this validity report are an indication only. The success of a service request is not final until fully processed in IP Australias administrative systems.</ns1:ResultText> </ns1:BatchValidationResult> <ns1:BatchRequestReceivedTimestamp>2015-09-07T15:19:53.000+10:00</ns1:BatchRequestReceivedTimestamp> </ns1:ResponseHeader> <ns1:ResponseBody> <ns1:IPABatchIdentifier>ABCD-0000000987</ns1:IPABatchIdentifier> <ns1:TransactionIdentifier>0000000987</ns1:TransactionIdentifier> <ns1:BatchTotalFeeAmount>1500</ns1:BatchTotalFeeAmount> <ns1:RequestsInBatchReceivedCount>2</ns1:RequestsInBatchReceivedCount> <ns1:RequestsInBatchWithWarningsCount>0</ns1:RequestsInBatchWithWarningsCount> <ns1:RequestsInBatchWithErrorsCount>0</ns1:RequestsInBatchWithErrorsCount> <ns1:IPRightRenewalResponses> <ns1:IPRightRenewalResponse> <ns1:SubmittersOwnReference>Own Ref</ns1:SubmittersOwnReference> <ns1:IPRight ns1:SchemaVersion="1.1"> <ns1:IPRightIdentifier>123456</ns1:IPRightIdentifier> <ns1:IPRightBusinessLine>TRADE_MARKS</ns1:IPRightBusinessLine> </ns1:IPRight> <ns1:IPRightCurrentPaidUntilDate>2015-06-13+10:00</ns1:IPRightCurrentPaidUntilDate> <ns1:IPRightNewPaidUntilDate>2025-06-13+10:00</ns1:IPRightNewPaidUntilDate> <ns1:ValidationStatus>SUCCESS</ns1:ValidationStatus> <ns1:RenewalFees> <ns1:Fee> <ns1:FeeCode>TQ02</ns1:FeeCode> <ns1:FeeDescription>Renewal of Registration (Electronic) – 2 Classes</ns1:FeeDescription> <ns1:FeeAmount>600</ns1:FeeAmount> </ns1:Fee> <ns1:Fee> <ns1:FeeCode>TEW</ns1:FeeCode> <ns1:FeeDescription>Trade Mark Renewal - Late Fee (per Class, per Month or part Month up to 6 Months)</ns1:FeeDescription> <ns1:FeeAmount>600</ns1:FeeAmount> </ns1:Fee> </ns1:RenewalFees> <ns1:IPAustraliaComment/> </ns1:IPRightRenewalResponse>


<ns1:IPRightRenewalResponse> <ns1:SubmittersOwnReference>Own Ref</ns1:SubmittersOwnReference> <ns1:IPRight ns1:SchemaVersion="1.1"> <ns1:IPRightIdentifier>654321</ns1:IPRightIdentifier> <ns1:IPRightBusinessLine>TRADE_MARKS</ns1:IPRightBusinessLine> </ns1:IPRight> <ns1:IPRightCurrentPaidUntilDate>2015-09-11+10:00</ns1:IPRightCurrentPaidUntilDate> <ns1:IPRightNewPaidUntilDate>2025-09-11+10:00</ns1:IPRightNewPaidUntilDate> <ns1:ValidationStatus>SUCCESS</ns1:ValidationStatus> <ns1:RenewalFees> <ns1:Fee> <ns1:FeeCode>TQ01</ns1:FeeCode> <ns1:FeeDescription>Renewal of Registration (Electronic) - 1 Class</ns1:FeeDescription> <ns1:FeeAmount>300</ns1:FeeAmount> </ns1:Fee> </ns1:RenewalFees> <ns1:IPAustraliaComment/> </ns1:IPRightRenewalResponse> </ns1:IPRightRenewalResponses> </ns1:ResponseBody> </ns1:IPRightBatchResponse>

The next example shows the validation response file for a standard patent examination and a request to postpone acceptance. Only one of these requests attracts a fee.

<?xml version="1.0" encoding="UTF-8"?> <ns3:IPBResponse xmlns:ns1=http://services.ipaustralia.gov.au/XMLSchema/base/1 xmlns:ns3="http://services.ipaustralia.gov.au/IPBSchema/response/1"> <ns3:ResponseHeader> <ns1:BatchSubmittersOwnReference>Own Ref</ns1:BatchSubmittersOwnReference> <BatchSubmitter>SUBMITTER</BatchSubmitter> <BatchResponse> <IPBBatchIdentifier>ABCD-0000000987</IPBBatchIdentifier> <ns1:BatchRequestReceivedTimestamp>2015-09-07T14:52:51.000+10:00</ns1:BatchRequestReceivedTimestamp> <TransactionIdentifier>0000000987</TransactionIdentifier> <BatchTotalFeeAmount>490.00</BatchTotalFeeAmount> <MainRequestsInBatchReceivedCount>1</MainRequestsInBatchReceivedCount> <MainRequestsInBatchWithWarningsCount>0</MainRequestsInBatchWithWarningsCount> <MainRequestsInBatchWithErrorsCount>0</MainRequestsInBatchWithErrorsCount> <AdditionalRequestsInBatchReceivedCount>1</AdditionalRequestsInBatchReceivedCount> <AdditionalRequestsInBatchWithWarningsCount>0</AdditionalRequestsInBatchWith WarningsCount> <AdditionalRequestsInBatchWithErrorsCount>0</AdditionalRequestsInBatchWithErrors Count> </BatchResponse> <ns3:BatchValidationResult> <ns1:ResultStatus>SUCCESS</ns1:ResultStatus> <ns1:ResultCode>M00310</ns1:ResultCode> <ns1:ResultText>The results in this validity report are an indication only. The success of a


http://services.ipaustralia.gov.au/XMLSchema/base/1

service request is not final until fully processed in IP Australias administrative systems.</ns1:ResultText> </ns3:BatchValidationResult> </ns3:ResponseHeader> <ns3:ResponseBody> <Response> <ns1:SubmittersOwnReference>Own Ref</ns1:SubmittersOwnReference> <ns1:IPRightIdentifier>2015123456</ns1:IPRightIdentifier> <IPRightRequestResponse> <ns3:ServiceRequestName>Patents Examination (Standard)</ns3:ServiceRequestName> <ns1:IPRightBusinessLine>PATENTS</ns1:IPRightBusinessLine> <ApplicationType>EXAMINATION</ApplicationType> <ns1:ResultStatus>SUCCESS</ns1:ResultStatus> <ns1:InventionTitle>TITLE OF INVENTION</ns1:InventionTitle> <AdditionalRequest> <ns3:ServiceRequestName>Request to Postpone Acceptance</ns3:ServiceRequestName> <ns1:ResultStatus>SUCCESS</ns1:ResultStatus> </AdditionalRequest> <Owners> <Owner> <ns1:Contact> <CustomerNameAddress> <Name> <PersonalName> <ns1:PersonFullName>NAME</ns1:PersonFullName> </PersonalName> </Name> </CustomerNameAddress> </ns1:Contact> </Owner> </Owners> <Fees> <Fee> <ns1:FeeDescription>Postpone Acceptance</ns1:FeeDescription> <ns1:FeeAmount>0</ns1:FeeAmount> </Fee> <Fee> <ns1:FeeDescription>Full Examination</ns1:FeeDescription> <ns1:FeeAmount>490</ns1:FeeAmount> </Fee> </Fees> </IPRightRequestResponse> </Response> </ns3:ResponseBody> </ns3:IPBResponse>


Reconciling direct debit information Once a batch is processed, an automatic deduction is made from your specified direct debit account for fees chargeable for each of the valid requests or renewals in your batch. This is likely to be initiated within 24 hours of the processing of your transaction, but may take several working days to appear in bank statements.

There are three fields included in direct debit operations that financial institutions in Australia must carry through to customer's statements – the lodgement reference, the name of remitter and the amount. For B2B transactions with IP Australia, the lodgement reference includes the batch identifier provided in your validation report. When you receive your bank statement for the direct debit account, you can reconcile each payment item with the transaction by means of its batch identifier.

Fee charge details in the validation report can provide the basis for reconciliation with bank statement details from the direct debit account.

On your validation report, the total amount for the batch is shown as follows:

<ns1:BatchTotalFeeAmount>1500</ns1:BatchTotalFeeAmount>

Individual fees for each service requests are itemised along with a description of the service request:

<ns1:Fee> <ns1:FeeCode>TQ01</ns1:FeeCode> <ns1:FeeDescription>Renewal of Registration (Electronic) - 1 Class</ns1:FeeDescription> <ns1:FeeAmount>300</ns1:FeeAmount> </ns1:Fee>

If there is no fee associated with a service request, this is also shown:

<Fee> <ns1:FeeDescription>Postpone Acceptance</ns1:FeeDescription> <ns1:FeeAmount>0</ns1:FeeAmount> </Fee>

If for any reason you have difficulty reconciling statement items with your validation reports, you should contact the Australian bank providing direct debit facilities for the full details relevant to each statement item.

Scheduling transfers You can specify how often batch jobs are triggered when files are placed in the \toIPA\staging folder. The batch job creates the signed hash file and transfers the files to the \toIPA\xferFiles folder. You can also specify how often files are despatched from \toIPA\xferFiles to IP Australia.

Transfer Properties template Use the Transfer Properties template to specify how often jobs will be triggered. The default value is 1 minute. To change this field, open the MFT Platform Server Administrator, select Transfer Properties for the template you are using, select the Schedule tab and change the value of the Interval field,

Server Properties Use the General tab in the Server Properties template in MFT to schedule transmissions to IP Australia’s B2B channel. The Dispatcher cycle field specifies the time the scheduled despatcher will wait before it checks if there are files to be transferred.


To change this field, open the MFT Platform Server Administrator, select MFT Platform Server Properties, select the General tab and change the value of the Dispatcher cycle field.

See the TIBCO MFT Platform Server for Windows User Guide for more details on tuning and scheduling your system.

Monitoring transfers You can monitor transactions in the MFT Platform Server Administrator. See the B2B Installation and Configuration Guide for more information.



Trouble shooting What messages do I get if one or more requests don’t meet regulatory or business requirements?

For each batch that you send, you receive an acknowledgement message and, provided authentication and initial validity checks are successful, a validation report.

However if any service request cannot be processed because of non-compliance with business or regulatory requirements, the validation report will contain both the fee charge details for successful requests and error messages about unsuccessful requests. Error messages will include explanations of the prime cause for the rejection of each request.

Very occasionally, exception-handling after fee calculations have been sent, can result in a failure to process a request that had earlier appeared valid. In such cases, a report will be sent to you indicating, where possible, the reason for the rejection and the amounts of any refunds payable to you.

What happens if there is an error in a request I send in a batch?

The validation report you receive for a batch indicates whether one or more requests in the batch were successfully processed (SUCCESS) or if no requests were processed (FAIL). A successful batch contains at least one successful service request, but it may also contain service requests that completed with a warning or that were now processed because of an error.

How do I know if there was an error or warning in a batch that completed successfully?

The validation report lists the status of each service request in the batch.

What happens if a service request has a WARNING but no ERROR?

Service requests succeed if they contain WARNINGS but no ERRORS. WARNINGs typically indicate additional actions that a client may need to complete or that further assessment of the service request is required.

What happens if a service request has an ERROR?

If a service request contains an ERROR, it is marked as received, but is not technically filed until the error is fixed. It will not be processed until the error is corrected.

What happens if my file can’t be authenticated by IP Australia?

If for any reason the file you transfer cannot be authenticated (for example, it involves a security failure) you will be sent an acknowledgement with a status of “ERROR” indicating authentication failure, and signalling that processing of your transaction has been terminated.

What other error or warning messages can I expect in an acknowledgement message?

Two kinds of technical error may result in warnings:

• If there is a positive virus scan of the file you have transferred, you will receive an XML message file with a Status of “WARNING”. This indicates that processing of your file has been suspended while a manual inspection is conducted to see if the scan result involves a genuine virus risk. If the risk is confirmed, you are sent another XML message file, this time with a status of “ERROR”, signalling that all processing on your file has been terminated. If the risk is found to be a false alarm, processing of your file resumes, and proceeds to checks against business rules and fee calculations. The next message you receive in this case will be a validation report.

• If there is a file integrity issue, such as non-compliant XML in your transaction file, an inability to unzip your file or excessive file size, an initial warning is sent, processing pauses, and a manual check is conducted.


If the manual check indicates the error is irretrievable, an XML message (“ERROR”) is sent and processing is terminated. If recovery is possible, processing is resumed, and a validation report can be expected for the transaction.

What format will all these messages take?

The Acknowledgement.xsd schema file is provided for acknowledgements and validation reports. The examples shown in this guide are provided to make it easier to automate any processes you wish to perform on acknowledgements, errors, warnings and validation reports.

What is an invalid service request in B2B processing?

If a service request meets any of the following criteria, it is invalid and will not be processed. Some examples of an invalid service requests are:

• the xml is not well formed or does not conform to the schema • an obsolete version of the B2B xml schema was used to create and validate the file • the transaction does not exist or has already been used • the user cannot be authenticated • the IP right number cannot be recognised • it is a prohibited patent • an IP right to be renewed has expired • an IP right to be renewed has lapsed and no extensive of time request had been filed • the details provided are not valid • the requested service is not valid for the IP right • required attachments are missing • attachments are not in valid format or too large • required information has not been supplied.

.


© Commonwealth of Australia 2015

Published by: IP Australia

Discovery House, 47 Bowes Street, Phillip, ACT 2606

1300 65 10 10

www.ipaustralia.gov.au

http://www.ipaustralia.gov.au/

Date post:	08-Feb-2018
Category:	Documents
Upload:	tranque
View:	215 times
Download:	1 times