自社で新しい製品を販売するとき、製品名について他社商標のクリアランスを行う上で、次のような場合に結合商標の類否判断に迷うことがある。 自社製品名「○○ △△」（結合商標）に対し、他社商標「○○」が見つかるパターン 自社製品名「○○」に対し、他社商標「○○ △△」（結合商標）が見つかるパターン 商標出願人は、商標の構成全体から他人の商標と識別するように商標を考案しているため、基本的には商標は全体として観察されるべきものである。 しかしながら、複数の要素からなる結合商標に関しては、一部の要素から生ずる呼び名や概念が識別標識として働く場合があるため、商標法の判例では商標の分離観察を認めている。 ここで実務での参考とすべく、結合商標の類否判断の方法が示された判例を紹介したい。 結合商標の分離観察に関して 過去の判例では結合商標の分離観察の可否及び要部認定の判断基準が言及されており、具体的には以下の３つの類型のいずれかに当てはまる場合は、分離観察も可とされている。 しかし、分離観察の可否の判例は統一された状況とはいえず、あくまで分離観察の可否を検討する上での一助という位置づけとなるかもしれない。 類型 概要 類型１ その部分が取引者、需要者に対し商品又は役務の出所識別標識として強く支配的な印象を与えると認められる場合 類型２ それ以外の部分から出所識別標識としての称呼、観念が生じないと認められる場合 類型３ 商標の外観等に照らし、商標全体としての構成上の一体性が希薄で、取引者、需要者がこれを分離して理解・把握し、その一部を略称等として認識する結果、当該構成部分が独立した出所識別標識としての機能を果たすと考えられる場合（分離された各構成部分の全てが当然に抽出して類否判断を行うことが許される要部となるものではない） 参考として、以下２つの判例の内容を掘り下げてみたい。 つつみのおひなっこや事件（最判、平成19年（行ヒ）第223号、平成20年9月8日） VENTURE事件（知財高判、令和5年（行ケ）第10063号、令和5年11月30日） つつみのおひなっこや事件 以下の本件商標（結合商標）が、引用各商標と類似するか否かが争われた事件である。 項目 出願・登録番号 商標 本件商標 第4798358号 引用商標１ 第2354191号 引用商標２ 第2365147号 類型1：非該当 以下の通り、判決文を要約すると、「つつみ」の部分が強く支配的な印象を与えるものではない、ということである。 判決の要約 本件商標は、「つつみのおひなっこや」の文字を標準文字で横書きして成るものであり、各文字の大きさ及び書体は同一であって、その全体が等間隔に１行でまとまりよく表されているものであるから、「つつみ」の文字部分だけが独立して見る者の注意をひくように構成されているということはできない。 本件商標の「つつみ」から地名、人名としての「堤」ないし堤人形の「堤」の観念が生じるとしても、本件審決当時、それを超えて、「つつみ」の文字部分が、本件指定商品の取引者や需要者に対し引用各商標の商標権者である被上告人が本件指定商品の出所である旨を示す識別標識として強く支配的な印象を与えるものであったということはできない。 類型2：非該当 以下のように、「おひなっこや」の部分から出所識別標識としての称呼、観念が生じていると判断されている。 判決の要約 本件商標の「おひなっこや」については、これに接した全国の本件指定商品の取引者、需要者は、ひな人形ないしそれに関係する物品の製造、販売等を営む者を表す言葉と受け取るとしても、「ひな人形屋」を表すものとして一般に用いられている言葉ではないから、新たに造られた言葉として理解するのが通常であると考えられる。そうすると、土人形等に密接に関連する一般的、普遍的な文字であるとはいえず、自他商品を識別する機能がないということはできない。 VENTURE事件 以下の本件商標と引用商標（結合標章）の類否判断において、分離観察が許される第3の類型を示した事件である。 項目 出願・登録番号 商標 本件商標 商願2020-128329 引用商標 第6434159号 類型3：該当（一部要素は類否判断の対象外） 本件では、引用商標の「遊」の部分が独立した出所識別標識としての機能を果たす一方、「VENTURE」の部分では果たさないとの判断がなされている。 確かに、「遊」の占める部分が大半なので、納得感のある判断ではないかと思う。 判決の要約 引用商標の各構成部分を比較すると、文字の大きさの違いからくる「遊」の文字部分の圧倒的な存在感 、書体の違いからくる訴求力の差、全体構成における配置から自ずと導かれる主従関係性、称呼及び観念において一連一体の文字商標と理解すべき根拠も見出せない等の事情を総合すると、引用商標に接した取引者、需要者は、「遊」の文字部分と「ＶＥＮＴＵＲＥ」の文字部分を分離して理解し、中心的な構成要素として強い存在感と訴求力を発揮する「遊」の文字部分を略称等として認識し、これを独立した出所識別標識として理解することもあり得る。 「ＶＥＮＴＵＲＥ」の文字部分は、商標全体の構成の中で明らかに存在感が希薄であり、従たる構成部分という印象を拭えず、取引者、需要者がこれに着目し、引用商標の略称等として認識するということは、常識的に考え難く、引用商標の要部と認定することはできない。 知財部としての判断 基本的には結合商標も全体として観察すべきところ、以下の類型のいずれかに当てはまる場合は分離観察する場合もある、ということとなる。 類型１：その部分が強く支配的な印象を与える 類型２：それ以外の部分から出所識別標識としての称呼、観念が生じない 類型３：一部を略称等として認識する結果、当該構成部分が独立した出所識別標識としての機能を果たす ただ、これらは商標審査基準として明文化されたものではないので、知財部としては、結合商標の一部が他社商標と同一となる場合は、同一となる範囲などの程度にもよるが、例えば半分以上同一だったり、同一部分がそこそこ識別力がありそうであれば使用を控えてもらうよう事業部に促すのが安全な判断になるのではないかと個人的には思う。 事業部としては「ちょっと慎重になり過ぎな判断では？」と疑問を持たれることがあるかもしれないが、特許とは異なりネーミングを変更することはそれ程難しいことではないと思われるので、そこは何とか納得してもらえるように説得するのが大事である（ブランド戦略上必要なネーミングであれば再考の余地はある）。 既に製品を量産したり、プロモーションを展開している場合は修正が大変となるかもしれないが、それは事前にクリアランスを怠った結果と言ってしまえばそれまでである。

