E-2.1 Conduct Acquisition Planning

1. Align the initial design studies to the major functional elements

2. Establish a clear understanding of the IP, data deliverables, associated license rights requirements. If it is likely that an Offeror may propose IP that was not developed at private expense, the Contracting Officer should engage with DCAA to determine what assistance can be provided to verify funding source/existing data rights, specific to that requirement.

3. Contracting Officer/Specialist serves as Business Adviser in development of acquisition documentation.

4. PM and Contracting Officer/Specialist conduct market research, including through the Defense Innovation Marketplace

5. Write an IP strategy for the system modules that align with Modular Open Systems Approach (MOSA): Technology developed all/part by USG Funding, get delivery of what you're going to pay for (in native format, if it seems too early or costly to reformat the data for DoD’s usual standard) (Guidance Intellectual Property Strategy - 2015 (IP Strategy Brochure_Final 2-10-15.pdf (dau.edu) and Army Implementation Guidance, Appendix C (requires CAC))

6. Verify that the strategy includes an approach for the remainder of modules that can be competitively acquired under the Restricted-Proprietary Model: Technology developed entirely at private expense (IP Strategy Brochure 2015 (IP Strategy Brochure_Final 2-10-15.pdf (dau.edu) and Army Implementation Guidance, Appendix C (requires CAC))

7. Verify the IP strategy accounts for both short-term and long-term needs, covering the full life cycle of the system.

8. Incorporate Modular Open Systems Approach (MOSA) considerations into Acquisition Strategy.

1. The solicitation should clearly and effectively communicate and prioritize IP goals.

2. Be transparent in articulating intellectual property; data deliverables; associated license rights requirements; Government operation, maintenance, installation, and training (OMIT); modernization; and sustainment objectives.

3. The Performance Work Statement (PWS)/Statement of Work (SOW) should identify the license rights and data deliverables (including OMIT data) required and be linked to CDRL(s). The offeror may need to provide costs/prices, if separately priced.

a. License Rights and data deliverables (including OMIT data) described under CDRLs should comprise a complete package (or as much as needed) of all technical data and computer software for enabling maintenance of an entire system.

4. Request that the offeror identify restrictions on license rights.

5. Incorporate delivery requirements and require offerors to assert their specific restrictions on license rights.

6. Required data or software must be a deliverable, assigned to a CLIN.

7. Incorporate appropriate provisions and contract clauses.

8. For commercial technologies, request information similar to that required in the DFARS listing and assertion requirements provision (DFARS 252.227-7017) and include CDRL requirements for copies of commercial and negotiated licenses in the solicitation.

9. Request that offerors propose their own sustainment transition plans. Suggestion: Use sustainment transition plans as an evaluation factor.

10. Use the deferred ordering and deferred delivery clauses (but don’t overestimate its power!) Should not be used in place of proper acquisition planning. Acquisition planning for the data deliverables, and incorporate in the solicitation.

11. Consider incorporating statement for trademark license rights in solicitations and contracts *Army Source Selection Supplement, Section H-2.3, Develop the Request for Proposal

12. Consider adding in Section H – Special Contract Requirement language regarding background patent rights.

13. Consider adding in Section H – Special Contract Requirement language regarding Modular Open Systems Approach (MOSA) – including interfaces, patent and data rights, and data deliverables.

14. If the IP strategy includes recompeting a system, subsystem, or component, consider requesting the offeror’s proposed terms and conditions for delivering a Technical Data Package (TDP) that grants rights to the TDP for the system/subsystem/component. Proposal shall clearly outline the terms and conditions, all associated costs, and any minimum quantity (if applicable), in addition to providing the Government with the capability to obtain an IP license from the date of notification of award. Government should be granted sufficient IP rights including technical data rights and background patent rights necessary to allow the Government to compete the design, potentially secure additional sources for the system/subsystem/component, and/or use submitted technical data on any other Government programs.

15. Consider the use of escrow. A data escrow account is an account, held by a third-party or even a prime (provided the prime is not the owner of the data to be placed in escrow), which is populated by the offeror with designated technical data, computer software, and/or computer software documentation (“the escrow data”) and will only be released to the Government under specified, mutually agreed to, conditions.

1. Evaluate IP, data deliverables, license rights, and MOSA in accordance with section M of the solicitation and the source selection plan. Negotiate, as needed, whether sole source or competitive.

2. Evaluate the proposed assertions (as to the restrictions on license rights).

3. With the assistance of a cognizant IP attorney, research to verify IP and data rights assertions made by each offeror. If there is reason to believe an offeror correctly asserted an item was developed exclusively at private expense, audit the offeror’s records with the assistance of the Defense Contracting Audit Agency (DCAA). (NOTE: The Contracting Officer should engage with DCAA as early in the process in the procurement planning process as possible to determine DCAA’s availability to assist.) See DFARS 252.227-7019 or DFARS 252.227-7037 for additional information.

4. Evaluate the offeror’s provided information for commercial technologies (similar to that required in the DFARS listing and assertion requirements provision (DFARS 252.227-7017)).

5. Evaluate offeror’s proposed terms and conditions for delivering a TDP and granting rights to the TDP for the system/subsystem/component, as requested in Section L, in accordance with the evaluation criteria stated in the RFP.

6. Ensure specific up-front delivery requirements for technology being developed under the contract are met; determine if cost-effective/fair and reasonable.

7. Evaluate and negotiate competitively-priced options for IP deliverables for which Army’s “need” for the deliverable is dependent on future uncertain events or decisions – When it is not certain whether an up-front purchase is cost-effective/fair and reasonable

8. Research to determine the cost of same or similar license rights or data deliverables (including data for OMIT). Research and understand any market trends specific to data and license rights that may directly impact cost. (This is typically necessary when license rights are a significant portion of the price and the evaluation will include a cost realism analysis or a complex price reasonableness analysis.)

9. When applicable, in accordance with the stated evaluation criteria in the solicitation:

a. Determine whether the software developer/owner is identified.

b. Determine whether the offeror wholly owns the rights necessary to make, use, sell, or offer for sale.

c. Determine whether there is a third-party software developer/owner.

d. Determine whether offeror proposed third-party software is open source software.

e. Confirm the offeror will ensure negotiated rights are passed down to subcontractors.

f. Determine whether the offeror has the capability and/or willingness to deliver license rights for technical data and computer software necessary for depot level maintenance.

g. Confirm whether the offeror’s proposed special licenses meet the solicitation criteria and are reasonable.

1. Early in negotiation process, when competition exists, establish an environment of open communication and negotiations of prices/costs.

2. Consider negotiating license rights and data deliverables (including data for OMIT) required (should be linked to CDRL(s)) and costs/prices, if separately priced.

3. Consider negotiating to ensure a complete package (or as much as needed) of all technical data and computer software for enabling maintenance of an entire system is delivered, when appropriate.

4. Contract Officer should discuss the proposed level of rights and proposed price/cost.

5. Ensure requirements for license rights, and data deliverables – including data for OMIT (developed, delivered, or provided by subs of any tier) are understood and request inclusion of required/desired terms in contracts with subcontractors.

1. Incorporate into contract all asserted license rights restrictions.

1. Incorporate into contract all applicable IP clauses and provisions.

2. Document (within contract) specific up-front delivery requirements for: 1) Technology being developed under the contract (i.e., you’re already paying for it!); and 2) Known requirements for proprietary technology deliverables, when cost-effective/fair and reasonable.

