Backward Compatibility Sample Clauses

Backward Compatibility. (a) During the period beginning on the Effective Date and ending on the fifteenth (15th) anniversary of the Original Effective Date, to the extent that: (i) TSI makes a generally commercially available release (a “GA” release) of a version of TSI’s Rendezvous product that is not backward compatible with the immediately preceding GA version of Rendezvous; (ii) TSI replaces the TSI Product known as “Rendezvous” with another TSI Product as TSI’s flagship messaging product (the “Non-RV Flagship Product”) and the Non-RV Flagship Product does not constitute a successor product to Rendezvous (as described in Section 3.2), and such Non-RV Flagship Product is not backward compatible with the then-current GA version of Rendezvous as of the date of GA release of such Non-RV Flagship Product; or (iii) TSI makes successive GA release of a version of the Non-RV Flagship Product that is not backward compatible with the immediately preceding GA version of such Non-RV Flagship Product, then upon written notice from Reuters identifying with specificity such failure of backward compatibility and specifically referencing this Section 3.4 of this Agreement (the “BC Notice”), TSI shall use commercially reasonable efforts to enable backward compatibility between such products (whether by provision of a patch, a software tool or other mechanism) and provide such mechanism to Reuters as soon as commercially practicable. If TSI has not provided such mechanism for backward compatibility within ninety (90) days of the date of the BC Notice, then Reuters shall have the right, at any time prior to TSI providing such mechanism to Reuters (but no more than six (6) months from the date of the BC Notice), to request those portions of the Source Code for such non-backward compatible product that are necessary to enable backward compatibility, if Reuters does not already have possession of such Source Code, by written notice to TSI requesting such Source Code and specifically referencing this Section 3.4 of this Agreement. Upon receipt of such written notice, TSI shall promptly provide such Source Code to Reuters, and Reuters shall have the right to use such Source Code solely for the purpose of enabling such backward compatibility as described above, and subject to the restrictions set forth in subsection (b) below. Reuters shall have up to 12 months from the date of the BC Notice to attempt to correct the identified backward compatibility problem. For purposes of this Section 3.4, “
Sample 1Sample 2Sample 3See All (4)
AutoNDA by SimpleDocs
Backward Compatibility. Any subsequent Program will be backward compatible with the previous version of the Program provided by SA under this Agreement.
Sample 1Sample 2Sample 3
Backward Compatibility. ‌ ODV is backward compatible in the sense that existing collections and configuration files created under previous ODV versions are fully supported.‌
Sample 1Sample 2
Backward Compatibility. The Enhancement shall be backward-compatible, such that populating and broadcasting SV data containing Pseudo-LRN records will not be visible to User systems that have not performed the steps necessary to use the functionality afforded by the Enhancement. Because the Enhancement shall be backward-compatible, its mere deployment in the NPAC/SMS will not result in any obligatory changes to SOA or LSMS systems for Users not opting to use their SOA or LSMS for the functionality afforded by the Enhancement.
Sample 1Sample 2
Backward Compatibility. ‌ We built a setup for evaluating backward compatibility of FlexRay traffic that includes key sharing sequences in the Fig. 13. Signaling during key exchange between the S12X nodes at 1Mbps Fig. 14. Signaling during key exchange between the TriCore nodes at 5Mbps TABLE IV‌ Communication parameters and characteristics of the BMW 7 series FlexRay network [29]. Node count: 15 | Bit rate: 10 Mbit/s | Cycle duration: 5 ms Static segment Dynamic segment Duration 3.003 ms Duration 1.987 ms Frame 16 bytes Frame 2-254 bytes Static slot count 91 Minislot count 289 Static slot duration 33 µs Minislot duration 6.875 µs Fig. 15. FlexRay communication cycles including key sharing traffic symbol window within a network with nodes that do not implement this mechanism. Two EVB9S12XF512E develop- ment boards were used as standard nodes to implement classic FlexRay communication at 10 Mbit/s. The communication cycle was configured to include all FlexRay segments (static, dynamic, symbol window and network idle time). The key sharing sequence was generated and sent from the TriBoard environment using a bit rate of 5 Mbit/s. We monitored the overall communication as well as the status returned by communication controllers from the S12XF microcontrollers for protocol error detection. There are several use cases to consider for key sharing sequence transmission. First, we evaluated the case of sending the key sharing sequence in the symbol window segment without collisions with symbols sent by standard nodes, as illustrated in Figure 15. This generates a symbol window syntax error on the receiving nodes since the key sharing sequence does not fit any of the specification defied sym- bols. This error is not used in the FlexRay automatic error confinement mechanism and does not generate message loss or communication halt. It is reported to the application layer where specific measures can be implemented. So the actual behavior of detecting such errors is application-specific. A standard node sending one of the two predefined symbols allowed in the symbol window (MTS or WUDOP) while the key sharing operation is ongoing will lead to collisions and will also generate to a symbol window syntax error being reported by the communication controller. Additionally the key sharing operation will fail due to the unsuccessful execution of the protocol verification step. In such cases nodes implementing the key exchange can retry the operation after waiting for several cycles in which standard...
Sample 1
Backward Compatibility. Any subsequent Program will be backward compatible with the previous version of the Program provided by S-A under this Agreement.
Sample 1
Backward Compatibility. Supplier shall cause each Software revision level, during the Software Warranty Period or such longer period not to exceed [***] as Mirror continuously maintains and pays for Software maintenance in accordance with this Agreement, to be backwards compatible with existing Software and the immediately preceding Software Patches made available to Mirror by Supplier.
Sample 1
AutoNDA by SimpleDocs
Backward Compatibility. Transcrypt may sell PRODUCTS incorporating MOTOROLA analog trunking, or MOTOROLA proprietary 12 kBs encryption only to those customers who have purchased or are in the process of purchasing ASTRO(R) or APCO 25 compliant digital Infrastructure.
Sample 1
Backward Compatibility. All scripts written for version 2.2 should still work with version 2.3, with the following exceptions: • You can no longer use the Justification command with TextObjects (see the section on minor changes above). The Justification command can still be used with TextBoxObjects. • The TextColor and BoxColor commands have been eliminated (see the section on minor changes above). However, it should be noted that version 2.3 involves major changes to the code base of the program, and there may be effects of these changes beyond those noted above.
Sample 1

