Open Innovation and Prize Competition Toolkit: Submissions, Firewalls, Rules, and Handover

By Casey Scott McKay · 2025-01-05

An open innovation programme is an invitation for strangers to send you ideas, and the legal risk runs almost entirely in one direction. This toolkit assembles the working material for practitioners advising companies that run submission portals, hackathons, prize competitions, and accelerators, and for the contributors who enter them. It covers the idea submission claims that arise from receiving an unsolicited proposal, and the submission terms that make a programme safe to run. It sets out the evaluation firewall and the independent development record that answer the coincidence case years later. It works through prize competition rules, hackathon ownership models, employer assignment obligations, and the disclosure timing that a demo day destroys. It closes with the commercialisation handover, clause language, worked scenarios, and the failures that recur.

IP and Technology > IP and IT in Corporate Transactions | Toolkit | Published 5 January 2025 - Updated 3 February 2025 | Casey Scott McKay - marksy.us

Summary. An open innovation programme invites strangers to send you ideas, and the legal risk runs one way. This toolkit covers idea submission claims and the theories behind them, submission terms that are enforceable rather than decorative, evaluation firewalls and the independent development record, hackathon and prize competition rules, contributor assignments, and the handover process that moves a winning submission into a product line without importing a claim with it.

Keywords: open innovation · unsolicited submissions · idea submission claims · submission terms · evaluation firewall · independent development · hackathon terms · prize rules · contest law · contributor assignment · commercialisation handover · implied contract · confidential submission · novelty · accelerator terms

Start Here

Open innovation is a good idea with an asymmetric risk profile, and understanding the asymmetry is the whole of the practice.

Ideas are not property. An idea, however good, is not protected by copyright — 17 U.S.C. § 102(b) excludes ideas, procedures, and concepts — and is not protected by patent until it is claimed. The doctrine descends from Baker v. Selden.

But receiving an idea creates exposure anyway. State law supplies several theories: breach of an express or implied-in-fact contract to pay for a disclosed idea, breach of confidence, and unjust enrichment. The classic authority is Desny v. Wilder, which held that a contract to pay for an idea may be implied from the circumstances of a solicited disclosure. Whether such claims survive federal preemption depends on the extra element analysis under 17 U.S.C. § 301; contract claims frequently do. See What the Copyright Act Kills.

The dangerous case is the coincidence. A company receives a submission, declines it, and launches a similar product two years later from an entirely independent line of development. It has done nothing wrong and it will be sued, and the outcome will depend on records created before anybody imagined the dispute.

So the programme is a records exercise. Enforceable submission terms, a firewall that keeps submissions away from developers, and an independent development record for every product line.

Four questions organise the work.

Are the submission terms binding, and what do they say?

Does the firewall actually separate evaluation from development?

Are the competition rules enforceable and compliant?

And can a winning submission be commercialised cleanly?

See Ideas Sent to You for the doctrinal treatment, Running an Open Innovation or Prize Competition Programme for the sequence, and the Open Innovation Programme Checklist for the working list.

Part one: submission terms

The submission terms are the programme's principal control and they only work if they are formed properly.

Formation first. Terms presented behind a link that nobody clicks are not agreed. Use a clickwrap: the terms displayed or immediately available, an affirmative action to accept, a record of the acceptance with a timestamp and the version. The formation analysis is the ordinary one — see Terms That Actually Bind.

State that submissions are non-confidential. The single most important term. A submission received in confidence supports a breach of confidence claim; one received expressly on a non-confidential basis does not, absent something else.

State that no compensation is owed unless a separate written agreement is signed, which negatives the implied contract theory that Desny rests on.

State that the company may already be developing similar things, and that it is free to continue.

Grant the company a licence to use, evaluate, reproduce, and disclose internally, and — depending on the programme — to use the submission without further obligation.

Require the contributor to warrant that the submission is theirs, that they have the right to submit it, that it does not contain a third party's confidential information, and that they are not subject to an employer's assignment obligation covering it. That last warranty is the one that matters most and is almost always omitted.

