It is easy for a climate-tech company to think that securing a patent completes technology protection. Yet a real product does not run on the inventions written in its claims alone. Sensor calibration coefficients, rules for choosing installation positions by barn, code that identifies missing data, training data, customer operating records, APIs, dashboards, and field-response procedures together create performance. Some of these assets may be patentable, some retain value only if kept confidential, and some require their permitted use to be defined by copyright or contract.

An IP strategy after the patent is therefore not about registering as many rights as possible. It is about deciding which assets to show to whom and to what extent, and how to manage leakage, copying, independent development, and reuse after a contract ends. Because each protection tool has different requirements and limits, one technology must be designed in several layers.

First misconception to correct: a patent is not proof of ownership of the entire product

A patent is an exclusive right recognized in a particular country or region for an invention that meets defined requirements. This article provides a general operating framework; novelty exceptions, employee inventions, data protection, and contractual effect vary by law and contract, so local patent and legal counsel should review them. WIPO explains that patents are territorial rights and work only in the country or region that granted them. A domestic filing or registration does not automatically protect a foreign sales country, and a PCT international application does not issue a single worldwide patent. Market, manufacturing country, competitors, and enforceability should guide entry decisions country by country.

A patent is also a structure in which rights are obtained in exchange for disclosing an invention. Revealing the core in a paper, exhibition, proposal, or customer demo before filing can destroy novelty in some countries. Conversely, if disclosure makes a workaround easy and infringement would be difficult to detect, a trade-secret approach may be more suitable. Both extremes—patenting everything or hiding everything—are risky.

Copyright is not a cure-all either. WIPO explains that computer programs and databases may be protected by copyright, but protection covers expression, not ideas, procedures, methods of operation, or mathematical concepts themselves. Copyright alone is unlikely to prevent a competitor from independently implementing the same function in different code. Patents, trade secrets, copyright, trademarks, contracts, and security must ultimately be combined according to their roles.

The first step is to create an IP asset map

Break the livestock-methane platform into assets instead of treating it as one invention. Hardware may include sensor placement, sampling paths, calibration equipment, and manufacturing drawings. The analytics layer may include ventilation-estimation formulas, outlier detection, baseline models, features, and model weights. The data layer may include raw observations, labels, activity data, calibration history, derived emissions, and reports. The software layer may include firmware, Edge applications, cloud code, API specifications, UI, and deployment scripts. The business layer may include prices, customer lists, installation costs, and partner evaluations.

For each asset, record at least the owner, creator or inventor, creation date, storage location, disclosure status, product version, business value, reverse-engineering potential, leakage impact, related contracts, and protection measures. Do not assume that code written by an employee, firmware developed by a contractor, a model created with a university, and data supplied by a farm have the same ownership. Paying for something or operating the server does not automatically transfer every necessary right.

The asset map must not end as a legal-team list. Connect it to the actual flow of product functions, data pipelines, and contracts. For example, an item called “emissions model v3” should link its permitted purpose for source data, open-source libraries, code repository, training run ID, deployed-model hash, and external disclosure documents. That allows protection scope and obligations to be updated when the technology changes.

For algorithms, define the patent–trade-secret boundary first

Different things are mixed under the name algorithm: processing methods that create a technical effect, model architecture, feature selection, training-data curation, thresholds, site-specific tuning values, and explanatory documents. Depending on the jurisdiction and specific claims, some may merit patent review, but the label “AI algorithm” alone does not create patentability. Before disclosure, review the inventive elements, prior art, and target countries with a patent attorney.

If a product reveals its function but makes internal parameters difficult to discover, consider a trade-secret strategy. A trade secret is not protected merely by declaring it confidential. WIPO generally describes information as needing commercial value because it is secret, being known only to a limited group, and being subject to reasonable measures by the holder to keep it secret. It is not a system for exercising exclusivity against someone who independently develops the same method or lawfully reverse-engineers it.

When treating an algorithm as a trade secret, lock down more than model files. Classify feature definitions, training and validation data, hyperparameters, performance limits, and deployment settings by level, and grant access only to people who need it for their work. Operate repository permissions, multifactor authentication, export logs, encryption, partner NDAs, and retrieval and access revocation at departure or contract termination together. Papers and customer materials should provide enough information to evaluate performance without automatically disclosing secret parameters unnecessary for reproduction.

Data cannot be protected with the single word “ownership”

Disputes arise if a platform assumes it owns every right simply because sensor data is stored on its server. Farm activity data, raw values observed by equipment, event labels added by people, corrections made by a model, aggregated emissions, customer reports, and models trained across farms have different creators and interests. The data itself, database structure, trade secrets, personal information, and contractual rights of use are separate questions.

In contracts, express permissions as verbs rather than an abstract “data ownership.” Separate who may collect, view, copy, correct, combine, train models, provide data to 3rd parties, and use it in external claims, along with purpose, period, territory, and anonymization level. At termination, define return and deletion of source data, treatment of backups, continued use of existing aggregated statistics and models, and legal retention duties. Give a verifier read access only for the period and scope needed to confirm a claim.