第三者と共同研究開発を行う前段階として、まずは情報共有できるようNDA（秘密保持契約）を結ぶことが多いかと思う。 （正直、NDA締結前から事業部が情報共有を始めてしまっている、というケースもあるのだが…） ここで、相手方が企業ではなく大学である場合は、少し独特の注意点がある。 特に大学側は「学内規則」「教育・研究の自由」といった制約があるため、以下の観点を押さえることが重要となる。 締結主体（大学単位・研究室単位・個人単位） 契約主体は、大学となることもあれば、研究室や教授個人となることもある。 大学単位での締結が基本 企業の立場で言えば、NDAは大学との間で締結することが望ましい。 企業から見れば、その方が研究室を超えた広範な関係者に秘密保持の義務を負わせることができるからである。 実務上は大学側が準備したひな型で締結することを求められる場合が多く、企業側はそれほど交渉の余地は無かったりする。 一方、大学側では管理ニーズもない上、管理工数もないため責任を負うのが難しいことを理由に、教授個人や研究室と締結することを学内規則とする大学もある。 この場合は仕方ないので、研究室単位・個人単位での契約を検討することとなる。 研究室単位・個人単位での契約 研究室や教授とNDAを締結する場合は、特定の研究やプロジェクトに焦点を当てた契約へとカスタマイズしやすくなる傾向がある。 ただ、実務的には教授が窓口となっても、契約書の署名者は大学の事務局となっており、結局交渉の余地があまり大きくないこともある。 大学とNDAを結ぶ際の留意点 大学は、研究の成果を学会や論文で発表することが重要な使命の１つであり、また目的によっては学生に秘密情報を開示する可能性もある。 こういった大学特有の事情を理解した上で契約内容を検討しておく必要がある。 大学側は秘密情報の開示ニーズが強め 大学は研究成果を公表する義務や慣習があるため、「学術論文としての公表制限」に慎重となる。 特に、秘密保持期間が長期間に及ぶことには難色を示されることが多い。 大学から見れば、せっかくの研究成果をアピールできず、これにより次年度以降の研究費を引っ張ってこれなくなるわけなので、当然の反応ではある。 企業側としては、大学側の意図を汲みつつも、開示前の事前通知・承認取得を要求する条項を設けるなどの予防措置を考えておきたい。 なお、大学によってはWeb上でひな型を開示していることもあるので、デフォルトでどの程度の秘密保持期間を設定しているのか、また例外規定を設けているのか参考にすると良い。 学生への開示 大学では学生が研究活動に関与することが多いため、企業としてはNDAの対象者に学生も忘れずに含めておきたい。 基本的には、一般的なNDAでよくある、お互いの役員や従業員に秘密保持義務を課すのと同じ考え方となる。 ここめ注意したいのは、学生は大学の従業員ではないため、企業の従業員のように守秘義務を自動的に負わない点である。 よって、大学のNDAに「大学の職員・学生等に必要な範囲で開示できる」「開示したものに対し、自らと同等の義務を負わせる」点を明記するだけでなく、大学から学生に対して個別の秘密保持誓約書を取る、という二段階の方式が推奨される。 そうは言っても、学生に開示するというのはそれなりのリスクを負うこととなる。 このため、開示先の学生はできるだけ少人数に留めるとともに、開示する情報も最小限にするよう依頼することが望ましい（NDAの基本的な考え方ではあるが）。 なお、学生は卒業することも踏まえ、大学という組織から離脱した場合も引き続き秘密保持義務を遵守させるよう誓約させる点も押さえておきたい。 実務上のポイント 大学とのNDAを結ぶ上での留意点は、以下の通りである。 大学側のひな型をベースに結ぶことが多く、それ程内容に交渉の幅が広いわけではないとは思うが、それでも念のため企業側が意図しない形で学会・論文発表するリスクが無いかは考えておきたい。 大学とNDAを結ぶのが望ましいが、研究室単位、個人単位での締結とならざるを得ないケースも 大学側のNDAひな型に合わせることが多い（企業側から提示すると交渉に時間がかかる） 秘密情報の「定義」や「有効期間」は過剰に広く・長くしない（大学側が応じにくい） 「学生等への開示」について守秘義務を担保する条項を盛り込むとともに、大学側で誓約書を取らせること それでも、開示する学生たち、開示する情報は絞り込んでおくこと なお、大学との取引においては、NDAよりも共同研究で生じた成果の帰属で交渉することが多い。 その辺りは、以下の記事にまとめているので参考にしてみて欲しい。 大学との共同研究で生じた発明の取扱い 大学との共同研究により発明が生じた場合、その特許の取扱いは共同研究契約により定められる。 実務上は、出願前に当事者間で協議し、あらかじめ契...