Address the employer problem directly. A contributor employed elsewhere may have assigned the submission to their employer by contract. A programme that takes an assignment from an individual who could not give it has acquired nothing. Require disclosure and, for anything valuable, verification.

Prohibit third-party material and require identification of any open source component.

Address personal data collected through the portal.

And keep the terms short. A four-page submission agreement reduces participation and produces no better protection than a one-page one that is actually read.

Part two: firewalls and the independent development record

The firewall is what protects the company from the coincidence case, and it is procedural rather than contractual.

Route submissions to a dedicated intake, not to a product team's inbox. An unsolicited proposal arriving at a named engineer's email address is the worst possible starting point and it is how most submissions arrive.

Screen before reading. A designated reviewer, outside the relevant product organisation, checks that the terms were accepted and that the submission is in scope before anybody with development responsibility sees it.

Return or delete out-of-scope submissions with a short standard letter, and record the return. A submission that was declined and returned unread is a very strong defensive position.

Keep the evaluation team separate from the development team for the relevant area, log who saw what, and prohibit informal circulation.

Maintain the independent development record. For every product line, a dated record of what the team was working on and when — design documents, commit history, meeting notes, and roadmap versions. This is the evidence that defeats the coincidence claim, and it must exist before the claim.

Timestamp everything. A dated internal document predating a submission is dispositive; the same document without a reliable date is an argument.

Handle inbound unsolicited material with a standard response, declining to review anything not submitted through the portal under the terms, and returning it unread.

Train the people who receive things. Sales, support, engineering, and executives all receive unsolicited ideas, and the standard response has to be known by all of them.

Retain the records for the limitation period and beyond, because the claim arrives years later.

And treat the firewall as a clean room, with the same discipline described in the Competitive Intelligence and Benchmarking Toolkit.

Part three: prize competitions and contest rules

A prize competition is a promotional contest with an intellectual property layer, and both bodies of rules apply.

Publish complete official rules before entries open, and make them available from every entry point. The rules are the contract with entrants and an incomplete set produces disputes with no answer.

Address the promotional law questions: eligibility, geographic scope, entry period with defined start and end times, the method of entry, whether purchase or consideration is required, the judging criteria, the identity of the judges, the odds or the basis of selection, the prize description and approximate value, the notification method, the deadline for claiming, and the sponsor's identity.

Consideration is the pivot. A contest requiring a purchase, or requiring substantial effort amounting to consideration, and awarding prizes by chance, is a lottery in most jurisdictions and is unlawful for a private sponsor. Contests judged on skill against published criteria avoid the problem, which is why open innovation competitions are almost always skill-based and why the judging criteria must be genuine.

Publish the intellectual property terms inside the rules, not in a separate document: what rights entrants grant, what happens to non-winning entries, what happens to winning entries, and whether an assignment is required as a condition of the prize.

Distinguish the licence from the assignment. Most programmes should take a broad licence in all entries and an assignment only from the winner, under a separate signed agreement executed before the prize is paid.

Say what happens to non-winning entries — returned, retained, deleted — and mean it.

Address publicity. Winners' names and images used in promotion require consent, which the rules can obtain, subject to state restrictions on conditioning a prize on publicity consent.

Address taxation and reporting of prizes, which is not an intellectual property question and which will be raised by finance.

Reserve the right to disqualify for breach, for third-party material, and for entries that cannot be verified as the entrant's own.

Reserve the right to award no prize if no entry meets the criteria, and to modify or cancel the competition, subject to whatever the jurisdiction permits.

And have counsel review the rules in every jurisdiction the competition is open to, because registration and bonding requirements apply in some for prizes above stated values.

Part four: hackathons and time-boxed events

Hackathons compress every question in this toolkit into forty-eight hours and add several of their own.

Who owns what is built is the question participants care most about and organisers address least. Three models are common: participants retain ownership with the organiser taking a licence; the organiser takes ownership of everything; or ownership follows the team with the organiser taking a right of first negotiation. State the model prominently, in advance, in plain words. Participants read this and they resent discovering it afterwards.

