License – Automated Check-in API
In London, 1st of June 2015
This LICENSE AUTOMATED CHECK-IN API (the “License”) is entered into as of the date of accessing the technical specifications of the API or using the services rendered by the API, by and between Advanced Travel Technologies, Ltd., 11 Staple Inn, London WC1V 7QH, England, registered at the Companies House 9555646, (the “Contractor”) and the company or individual using the services through accessing the API (hereinafter the “API Client”), (individually, a “Party” and collectively, the “Parties”.
This license may be an Annex to a Master Services Agreement entered if applicable into between the Parties (the “MSA”).
This License will be governed by the terms and conditions contained below, and if applicable in the MSA. Unless otherwise provided in this License, all regulations of the MSA shall apply to this License.
In the case of a conflict between the terms and conditions described in this License and the MSA, this License will overrule the MSA. In case of separately signed Terms of Service with the API Client for using the services included in the API, the such, in case of conflict, shall prevail over the terms of the license contained herein.
Any capitalized terms used in this License and not otherwise defined will have the meanings given to them in the MSA.
This License shall provide the terms and conditions applicable to the Services, as well as (i) general acceptance criteria for the Services, (ii) Services ordered and the associated pricing, (iii) Services implementation details and applicable customizations as well as additional rates for customization of Services, (iv) rollout schedule in terms of further markets and customer segments or features of/for the Services, and (v) applicable service level commitments of the Contractor.
All the above terms are made a part of this License through incorporation in this License or by reference and through amending the relevant Annex. By accepting this License, the API Client represents that it has read and agreed to such terms and the terms of this License. The Contractor shall only accept the provision of the Services by signing this License. The Contractor’s provisioning of the Services shall indicate its acceptance to provide the Services.
In consideration of the representations, warranties, mutual covenants and agreements set forth in this License, the Parties agree as follows:
TABLE OF CONTENTS
Table of contents
(1.1.) By signing this License, The Contractor will provide to the API Client a flight check-in service (“Automated Check-in”), which shall allow the API Client to offer to their end user(s) the option of being checked in on booked flights with almost no further end user action required and to deliver all required boarding passes (hereinafter, the “Services”).
(1.2.) The automated check-in can be broken down into the following phases:
(1.2.a.) Upon end user(s) completion of the flight booking, either through the API Client’s self-owned interface(s), webpage(s), mobile application(s) and/or merchant(s) (hereinafter “API Client Systems”) or through a third party flight booking provider, the end user(s) receives the offering to be automatically checked into the regarding flight.
(1.2.b.) The API Client submits a request to perform the check-in (hereinafter “Check-in request” to the Contractor through the provided communication interface (eg. API);
(1.2.c.) Prior to check-in, end user(s) shall have the chance to change certain preferences (e.g. preferred seats, boarding pass formats, etc.). The Service shall be performed either way the end user(s) changes flight preferences or not;
(1.2.d.) The Contractor performs the flight check-in;
(1.2.e.) The Contractor provides access via an URL to download or delivers the boarding pass to the API Client or to the end user(s) via typical messaging methods (eg. email, mobile notifications or SMS) hereinafter “Message”.
(1.3.) Prior to offering the Services to the end user(s), the API Client shall verify the availability of the Automated Check-in with the end user(s) itinerary and airline. Such verification may be accomplished through an Application Program Interface (hereinafter “API”) call to the Contractor’s servers.
(1.4.) Once the availability of the Automated Check-in service is successfully verified and granted, a check-in request shall be sent to the Contractor by:
(1.4.a.) An API call from the API Client to the Contractor’s servers. The API will respond with a check-in request ID that can be used by the API Client for further reference; so called “API Client sided request”.
(1.4.b.) By sending to the end user(s) a message containing a button (which may be titled “Activate now”) in order to activate the Automated Check-in. This button shall include a link to a “deep URL” containing the passenger information and the booked flight; so called “End user sided request”.
(1.5.) For the proper performance of the Services by the Contractor, the gathering of the certain data is necessary:
Table 1: required data for flight check-in
The latest valid set of required data is specified in the according Application Programming Interface.
On certain routes and/or airlines exceptions may apply which shall be documented in a “Service Implementation” documentation that shall outline the requirements and case-to-case details for the provision of the Automated Check-in service.
(1.6.) When any of the data needed by the Contractor is not gathered by the API Client during or post flight booking, the Contractor can through its iFrame, which is a frame that allows a visual HTML Browser window to be split into segments, each of which can show a different document, being dynamically displayed to the end user(s), gather the missing data information required for the provision of the Services. If such gathering shall be performed by the Contractor depends on the implementation scheme agreed with the API Client.
(1.7.) Once the Contractor has been provided with all needed data and at the earliest opportunity prior to departure, the Contractor will process the check-in request and deliver the end user(s)’s boarding pass. Such boarding pass will be alternatively send:
(1.7.a.) Directly through a message to the end user(s);
(1.7.b.) In a message to the API Client with sufficient metadata to be forwarded to the end user(s); or
(1.7.c.) As an HTTP POST message that the API Client can process in whichever way the API Client desires.
All email messages will be formatted in HTML and, subject to any agreed Customization in the relevant annex, customized to be consistent with layout requirements (eg. branding) of the API Client. Limitations of such customizations may apply in order to grant certain performance levels when providing the service.
(1.8.) For further comprehension of the Services, the flow of events will be as indicated below:
Diagram 1: Flow of events
This flow of events shall serve as a basis of understanding of possible events and its typical order, but not represent a precise and binding order in which events have to occur as the Automated Check-in service may be offered prior to flight booking. However, logical constraints such as the delivery of the boarding pass post-check-in apply.
(1.9.) When the API Client intends to offer the Contractor’s Services to other third parties so that they can offer the Contractor’s Services to their end user(s), the API Client shall mandatory request the Contractor prior written authorization and the API Client shall demand this other third party the same terms and conditions and agreed among the Contractor and the API Client. In such event, the Parties shall negotiate in good faith any further agreement to be subscribed.
(2.1.) The API Client shall use the Services in accordance with all applicable laws, rules and regulations and in accordance with the MSA. The API Client shall use the service for the sole purpose of offering, distributing and reselling the Service to end-customers, either free or for a price to be paid by the end-customer (“Permitted use”).
(2.2.) As agreed among the Parties in the MSA, the API Client shall not copy, modify, resell or redistribute the Contractor’s Platform, create or recreate the source code for the Platform or any other software included in the Service, or re-engineer, reverse engineer, decompile, disassemble the platform, or attempt in any way to disable, deactivate or render ineffective the security, encryption or password protection of the Platform.
(2.3.) The Contractor is not responsible for the configuration of, or internal equipment for, the API Client’s interface(s) that may be necessary to the successful provision of the Services, and therefore, the Contractor shall not be responsible for any underperformance or malfunction of the Services caused by the API Client’s unfitness of its interface(s). In this sense, the Parties shall collaborate in good faith, so that the provision of the Services reaches the desirable performance.
(2.4.) In addition to the aforementioned, the API Client understands and agrees that the performance of the Services may be dependent on API Client’s timely and effective performance of its responsibilities. The API Client agrees to undertake its responsibilities described in this License. Tasks that are primarily the responsibility of the API Client’s personnel will remain the API Client’s responsibility, even if the Contractor assists the API Client in performing such tasks.
(2.5.) The accuracy of the content of messages sent out to end user(s) are essential to the successful provision of the service towards end user(s) and shall create no confusion at all. Therefore all messages shall reflect the actual flight associated with each end user(s) being flight numbers and airline. Whenever such messages are sent out to end user(s), these messages shall be provided with no variation to the agreed content which shall be approved prior in written between both parties; foreseen through the documentation of the “Service Implementation”.
(2.6.) For as long as the Contractor provides the Services to the API Client, and unless otherwise agreed, the API Client shall remain proprietary of the end user(s) data and shall be granted access to such data by the Contractor.
(2.7.) The API Client shall be the owner of all payments collected by or through him, and not have any obligation to forward such payments partially or in full to the Contractor, unless otherwise agreed in this Agreement, eg, in annex “Pricing and Payment”.
(3.1.) The following annexes may become part of this agreement or added later on, but are not limited to:
Annex - Acceptance Criteria
Annex - Pricing and Payment
Annex - Service Implementation / Customization
Annex - Rollout Schedule
Annex - Service Level Agreement (SLA)
Annex - Performance Reports
Annex - Terms and Conditions for end users
All annexes are, if agreed between both parties and amended an integral part of this License and prevail - if they contain different rules - over the License.
(4.1.) The Contractor has no ability to regulate the accuracy of, and makes no claim to accuracy, the information provided by the API Client for/in the provision of Services by the Contractor.
(4.2.) The Contractor offers and provides the Services to the API Client and to the API Client’s end user(s) through the API Client Systems, which is not owned, operated nor managed by the Contractor. The API Client’s use of the Services is solely at API Client’s own risk and is subject to all applicable local, state, national and international laws and regulations.
(4.3.) The Parties acknowledge that the provision of the Automated Check-in services operated through the Internet on the API Client Systems, has access to the Internet and therefore is dependent on numerous factors, technologies and systems, which are beyond the Contractor’s authority and control.
(4.4.) The Automated Check-in service is subject to the availability and support by the relevant airline and/or airport systems and integrations of the Contractor’s servers and processing infrastructures. See also “SDW Service” under clause 6.3.3.
(4.5.) The Contractor shall hold no responsibility nor liability in relation to the API Client and the end user(s) for an unsuccessful provision of the Services when:
(4.5.a.) The relevant airlines, airports and/or authorities of any kind deny the end user(s) flight check-in;
(4.5.b.) Any of the data provided to the Contractor is inaccurate, incomplete, false or not provided in due time;
(4.5.c.) The airline and/or airport system suffers from an outage or shutdown, preventing the Contractor from the proper and agreed provision of the Services;
(4.5.d.) During the check-in, the preferred seat marked by the end user(s) has been unavailable;
(4.6.) The Contractor shall hold neither responsibility nor liability in relation to the API Client or any other third Party when the API Client’s end user(s) turns out to be a terrorist, hijacks any plane or person, carries out a bomb into the airport or airplane or any other explosive device or conducts any other illegal or unauthorised action.
(4.7.) Whenever a API Client’s end user(s) has voided an authorization for payment or the payment itself to API Client related with the provision of Automated Check-in service to the end user(s), the API Client shall not in any way be released from the payment to the Contractor in accordance with the agreed pricing.
(5.1.) During the provision of the Services, and complementary to clause 5 of the MSA, API Client undertakes to:
(5.1.a.) Provide in due time and form to the Contractor any and all end user(s) data needed for the execution of the Services;
(5.1.b.) Obtain all needed authorizations from the end user(s), including the authorization to transfer their personal data to the Contractor for all purposes included in the provision of the Automated Check-in, included but not limited to, the Contractor’s right to represent the API Client before any relevant authorities and other entities required for the proper performance of the check-in and/or booked flight (such as airlines, airports, immigration and customs authorities, etc…);
(5.1.c.) Collect, where applicable, a payment from his own customers for the Services.
(5.1.d.) When the API Client offers or provides the Services provided by the Contractor under this License, the API Client shall announce such service always as “powered by [commercial name of product or service]”. According logo and design will be provided by the Contractor and may change over time.
(5.1.e.) Duly document on the Contractor’s request where, when and how the Services are being or have been offered incl. if not to end user(s);
(5.1.f.) The API Client will not access or use the Contractor’s Services in a way, intended or unintended, to avoid incurring fees or to exceed the agreed scope of the Services;
(5.1.g.) The API Client will not share passwords or other access information or devices or otherwise authorize any third party, to access or use the Services;
(5.1.h.) The API Client will obtain, at its own expense, all rights necessary from any third party needed for the proper performance of the Services by the Contractor.
(6.1.) For the case that any foreseeable or unforeseeable exception of the provision of the services results in a check-in not being able to be processed successfully in the manner to issue and/or deliver a boarding pass for the end user, the the Contractor platform delivers a Message to the end user(s) or the API Client (according to agreed Service Implementation) with the corrective action, in most of such cases being “perform check-in at airport”.
(6.2.) Foreseeable exceptions
(6.2.a.) There are numerous foreseeable exceptions all being documented on a periodical basis in a separate technical document called “Automated Check-in API Specification” under section “Error Codes” which on request is provided to engineers of the API Client for setup, integration and maintenance of the Automated Check-in service.
(6.2.b.) A very common exception is a flight that has been changed post submission of a check-in request of the API Client to the Contractor, for which if the Partner has no knowledge of any of these changes, the Contractor - not being the booking merchant - has although given technical possibility on constant PNRs, no consultation rights of those booking changes none withstanding technical integrations to travel or booking distribution systems, airlines, or airports. However, if the API Client has knowledge of those changes, the API Client shall submit those changes to the Contractor through the integrated interface (eg. API) indicating the regarding check-in request ID provided when requesting a check-in. The Contractor then updates the internal queue of pending check-ins regarding the impacted records (eg. on multi-passenger booking PNRs).
(6.3.) Unforeseeable exceptions
(6.3.a.) Unforeseeable issues arising from service provision will be, once sorted out and accordingly agreed with the API Client, annexed to this agreement if considered necessary by one of both parties. If issues are of technical of technical nature they shall become part of the relevant technical documentation.
(6.3.b.) In general, all unforeseeable technical or regulatory exceptions in direct relation with the provision of the service shall be within the comprehension of the Automated Check-in being a service that is (a) required to dynamically updating its integration layers and processing infrastructure components, and (b) provided between a constantly changing technological and regulatory environment. These changes require constant and unpredictable pace of maintenance of the service performing platform. Based on this understanding, both parties sort out performance issues due to unpredictable changes on a good faith and efforts basis and on a partner basis.
(6.3.c.) The technical solution the Contractor provides in order to limit unforeseeable exceptions arising from the provision of the service is a feature the Contractor calls “Smart Dynamic Whitelist” (hereinafter “SDW Service”) which provides the availability of given routes for the Automated Check-in service as described under 1.3 of “1. Description of the Service”.
This dynamic and smart character of the SDW Service, beyond the provision of availability of a given route, limits exceptions through an additional functionality in regards to routes becoming unavailable post check-in request, meaning (1) for end users to which the Automated Check-in service has been offered, for which later on when the time of processing the check-in arrives, and at this moment the check-in becoming unavailable for not just the first check-in opening route, but all end users who have a check-in pending on this route, in the following way:
When first time requesting a given route, the whitelist replies with “route available”, but then always replies “unavailable” until the actual check-in has been completed. Once a check-in has been completed successfully, the Contractor re-enables the given route within the whitelist.
The Contractor calls this procedure “Service Calibration” and may be undertaken on a periodical basis and be understood as a predictable scheduled Downtime for maintenance and quality assurance purposes. However this Service Calibration shall not be considered against the calculation of the availability percentage target of the platform or service. The API Client shall not be entitled to receive any compensation for such “service calibrations” meaning certain unavailability of the service. The Contractor compromises on scheduling such Service Calibration on basis of an artificial intelligence algorithm incorporated into the SDW Service intending a machine based distribution of calibration for a maximized stability of the service coverage across all supported routes.
The here listed terms apply for the Services rendered through the Platform, except for professional services (eg. consulting), that may be provided as well by the Contractor to the API Client:
(7.1.) Maintenance activities: In order to maintain and improve the functionality, performance and reliability of the Platform and the Services provided, it will be necessary to perform regularly recurring maintenance activities as well as needed emergency maintenance. While the majority of maintenance activities do not impact availability or otherwise affect the Platform or the provided Services, it will be necessary, on occasion as part of either regular recurring maintenance activity or an as-needed emergency maintenance, to conduct a predictable scheduled, Downtime. All scheduled maintenance shall be notified in advance to the API Client and the Contractor shall use best efforts to schedule same from Monday to Friday between 12a.m - 6 a.m. EST, not more than 2 hours a week.
(7.1.a.) A predictable scheduled downtime shall be a pre-planned period during which the availability, functionality or performance of the platform or the Contractor’s services may be impacted or affected, for which the API Client has been given prior notification. When predictable scheduled maintenance to the Platform is required, this will be announced by the Contractor with a notice period of three working days. The maintenance shall be carried out by the Contractor in such a way to minimize adverse effects to API Client. Further, such predictable scheduled Downtime is limited to 3 hours/month. A predictable scheduled Downtime will be conducted during times when the Services are not in high demand, whenever possible. Predictable scheduled maintenance downtimes shall not be considered against the calculation of the availability percentage target of the Platform or Service. The API Client shall not be entitled to receive any compensation for such interruptions.
(7.1.b.) If any unexpected maintenance to the Platform is necessary to maintain system functionality and initiated by the Contractor, then the Contractor shall inform the API Client immediately, and with as much advance notice as possible, indicating the start and end time then foreseeable, especially if such maintenance requires a scheduled Downtime. If unexpected maintenance or error solving measures are necessary for reasons originating solely from the API Client, this downtime will not be considered in the calculation of the availability percentage and the API Client shall not be entitled to receive any compensation for such interruptions.
(7.1.c.) Maintenance Notifications: The Contractor will notify the API Client of the described maintenance events and potential Scheduled Downtime via e-mail to the e-mail address(es) specified in the relevant Terms of Service, or to other email address(es) indicated by the API Client to such effect).
(7.2.) Support: The Contractor provides a support service (the “Support Desk”) which is the single point of initial contact for the API Client to open a troubleshooting case with or obtain support information for the Services. Support Desk is available from 8 AM to 8 PM C.E.T., Monday to Friday, excluding Spanish public holidays (respectively “Business Hours” and “Business Days”). The Contractor shall provide maintenance and support services regarding the provided Services in accordance with API Client’s instructions. The Contractor shall solve demands between 24 hours and 72 hours, not being subject to any warranty.
(7.3.) The contractor shall provide the Service at the agreed Service Level as agreed in the Terms of Service. Notwithstanding this section, the Contractor shall not be liable to the API Client if the Contractor fails to achieve the relevant Service Level is caused directly or indirectly and exclusively by any act or omission of the API Client or by reason of an event of force majeure.
(7.4.) If no MSA has been agreed, then the above terms shall apply, else the agreed terms within the MSA under “8. Availability / Maintenance / Troubleshooting / Support” shall apply.
(8.1.) The API Client acknowledges and agrees that the Platform is of the exclusive property of the Contractor, that the property of the Contractor’s title to it shall remain fully vested with the Contractor and that nothing in this Agreement shall be construed as an assignment or transmission of any intellectual property rights worldwide, including without limitation any and all patents, applications for patents, utility patents, design patents, copyrights, trademarks, trade secrets, moral rights, database rights, topography rights, character rights, rights of publication, trade dress, drawings, specifications, manuals, documents, data and software, and any other worldwide intangible or tangible right related to material belonging to the Contractor which are not granted herein (hereinafter, “IP Rights”).
(8.2.) The API Client shall be granted a non-exclusive license, with the right to sublicense to its Group Companies, to use such IP Rights for the purpose of this Agreement. The API Client, undertakes to return and/or destroy such information and documentation upon request in writing by the other Party, at the termination of this Agreement.
(8.3.) No rights are granted to the API Client hereunder other than as expressly set forth herein. In addition, the Contractor shall own all rights, title, and interest, including intellectual property rights, in and to any improvements which are strictly connected to the Platform, including without limitation those relating to any new programs, upgrades, modifications, refinements, or enhancements (collectively, “Customization”) developed solely by or for the Contractor which are strictly in connection with the Platform or Services to the API Client, even when such Customization results from API Client’s request.
(8.4.) To the extent, if any, that ownership in such Customization shall be vested in SATS as per clause 3 above but it does not automatically vest in the Contractor by virtue of the Agreement or otherwise, the API Client hereby waives for the Contractor all rights, title, and interest that the API Client may have in and to such Customization, unless such Customization has been developed solely by the API Client (incl. its subcontractors and consultants), and unless otherwise agreed between the Contractor and the API Client.
(8.5.) Any customization or development not strictly related to the Platform and which has been developed as a customization specifically for the API Client, and paid separately by the API Client, shall be owned by the API Client and more in particular, no license or other right to use that particular customization shall be granted unless agreed with the API Client.
The API Client shall be considered as sole owner of the intellectual property rights of such customization described in this paragraph (5). For as long as the Contractor provides Services to the API Client, the API Client shall grant a non-exclusive, worldwide, royalty free license for use the Customization intellectual property rights to the sole extend of the provision of the regarding Services. For the avoidance of doubt, upon termination of the relevant Terms of Service under which the software development has been ordered, the aforementioned license shall be automatically extinguished and the Contractor shall immediately cease its use.
(8.6.) For the avoidance of doubt, all data provided between each Party to perform the relevant Services, shall be and at all times remain in the ownership of the disclosing party. Neither Party shall use these data in any manner whatsoever other than as is necessary to comply with its obligations hereunder or under the applicable Terms of Services. For the processing of data under this Agreement the parties agree on the Data Processing Agreement included in annex hereto.
(8.7.) The Parties shall fulfil their respective contractual obligations, without infringing third party rights (including but not limited to the potential infringement of third party right resulting of transmission, the use and the linking of data). Should third parties claim compensation from a Party (the Indemnified Party) on the basis of actual infringement by the other Party (the Indemnifying Party), the Indemnifying Party shall indemnify the Indemnified Party being sued in full, shall take immediate action and shall be liable to compensate the Party being sued for the costs of the proceedings.
(8.8.) If no MSA has been agreed, then the above terms shall apply, else the agreed terms within the MSA under “10. Intellectual property and other proprietary rights” shall apply.
(9.1.) The Contractor reserves the right, at its sole discretion, to decline the provision of other services, which will be subject in any case to the subscription of the relevant License.
(9.2.) The Contractor may reject the provision of any other services that diverge in any respect from the Services agreed herein or if the Contractor is technically unable to provide such other services as ordered.
(10.1.) The Contractor may at its discretion maintain or undertake agreements (a) with subcontractors acting on behalf of the Contractor, or (b) to subcontract Services or parts of the Service established herein to third parties.
(10.2.) Subcontracting third parties will not relieve the Contractor’s obligations and responsibilities towards the API Client deriving from this Agreement. In this regard, the Contractor shall ensure that the subcontracted third parties are fulfilling the obligations assumed by the Contractor by virtue of this License and the MSA.
(11.1.) The Contractor warrants that the Services will be performed in a professional manner, pursuant to generally accepted industry standards and practices for similar services, and the Contractor further warrants that services shall conform to the MSA. Moreover, the Parties fully subscribe to “11. Warranties and Disclaimers” set forth in the MSA.
(12.1.) The API Client hereby agrees to defend, indemnify and hold the Contractor, its affiliates, directors, officers, employees and contractors harmless from any and all third party claims, liabilities, losses, damages, expenses, or causes of action, including, without limitation, reasonable legal fees and expenses arising from or in connection with:
(12.1.a.) the API Client’s services or product to any end user(s) via any method whether permitted or prohibited by law;
(12.1.b.) the API Client’s illegal use of, or any misuse of any Service in violation of this License or any additional terms and conditions associated with the Services (including the MSA), laws, rules or regulations (including any and all such illegal use or misuse by the API Client’s employees, agents, and contractors);
(12.1.c.) bodily injuries (including death) to any person, damage to any property, real or personal (public or private) occurring directly or indirectly by virtue of the API Client’s services or products; and
(12.1.d.) any gross negligence or wilful misconduct of the API Client.
(13.1.) This Agreement is effective from the Effective Date for a period of 12 months (Initial Period). After the Initial Period this Agreement shall be tacitly extended for one (1) year periods, each a “Term”, unless terminated by either party upon thirty days prior written notice to the other party. Termination of this Agreement will automatically terminate any valid Terms of Services remains in force among the Parties.
(13.2.) Without prejudice to any other rights to which it may be entitled, either Party may give notice in writing to the other terminating this Agreement and/or any Terms of Service with immediate effect if:
(13.2.a.) the other Party commits any material breach of any of the terms of this agreement and (if such a breach is remediable) fails to remedy that breach within 30 days of that party being notified of the breach; or
(13.2.b.) an order is made or a resolution is passed for the winding up of the other party, or an order is made for the appointment of an administrator to manage the affairs, business and property of the other Party, or such an administrator is appointed, or a receiver is appointed of any of the other Party's assets or undertaking, or circumstances arise which entitle the Court or a creditor to appoint a receiver or manager or which entitle the Court to make a winding-up order, or the other party takes or suffers any similar or analogous action in consequence of debt, or an arrangement or composition is made by the other Party with its creditors or an application to a court for protection from its creditors is made by the other party.
(13.3) The API Client is entitled to terminate this Agreement immediately by providing a notice of termination if the Contractor:
(13.3.a.) fails to provide the Services in compliance with the agreed Service Levels;
(13.3.b.) fails to perform any specific Customization as provided herein.
(13.3.c.) breaches clause 11(2) above, and did not repair such breach within 15 days after the the API Client´s notice to the Contractor.
(13.4.) The rights and obligations included in the following Sections shall supersede the termination of this Agreement and, therefore, remain enforceable between the Parties: Sections 4, 5, 8, and 11.
(13.5.) Upon termination this Agreement or the termination of any Terms of Service, each Party must promptly, permanently and irreversibly erase all copies of the other Party’s Confidential Information from the computers, servers and other storage devices of such Party , and return to the other Party or, at the other Party’s request, destroy all copies of such Party’s Confidential Information in the possession of the Party and certify in writing to the other Party that it has fully complied with these requirements.
(13.6.) If no MSA has been agreed, then the above terms shall apply, else the agreed terms within the MSA under “14. Duration and Termination” shall apply.
(14.1.) Save as expressly provided in this Agreement, no amendment or variation of this agreement shall be effective unless in writing and signed by a duly authorized representative of each of the Parties.
(14.2.) No failure or delay by either Party in exercising any right under the Agreement shall constitute a waiver of that right. Other than as expressly stated herein, the remedies provided herein are in addition to, and not exclusive of, any other remedies of a Party at law.
(14.3.) Any notice required to be given pursuant to this Agreement, shall be in writing and shall be given by delivering the notice by hand at, or by sending the same by prepaid first class post to the address of the relevant party as set out here below or such other address as either party notifies to the other from time to time. Any notice given according to the above procedure shall be deemed to have been given at the time of delivery (if delivered by hand) and when received (if sent by post).
In the case of the Contractor to:
Advanced Travel Technologies, Ltd.
11 Staple Inn, London WC1V 7QH, England
In the case of the API Client, all notifications will, if applicable, be notified to the agreed address for notifications, and/or published on the website containing the technical specifications. If no address for notifications has been agreed, then it is an API Client responsibility to check periodically if there are any relevant notifications, eg, scheduled downtimes of the services or relevant changes of how the API works.
(14.4.) Neither Party shall without the prior written consent of the other Party assign, transfer, change or deal in any other manner with this Agreement or its rights under it or part of it, or purport to do any of the same. Both parties are entitled to assign, novate or transfer this Agreement or any of the rights and obligations under this Agreement to any Group Company without the prior consent of the other Party, however subject to a fifteen 15 (fifteen) days prior written notice to the regarding party.
(14.5.) If any part of this Agreement becomes invalid, illegal or unenforceable, the Parties shall negotiate in good faith in order to agree the terms of a mutually satisfactory provision to be substituted for the invalid, illegal or unenforceable provision which as nearly as possible validly gives effect to their intentions as expressed in this Agreement.
(14.6.) This Agreement constitutes the entire understanding between the Parties with respect to the subject matter of this Agreement and supersedes all prior agreements, negotiations and discussions between the Parties relating to it. No general terms and conditions of either Party shall apply to the subject matter of this Agreement.
(14.7.) In the event of a dispute between the Contractor and the API Client with regard to this Agreement, the Contractor and the API Client agree to use best efforts to resolve each dispute in good faith. If such resolution attempt fails within thirty (30) business days, each party may terminate this agreement upon and additional thirty (30) days’ notice to the other.
(14.8.) This Agreement is subject to Laws of England and Wales. Any dispute between the Parties resulting from this Agreement shall be submitted to the exclusive jurisdiction of the Courts in London.
(14.9.) If no MSA has been agreed, then the above terms shall apply, else the agreed terms within the MSA under “15. Final Provisions” shall apply.