Employee-Inventor, Post-Employment Non-Compete and a Section 3(k) Objection
Nimbus, a Bengaluru analytics firm, builds a churn-prediction product. Its lead machine-learning engineer signs a contract with confidentiality covenants, a 12-month post-employment non-compete, and an assignment of 'all inventions made in the course of employment'. He resigns in March and joins Stratos in April. In September Stratos files a patent application for 'a method for real-time churn prediction using gradient-boosted ensembles with drift detection', naming him as sole inventor. Nimbus alleges the method was conceived during his employment and that he copied a customer feature-weight table that Nimbus kept on a restricted server. Stratos argues the idea is the engineer's own, the non-compete is void, and no confidential information was used. The examiner has raised an objection that the claims are a computer programme per se.
1. Who owns the patent application? Analyse the employment relationship, the assignment clause and the statutory default.
Read the worked answer
The starting point is the statutory default for employee inventions, not the contract.
- Statutory default. Where an employee is not employed for research or development, an invention made in the course of employment belongs to the employee, and the employer's protection is a default licence to use it. Where the employee is employed for research and development, the invention belongs to the employer. The distinction turns on the nature of the duties, not on the job title.
- This engineer. He led an ML team building a churn product. His duties were substantially inventive and developmental. A tribunal is likely to find he was employed for research and development, which points to employer ownership of inventions made in the course of that employment.
- The assignment clause. 'Course of employment' is doing real work here. It captures inventions conceived in the course of duties, using employer data, infrastructure and customer insight. It does not capture ideas conceived independently after hours. The dispute is therefore factual: when was the concept formed, and on what inputs?
- Indicators to weigh. The September filing is five months after he left; the restricted feature-weight table, if used, is strong evidence the method was not independent; the drift-detection element looks like an extension of the product roadmap he worked on.
Ownership is likely to be shared at best; the cleaner claim is that the application is held for Nimbus's benefit.
2. Can Nimbus enforce the 12-month non-compete and the confidentiality covenants?
Read the worked answer
Non-compete. A post-employment restraint is void as a restraint of trade. Indian law enforces restraints only during employment, or where the restraint is reasonably necessary to protect a legitimate proprietary interest such as confidential information or customer connections. A bare 12-month bar on working for a competitor is unenforceable, and a court will not rewrite it into a narrower covenant.
Confidentiality. This covenant is enforceable because it protects information, not competition. Nimbus must prove three things: the feature-weight table was confidential (restricted server, limited access, not public); it derived commercial value from secrecy; and the engineer used or disclosed it. The fact that some of the knowledge is in his head is not a defence - skill and general knowledge are not protectable, but a specific table built from Nimbus's customer data is.
Practical route. Nimbus should seek an injunction limited to use of the table and to any product built on it, not an injunction restraining employment. The 'inevitable disclosure' theory is not settled in India, so the claim must be anchored in evidence of actual use. A forensic review of the engineer's devices and Stratos's repository is the decisive step.
3. How should the Section 3(k) objection be met?
Read the worked answer
Section 3(k) excludes a computer programme per se, not every invention implemented on a computer. The objection is met by showing a technical effect or technical contribution beyond the normal operation of a computer.
Arguments available.
- Technical problem, technical solution. The claim addresses model drift in a live prediction pipeline - a problem internal to the system's performance. The solution improves prediction stability and reduces retraining load, which are technical effects on the functioning of the system.
- Specific technical features. Drift detection thresholds, ensemble weighting updates and a memory-aware deployment schedule are concrete features, not a business method dressed as software.
- Avoid the abstract core. Claim 1 should not read as 'predict churn using an ensemble'. It should tie the features to the pipeline, data structures and latency constraints.
- Drafting fix. Move the business advantage - higher retention, better targeting - out of the claim and into the description. Business effects do not rescue a computer programme; technical effects do.
Risk. If the specification's only stated advantage is commercial, the objection will stick, and the application will be refused. The response should amend the claims to foreground the technical effect and file a written submission distinguishing the cited prior art on that basis.