Employer obligations are acute. A participant employed by a technology company has probably assigned to their employer anything relating to the employer's business. A hackathon output built by such a participant may belong to their employer regardless of the event terms. Require disclosure and expect that valuable outputs will need employer consent.

Team formation creates joint ownership. Absent agreement, co-authors of a work are joint owners under 17 U.S.C. § 201(a), each able to licence non-exclusively subject to accounting, and joint inventors under 35 U.S.C. § 116 may each exploit without accounting under 35 U.S.C. § 262. Neither default suits a team that intends to build a business. Provide a short team agreement template and require it.

Open source is everywhere in a hackathon output, frequently unrecorded, and a winning project that turns out to incorporate copyleft components has a problem. Require a component declaration. See Copyleft and Consequences.

Third-party APIs and datasets used during the event carry terms that may prohibit commercial use of the output.

Judging and mentoring create exposure, because mentors from the sponsoring company see the projects and may later work on similar things. Apply the firewall discipline to mentors and record who mentored what.

Prizes trigger the contest rules in part three.

Photographs and recordings of the event need releases if used promotionally.

And the aftermath matters most. A hackathon output the organiser wants to pursue requires a proper assignment, an employer release where relevant, an open source clearance, and a team agreement — none of which exist at two in the morning on the second day. Build the handover process before the event.

Part five: commercialisation handover

Winning a competition is not the same as being able to build the thing, and the handover is where programmes fail quietly.

Take a proper assignment, in writing, signed by every contributor, before any development spend. 17 U.S.C. § 204 requires a signed writing for copyright transfers, and 35 U.S.C. § 261 requires one for patents, with the present assignment language discussed in FilmTec Corp. v. Allied-Signal Inc. and Board of Trustees of the Leland Stanford Junior University v. Roche Molecular Systems, Inc..

Identify every contributor. Competition entries are frequently team efforts with contributors nobody listed, and an assignment from three of five people is an assignment from three of five people.

Obtain the employer release where a contributor may have assigned to an employer, and treat a refusal as a reason not to proceed rather than a formality.

Run inventorship properly if a patent application will follow, claim by claim, under 35 U.S.C. § 116, with correction available under 35 U.S.C. § 256. See the Inventorship Determination Checklist.

Check the disclosure position. A competition entry presented publicly, demonstrated at a demo day, or published in a programme brochure is a public disclosure starting the grace period under 35 U.S.C. § 102 and destroying novelty in most foreign jurisdictions. File before the demo day, not after. See Prior Art in a First-Inventor-to-File World.

Clear the open source and third-party components before the code enters a product.

Record the provenance of anything generated with an AI tool, and check the tool's terms. See the Generative AI IP Compliance Checklist.

Pay properly. A contributor paid a prize and then asked for an assignment has leverage; a contributor who assigned as a published condition of the prize does not. Sequence it correctly.

Consider ongoing arrangements. A contributor may be more valuable engaged than paid off, and a consultancy, an option, or an employment offer is frequently the better outcome for both sides — with the ordinary assignment discipline applied. See the Employee Invention Checklist.

And record the handover, so that three years later the company can show how it acquired what it is now selling.

Clause bank

Submission terms — core provisions. By submitting, you agree that: (a) your submission is not confidential and no confidential relationship is created; (b) we are under no obligation of any kind in respect of it, and no compensation is or will become payable unless we sign a separate written agreement with you; (c) we may already be developing, or may in future develop, ideas similar to yours from our own resources, and nothing here restricts us from doing so; (d) you grant us a non-exclusive, worldwide, royalty-free, perpetual, sublicensable licence to use, reproduce, adapt, and disclose your submission for any purpose; (e) you own your submission or have the right to submit it; (f) it contains no confidential information of any third party; (g) you are not subject to any agreement with an employer or other party that would give them rights in it, or if you are, you have disclosed this to us in your submission; and (h) it contains no third-party material other than as identified in your submission.