NDA（Non-Disclosure Agreement, 秘密保持契約書）とは、新規の取引の検討や実際に取引を行うにあたり、相手方に自社の秘密情報を提供する場合に結ぶ契約で、相手に秘密情報を漏らさない義務を課すものである。 相手方と契約交渉をしている事実や、契約条件（開発内容、ライセンス条件、料金表など）は、企業秘密として保護するべきことが多い。 ところが、開発側では既に交渉を始めており、後から「交渉の結果契約が結べそうなので、NDAを結びたいのですが・・・」と相談を受けてしまうこともある。 実務上は、具体的な契約交渉をする前に、きちんとNDAを取り交わすよう意識づけを行うことが重要となる。 ここで、プロジェクト毎に相手方とNDAを結ぶのは大変なので、包括的NDAを結びたいと思う人もいるかもしれない。 例えば、過去に締結したNDAをそのまま使えれば、新たな締結は必要ないと考えるだろう。 まずはNDAの基本構造に触れつつ、包括的NDAと個別NDAのメリット・デメリットを整理したうえでおススメを紹介したい。 NDAの基本構造 主な条項の基本構造は以下の通りである。 条項 内容 目的 何のために秘密情報を開示するか（共同開発、業務委託、事業提携の検討など）。 秘密情報の定義 あまりに包括的な定義付けは紛争の火種となりかねないので、書面に「Confidential」等と明記したもの、口頭の場合は一定日数内に書面で確認するなど、何を秘密情報とみなすかを明確にする。更に、以下のような例外も設ける。 (1)開示を受けたときに既に保有していた情報 (2)開示を受けた後、秘密保持義務を負うことなく第三者から正当に入手した情報 (3)開示を受けた後、相手方から開示を受けた情報に関係なく独自に取得し、又は創出した情報 (4)開示を受けたときに既に公知であった情報 (5)開示を受けた後、自己の責めに帰し得ない事由により公知となった情報 秘密情報等の取扱い 秘密を適切に保管・管理する方法のほか、目的外使用の禁止、相手方の事前承諾なしによる第三者提供の禁止等を記載する。 返却・廃棄義務 契約終了時や目的達成時に、秘密情報を返却・廃棄する義務。 有効期間・秘密保持期間 契約自体の有効期間、秘密保持義務の存続期間。契約締結等に要する期間をもとに設定するのが良い。秘密保持契約終了後も、一定期間は秘密保持義務を負わせるということも可能。 その他一般条項 反社会的勢力の排除、損害賠償、裁判管轄など。 契約を締結する目的や、秘密情報の定義・範囲が明確であるかを確認するとともに、お互いの目的が達成できるかを個別に確認することとなる。 開示側であれば、「保護すべき秘密情報が対象としてすべて含まれているか」「相手方に対し、秘密情報を保護するために必要な義務を課しているか」という点、受領側であれば「契約締結の目的を達成するために必要な情報をすべて受領できるか」「秘密情報の管理体制が、自社にとって構築・運用可能なレベルになっているか」という点が確認のポイントになるかと思う。 包括的NDAの特徴 以下、包括的NDAの特徴を記載する。 メリット 一番のメリットは、契約締結が一度で済むところである。 プロジェクトごとにNDAを作らなくても、一定期間の秘密情報授受を一括管理でき、企業間で複数プロジェクトが並行していても、基本ルールが一本化される。 また、案件がまだ具体化していない段階でも、早く情報を共有しやすいという利点もある。 デメリット ある程度開示目的が抽象的になってしまうのは避けられない。 例えば、「今後の業務全般に関する検討」など、広い表現になると、秘密情報の利用目的が曖昧になる。 これにより、仮に目的外使用禁止を定めていたとしても、相手方に渡した秘密情報が、思わぬ形で使用されてしまう可能性が生じてしまう。 更に、ある情報がどのプロジェクトのために開示されたか特定しにくく、契約違反の有無を判断しづらくなる。 例えば、目的条項を「両当事者間の今後の業務全般に関する検討のため」と書くと、何でもかんでも秘密情報にできるし、何のために使っていいかが曖昧となる。 個別NDAの特徴 次に、個別NDAについても記載しておきたい。 メリット 包括的NDAとの裏返しとなるが、まず目的を明確化できることが挙げられる。 「〇〇プロジェクトに関する検討」など、情報の利用範囲を限定しやすい。 どの情報がどの契約に基づいているか明確となることで、管理・証明が容易となる。 また、情報の重要度や秘密保持期間、返却・廃棄方法など、案件に応じて条項を変えられる。 デメリット 毎回契約作業が発生することとなるため、事務手続きが増える。 特に、スピード感が求められるビジネスでは遅れの原因になる。 プロジェクト毎に個別NDAを結ぶべきか、包括的NDAとすべきか より確実に秘密保持管理ができる個別NDAをおススメしたいが、場合によっては手間が増加することもある。 もし、同一の企業間で多くのプロジェクトが走る場合は、その負担はより大きいものとなるであろう。 そこで、実務上の折衷策としては、包括的NDAと個別確認方式との組み合わせが考えられる。 もっと正確に言うと、取引が頻繁に生じる企業との間で「基本契約」を締結し、その中に包括的NDAに相当する秘密保持条項を盛り込むという形である。 基本契約でベースとなる秘密保持の条件を押さえたうえで、プロジェクトごとに「個別契約書」等で目的・期間・情報範囲を特定することとなる。 基本契約で各プロジェクトに共通する決まり事や一般条項を盛り込んでおくことで、個別契約毎にそれらを記載する手間を省くことができる。 この場合、基本契約における目的条項は「当事者間で現在および将来行われる、個別に合意した取引または共同検討（以下「個別案件」という）のため」と記載すると、ある程度曖昧さを回避可能である。 とはいえ、それほど頻繁な取引を行うことが想定されなければ、個別NDAで問題ない。 過去に締結したNDAは使い回せる？ 開発からの問い合わせが多いのはこのパターンである。 結論、目的や契約期間が一致しさえすれば、新たなNDAは不要である。 しかし、別のプロジェクトで設けられたNDAであればその目的も異なることが通常であり、別途NDAを締結することが必要となるのが大半である。 まとめ 包括的NDAは「スピード・手間の軽減」には有利だが、秘密情報の「利用目的」がぼやけるリスクがある 個別NDAは事務手続きが増えるものの、「利用目的・範囲の明確化」には有効 実務上は都度個別NDAを結ぶのが好ましいが、取引が多い相手との間では基本契約を締結し、その中で包括的な秘密保持条項を設けることも 特定プロジェクト向けのNDAをプロジェクト間で使い回せることもあるが、基本的には別途締結が必要

