When you are designing a product and have some patented components or processes, which you don't own, and you wish to include (embed) them within your product, how do you go about evaluating these patents to make sure they will add expected and real value to your product?

A practical flow-chart presented herein outlines a process that will help you evaluate whether a patented component or process can be appropriately functional, useful and cost-effective when embedded within your product or its associated development processes. Note, though, that this evaluation process should not be confused with what is commonly called Patent Valuation ¹, which refers to estimating the asset value of a patented item by itself.

First, it's necessary that a complete description of the proposed product and a proper business justification for the product already exist. This is commonly achieved with a Market Requirements Document² (MRD), which describes (1) the product in detail: e.g., use, function, performance, visual, reliability, standards, etc., (2) the requirements of the development project: e.g., resources, expertise, facilities, regulatory compliance, reliability, etc. and (3) the business justification: e.g., project plans, business case, markets, production, distribution, support, etc.

It's also highly advised that a Product Requirements Specification ³ (PRS) be developed, even if not yet completed. The PRS describes the complete technical implementation of the product such as: (1) the product's architecture, selected and proposed technologies, including patented items and required ancillary components, (2) test plans and special production equipment, regulatory compliance, support, QA and reliability test plans.

These important credentials must exist - otherwise, assessing whether a patented item adds value, when included within a vague product design, is very difficult. If the new product is fairly well described and documented as declared above, then the following flow chart can help you wade through this evaluation process successfully.

Some of the tasks, decisions and the order of flow are very general and should be interpreted according to your product type, industry and development plans.

Flowchart - Page 1:	Flowchart - Page 2:	Flowchart - Page 3:	Flowchart - Page 4:
Please click on the thumbnail to enlarge