Firewall protocol. All submissions shall be delivered to the Intake Address and shall be accessible only to the Review Team. No member of a Product Team for a Relevant Area may access a submission relating to that area without the written approval of the Programme Counsel, which shall be recorded. Submissions declined at screening shall be returned or deleted within [10] business days and the return shall be logged. The Review Team shall maintain a log recording, for each submission: the date received, the terms version accepted, the screening outcome, every individual who accessed it, and the date of return or deletion. Any submission received otherwise than through the Intake Address shall be returned unread with the Standard Response Letter.

Standard response to unsolicited material. Thank you for contacting us. We are not able to review unsolicited proposals except through our submission portal at [address], where our submission terms apply. We have not read the material you sent and are returning or deleting it. If you would like us to consider your idea, please submit it through the portal. Please note that we develop products independently and may already be working on ideas similar to yours.

Competition intellectual property terms. You retain ownership of your Entry. By entering you grant Sponsor a non-exclusive, worldwide, royalty-free licence to reproduce, display, and use your Entry for the purposes of administering and promoting the Competition. If you are selected as a Winner, you must execute the Assignment Agreement at Schedule [B], assigning to Sponsor all rights in the Entry, before the Prize is awarded; if you do not, Sponsor may select an alternative Winner. Non-winning Entries will be deleted within [60] days of the Competition close, save for the record required by clause [X].

Contributor assignment. Each Contributor hereby irrevocably assigns to Sponsor all right, title and interest in the Submission and in all intellectual property rights in it, worldwide, including the right to sue for past infringement, and waives all moral rights to the fullest extent permitted with a consent as fallback. Each Contributor warrants that they are the sole author of their contribution, that no employer or other party has any claim to it, and that it incorporates no third-party material other than the Declared Components at Schedule [C]. Each Contributor shall execute such further documents as Sponsor reasonably requires, and appoints Sponsor as attorney to execute them if the Contributor fails to do so within [20] business days of request.

Hackathon team agreement. The Team members listed above agree that: intellectual property in the Project is owned by the Team members in equal shares unless otherwise stated; no Team member may licence, assign, or commercialise the Project without the written agreement of all; if the Team wishes to pursue the Project, the members will negotiate a formal arrangement in good faith within [60] days; each member confirms they have disclosed any employer obligation that may affect their contribution; and each member has declared every third-party and open source component they used, at Schedule [D].

Worked scenarios

The coincidence. A consumer products company runs a submission portal. A contributor proposes a packaging feature; the company declines. Twenty months later it launches a product with a similar feature, developed by a team that never saw the submission. The contributor sues on implied contract and breach of confidence. The company's defence rests on three documents: the accepted submission terms stating non-confidentiality and no compensation, the firewall log showing the development team never had access, and the dated design records showing the feature's independent origin. It wins, on the records rather than on the merits of the idea. A company without those records settles.

The employer's invention. A hackathon winner builds a promising tool over a weekend. The sponsor wants to commercialise it. The winner is employed by a large technology company whose invention assignment agreement covers anything relating to its business — which this does. The winner cannot assign what they do not own. The employer, approached, declines. The sponsor has paid a prize for something it cannot use. A disclosure requirement in the entry terms would have surfaced this before the prize was announced.

The demo day disclosure. An accelerator programme culminates in a public demo day, streamed and covered by the trade press. Three of the cohort present unfiled technology in detail. In the United States they have twelve months; in Europe and Asia the novelty is gone. Two of the three intended to raise money on the strength of an international patent position. The filing sequence should have been part of the programme's curriculum, and in well-run accelerators it is.

The rules that were not rules. A competition publishes a short entry page and a promise of a prize, with the intellectual property terms in a separate document nobody linked. A finalist disputes the outcome and, separately, refuses to assign. The sponsor has no enforceable rules, no assignment mechanism, and a public dispute with a participant. Complete official rules, published before entries open and linked from every entry point, are not a formality.

Failures that recur

Submission terms behind an unclicked link.

Terms that do not state non-confidentiality or negative compensation.

No warranty about employer obligations, which is the most common cause of an unusable winning entry.

Unsolicited material read by a product engineer before anybody screened it.

No firewall log, so the independent development defence has no evidence.