Related to Backward Compatibility

  • Compatibility 1. Any unresolved issue arising from a mutual agreement procedure case otherwise within the scope of the arbitration process provided for in this Article and Articles 25A to 25G shall not be submitted to arbitration if the issue falls within the scope of a case with respect to which an arbitration panel or similar body has previously been set up in accordance with a bilateral or multilateral convention that provides for mandatory binding arbitration of unresolved issues arising from a mutual agreement procedure case.

  • Traceability 11.1 Under the terms of this Agreement, Supplier shall have and operate a process to ensure that all Products, sub-assemblies and the components contained therein supplied to the Buyer are completely Traceable back to manufacturer by batch or lot or date code.

  • Speed The relative importance we attach is “high”.

  • Hardware and Software Requirements In order to access and retain Disclosures electronically, you must satisfy the following computer hardware and software requirements: access to the Internet; an email account and related software capable of receiving email through the Internet; a web browser which is SSL-compliant and supports secure sessions, and hardware capable of running this software.

  • Year 2000 Compliant Borrower shall perform all acts reasonably necessary to ensure that (a) Borrower and any business in which Borrower holds a substantial interest, and (b) all customers, suppliers and vendors whose compliance is likely to be material to Borrower's business, become Year 2000 Compliant in a timely manner. Such acts shall include, without limitation, performing a comprehensive review and assessment of all Borrower's systems and adopting a detailed plan, with itemized budget, for the remediation, monitoring and testing of such systems. As used in this paragraph, "Year 2000 Compliant" shall mean, in regard to any entity, that all software, hardware, firmware, equipment, goods or systems utilized by or material to the business operations or financial condition of such entity, will properly perform date sensitive functions before, during and after the year 2000. Borrower shall, immediately upon request, provide to Agent such certifications or other evidence of Borrower's compliance with the terms of this paragraph as Bank may from time to time require.

  • Monitoring System In each case in which the Custodian has exercised delegated authority to place Assets with a Foreign Custodian, the Custodian shall establish a system, to re-assess or re-evaluate selected Foreign Custodians, at least annually in accordance with Rule 17f-5(c)(3).

  • Customer Service A. PRIMARY ACCOUNT REPRESENTATIVE. Supplier will assign an Account Representative to Sourcewell for this Contract and must provide prompt notice to Sourcewell if that person is changed. The Account Representative will be responsible for: • Maintenance and management of this Contract; • Timely response to all Sourcewell and Participating Entity inquiries; and • Business reviews to Sourcewell and Participating Entities, if applicable.

  • Interfaces Bellcore’s GR-446-CORE defines the interface between the administration system and LIDB including specific message formats. (Bellcore’s TR-NWP-000029, Section 10)

Time is Money Join Law Insider Premium to draft better contracts faster.