記事を見ている人の中には、現在は開発業務に携わっているものの、知財部への異動を考えている方がいるかもしれない。 筆者はまさにそのパターンで異動・転職を経験してきたので、どこまで参考になるか分からないが、当時の体験を踏まえた記事を書いてみたい。 以下、知財関係のキャリアパスに進むにあたっての検討事項を整理する。 知財業務が自分に合うのか見定める 自分のキャリアを無駄にしないよう、自分が本当に知財に興味を持って取り組めるかを見定めておきたいところである。 単に今の環境を変えたいのであれば、エンジニアとしての転職もあるだろうし、技術営業、企画等への異動も選択肢に入るはずである。 通常の知財業務としては、技術者とのコミュニケーションを通じた技術内容の理解を起点として発明発掘をしたり、他社特許調査、知財戦略立案などを行うのがメインとなる。 こういった業務は決して華々しいものではなく、黙々と特許明細書を読む時間が結構長かったりする。 開発の立場で明細書を読んだことがあれば、あの独特の言い回しの文章を大量に読むのが地味に辛いと感じるのではないだろうか（中には、休日も読書のように読みふける兵もいるらしいが）。 また、特許法をはじめとする知的財産法の知識も必要だし、チームによっては契約書のドラフトをしたり、渉外業務を行うことが求められる。 開発で得た技術知識がある程度役に立つかもしれないが、開発時代とはかなり異なる業務に携わることとなるということを理解することが重要である。 知財に進みたい気持ちが薄れるようであれば、以降の記事は読み進めなくても大丈夫である。 まずは知財部への異動を考えてみる もし今の会社自体に勤めること自体に不満が無いのであれば、知財部への異動可能性を探ってみるのが良い。 基本的に部外への異動のハードルはそれなりに高いと思われるが、それでも知財業務未経験での事業部知財への転職よりは可能性がある。 いつ異動のチャンスが訪れるか分からないので、その時に備えて準備することが重要となる。 そもそも異動のチャンスは多くない まず開発部長等の目線から考えて、果たして部下が知財部へ異動することを認めてくれるか、という観点で考えてみる。 開発部から見ると、別部署への異動であればまだしも、知財部に限らず他部門に出て行かれてしまうと大事な人足が減ってしまうため、社内異動とはいえ歓迎してくれるとは考えづらい。 このため、知財部への異動により開発部にも大きなメリットが得られる事情があったり、元の部門の人員確保に目処がつかない限りは、異動のチャンスはそう高くないと思われる。 社内公募制度があればこの限りではないが、開示される諸条件（現役職など）に合致する必要はあるだろう。 選抜されるのも下準備が必要 また、仮に異動のチャンスがあったとしても、自分がその対象者に選ばれるとは限らない。 開発業務と知財業務とは内容がかなり異なるため、会社としてもどの異動希望者が知財適性があるかどうか、熱意があるのかどうかを見極める必要がある。 同様の希望を出している社員の方が適切だと思われれば、当然そちらが選ばれる。 したがって、たとえすぐの異動が叶わなくとも、来たるときに備えて各種アピール・準備をしておく必要がある。 開発活動と並行して、例えば、以下の活動を進めておくことで、自分に白羽の矢が立ちやすい土壌を形成しておくと良いかと思う。 積極的な特許活動のリーディング 部内の発明抽出会 知財部と連携した他社特許クリアランス活動 資格の取得 知財検定 弁理士（短答通過だけでもアピールポイント） 日頃の1 on 1やキャリア面談でのアピール 開発知見を活かした知財活動による企業貢献が可能である点の説明 思いつきの希望ではなく、数年先のキャリアを見据えた上での希望である旨の説明 知財部員への相談 同期等を通じて知財部の人員状況・異動の可能性のヒアリング 特に気を付けたいのは、面談でアピールするときである。 何の下地もなしに「なる早で知財部へ行きたい」と言うと、上司にはおそらくネガティブなイメージを与えてしまう（今の職場から逃げたいだけでは？と思わせてしまう）であろう。 実際、開発部から異動したまでは良かったが、知財業務が肌に合わず、数か月後に開発部にトンボ返りしてしまうケースもあるらしく、その辺りは開発部や人事部は判断が慎重にならざるを得ない。 もちろんすぐに異動が叶えば言うことなしだが、「開発活動は疎かにしない」「開発経験を生かした知財業務を通じ、会社に貢献したい」「キャリアパスはこう考えており、今はこんな準備をしている」という伝え方をすることで、大分上司の印象は変わってくるはずである。 自分が異動を通じてどう会社に貢献できるかを説明することは、就活や転職活動にも通じるところがある。 転職による企業知財部への配属狙いは厳しい もし今の職場で異動が難しければ、転職を通じた知財部配属というのも選択肢として挙がるかもしれない。 だが、あくまで私見ではあるが、それなりに難易度は高い。 転職の場合は、第二新卒であればポテンシャル採用ということも期待されるものの、基本的には即戦力として採用されることが多い。 果たして企業側に、開発経験はあるけれども知財は未経験という人間を、敢えて中途で採用するモチベーションがあるだろうか？ 特許事務所であれば、未経験であっても比較的年齢が若かったり、弁理士資格を取得していると採用してくれることもあるかと思う。 中には、「企業開発部→特許事務所→企業知財部」というキャリアパスを描く人もいるので、そういった道も無くはない。 ただ、企業によっては特許事務所経験（明細書書けます、という点など）はあまり求められていないことから、企業知財部への転職が容易とまではいえない点は注意である。 特許事務所への転職 上でも軽く触れた通り、企業知財部とは異なり、こちらは未経験であってもある程度の門戸は開かれている。 事務所で勤務する場合は弁理士資格が重要なため、既に資格を持っていたり、短答試験だけでも合格していたりすると、採用確率も高くなる。 ただし、特許事務所に勤務するということは、明細書のドラフトや中間処理書類の作成が主な業務となることは理解しなければならない。 企業知財部のようにビジネスに直接携わった提案がしたければ、その点はギャップが生じざるを得ない。 中小企業に対するコンサル業務をしている特許事務所もあるため、ある程度希望を満たせる可能性はあるが、可能性は高くない。 また、個人的な意見を承知で言うと、生成AIの技術発展に伴い、明細書作成をはじめとする書類作成業務は生成AIが代替していく流れは止まらないと思う。 したがって、単純な明細書作成という能力の価値は下がってしまい、将来が明るいとは言えない。 （もちろん、優秀な先生が様々な形で企業に付加価値を提供していく存在として生き残っていく可能性は否定しない） 特許庁への転職 特許審査官になるためには、人事院の実施する国家公務員採用総合職試験に合格する必要がある。 受験には３０歳という年齢制限がある。 これは、採用年の４月１日時点での受験可能年齢上限を意味しており、受験時に３０歳でも翌年の４月１日までに３１歳になる場合は、国家総合職を受験できない点は注意である。 実際に受験したことが無いので難易度は不明だが、弁理士試験と同様に難易度は高いと推測する。 また、理系の社会人、ポスドクなどの人材であれば、任期付審査官として採用されるというルートも存在する。 なお、審査官として審査の事務に７年間従事した場合には、弁理士となる資格が取得できる（弁理士法第7条）。 審査官を経て特許事務所や企業知財部へ進むキャリアパスも無くはないが、審査という業務の性質上、良くも悪くも企業知財部の業務とは異なる部分が多くなるであろう。 企業知財部としての経験を積んだ後の転職は？ もし幸運にも異動が叶い、知財部としての各種業務（出願権利化、他社知財対応、知財戦略立案、渉外活動、契約業務など）の経験を積むことができれば、他業種へ転職はそれほど大変ではないと思われる。 知財の素養が備わっていれば、経験上、担当技術領域の違い（HW系、SW系）はそこまで転職の合否に影響はしない。 技術知識そのものは入社後に勉強すれば十分カバーできるので、例えば以下の能力を総合的に鑑みて、採用ポジションと合致する人材かどうかを判断していると考えられる。 法律・制度の知識 特許法、商標法、著作権法などの基本法令の理解 海外知財制度（PCT、マドプロなど）の概要把握 判例・審決動向の把握 技術理解力 技術・製品・サービスを正しく把握し、発明の本質を抽出できる力 技術者との円滑なコミュニケーション能力 ビジネス・戦略的視点 知財権を守るだけでなく活用する（ライセンス、クロスライセンス、共同開発契約など）視点 競合調査・パテントマップ作成を通じた事業戦略へのフィードバック ブランド・デザイン保護の戦略立案 契約・交渉力 秘密保持契約、共同開発契約、ライセンス契約などのレビュー・起案 相手方との交渉・調整スキル（リスク説明、代替案提示） 社内調整・教育力 開発部門・営業部門と円滑に連携し、知財の重要性を説明・啓蒙する力 社内規程・発明報奨制度の整備と運営 情報収集・分析力 特許・商標データベース、学術論文、業界動向などの情報を効率よく収集・分析する力 知財リスクや訴訟リスクを早期に察知する力 コミュニケーション力・文章力 出願書類・契約書・社内報告書などの明確な文書作成 経営層や非専門部門にも分かるように説明する能力 ただし、有機化学（医薬関係など）に関してだけは、ある程度の専門知識の下地がないと、知財経験があったとしても転職は難しい印象である（求められるポジションにもよるが）。 筆者のキャリアパス（参考） 因みに自分の場合は、新卒後はとあるメーカーでハードウェアの開発部に数年間在籍していた。 しかし、特定機能に特化した開発業務にばかり従事しており将来的な発展性が見込めなかったこと、社外でも通用するような経験が積めず他業種への転職も難しく手詰まり感があったこと、そして自身が発明者として知財部員と仕事をしたときに水が合いそうだと思ったことが知財畑に進むきっかけとなった。 そして、開発時代はできるだけ知財業務を引き受けるよう努めるとともに、弁理士資格の取得に漕ぎつけることで、数年後にようやく知財部に異動することができた。 その後は「出願権利化業務」および「他社特許対応」を担当するものの、分業化が進んでいたこともあって幅広い知財経験が積めないことから、新天地を求めることとなった。 そして現在はあるSW企業の知財部として、契約、商標、著作権（OSS含む）、他社動向調査など、前職よりも多様な業務に携わらせてもらえており、決して楽ではないがとても有意義な経験をさせてもらっている。 中には知財と関係性の低い契約相談などもあり、その都度社内弁護士に問い合わせることもままあるが、それはそれで事業に対する視野が広がるので、決して悪いことではないと考えている。 今のところ転職する気はないが、もしすると決めたときは「書類準備」「面接の対策」「課題対応」など、それなりのエネルギーを充てる覚悟はしておかないといけないなと思う。