No dated development records, so the coincidence case cannot be answered.

Competition rules incomplete or published after entries opened.

A chance-based competition requiring effort or purchase, which is a lottery.

Prize paid before the assignment is executed, giving the winner leverage.

Team outputs with no team agreement, producing joint ownership nobody wanted.

Open source components undeclared and discovered during productisation.

Demo day disclosure before filing.

And no handover process, so a winning idea sits unused because nobody can establish who owns it.

Part six: accelerators, incubators, and corporate venture programmes

Longer-form programmes raise the same questions over months rather than days, and the money makes them sharper.

The programme terms are an investment document as much as a participation document, and participants read them as such. Equity, options, and rights of first refusal belong there, stated plainly.

Background and foreground. A participant arrives with existing intellectual property and creates more during the programme. The terms should confirm that background remains the participant's, define foreground, and state what the programme takes in it — which for most accelerators should be nothing beyond a licence to use the participant's name and a right to be told about a financing.

Rights of first refusal and first negotiation are common and should be time-limited and narrow, because a broad right chills the participant's ability to raise money elsewhere, which is the outcome the programme least wants.

Mentor exposure is the firewall problem again. Mentors are frequently executives at companies operating in adjacent spaces, and a mentor who advises a participant and then works on something similar has created the coincidence case. Record mentor assignments, obtain mentor acknowledgements, and keep a log.

Corporate venture programmes run by an operating company have a sharper version of the same problem: the corporate parent is a potential competitor, and a participant disclosing technology in a pitch meeting has no protection unless one is created. Offer a mutual confidentiality agreement for substantive technical discussions, and route pitch material through an intake that the relevant product teams do not see.

Demo days are disclosures, as in part five, and the filing sequence should be in the programme curriculum from week one.

Cohort effects matter. Participants share space, ideas circulate, and two companies in the same cohort may end up building similar things. A short cohort confidentiality expectation, stated in the terms, prevents the worst of it.

Alumni obligations — reporting, name use, and any revenue share — should end on a stated date rather than continuing indefinitely.

And the programme's own brand should be protected and licensed to participants narrowly, since "backed by [Programme]" is a valuable claim that alumni will make forever.

Part seven: the contributor's side

Almost all writing here is addressed to the organisation receiving submissions. The contributor's position is worth setting out.

Understand what you are giving. Most submission terms grant a broad licence and disclaim confidentiality and compensation. Read them before submitting, because they are what you agreed to.

Do not submit your best unprotected idea. File first if it is patentable and valuable, or submit a version that describes the benefit without disclosing the mechanism.

Check your employment agreement. If you are employed, your employer may own what you are about to submit, and submitting it may itself breach your obligations.

Keep your own records. Dated documentation of what you had and when, independent of the submission, which is what supports a claim if one is ever justified and what protects you if the recipient alleges you took something from them.

Do not include third-party material or anything confidential to anybody else.

Negotiate for anything substantial. A serious submission to a serious counterparty can be preceded by a request for a confidentiality agreement. Many companies will refuse; some will not, and the ones that will are the ones worth dealing with.

Understand the realistic outcome. Most submissions are declined, most declined submissions are never used, and the coincidence case is genuinely a coincidence far more often than contributors believe. A claim brought on suspicion alone will fail against a company with a firewall log and dated development records.

And treat a prize competition as a contract. Read the official rules, note what the assignment condition requires, and decide before entering whether you are willing to give up what winning would cost you.

Part eight: programme design, from the top

Before any of the machinery, a programme needs a decision about what it is for, because the answer changes every term in it.

Marketing programmes exist to generate attention and goodwill. They should take the narrowest rights consistent with running the competition, should return or delete entries afterwards, and should be judged on participation rather than on acquired technology. The submission terms can be short and generous, and the firewall matters more than the assignment.

Sourcing programmes exist to find technology the company will use. They need the full apparatus: enforceable terms, a firewall, a real assignment mechanism, employer disclosure, and a handover process funded before the programme launches.