Broad data rights are not automatically the best strategy. An indefinite right with an unclear purpose can reduce a farm’s trust and become a burden in overseas regulation and customer procurement reviews. Conversely, without the correction, quality-control, and model-improvement rights needed to provide the service, the product is hard to operate. Match minimum necessary permissions with value that can be explained to the customer.

Manage code, dependencies, and distribution rights together

Software copyright protects the expression of code, but in business the first questions are who wrote it and what rights the company secured. Review agreements with employees, freelancers, contractors, and joint-research partners, and specify ownership of deliverables, modification, reproduction, distribution and relicensing rights, source-code delivery, and whether documentation and tests are included. Repository commits and review records help evidence the creation process and versions.

Open source is not code exempt from rights review merely because it is free. Record components, versions, licenses, modifications, and distribution methods in a software bill of materials, and check notice and source-provision obligations. Sensor firmware, Edge images, cloud services, and customer-installed programs are distributed differently, so the same license conclusion cannot simply be applied to all of them. Code generated by AI must also be handled in the development process for provenance, review, security testing, and possible license conflicts.

Customer contracts should distinguish account access rights from software ownership. A customer may receive the right to use results without receiving source code or a model. Conversely, to prepare for a supplier discontinuing service, an enterprise buyer may request source-code escrow, data export, and transition support. Design trigger conditions, scope, cost, and confidentiality duties instead of automatically refusing or transferring everything.

Field scenario: joint development with a farm, university, and manufacturing partner

Suppose a hypothetical methane-monitoring company collects data at a farm, improves an emissions model with a university research team, and has a manufacturing partner build gateway firmware. If ownership of results is discussed only after the joint research begins, inventorship, publication, code use, and the scope of data training may conflict.

Before starting, freeze a list of each party’s background IP. For foreground IP newly created in the joint work, set ownership by invention and work, filing decisions, costs, licenses, and business fields. University publication procedures should include a pre-review period for filing review and removal of trade secrets. Split farm-data consent for research, service delivery, model training, and public case studies, and provide the manufacturing partner only the drawings, keys, and firmware modules required for production.

WIPO also explains that technology-transfer agreements distinguish licenses from assignments, and that joint-research agreements should address background IP, ownership and access to results, benefits and risks, and commercialization rights. Adjust the agreement with legal counsel to the actual collaboration and jurisdiction rather than using a template unchanged. This framework is not legal advice.

Operating standard: connect the IP Register to a disclosure gate

An IP Register should contain more than patent numbers. Record the asset ID, type, owner, creator or inventor, related contracts, jurisdiction, disclosure status, confidentiality level, authorized users, repository, product version, renewal or review date, and the person responsible for infringement or leakage response. Compare it with the product roadmap each quarter to check for missing code, data, or know-how.

Use one gate for external disclosure. Before a paper, press release, proposal, public Git repository, exhibition demo, or customer API document goes out, review patent-filing need, trade secrets, personal information, customer contracts, and open-source duties. Keeping the approval result and disclosure hash makes it possible to trace what was disclosed and when.

Prepare incident response as well. If credentials leak, a repository is copied, equipment is not recovered from a departing employee, or a partner uses material outside its purpose, decide who will block access, preserve evidence, determine impact, issue contractual notices, and take legal action. Because it is difficult to restore secrecy after a trade-secret leak, prevention and early response speed matter.

Implementation checklist

  • Have you broken the product into hardware, algorithm, data, software, and operational-know-how assets?

  • Have you accurately separated the jurisdiction and status of domestic filings or registrations from foreign rights?

  • Do you review novelty, confidential information, and customer disclosure authority before external presentations?

  • Do you choose between patent and trade secret based on reverse-engineering potential, disclosure cost, and enforceability?

  • Are the trade-secret list, confidentiality levels, least privilege, NDA, and departure or termination procedures actually operated?

  • Have you separated raw data, labels, derived values, reports, and model-training rights in the contract?

  • Have you documented ownership and permitted use of employee, contractor, and joint-research results?

  • Do you manage open-source components and license obligations by distribution form?

  • Does the IP Register connect product, model, and data versions to related contracts?

  • Do local experts review differences in national law and contracts before market entry?

Conclusion: an IP portfolio is a system for operating the boundaries of technology

A patent is an important starting point, but it does not protect an algorithm’s secret parameters, a farm’s data-use rights, software code, and field know-how all at once. Because protected assets and exposure paths differ, place patents, trade secrets, copyright, contracts, and security controls around each asset.

A good IP strategy does not lock up every piece of information. Provide customers and verifiers with evidence to judge performance while protecting secrets unnecessary for reproduction through least privilege. When you can trace who created and may use something, where it is effective, and what remains after a contract ends, IP becomes an operating foundation for product expansion and collaboration—not a bundle of registration certificates.

Sources