営業秘密管理指針が本年度の不正競争防止法のデータ利活用に関する改正を受けて改訂され、それが先月、経済産業省のホームページで公開されました。
・営業秘密管理指針（最終改訂：平成３１年１月２３日）
改訂個所はあまり多くありませんが今回の改訂では非公知性の説明に、自社製品のリバースエンジニアリングによる非公知性喪失に関する記載が裁判例と共に追加されています。
自社製品のリバースエンジニアリングによる非公知性喪失は、技術情報を営業秘密理とするうえで非常に重要な事項であると私自身も考えており、このことが営業秘密管理指針に追加されたことは好ましいことだと思います。
しかしながら、個人的にはもう少し記載内容を充実させてもよかったかもしれません。
技術情報を営業秘密として管理するか否かの判断は、この自社製品のリバースエンジニアリングによる非公知性喪失の可能性の有無が重要な判断材料となるためです。
もし、自社製品のリバースエンジニアリングによって非公知性が喪失する技術情報であれば、当該技術情報を秘密管理していても、裁判において営業秘密とは認められません。
このような技術情報をどのように“知財”として管理するのか？
裁判所が営業秘密として認めないからと言って、当該技術情報の秘密管理に意味がないわけではありません。
秘密管理している技術情報であれば、たとえ営業秘密と認められなくても、企業の意に反して当該技術情報を漏えいさせた従業員や取引会社等に対して、秘密保持義務違反の民事責任を問うことが可能かもしれません。
また、当該技術情報に対して特許、実用新案、又は意匠といった権利取得を行うという選択肢もあります。
営業秘密とすることを検討している場合には、公開を前提とした上記出願は行わないという決定を一旦したのかと思いますが、自社製品のリバースエンジニアリングによって非公知性が喪失するのであれば、権利取得のための出願も再考する必要があるでしょう。
自社製品のリバースエンジニアリングによる非公知性の喪失について詳しく知りたい方は、私の下記寄稿をご参考にしてください。
知財管理誌への寄稿は近年の判例をまとめたものであり、詳しく解説していますが、少々長くなっています。一方、弁理士会のコラムは、これを短くしたものであり、知財管理誌に比べて読みやすいかと思います。
・「リバースエンジニアリングによる営業秘密の非公知性判断と自社製品の営業秘密管理の考察」知財管理誌
・「自社製品に対するリバースエンジニアリングと営業秘密との関係 」弁理士会ホームページ 営業秘密に関するコラム
弁理士による営業秘密関連情報の発信
営業秘密侵害と特許侵害との違いは何でしょうか？
当然、色々あるかと思います。
そもそも、特許侵害は特許権が存在しないと成り立ちません。
一方、営業秘密侵害は営業秘密の存在が必要です。
ここで、大きな違いの一つに、営業秘密侵害は“人”が介在する場合が多い一方、特許侵害は“人”の介在はないということでしょうか。
営業秘密侵害における人の介在の典型的なパターンは、転職者でしょうか。具体的には、営業秘密を保有する企業の元従業員が競合他社に転職する場合に、この元従業員が営業秘密を持ち出すパターンです。このように元従業員の転職と共に侵害が発生するようなことは、特許侵害では考え難いです。
そして、営業秘密侵害では、被告企業と共にこの元従業員も被告となる場合が多々ありますし、この元従業員は刑事責任を負う場合もあります。
また、訴訟が提起された後の被告企業の対応も異なるかと思います。
特許侵害の場合であれば、当該特許権の無効を争うでしょうし、訴訟で侵害の事実が認められた場合に備え、製品の仕様変更や製品の販売停止等を検討するでしょう。
一方、営業秘密侵害であれば、原告が営業秘密と主張する情報の秘密管理性、有用性、非行知性の妥当性を争うでしょう。
ここで、営業秘密侵害の場合には、営業秘密を持ち込んだ疑いのある転職者（原告の元授業員）の処遇も被告企業は考えることになるでしょう。
営業秘密侵害の場合において被告企業は、訴訟を提起されるまで又は原告企業から警告等されるまで、転職者が原告企業の営業秘密を持ち込んだことを認識しない可能性が高いと思われます。
このような状況において被告企業は、この転職者にそれまでと変わらず業務を遂行させることができるのでしょうか？それは難しいかもしれません。一旦、全く異なる業務に従事させるという判断もあり得ます。
さらに、訴訟は２～３年も継続される可能性もあります。結論が出ない間、被告企業は当該転職者の処遇をどのようにするべきか悩むでしょう。
また、被告敗訴となった場合、当該転職者をどうするべきでしょうか？解雇するのでしょうか？
ここで、このような転職者は、原告企業の営業秘密を知り得る立場にあることから、転職先である被告企業にとっても優秀な人材の可能性が高いかと思います。実際に、転職者が被告企業で厚遇を得ていたことが示唆される裁判もあります。
被告企業にとっては、このような優秀な転職者に対して当初予定していた業務を遂行させることができない事態や解雇する事態に陥ることは、甚だ不本意でしょう。
このように営業秘密侵害では、被告企業にとってこのような人的問題も発生する可能性が考えられます。
逆に考えると、企業（転職元企業）は元従業員の転職先企業に対して、営業秘密侵害を問うことで転職先企業における元従業員の業務遂行を妨害できる可能性があります。
それが、ボンバルディアが三菱航空機に対して行った訴訟かもしれません。
これに対して、三菱航空機はボンバルディアに反訴を行うという手段で対向しています。人材の流動化が高まっている現在、このような訴訟も増加するかもしれません。
では、転職者を受け入れる企業はどうするべきでしょうか？
対策としては、当該企業が営業秘密の流入リスクを十分に理解したうえで、転職者に対しても前職企業が保有する営業秘密の持ち込みは刑事罰もあり得る違法行為であることを入社前に理解してもらうことです。
また、入社後に転職者の上司等が、前職企業の営業秘密であろう情報を当該転職者から聞き出そうとする行為も行ってはなりません。
もし、転職者が前職企業の営業秘密を持ち出して自宅に保管していた場合には、この上司の言動が圧力となり、違法と分かっていても転職先企業で当該営業秘密を開示する可能性があるからです。
このようなことにより、転職先企業は、転職者を介した他社の営業秘密の流入を確実に防止する必要があります。
弁理士による営業秘密関連情報の発信
技術的に特徴のないプログラム（ソースコード）は、営業秘密として認められるのでしょうか？
すなわち技術的に特徴のないソースコードは、既知のソースコードの組み合わせであり、非公知性や有用性がないと解釈できるかもしれません。
このようなことに対して判断が行われた裁判例として、Ｆｕｌｌ Ｆｕｎｃｔｉｏｎ事件（大阪地裁平成25年7月16日 平成２３年（ワ）第８２２１号）があります。
この事件は、原告の元従業員であった被告Ｐ１及び被告Ｐ２が原告の営業秘密である本件ソースコード等を被告会社に対し開示し、被告会社が製造するソフトウェアの開発に使用等したと原告が主張した事件です。
この事件において、原告が開発して販売しているソフトウェア（原告ソフトウェア）は、原告が購入したエコー・システム社の販売管理ソフトウェアであって、ソースコードを開示して販売される「エコー・システム」に原告独自に機能を追加して顧客に応じてカスタマイズをしたものであり、開発環境及び実行環境としてマジックソフトウェア・ジャパン社のｄｂＭａｇｉｃ（以下「ｄｂＭａｇｉｃ」という。）を使用するものであす。そして、ｄｂＭａｇｉｃで使用可能な原告ソフトウェアのソースコードが、原告が営業秘密であると主張している本件ソースコードです。
このような事実のうえで原告は、本件ソースコードの非公知性に対して次のように主張しました。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
（ア）公知情報の組合せであっても，当該組合せが知られておらず，財産的価値を有する場合は，非公知性がある。
（イ）本件ソースコードは，市販のエコー・システム（甲２２）のソースコードを基に作られているが，以下のとおり，非公知性がある。
ａ 原告ソフトウェアは，エコー・システムにはない生産管理に関する機能等も有するなどエコー・システムよりも機能が追加されている。本件ソースコードのうち，上記追加機能に対応する部分は，それ自体非公知である。
ｂ また，本件ソースコードは，エコー・システムのソースコードを長期間にわたりカスタマイズしたもので，全体が非公知である。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
一方、被告は「本件ソースコードは，エコー・システムのソースコードを基に，顧客に応じてカスタマイズされたものである。」として非公知性がないことを主張しました。
これに対して裁判所は「一般に，このようなシステムにおいては，個々のデータ項目，そのレイアウト，処理手順等の設計事項は，その対象とする企業の業務フローや，公知の会計上の準則等に依拠して決定されるものであるから，機能や処理手順に，製品毎の顕著な差が生ずるものとは考えられない。そして，機能や仕様が共通する以上，実装についても，そのソフトウェアでしか実現していない特殊な機能ないし特徴的な処理であれば格別，そうでない一般的な実装の形態は当業者にとって周知であるものが多く，表現の幅にも限りがあると解されるから，おのずと似通うものとならざるを得ないと考えられる。原告自身も，原告ソフトウェアに他社製品にないような特有の機能ないし利点があることを格別主張立証していない。」とのように述べており、原告ソースコードの非公知性が低いような心証であることをうかがわせています。
しかしながら、これに続いて裁判所は「イ そうすると，原告主張の本件ソースコードが秘密管理性を有するとしても，その非公知性が肯定され，営業秘密として保護される対象となるのは，現実のコードそのものに限られるというべきである。ウ そうすると，本件ソースコードは，上記趣旨及び限度において，営業秘密該当性を肯定すべきものである。」とのように判断し、原告主張の本件ソースコードの非公知性を肯定しました。
これは原告による「本件ソースコードは，・・・全体が非公知である。」との主張を認めたものと思われます。
このように、複数の公知のコードが組み合わされたソースコードであっても、全体として公知でなければ、営業秘密としての非公知性は認められると考えられます。
では、このような全体として非公知であるとして営業秘密性が認められたソースコードに対する不正使用の範囲はどのようなものでしょうか。
本事件において、被告による不正使用について原告は「ア 被告Ｐ２は，被告ソフトウェアの開発に当たって，本件ソースコード（プログラミングの設定画面）を参照し，原告ソフトウェアのテーブル定義，パラメータの設定，そこで行われているプログラムの処理等の仕様書記載情報を読み取り，当該情報を基に，被告ムーブの担当者にＶＢ２００８によるプログラミングを指示して，被告ソフトウェアを開発した。」と主張しました。
しかしながら裁判所は、「本件において営業秘密として保護されるのは，本件ソースコードそれ自体であるから，例えば，これをそのまま複製した場合や，異なる環境に移植する場合に逐一翻訳したような場合などが「使用」に該当するものというべきである。原告が主張する使用とは，ソースコードの記述そのものとは異なる抽象化，一般化された情報の使用をいうものにすぎず，不正競争防止法２条１項７号にいう「使用」には該当しないと言わざるを得ない。」とのように判断し、被告による不正使用については認めませんでした。
このように、全体として非公知であるとして営業秘密性が認められたソースコードに対する不正使用の範囲は非常に狭く、具体的には「そのまま複製した場合や，異なる環境に移植する場合に逐一翻訳したような場合」に限られると解されます。このような不正使用の範囲はプログラムに対する著作権侵害と同様の範囲とも考えられます。
すなわち、ソースコードを営業秘密として管理するにあたり、当該ソースコードの技術的な特徴の有無を判断し、当該ソースコードの不正使用の範囲がどの程度となり得るのかも理解することが望ましいと思われます。また、ソースコードに技術的な特徴があるのであれば、当該ソースコードのアルゴリズムも営業秘密として管理するべきでしょう。
弁理士による営業秘密関連情報の発信