普段お世話になっている製品名やサービス名の中には、他社の登録商標が含まれることがある。 ウェブサイトやアプリの説明文、仕様書、マニュアルなどで気付かず使ってしまうものがあるが、その代表的なものとして「QRコード」「Bluetooth」を取り上げたい。 これらを商用の場や公式ドキュメントで無造作に使うのは避けておきたい。 「QRコード」に関して 「QRコード」（文字商標）は株式会社デンソーウェーブの登録商標である。 商標権者の許可なしに商品名・サービス名として自由に使うと、商標権侵害になるおそれがある。 しかし、「QRコード」に関しては、次の要件を満たせばデンソーウェーブに許可を求める必要は無い。 「QRコード」を使いたい場合 デンソーウェーブは公式サイトで使用に関する案内を公開しているので、商標使用条件や注意点を守れば使用することができる。 2025年8月時点の情報にはなるが、登録商標文を掲載※（例：「QRコードは株式会社デンソーウェーブの登録商標です。」）すれば、使用料の支払いやその他の手続きは不要である。 ※QRコード(名称)を利用した画面・印刷物ごとに掲載すること なお、自社の商品名やサービス名に「QRコード」を含めること(商用利用)は禁止されている。 使用の際は、今一度公式サイトを確認いただきたい。 こだわりがなければ別表現へ コードそのものを掲載すること自体は全く問題ないので、「QRコード」という名称にこだわりがなければ、別の呼び方に置き換えてしまうのが手っ取り早い。 例えば「二次元コード」とすれば、使用条件の確認も不要であるし、「詳しくはこちらをスキャン」と説明すれば、コードの名称自体に言及することもない。 Bluetoothに関して Bluetoothの代表的な商標として、「ＢＬＵＥＴＯＯＴＨ」（文字商標）と以下の図形商標が存在する。 これらの種類のBluetooth商標は民間団体であるBluetooth SIGが所有している。 Bluetooth商標を使用したい場合 Bluetooth SIGの公式サイトによれば、Bluetooth商標を使用するには以下の2つの要件を満たす必要がある。 Bluetooth SIGのメンバーであること（政府機関、大学、個人事業主のメンバー登録は受け付けていない） Bluetooth SIG メンバー登録には、AdopterメンバーとAssociateメンバーの2種類がある Adopterメンバーは入会費・年会費無料、Associateメンバーは有償だが、公開前のBluetooth仕様を閲覧したり、Receipt Numberの取得等をより安価に行えるなどの利点あり 提供される商品が、同製品のマーケティングと販売を行う企業のメンバーアカウントのもとでBluetooth認証プロセスを完了していること これらの要件を満たすためには、ざっくり以下の表に示すような費用が発生する。 項目 備考 Bluetooth SIGメンバー年会費 Adopterメンバーなら無料 認証テスト費用 製品に使用するデザイン（Bluetooth制御部分の設計）によっては不要 Receipt Number取得費用 Associateメンバーなら購入費が割安 このように、手間や費用を踏まえると、中々気軽に自社製品にBluetooth商標を使用することはできない。 まとめ うっかり使いがちな登録商標は色々あるが、適切に使おうとすると、権利者となる企業ごとに利用を許諾する条件（手続き、費用など）は千差万別である。 よって、登録商標の有無に感度を持つことは勿論のこと、いざ使いたいとなったときの負担の程度も調査しておくことが望ましい。