Ecosystem programmes exist to build a community of developers or partners around a platform. Rights should largely stay with the contributor, the company takes a licence to run the platform, and the value is participation rather than ownership.

Research programmes with universities or institutes are a different instrument entirely, governed by sponsored research and material transfer agreements. See Negotiating University and Research Institution Agreements.

Talent programmes exist to identify people rather than ideas, and should say so — which removes most of the intellectual property tension and produces better outcomes on both sides.

Choose one. The programmes that generate disputes are the ones that were launched for marketing reasons and then, when something promising appeared, tried to behave like sourcing programmes without the terms to support it.

Budget the handover before the launch. A programme that produces a winner it cannot commercialise has wasted its budget and damaged its reputation with the participants it will want next year.

And publish honestly. Participants can tell the difference between a programme that says "we will take a licence and may build something similar ourselves" and one that implies a partnership it does not intend. The first attracts fewer entries and better ones.

The three-day test

The quickest diagnostic on an open innovation programme takes three days. Pick the most recent submission the organisation received and ask five things.

Can somebody produce the terms as accepted, with the version and the timestamp? Does the log show who has accessed the submission, and does that list exclude the product team for the relevant area? Is there a dated development record for that product area predating the submission? If the submission had been the winner, is there a signed assignment mechanism ready to execute, and does it reach every contributor? And has anybody checked whether the contributor's employer might own it?

A programme that answers all five is safe to run. A programme that answers two is the ordinary case and is running on the low probability of a claim. A programme that answers none has an inbox full of other people's ideas, no record of who has read them, and a product roadmap that will one day resemble one of them.

One paragraph to remember

Ideas are not property and receiving them creates exposure anyway. Make the submission terms binding, say expressly that submissions are non-confidential and that no compensation is owed, warrant against employer obligations, and route everything through an intake the product teams cannot see. Keep the firewall log and the dated development records, because the claim arrives two years later and those are the only two documents that answer it. Publish complete competition rules before entries open, judge on skill against stated criteria, and take the assignment before the prize rather than after. And decide at the outset whether the programme exists for marketing, for sourcing, or for talent — because the trouble comes from programmes that started as one and behaved as another.

Documents that must exist

For each item: does it exist, who owns it, and can it be produced in three days?

The submission terms, every version, with effective dates.
The acceptance record for each submission: version, timestamp, and identity.
The submission log: date received, screening outcome, everybody who accessed it, and the date of return or deletion.
The standard response letter for material received outside the portal.
The firewall protocol and the list of restricted product areas.
Dated independent development records for every product line, maintained continuously.
The official rules for each competition, with the publication date and the entry-point links.
The jurisdiction review for each competition, including registration and bonding where required.
The assignment agreement template, and the executed assignments for every winner.
Employer disclosure responses from winning contributors, and any employer release obtained.
The declared components schedule for any software submission.
Team agreements for multi-contributor entries.
Publicity releases for winners used in promotion.
Mentor acknowledgements and the mentor assignment log for accelerator programmes.
The handover record for anything commercialised: assignment, clearance, inventorship analysis, and filing dates.
Retention records showing when non-winning entries were deleted.

A note on why programmes still run

Everything above describes risk, and it would be easy to read this toolkit as an argument against open innovation. It is not.

Programmes that are run properly produce genuine value: technologies a company would not have found, relationships with people it would not have met, credibility in a developer or research community, and a pipeline of talent. The companies that have built serious external innovation functions did not do it by accident, and none of them stopped because of the legal exposure.

What they did was decide what the programme was for, write terms that matched, put a firewall in place, and keep records. That is a week of work at the outset and a small ongoing administrative burden, and it converts an activity with an open-ended liability into one with a managed one.

The programmes that produce the cautionary tales are almost never the sophisticated ones. They are the informal ones: an email address on a website, a hackathon organised by a product team, a competition announced on social media with no rules. Those are the arrangements that receive somebody's genuinely good idea, lose track of who read it, and appear in a complaint three years later.

The advice, therefore, is not to avoid open innovation. It is to avoid running it informally.

The people who receive things

