IP Commercialisation – Case Study Related to Software /IT Industry

Prologue:

IP commercialization entails that one has the necessary intellectual property rights on the IP being commercializated and the commercialization would essentially have two parts – IP valuation and the consideration (fees).

In this article we look at the commercialization aspects of the intellectual property rights in software; through the case study approach.

Valuaton and Licensing (not Assignment):

2. Commercialization

In order to commercialize, decision has to be taken whether the IP would be assigned or licensed out. Assignment, in lay man’s terms is equivalent o selling off; while in licensing the ownership would be retained and the licensee would pay license fees. In this write-up we are considering, the case where the ownership of the software is retained by the organization that develops it and a revenue model would be established which can bring in one time or distributed (continuous or staggered) revenue.

2.1 IP in software

Software can be sought to be protected from an IP perspective, through patents, copyright, trade secrets and trademark; or a combination of these.

2.2 Software Licence

The end-user license agreement (EULA) of the software should contain a framework – a skeleton – which provides support for other clauses or systems of clauses in the License Agreement. The license thus granted can be exclusive licence, sole licence or non-exclusive licence; with or without provision for “sublicense” of the rights granted to the licensee.

A Commercial Software Product:

3. Redspark for IoT Billing

The Connected Suite IoT (Redspark) of Optiva Solutions (formerly Redknee Solutions) enables monetization of smart services and applications. Data and events from connected devices as well as other billable content is analyzed and processed in real-time to generate online billing information as well as to trigger immediate customer engagement activities. The Connected Suite IoT supports subscription based as well as usage and consumption based monetization models, in order to enable the business model that fits the service provider’s business requirements – even if models dynamically change over time along with the surrounding business conditions. The Connected Suite IoT supports vertical agnostic, agile billing functions.

The underlying, telco-proven product platform allows creation of arbitrary, complex monetization models while the Connected Suite IoT provides tools to hide most of the complexity for simple and easy utilization experience.

3.1 IoT Monetization

The IoT is not a clearly defined market with specified services and established business models. Rather, a variety of industries with different market segments is going to make use of connected devices building value propositions and services being offered to others. Even further, offered services and business models would evolve and, thus, would be subject to change over time.

3.2 Product Concept

Using the core parts of REDKNEE’s telecommunication portfolio, all well-proven capabilities of tariff complexity, scalability and stability can be provided for IoT applications and services as well. The same time, the REDKNEE Connected Suite IoT simplifies the usage of this core by providing comprehensive GUIs and APIs and let it be easy to use and easy to integrate. This way, based on the highly capable and flexible core products, the majority of monetization pattern can be easily covered while complex pattern can be provided via Professional Services.

• 

3.3 Value Extraction

The IoT Services allow extracting value from all layers of an IoT proposition. Starting from the device hardware, the IoT platform ecosystem up to the value added services, dedicated business models can be supported as some examples show in the following.

• Service Revenue
  • Subscription
  • Pay per use
  • Pay for results
• Ecosystem Building
  • Transaction based
  • Revenue share
• Hardware Premium
  • Vending
  • Rental

3.4 Product Features

Following features can be utilized based on APIs or GUI access.

Provider Management

New Service Providers can be easily on-boarded by following a simple registration process. Service Providers are separated tenants on a Connected Suite system instance operated by the system owner (referenced as System Operator). They have separate access credentials and data views. Each Service Provider manages his own services, products and Customer accounts.

• 

Revenues of service Customers are automatically consolidated for their corresponding Service Providers allowing implementation of a revenue sharing model between Service Providers and the System Operator.

IP Aspects & Commercialisation:

4. Overview

Due to cost and complexity of software patents and difficulty of enforcement; copyright and trade secrets along with trademarks are often the preferred way to protect the IP rights in software.

4.1 Potential IP

In this case i.e. for the Redspark software, it should be noted that it is not exactly a novel IoT software for device management; but rather a product for IoT billing. It is built upon the core telecom billing engine of Redknee Solutions and although there are new GUIs and APIs and addition of several modules described above, the same are not novel and non-obvious. The experts in this area can come up with the requisite business logic which can be given the shape in the form given above.

Since the core billing engine is already protected by patent, the other parts of the software can be protected by copyright. However, to bring a sense of reliability as well as to tap the existing telecom customers of Redknee to start with as a poetential customer base (this is not exactly an OTC software product), the trademark of Redknee can be put in alongside a new trademark for Redspark (to be devised and registered).

• 

4.2 IP Issues

As mentioned earlier, the core billing engine CCB is already patented. So while the modules sitting between the GUIs and the web-services – used to prepare and feed the data received to the core engine, are not merely computer program per se, the cost and legal hassles involved may not be worth it if attempts are to be made to patent them only. Aside from the non-patentability of the software, there can be some other IP issues as well. These can be:

• Similarity of the GUIs i.e. front end screens with existing websites in terms of layout;
• Similarity of the API code with others; and
• Customization facility for each buyer/licensee – the IP protection for the same.

GUIs can be quite standard in these days. So while the GUIs while developing may bear some similarity with other metering interfaces, it is unlikely to be of much consequence from a copyright point of view as many of these are industry standard.
Similarly, the APIs of the web services of this software follow the standard restful or SOAP-based patterns and the code would also not be at much risk from copyright standpoint as they are independently developed.

So these codes would have to be copyrighted and the licensing agreements and contracts should clearly spell out the terms of use and termination of license in case of violation. Studying the program and making a competing application for commercial purpose using the code of the previous program will amount to copyright infringement. But copyright law of some jurisdictions allow for a program to be decompiled or reverse engineered for achieving interoperability. The dividing line can be thin and caution should be taken against over-exercise of this right by someone.

So if someone reverse engineers the peripheral part of the software and plugs it in with a different billing engine (other than CCB), then it can result in loss of business for Redknee.

4.3 Licensing, Royalty & License Fee

As mentioned in Section 3.4 earlier, the major customers would be the operators and in rare occasion the provider as well (who decided to operate only for his own business).The licensing, in all cases would be non-exclusive and the license fees would require multiple models so that different categories of customers can be tapped to create a reasonably large customer base for sufficiently high revenue level and continuity of the income flow over time. On the other hands, customers would typically want to keep the initial cost low and stagger the cash outflow over time. Sub-licenses can be allowed upto a specified limit, especially for foreign clients.

For operators who have large provider base, who in turn have high customer base, the transaction volume tends to be high and the monetary value associated with each transaction can be low. For such businesses, the initial cost of license can be kept low and the royalty can be made payable on a per transaction fixed amount or percentage of revenue to provider per transaction basis. 

At the other end of the spectrum, for operators with a low subscriber base and low number of transactions, the above model will not be viable and Redknee will insist on a lump sum payment as license fee before installing the software for the operator.

Most cases however, would fall midway between these two extremes and a combination of lump sum license fee and transaction based royalty would be applied – the exact contours and parameters of the contract depending upon the size and nature of the business of the operator. That way, some money would get collected immediately but the revenue stream to Redknee would also be maintained over a longer period of time; at the same time making the software affordable to the operators who would be the customers. Keeping the initial fee high can make the software unaffordable to many of them as the initial capital cost of their business would be very high and most of them would not like the idea and risk of ending up with too high a sunk cost.

So a judicious mix of license fees (one-time or staggered) and royalties would have to be arrived at during the negotiation phase with potential customers of the software. Minimum and maximum royalty collection levels may be fixed for certain cases.

An Epilogue:

5. Conclusion

Thus we see that given the fact that the organization that is developing the software will be owning it and selling it to the operator customers after customization. So there is no assignment involved in this case – only royalty and license fees would be collected for grant of license.

For lump-sum fee, amounts can be quite pre-determined and only slight discounts can be permitted. But for royalty-based or combination-contracts, the basis of royalty calculation, what would be “reasonable royalty”, MFN status, etc would figure prominently in the negotiations.

If the royalty is tied to revenues or sales, it is usually expressed as a percentage of a defined monetary amount – for example, 5% of “Net Revenues”, or 10% of “Gross Profit”. It is ultimately up to the parties to define these amounts and agree on an acceptable basis for royalty calculation.

6. Bibliography:

6.1 References:

1. Bebchuk, Lucian A., Cohen, Alma and Ferrell, Allen ‘ What Matters in Corporate Governance?’(September 1, 2004). Review of Financial Studies, Vol. 22, No. 2, pp. 783- 827, February 2009; Harvard Law School John M. Olin Center Discussion Paper No. 491 (2004)
2. Bebchuk, Lucian A., Cohen, Alma and Ferrell, Allen ‘ What Matters in Corporate Governance?’(September 1, 2004). Review of Financial Studies, Vol. 22, No. 2, pp. 783- 827, February 2009; Harvard Law School John M. Olin Center Discussion Paper No. 491 (2004)
3. KEY ASPECTS OF IP LICENSE AGREEMENTS by Donald M. Cameron and Rowena Borenstein

6.2 Words:

1. IP – Intellectual Property
2. IPR – Intellectual Property Rights

Author: Sourish Roy, a LL.B. student of Rajiv Gandhi School of Intellectual Property Law. In case of any queries please contact/write back to us at niharika@khuranaandkhurana.com