Необходимость патентования изобретений для бизнеса освещена чуть ли не в каждой второй статье об интеллектуальной собственности. Но что же делать, когда необходимо защитить продукт компании, а при разговоре с разработчиками ответы один содержательнее другого: «я просто улучшил код», «ничего нового тут нет», «я просто фиксил баги», «мне это не интересно» и «отстань от нас, мы уже все предложили» т.д.? Рецепты под катом.

Столкнувшись с такой реакцией (а также в принципе с проблемой найти патентоспособные идеи), я выделила несколько моментов, которые помогают собрать идеи и организовать процесс по работе над защитой интеллектуальной собственности в компании.

Проясните основные моменты потенциальным авторам изобретения

Для начала надо пояснить, что такое патент, для чего он используется, что защищает, выгоду для компании и для самого разработчика.

Например:
Патент – документ, подтверждающий исключительное право (право на запрет использования другими лицами), авторство и приоритет изобретения, полезной модели либо промышленного образца.

Выданный патент позволяет владельцу запрещать любое несанкционированное использование изобретения, описанного в документе, то есть защитить продукт от копирования и претензий других лиц на результат творческой деятельности разработчика. Однако, тут же могут возникнуть восклицания со стороны этого же разработчика, что никакой творческой деятельности и в помине не было, и все заурядно и просто. Решение – проанализировать какую-либо его работу и показать, что в ней можно считать новизной, или же показать, что можно в нее добавить, чтобы она появилась.

Компания-правообладатель может получать следующую выгоду от патента:
• Защита от нападок конкурентов и троллей;
• Защита от копирования;
• Продажа лицензий на защищенные технологии;
• Продажа технологий;
• Повышение стоимости компании (ИС – нематериальный актив компании).

Для автора изобретения же немного другая польза от патентования:
• Научная публикация с подтверждением новизны предложенных технологий;
• Выплата бонусов за патентуемые изобретения, созданные в рамках служебных обязанностей.

С таким подходом даже если разработчику не очень понятна цель патентования идей, он будет мотивирован улучшением резюме или бонусами.

В случае, если разработчик настаивает только на улучшении кода, и что именно написанный код (обновленный, переписанный, улучшенный и т.д.) и является предметом для патента, можно дать ему понять, что код — это объект авторского права, а не патента. В заявке на патент необходимо описать способ или функцию, а именно посмотреть, что выполняет написанный код, какие проблемы в продукте решает и что улучшает.

Приведите примеры запатентованных идей

Однако далеко не всегда бывает понятно, что под этим понимается и какие идеи можно предлагать для патентования.

Для решения этой проблемы советую приготовить презентацию с примерами уже поданных заявок и выданных патентов (желательно своей компании, если таковых нет, то можно и из интернета).

Учитывая, что изобретение в заявке описано своеобразным образом, стоит пояснить и отдельно идею, и что написано в claims и description. Это позволит показать, как из предложенной идеи составляют заявку на патент и какие идеи в принципе могут быть защищены (включая «бредовые», незаметные изначально и даже самые незначительные).

Организуйте мозговой штурм

На следующем этапе, если у программиста так и не возникает никаких идей и он все же придерживается своей позиции, можно организовывать мозговые штурмы, групповые или один на один.

По опыту на групповых результат по количеству идей лучше, однако после таких встреч нужны еще разговоры один на один для обсуждения отдельных предложенных идей.

Групповые обсуждения эффективней организовывать по 3-6 человек, учитывая сферу занятости и знания каждого из приглашенных. В Parallels я стараюсь беседовать по командам, к примеру, один день команда по клиентским приложениям продукта Parallels RAS, другой день по VDI компоненту того же продукта и т.д.

Так люди будут более открыты и обсуждать какие-либо идеи или проблемы со своими коллегами, главное только разговорить их. Не стоит обсуждать детали каждой предложенной идеи сразу со всеми – только время потеряете, лучше накидать как можно больше идей и после этого отдельно встретиться с автором и все уточнить. На таких встречах так же сразу откидываются идеи, которые не подходят ввиду известного одному или нескольким участникам prior art (аналога). Причем идеи могут возникать как по тому, что было сделано в продукте, так и по тому, что планируется или может быть сделано. Бывали случаи, когда из брэйнштормов для патентов рождались новые фичи для продукта компании, реализованные в дальнейшем.

На встрече один на один программисту сложнее раскрепоститься, поэтому лучше пройтись по тому, что он уже реализовал и посмотреть, как еще можно было бы улучшить части продукта, с которыми он работает.

Совет: приглашайте на любые мозговые штурмы дополнительно человека, который работает с продуктом длительное время, желательно с глубокими техническими знаниями и который каким-то образом взаимодействовал с патентами (уже есть запатентованные идеи).
На брэйнштормах собирать лучше все идеи, шарообразные и узко применимые, непроработанные и реализованные. А уже потом решать, что с ними делать.

Проведите анализ нового функционала продуктов

Другой вариант сбора идей для патентов – анализ нового функционала в последних и планируемых релизах с руководителями проектов и менеджерами по продукту. Тут так же не стоит заострять внимание на мелочах и деталях, все разъяснить можно позже с разработчиком, работающим над конкретным функционалом. Цель такого анализа — выявление потенциальных идей для патентов.

Так, например, периодически я организовываю встречу с руководителем проекта Parallels Desktop и менеджером этого же продукта, где мы проходимся по списку реализованного в готовом обновлении. Параллельно с выписанными потенциальными идеями записываю имена разработчиков, которые работают над ними. Далее уже уточняю все интересующие меня вопросы конкретно у них, что не тратит время руководства и дает возможность подробно проговорить реализацию.

Не забывайте, что в первую очередь следует работать над функциями, которые уже были внедрены в опубликованные обновления. Конечно, зависит от законодательства страны, но в большинстве случаев запатентовать их можно только в течении определенного промежутка времени.

Также не отбрасывайте идеи, связанные с инновациями, которые могут быть применены в вашем продукте. Бывает полезным обсудить их с руководством и проанализировать возможность внедрения их в продукт, а как следствие появляется вероятность возникновения изобретения.

Организуйте процесс анализа идеи и работы над патентными заявками

Все собранные идеи можно обсудить на патентном комитете, это позволит всесторонне взглянуть на предложенные изобретения и решить с чем работать, что нужно доработать и что не годится для защиты. На патентном комитете так же есть вероятность появления новых идей, так как при обсуждении предложенных участники могут модифицировать, объединять, или же вообще натолкнуться на совершенно иную мысль.

У нас в такой комитет входит 6 человек, и включает представителя каждого крупного проекта и руководителя всей разработки компании.

На таком обсуждении идеи анализируются с учетом не только трех критериев патентоспособности (новизна, полезность и неочевидность), но и необходимости патента для компании.

Четко покажите процесс обработки идей в компании разработчикам и их руководству, куда записываются идеи, какие стадии разработки заявки существуют и что хотелось бы видеть от авторов изобретений.

Итог

Правильно замотивированные программисты смогут найти изобретения в продуктах компании, но стоит помочь им в понимании целей, задач, процессов и организации мероприятий. Правильный подход тоже играет важную роль, помните: люди разные – интересы разные, кто-то слушает только начальника, кому-то интересны бонусы, а кто-то просто любит все новое и с радостью поработает вместе.