ソフトウェアやWebサイト、文章や画像など、あらゆる著作物に「©2025 ○○」といった著作権表示が付いているのをよく目にする。 しかし実は、日本の著作権法ではこの表示が義務付けられているわけではない。 とはいえ「表示しなくても権利が守られる」ことと「表示しない方がよい」ことは別問題である。 本記事では、著作権表示が法的に義務ではない理由と、それでも表示しておくべき実務的な意味、さらにOSS（オープンソース・ソフトウェア）における表示義務のポイントを整理する。 著作権表示は義務ではない（OSSの場合を除く） 上述の通り、日本の著作権法では義務ではない。 日本が加盟する万国著作権条約では、「著作権を表記すれば守る」と規定されている。 しかし、日本はベルヌ条約にも加盟しており、この条約では「手続きせずとも、著作物の創作と同時に著作権が発生する」としている。 両方加盟している場合はベルヌ条約が優先されるので、著作権表示は必要ないというわけである。 著作権表示しておくのが無難 仮にOSSを使用しない場合であっても、著作権表示により以下のようなメリットがあるため、特別な理由が無い限りは表示しておいた方が良い。 権利帰属先が明確となる 「誰が著作権者か」を示すことで、利用者がライセンス交渉や問い合わせをしやすくなる。 また、無断利用された場合にも、権利者を主張しやすくなる。 ソフトウェアやWebサイトなど、他人が利用することを前提にする場合は特に重要となる。 無断利用の抑止 著作権表記があると、利用者に「これは著作権のあるものだ」と意識させられるため、結果的に無断利用を減らせる。 裁判での故意・過失の立証にも有利に働くこともメリットである（「知らなかった」と言いにくくなる）。 ベルヌ条約に非加盟の国で著作権が有効となる 多くの国はベルヌ条約に加盟しているが、中には万国著作権条約にしか加盟していない国もある。 著作権表示をすれば、そんな国でも著作権を発生させることができる。 権利保護期間の証拠となり得る 「©2025 Author Name」のように年を入れることで、「いつからいつまで権利が発生しているか」の証拠の一助になる。 社内利用のソフトウェアでも、一応表示した方が良い 社内利用に限るのであれば、わざわざ権利帰属先を明確にしなくても良いと思うかもしれない。 しかし、悪意ある社員が無断でソフトウェアを持ち出したときに自社帰属である旨を証明する場合に著作権表示が役立つ可能性がある。 したがって、著作権表示しておくと良いことは確かだが、必須というほどではない。 OSSの場合は著作権表示・ライセンス表示義務あり ただし、OSSの場合は、殆どの全てのOSSライセンスにおいて、著作権表示・ライセンス表示義務が規定されている点には気を付けたい。 例えば、MITライセンスであれば以下のような著作権＋ライセンス文の表示が義務づけられる。 Copyright <YEAR> <COPYRIGHT HOLDER> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. このように、上部では著作権表示、またライセンス文の中には「著作権表示および許諾表示を記載すること」と定められている。 ...

企業内でエンジニア相手にOSSライセンスの確認を行う際は、OSSの中にあるLICENSEファイルにアクセスすることが殆どかと思う。 そして、自社で開発したソフトウェアでもOSSライセンスの表示義務を果たすために、同じくLICENSEファイルの同梱をするよう促す。 しかし、最終的にはスマホアプリの形で配布する場合であったり、HW機器に組み込んだ形で提供することも念頭に置かないとならないところ、その場合は上記のような対応ではユーザーがOSSライセンスを確認できなくなってしまう。 したがって、OSSライセンスの表示方法は「どのようにOSSを配布するか」によって異なることとなる。 この点、意外と知財部員だと見逃してしまうポイントではないかと思われるので、一般的な整理を以下にまとめておきたい。 ソフトウェアのファイル自体を提供する場合 Zip配布する場合や、GitHub公開するケースが当てはまる。 この場合は、配布パッケージにLICENSEファイルやNOTICEファイルを同梱するのが通常である。 例えば、OSSごとに、ライセンス文をまとめたライセンスファイルを同梱することが考えられる。 ライセンスによって、どこまで同梱するか（全文なのか、著作権表示とライセンス条項なのか）の条件は異なる。 スマホアプリとして提供する場合 バイナリ形式で配布される場合は、「アプリ内での表示」が一般的である。 iOS/Androidのガイドラインでも「OSSライセンス表示」はアプリ内に設けることが推奨されている。 具体的には、アプリ内の「設定」「ヘルプ」「クレジット」等のメニューに「OSSライセンス情報」の項目を設けることとなる。 リスト化された各OSSをタップすると、OSS毎のライセンス文やが閲覧できる形である。 多数のライセンスを管理するのは大変なので、ライセンス表示のためのライブラリを用いることが多いかと思う。 なお、アプリ内にはプライバシーポリシー、利用規約といった表示を併記することが多い。 （Google Playの監査でプライバシーポリシーを指摘されることが多いらしい） ソフトウェアが組み込まれた機器として提供する場合 ルーター、家電、IoT機器等に組み込まれる場合も、表示は必要である。 付属CD/USBにライセンスファイルを格納したり、機器のUI（Web管理画面やディスプレイ）に「OSSライセンス情報」ページを設けて参照可能にすることが考えられるが、中にはそういった表示が難しい機器もある。 その場合は、機器に同梱するマニュアルもしくはユーザーガイド、または製品Webページにライセンス文を記載することで表示義務を果たすこととなる。 まとめ 表にまとめると、以下の通りである。 配布形式 OSSライセンス表示方法 ファイル配布 パッケージにライセンス文を同梱 アプリ配布 アプリ内に「OSSライセンス情報」メニューを設ける 機器配布 マニュアル、付属CD、Web UI、製品Webページ等で表示

