Analysis of February 2024 Delhi High Court Judgment in InterDigital v. Oppo – II
Bank Guarantee
In the given case, the Court held the bank guarantee issued by HSBC-Paris to be unacceptable – since it does not fall within the jurisdiction of Delhi High Court. HSBC-India declined to confirm the bank guarantee citing that HSBC-India and HSBC-Paris are technically different entities (para 22).
My understanding is, the guarantee issued by HSBC-Paris was meant to secure the counter-offer made by the defendants in the global licensing negotiations. It is also irrevocable and unconditional. It can expire only upon the return of originals or will automatically expire by the stipulated deadline of 30 January 2028 (para 16). The defendants handed over the originals of the bank guarantee to ID on 13 September 2022.
I am raising certain questions here. I don’t have all the facts at this juncture and I am only trying to make a reasonable guess. It may be the case that the premises of these questions are inaccurate.
How can ID take a stand that the HSBC-Paris Bank Guarantee is totally unacceptable when the bank guarantee was issued to secure the counter offer made by the defendants on global royalty rate (which is likely to include Indian royalty rate)? Of note, the global licensing negotiations generally try to arrive at a global royalty rate with a special royalty rate for China.
Further, why did ID accept the bank guarantees on 13 September 2022 if it was totally opposed to the idea of HSBC-Paris bank guarantee securing the Indian leg of the counter-offer?
ID wanted safeguards to the effect that the HSBC-Paris bank guarantee acts as a security for the India-related proceedings and are not frustrated by proceedings elsewhere (para 17). What if there was an agreement between ID and Oppo enabling ID to realise the corresponding bank guarantee in Germany with regard to the Indian litigation? Would it have addressed ID’s concerns? I am aware that this counter-factual will have tax implications.
In the given case, the defendants gave two securities – the HSBC- Paris bank guarantee and the interim deposit mandated by the Delhi High Court. The defendants ended up furnishing two securities when the Delhi High Court did not even find a prima facie case against the defendants. Does it evince procedural fairness?
Need for a framework
The negotiations between ID and the defendants have taken almost a decade. It is too long a time period. If the defendants caused the delay, they ought to face the music. But that does not negate the requirement of procedural fairness in judicial determinations. It is high time that we develop a robust framework for handling standard essential patent disputes.
(The European framework, for example, sets out certain clear principles which go a long way in providing clarity and certainty:
Infringer can rely on a FRAND defence only when it is willing to take a FRAND license. When it is not willing to accept the offer of SEP holder, it should submit a counter offer without much delay. It should also park sufficient funds in the escrow (Huawei v. ZTE, CJEU, paras 63 and 66)
Implementer will have a tendency to delay the signing of licence until the expiration of the patent (“hold out”). If an implementer takes several months to respond to a notification of infringement, it evinces unwillingness on the part of implementer. A willing implementer should actively seek a licence in a timely manner. (German Federal Court in Sisvel v. Haier, para 85; OLG Karlsruhe in Sisvel v. Wiko, para 303; UK Supreme Court in Unwired Planet v. Huawei, para 167)
The list goes on.)
There is no case law in India that has gone into the depth of a typical standard essential patent dispute and has set out a framework for resolving SEP disputes. That should not come as a surprise. The only standard essential patent dispute to have reached finality is the one involving Philips in 2018. The tendency of litigants in SEP disputes is to settle them at some stage. If the judiciary is unable to provide a framework, the executive can step in and provide a framework.
( Will be continued… )