3. Ensure all data deliverables are assigned CLIN(s) and CDRL(s) and are traceable to the PWS/SOW

4. Incorporate proposed product support/sustainment strategy in the final contract.

5. If escrow account is used, ensure it is assigned a priced CLIN(s).

1. Make sure the award is clear on what will be delivered and delivery date.

2. If there is a patent clause (usually in research and development contracts), ensure the invention disclosures are timely, patent applications are properly filed when appropriate, and the Government’s rights are established. Establish follow-up procedures.

3. Monitor to ensure the deliverable schedule is being met and the data quality is as required.

4. Review the IP strategy as major development milestones are completed.

5. Continuously, assess and update the IP strategy and ensure a life cycle consideration for competition is sustained within the costs of the program’s business objective.

6. Create a Program or PEO Repository to ensure that the data can be retrieved and [re] used when it is needed later (bonus: transfer to, and reuse by, other programs whenever possible).

7. Technical/operational needs are the responsibility of the Government. Do not rely on industry to ensure Government requirements can be competitively replaced.

8. Business/legal needs are the responsibility of the Government program office with support from appropriate contacting office and legal office (e.g., tracking Gov’t investment to support challenging IP restrictions/assertions).

9. Update as necessary any post-award changes to the list of asserted data rights restrictions.

10. Monitor compliance of requirement to report inventions developed during contract performance.

11. Conduct reviews to verify data is delivered and complies with contract requirements: 1) Does the data delivered match the technical/functional requirements identified in the contract; and 2) Asserted data rights markings (Do the markings match up with the list of assertions?).

12. Assess Technical compliance (audit or Independent Verification & Validation).

13. Regularly audit deliverables for Restrictive Markings (recurring) conforming and justified.

14. Invoke withhold payment clause (DFARS 252.227-7030, Technical Data-Withholding of Payment) for non-compliant technical data.

15. Initiate a validation procedure when markings are not justified (i.e., do not accurately describe the Army’s license right) Refer to DFARS 252.227-7019 and 252.227-7037.

16. Follow procedures under DFARS 252.227-7013 and 252.227-7014 when markings are nonconforming (i.e., not a marking prescribed by the DFARS).