企業同士で契約を取り扱う上ではあまり気にしなくても良いと思うが、未成年者と契約を締結したり、利用規約・プライバシーポリシーに同意してもらう際の留意点についてまとめておく。 「親の同意が必要では？」と思うかもしれないが、実際は同意を必要としないものもそれなりに存在する。 親の同意が必要・不要なケース 主親の同意に関係しそうな契約絡みのケースは、以下の通りである。 契約書の締結 以下の民法第5条にある通り、原則として、未成年者が締結する契約は、親権者など法定代理人の同意がなければ取り消し可能である。 （未成年者の法律行為） 第五条　未成年者が法律行為をするには、その法定代理人の同意を得なければならない。ただし、単に権利を得、又は義務を免れる法律行為については、この限りでない。 ２　前項の規定に反する法律行為は、取り消すことができる。 したがって、契約を締結する側としては、親の同意が必要となる。 例えば、以下のケースで必要となる。 携帯電話契約（端末購入・通信サービス契約） サブスクリプションサービスの有料契約（動画配信・音楽配信など） 習い事や塾の契約 クレジットカード・ローン等の金融契約 医療行為（手術や検査など、リスクを伴う場合） 一方、民法第5条3項では、以下のような例外が設けられている。 ３　第一項の規定にかかわらず、法定代理人が目的を定めて処分を許した財産は、その目的の範囲内において、未成年者が自由に処分することができる。目的を定めないで処分を許した財産を処分するときも、同様とする。 「法定代理人が目的を定めて処分を許した財産をその目的の範囲内で使う場合」とは、例えば参考書、定期券の購入のための代金のことである。 「目的を定めないで処分を許した財産で、支払いができる場合」は、いわゆる小遣いが該当する。 したがって、以下のケースであれば法定代理人の同意は不要である。 参考書や文房具の購入 小遣いからの飲食物の購入 定期券や切符の購入（通学・通勤に通常必要な場合） なお、民法第5条は強行規定なので、契約書で「法定代理人の同意は不要」と定めたとしても無効である。 この規定の適用を免れるとすると、未成年者保護の目的が果たせないためである。 利用規約への同意 利用規約は契約行為の一種に該当するため、未成年者は親の同意が必要となる。 ※利用規約の詳細に関しては、以下の記事を参照のこと。 利用規約の特徴と重要性 最近、様々なユーザ向けの自社サービスを展開することとなり、そのサービスの利用規約を作成する機会があった。 法律上、サービス提供者に利用規約... 利用規約では、未成年者の利用に関する条項を明確にし、親権者の責任についても適切に定めておくことが重要となる。 プライバシーポリシーへの同意 プライバシーポリシーは個人情報の取り扱いに関する説明であって、契約そのものではない。 それでは、原則親の同意は不要であるかというと、個人情報保護委員会のFAQには、次のように記載されている。 法定代理人等から同意を得る必要がある子どもの具体的な年齢は、対象となる個人情報の項目や事業の性質等によって、個別具体的に判断されるべきですが、一般的には12歳から15歳までの年齢以下の子どもについて、法定代理人等から同意を得る必要があると考えられます。 ということで、未成年という括りではなく対象年齢に幅があるのは気持ち悪いが、ある程度年齢が低い場合は親権者の同意が必要となる。 なお、利用規約の中にプライバシーポリシーの内容を含めることも可能ではあるが、個人情報の取り扱いを慎重に行うため、利用規約とは別にプライバシーポリシーを設けるのが通常となる。 その他年齢制限に関する規定 ただし、サービス事業者が独自に「◯歳未満は保護者の同意が必要」とポリシーに定めたり、規約で年齢制限をかけることはあり得る。 同意書の取得は必要？ 民法上は「未成年者が親権者の同意を得ている」ことが重要で、同意の形式（口頭・書面）は問われない。 つまり、親が口頭で「いいよ」と言っていても法的には有効である。 とはいえ、事業者側は、後で「同意がなかった」と言われるリスクを避けるため、同意書への署名を求めるといったエビデンスを残すことが多い。 一方、アプリ・ネットサービスの利用登録では、「保護者の同意を得ました」にチェックを入れる方式等で良しとしているケースの方が多い。 このあたりは、同意に関するリスクと、同意書取得のコストとのバランスで決めているのが現実ではないかと思う。 おまけ（未成年者の年齢引き下げ） ちなみに、2022年4月1日の民法改正により、成年年齢は20歳から18歳に引き下げられた。 このため、18歳未満は引き続き未成年者として扱われるが、18歳以上は親の同意なしに契約や進路決定が可能になっている。 一方、飲酒・喫煙・公営ギャンブルは、従来同様に20歳未満は禁止されている。 このため、関連する法律の名前も「二十歳未満ノ者ノ飲酒ノ禁止ニ関スル法律」等に変更されている。

プログラムのソースコードが著作権法上の保護対象に含まれる（著作権法第10条第1項第9号）ことはよく知られている。 しかし、アルゴリズムは流用したい開発部からは、「コードの表現を変えたり、プログラミング言語を変えれば大丈夫？」と問い合わせを受けることが多い。 確かに、特許権とは異なり、著作権はアルゴリズム自体を保護するものではないので、理屈上はそういった回避策もあり得る。 ではソースコードをどのレベルまで利用すると著作権侵害となり得るのか、実務的な面で整理してみたい。 プログラムの著作権が及ぶ範囲 プログラムの著作権は「表現」に及ぶ。 つまり、ソースコードの具体的な表現として、 指令の表現自体 指令の表現の組み合わせ 表現の順序 などが保護されることとなる。 一方、アイデアやアルゴリズム自体は保護されない（著作権法第10条第3項第3号）。 例えば、「Aを入力したらBを計算して出力する」といった処理の仕組みや数式は著作権ではなく、場合によっては特許の対象になるだけである。 また、過去の判例（平成２９年６月２９日判決（東京地裁 平成28年（ワ）第36924号））では、次のように判示されている。 プログラムに著作物性があるというためには，指令の表現自体，その指令の表現の組合せ，その表現順序からなるプログラムの全体に選択の幅があり，かつ，それがありふれた表現ではなく，作成者の個性，すなわち，表現上の創作性が表れていることが認められる必要がある。 つまり、プログラムの表現に選択の幅が無い場合や、ありふれた表現である場合は著作権の保護対象とはならない。 なお、システム設計書等は著作権法上のプログラムには該当しないものの、言語の著作物（著作権法第10条第1項第1号）や図形の著作物（同法第10条第1項第6号）として保護され得る。 著作権侵害の判断基準 プログラムの著作権侵害を判断する場合、以下２つの基準が重要となる。 ソースコードが一致（類似）する箇所の量 比較対象と一致するソースコードの文字数や行数などの客観的な数値的の指標が高いほど、類似性も高くなり、著作権侵害が認められやすくなる。 一致（類似）する箇所を別の表現に創作できるか ある機能を実装するのに色々な書き方ができるにも関わらず、他社のプログラムと一致・類似する記述であれば、著作権侵害の可能性が高くなる。 更に比較対象のプログラムと同じバグが生じる場合は、ソースコードをコピペしている可能性が高いので、著作権侵害を裏付ける要因となり得る。 逆に、ある機能を実装しようとすると誰が作成してもほぼ同じような表現になる場合、そこに創作性は存在せず、著作権法上の保護対象から外れることとなるため、侵害可能性は下がる。 ただし、変数や定数、関数の名称等を変えただけでは、実質的にはプログラムの類似度を低減することにはならないと思われる。 プログラムの創作性は、単なる変数等の名前の付け方ではなく、ある機能を実現するための構成という観点が重要（著作権上の保護対象となる）だからである。 他社のソースコードを参考にしただけの場合は？ 「他社のソースコードを全てコピペすれば著作権侵害となる」「一部を書き換えたに過ぎなければ侵害可能性が高い」のは良いとして、場合によってはソースコードのアイデアやアルゴリズムは参考にしつつも、実際は一から自分でコーディングするような場合もあるかもしれない。 この場合はどう判断すべきだろうか？ 場合にもよるが、著作権侵害リスクはかなり低くなると思われる。 上述の通り、アイデアやアルゴリズム自体は著作権法の保護対象ではないため、これらをゼロベースで実装することでソースコードの構成が異なっていれば、もはや他社の著作物と類似するとは言えなくなるためである。 仮に著作権侵害要件の１つである「依拠性」は充足するとしても、そもそもソースコードが類似しなければ問題はない。 また、仮に元のソースコードとは異なる言語で記述するのなら、当然表現方法も変わり得るわけで、更に類似度は低下するだろう。 ただし、決してリスクがゼロになる訳ではなく、言語を変えたとしてもソースコードの具体的な構成・記述を忠実に模倣した場合は「翻案」とみなされ、著作権侵害と判断される可能性がはあると考えられる。 まとめ 開発部に対しては必ずしも確実な回答をするのが難しいかと思うが、著作権侵害可能性に関しては、概ね以下の通りとなる。 元のコードとの一致割合が高いほど侵害可能性大 別の表現にできるはずなのに、敢えて一致する表現となっていると侵害可能性大 変数/定数/関数の名称だけを変更しても侵害回避は困難 アルゴリズムだけ参考にして、新たにコードを作成するなら侵害可能性低 もちろん、特許権が存在する場合はコードの表現を変えても特許権侵害は回避できないので、その点は開発部との協業で他社特許クリアランスは進めておきたいところである。

