IP review before technical disclosure
An OEM/ODM discussion can involve design files, algorithms, product concepts, trademarks and manufacturing know-how. Begin with a non-confidential overview, then identify what needs protection before detailed disclosure. The relevant parties should agree the permitted purpose, recipients and access conditions. This page outlines procurement considerations; it does not itself transfer rights, sign an NDA or guarantee that a project creates exclusive intellectual property.
Background and newly developed technology
Background IP may include an existing device platform, firmware libraries, algorithms, tools or supplier know-how used before your project. New project work may include custom drawings, source modules, artwork or tooling. Separate these categories in the proposal. State which items are owned, licensed or only made available for a limited purpose. Paying a development fee does not by itself explain ownership or the scope of a license; the agreement must do that.
Industrial design, drawings and hardware files
Agree the ownership and delivery scope for industrial design, mechanical drawings, PCB files, BOMs and test fixtures. Specify the format, revision, documentation and handover milestone for each deliverable. If a reference design is adapted, identify what can be reused and whether any exclusivity is included. Ask how supplier-standard elements and buyer-funded modifications are treated when a project stops, changes supplier or moves to another manufacturing site.
Tooling, molds and production fixtures
Tooling is a separate commercial and operational asset. Clarify who pays, owns, stores and maintains it; what identifiers are used; and whether transfer is possible. Agree permitted use, replacement wear, access, movement and the treatment of shared fixtures. A quotation for tooling should not be interpreted as an automatic transfer of all associated process know-how. Put the tool-transfer procedure, costs and completion conditions in writing if relocation may matter to your supply strategy.
Firmware, apps, SDKs and cloud interfaces
List the software components involved and distinguish source code, compiled binaries, SDK documentation, API access and hosted services. Agree licenses, distribution rights, app-store accounts, credentials, third-party dependencies and update responsibilities. A white-labeled interface does not automatically mean ownership of the underlying code. For cloud-linked devices, clarify export, migration and service continuity so your brand’s product roadmap is not based on an unrecorded software assumption.
Brands, artwork and third-party materials
Supply logos, fonts, packaging artwork and other materials only when you hold the necessary rights or permissions. The project agreement should limit their use to the approved work. Review any third-party assets, licensed software or patented components included in the design. Listing a technology, standard or brand on a website does not grant a license to use it. Product naming, packaging and promotional claims should be checked before a branded production order is released.
Patents and exclusivity
Ask for a patent number, holder, territory, status and relevant scope when patent protection is part of the commercial discussion. A patent-related image is not an ownership or validity verification. Territorial sales exclusivity, design exclusivity and patent rights are different arrangements. If exclusivity is needed, define products, territory, duration, volume commitments, exceptions and consequences of non-performance. Do not assume exclusivity from a custom logo, private-label order or development payment.
Controlled sharing and project handover
Use revision-controlled files and the agreed transfer route for sensitive materials. Identify who can access files, whether subcontractors are involved and which disclosures require approval. Before production or project closure, review the deliverable inventory and license or ownership records. Address permitted retention, deletion, transition support and open issues. A written handover checklist is especially useful where a buyer expects tooling, engineering files or software to support a second-source strategy.
Concerns, changes and contact
If you identify an IP concern, describe the affected material, project and requested action to the technical or sales contact. Avoid distributing disputed files more widely while the parties review the issue. Changes to design or software ownership should be documented rather than agreed only in informal messages. For confidentiality arrangements, see NDA / Confidentiality. For ownership or license decisions, rely on the executed agreement between the identified legal parties.
Common questions
Does paying for OEM development automatically give us all source code?
No automatic source-code handover or ownership scope is stated here. Identify the code, files and rights you need in the written agreement.
Can we own a mold while licensing the underlying platform?
Different assets can have different ownership and license arrangements. Document tooling and platform rights separately.
Is a private-label product exclusive to our brand?
Private labeling alone does not establish exclusivity. Any exclusive scope must be expressly agreed.
Questions about your project?
For a business inquiry or policy clarification, contact the STAR KING team. Identify your company, product or order reference and the question you want to resolve. Use a non-confidential summary until a suitable file-sharing or confidentiality arrangement is agreed.