A practical closing note, because the firewall fails at the same point in every organisation.

Unsolicited ideas do not arrive at the submission portal. They arrive in a salesperson's inbox after a conference, in an executive's direct messages, in a support ticket, and occasionally in the post. The person who receives one is usually flattered, frequently helpful, and almost always forwards it to the product team with a note saying "this looks interesting".

That single forward is the event that creates the exposure, and it is preventable with two things: a standard response that everybody has, and a rule that nothing gets forwarded internally.

Circulate both. Put them in the induction. Repeat them once a year. It is the least sophisticated intervention in this entire toolkit and it prevents more claims than the firewall protocol does, because the firewall only protects submissions that reach it.

One more sentence about records

Every defensive position in this toolkit rests on a document created before anybody knew it would be needed: the acceptance timestamp, the access log, the dated design note, the return letter. None of them is expensive and none of them can be produced retrospectively. A programme that keeps them is not more careful than one that does not; it is simply the one that will still be able to explain itself in three years, which is when the question is asked.

And a word on tone with contributors

The people who send ideas to an open innovation programme are, almost without exception, acting in good faith and hoping somebody will take them seriously. The submission terms necessary to run a programme safely read, to that audience, as a wall of disclaimers.

Both things can be true. A programme that explains, in a short paragraph above the terms, why the disclaimers exist — that the company develops independently, that it cannot accept ideas in confidence, and that this protects contributors as much as the company — gets better submissions and fewer complaints than one that presents the same terms without explanation. It costs a paragraph, and it is the difference between a portal people use and one they resent.

Key Authorities at a Glance

Idea protection and its limits. 17 U.S.C. § 102(b); Baker v. Selden; Feist Publications, Inc. v. Rural Telephone Service Co. on facts; Desny v. Wilder on implied contract for a disclosed idea; 17 U.S.C. § 301 on preemption of equivalent state claims.

Ownership and transfer. 17 U.S.C. § 201 on initial ownership and joint works; 17 U.S.C. § 204 on transfers; 17 U.S.C. § 101 on work made for hire; Community for Creative Non-Violence v. Reid; 35 U.S.C. § 261 with FilmTec Corp. v. Allied-Signal Inc. and Board of Trustees of the Leland Stanford Junior University v. Roche Molecular Systems, Inc..

Inventorship and joint ownership. 35 U.S.C. § 116; 35 U.S.C. § 256; 35 U.S.C. § 262; Burroughs Wellcome Co. v. Barr Laboratories, Inc..

Disclosure and patentability. 35 U.S.C. § 101 with Alice Corp. v. CLS Bank International; 35 U.S.C. § 102 grace period; 35 U.S.C. § 111 provisionals; 35 U.S.C. § 112.

Trade secret and confidence. 18 U.S.C. § 1836; 18 U.S.C. § 1839; Kewanee Oil Co. v. Bicron Corp..

Contract formation and consumer protection. Online formation as discussed in Terms That Actually Bind; 15 U.S.C. § 45 for deceptive promotional practices. Contest and sweepstakes regulation is largely state law; see Contest and Sweepstakes Rules.

| Authority | Governs | Practical consequence | | --- | --- | --- | | 17 U.S.C. § 102(b) | Ideas | Not protected by copyright | | Desny v. Wilder | Implied contract | Receiving an idea creates exposure | | 17 U.S.C. § 301 | Preemption | Contract claims often survive | | 17 U.S.C. § 204 | Transfers | Signed writing required | | 35 U.S.C. § 261 | Patent assignment | Present assignment language | | 35 U.S.C. § 262 | Joint owners | Each may exploit without accounting | | 17 U.S.C. § 201(a) | Joint works | Co-authors are joint owners | | 35 U.S.C. § 102 | Grace period | Demo day is a disclosure | | 18 U.S.C. § 1839 | Confidence | Non-confidential terms matter | | Stanford v. Roche | Vesting | An employer may already own it | | 15 U.S.C. § 45 | Promotions | Rules must match practice | | State contest law | Consideration and chance | Skill-based judging avoids the lottery |