自社の製品やサービスの知名度を上げる手段の１つとして、他社の著作物を利用することが考えられる。 例えば、自社製品などに有名漫画のキャラをデザインしたり、自社イベントの広告やノベルティに、有名なアニメに出てくるグッズを用いる機会があるかもしれない。 この場合は、当然著作権者からの許諾が必要になる著作権者に問い合わせをして各種条件を合意したうえで使用許諾を得ることとなるが、いくつか留意点を挙げておきたい。 ライセンス条件 ライセンス条件の骨格としては、「独占性」「期間」「地域」「用途」を押さえておく必要がある。 独占か、非独占か 「著作物を自分が使用可能か」という観点のほか、「第三者にも同じ著作物を使わせて問題ないか」という点は検討事項になろうかと思う。 唯一の使用者になりたいなら独占的なライセンス契約とすることが必要だが、ライセンサーも色々な企業に使ってもらいたい場合が多いため、通常は非独占となることが多いと思われる。 ライセンス期間 選択肢としては、以下のパターンに層別される。 永続 期間限定 期間限定（更新可能/自動更新の有無） 期間限定イベントに使うのなら期間限定の契約でも問題無いが、そうでない場合は固定費が嵩むこととなる。 使用する側からすれば期間を気にせず使える永続がベターだが、その場合はライセンサーは将来の利用料を受け取れなくなるため、実際は期間を設けて使用を許諾してもらうことが多い。 仮に永続とした場合であっても、対価は高額になるであろう。 ライセンス地域 著作物は国境を越えて利用されるため、世界各国は様々な国際条約を結んで、著作物や実演・レコード・放送などを相互に保護し合っている。 日本も各条約に加入しているため、世界の大半の国と相互の保護関係がある。 著作物が利用される際の法律の適用に関しては、例えば、日本の著作物がアメリカで利用される場合にはアメリカの著作権法が、逆にアメリカの著作物が日本で利用される場合には日本の著作権法が適用されるのが原則となる。 というわけで、ライセンスのテリトリーについては日本国内だけでなく外国についても指定することが考えられる。 具体的には、例えば以下のようなパターンとなる。 日本国内のみ 特定の国・地域 全世界 ライセンス用途 ライセンサーとしてはどんなものにも使われてしまうとガバナンスが効かなくなってしまうため、例えば、利用できる媒体や業界を限定（例：書籍出版のみ、ゲームのみ、Web広告のみ）したり、または用途を限定（○○商品への掲載のみ、△△イベントの販促品のみ）することが考えられる。 ライセンス費の支払い方法 両者間で合意が取れればライセンス料の価格や支払い方は特に限定は無いが、支払い方法で言うと主に以下のような選択肢が挙げられる。 一括支払い 定額支払い ランニングロイヤルティ これらの組み合わせ もし顧客に販売するような自社製品に用いる場合であれば、「ランニング・ロイヤリティ方式」を取ることが考えられる。 例えば、「製品１個あたりの販売価格 × ●% × 個数」というような算出方法である。 ここで、販売価格を実際の販売価格から消費税、輸送費等を控除した額を指すように定義することもあり得るが、その場合はライセンシーが各種諸費用をわざと高く計算することもあり、その計算根拠についてトラブルが生じる原因ともなる。 したがって、販売価格は諸経費や手数料、税金などを含めた「グロス価格」とするのが望ましい。 一方、ノベルティに用いる場合だと、実際に販売するものではないことから、販売価格という指標を使うことはできない。 この場合は、販売価格ではなく、製品の１個あたりの原価を使って算出することが考えられる。 またライセンサーとしては、ライセンス許諾はしたものの、ライセンシーの製造・販売数が少なすぎるとライセンス料が予想を大幅に下回ることもある。 そういったケースを回避するため、最低限のライセンス料はいくら、ランニングロイヤリティ方式で算定した料金が上回ったらその金額を支払う、といったスキームを組むことも可能である。 中には展示物として使用するケース等、販売価格・原価のいずれで算出する方法も適当でない場合もあるので、その際は一括支払いや、定額支払い方式を採用することとなる。 その他留意点 その他、著作権のライセンス時における主な留意点を挙げておきたい。 著作者人格権は譲渡できない 日本法では、著作者人格権（氏名表示権・同一性保持権など）は譲渡不可である。 したがって、実務上は「著作者人格権を行使しない」との条項を入れる。 二次利用の範囲を明記すること もし著作物の改変や二次利用を予定しているのであれば、改変や翻案・二次的著作物の作成（翻訳、リメイクなど）が可能かどうかを契約で明確にしておく必要がある。 対価の妥当性 これは完全買い取りにする場合、権利者は将来の利用料を受け取れなくなるため、初期対価が高額になるのが通常。 第三者権利の有無 許諾を依頼する作品に第三者素材（写真、音源、製品など）が含まれていれば、第三者部分の利用制限は残る点は注意すべきである。 その他 これは著作権に限った話ではないが、サブライセンスの可否、契約解除条件等も考える要素となってくる。