知財系サラリーマンの備忘録

転職したい・・・日々の学びの備忘録です。

【極意シリーズ】発明発掘の極意

 私は出願件数が日本企業でトップクラスのメーカーで知財部員として働いています。

 出願件数が多い理由は二つです。

  1. 開発部門に発明提案ノルマが課せられていること
  2. 知財部員が率先して発明発掘を行なっていること

 件数に直結しているのは開発ノルマですが、質の高い出願を創出するのはいつも知財部員による発明発掘です。

 今日は発明発掘のコツをまとめます。

目次

発明発掘の極意

f:id:ma7pat:20190216100637p:plain

 発明発掘には大きく分けて以下の2パターンあります。

  1. 開発部門からアイデア相談を受けて発明群を発掘すること
  2. 知財部員が開発部員に発明創出を促すもの

 似てるようですが好ましい対応は全く異なります。順に説明しましょう。

開発からのアイデア相談受けの極意

 バカになるべし。

 このパターンの活動は、すでに発明が完成している状態からスタートします。

 あなたはこの状態から、発明を整理し、最良の特許群を形成して出願する必要があります。

 そのためには、発明者や開発部門から発明の全体像を漏れなく聞き出さなければなりません。

 技術者からものを聞くために必要なのは、ずばり無知を装うことです。技術者は自分の知識を話すことが大好きな存在です。彼らの開発業務に興味を示しながら、何も知らないフリをして嬉々として彼らの話を聞くのが技術者との正しい付き合い方です。

 あなたは何年もこの開発分野を担当しているかもしれません。そうすると自社の事業形態、自社の製品知識は持っていることでしょう。製品に使われている技術にも、きっと開発部門の若手よりかは詳しいはずです。聞きたいことがあればきっと端的に話を聞く質問力を持っているでしょう。でもそれだと100%の情報しか引き出せません。

 そのような質問力を持った上で、技術者と話す時には嬉々としたバカを演じるべきです。そうすれば技術者は勝手に話し出します。そして、120%の情報が引き出せるようになります。知財部員として働くなら技術者から120%の情報を引き出せるコミュニケーション能力は極めて重宝されるでしょう。

技術者から何を聞き出すか

 とはいえあなたは知財部員です。嬉々としたバカとなりながら、虎視眈々と自分の欲しい情報を聞き出さなければなりません。

 特許要件に立ち返りましょう。細かいことは置いておくとして、発明は新規性進歩性があれば特許になります。つまり「新しい構成」「それによる技術的効果」があれば特許になります。

 しかし技術者にとって知財とは未知の領域です。そのため、技術者には「新しい構成」と「それによる技術的効果」があれば特許になるという概念がありません。

 技術者からアイデア相談を受けた場合、以下のフローで質問をすれば知財部員として知りたい情報はだいたい手に入ります。ポイントは発明の効果から聞き出すことです。技術者は効果を説明するのは好きですからね。

  • その発明の効果は何?
  • その効果は発明のどんな特徴から来てる?
  • その特徴のうち従来と何が違うの?
  • どうやって作るの?
  • 別の応用先はあるの?
  • (クレームがまとまりそうなら)回避手段は?

 バカになれずとも、以上のことは必ず技術者から聞き出しましょう。いくら自分がその分野に詳しくてもです。現場しかわからない事象が必ずあります。

 この情報を集めれば、技術者のアイデアを課題別に整理でき、実施可能要件を満たすための情報も得られるし(分野によっては重要)、クレームドラフトの役に立ちそうな情報も得られます。

 課題別に整理できれば発明群としてグルーピングできます。この結果一つの発明にまとまったのなら、それも良しです。


 なお、新製品、新プロジェクトに関する出願が一通り終わったあとに出願漏れがないか確認するアイデアの落穂拾いを行うときには新規な構成を聞き出して、その構成から何か効果が言えないか検討するというアプローチが非常に有効です。上記のフローとアプローチが逆なので、上記フローでは出せなかったアイデアを出願に導けるでしょう。これも覚えておくと役立つと思います。

開発に発明創出を促す際の極意

 創出すべき発明を明確にすべし。

 このパターンの活動は、発明が全くない状態からスタートします。活動としては難易度が高いと思います。したがって、あなたは開発者を動かして発明を創出させるように導かなければなりません。しかし、私の経験上半端な指示をしても開発者は全く動いてくれません。むしろちょっとバカにされます。

 このような活動が求められるのはどういう時でしょうか。例えば、競合他社Xの特許出願動向を調べて自分の会社と比較したとします。調べてみると、自分の会社からの出願は同じ製品に対しても一部の技術Aについて極端に少なく、一方で他社Xは満遍なく出願をしていたことがわかります。技術Aは自社ビジネスにとっても将来技術として有望です。

 さて、技術Aについて自社は他社Xよりも特許上弱いことが明らかになりました。これでは他社Xと契約交渉を行った際、技術Aに対する穴を突かれて不利になることが考えられます。

 ここであなたに求められる特許戦略上の行動は2つです。

  1. 自社の弱み技術Aに関する出願を増やし、自社の弱みを補強する
  2. 他社Xからの出願が少ない領域(技術B)を見つけだして集中的に出願し、他社Xに対する強みを作る

 すでに出遅れている技術Aについてのアイデア提案が開発から上がってくるとは思えません。また、技術Bについてもあなたが見つけ出さなければ開発はそれが強みになりえるとは知る由もありません。つまり、上記1も2も、知財部員たるあなたが行動を起こさなければなりません。

自社の弱みを補強する

 弱み技術Aに関してアイデア出してくださいよ~といって開発者がアイデアを出してくれればいいんですが、そんな簡単な話はありません。

 おすすめの方法は、他社Xの技術Aに対する出願をいくつかピックアップして、その発明の課題とその解決手段を考えてもらうことです。

 分野によっては、他社の出願における詳細設計が開示されていない、などと課題設定をして他社の出願の完全下位出願をすることも考えられるでしょう。他社Xの技術Aに関する出願を開発者に見せ、当該出願に開示されていない範囲で設計上好ましい条件を見出させるのです。審査官は上位概念から下位概念を認定することができないため、設計事項以上の完全下位出願には特許性があります。

 このように、開発者にやるべきことを明確化してから依頼することで開発者を動かすハードルはぐっと下がります。

他社に対する強みを作る

 「他社Xが技術Bについてあんまり出願してないんでアイデア出してくださいよ~」、、、、当然開発者は動きません。

 このパターンは非常に難しいと思います。あなたに相当の技術知識がなければいけません。少なくともあなたには相当の技術知識が必要です。

 例えば「技術BをT製品に組み合わせるとどうなりそうですか?」「技術Bを使った場合に小型化、軽量化(極めて一般的な課題)を図るとどうなりますか?」などのように、知財側で課題を設定して開発者に打診するのが良いでしょう。技術者は解決手段をひねり出すのは好きです。課題ベースで打診することで、以後の活動を円滑に進められます。

おわりに

 知財部員にとって発明発掘を円滑に進められるようになる、というのは極めて重要なスキルです。知財から開発者に活動を持ち掛けるのは、会社の体制によってはやりにくいかもしれませんが是非やってみましょう。必ず成果が埋まっているはずです。

 過去に書いた極意シリーズはこちらです。

 知財部員の仕事についてはこちらをご覧ください。

【極意シリーズ】出願明細書作成の極意

 私は大手メーカで知財部員として働いています。知財の面でも良く知られたメーカです。

 実務量は年間出願100件強、中間処理200件弱くらいです。

 出願のうち2~3割は全文作成しています。中間処理はほぼ全文作成です(外国の場合は一部代理人に任せますが一次推敲できるレベルの文章は自分で書きます)。

 今日は私がこれまで得てきた、出願明細書作成の極意(その1)をまとめます。時間がない方、発明を実施するための形態の極意だけでも是非ご覧ください。

 これまで企業内知財部の話も書いています。ぜひこちらもどうぞ。

目次

出願明細書作成の極意

f:id:ma7pat:20190212230437p:plain

 明細書は以下の項目で構成されます。

  • 明細書
    • 発明の名称
    • 背景技術
    • 先行技術文献
    • 発明が解決しようとする課題
    • 課題を解決するための手段
    • 発明の効果
    • 図面の簡単な説明
    • 発明を実施するための形態
  • 特許請求の範囲
  • 要約書
  • 図面

 各項目のポイントについて解説します。直感的に理解できるように、なるべく例を付けます。

背景技術・先行技術文献の極意

 冗長に書くべからず。

 この項目をA4で半ページも書いていたら、それは書きすぎです。

 この項目の記載によって本願の権利解釈に有利に働くことはありません。一方、書きすぎると米国出願時に自認した従来技術ととられる場合があります。

 この部分には、先行技術文献として1つの特許文献を挙げ、その文献の内容を客観的に記載しましょう。先行技術文献は一つでいいです。二つ目は最近接の先行技術とは言えず、無駄だからです。二つ以上先行技術を挙げると米国出願時にIDSするものが増えてめんどうだし翻訳費用がかさむという理由もあります。

 こんな記載でいいでしょう。

【背景技術】

 X製品にYという技術が適用されることがある。

 例えば、特許文献1には、Y技術を用いたX製品に関し、Z手法を組み合わせることでより高精度化できることが記載されている。

【先行技術文献】

   【特許文献1】 特開****-******号公報

解決しようとする課題の極意

 請求項1の構成要件から主張できる効果のみを記載すべし。

 この項目は権利解釈に大きな影響を与えます。不用意な文章を記載すると限定解釈や効果不奏功の抗弁の機会を与えることになりかねません。

 このくらいのことなら、実務をやったことがある人なら一度は聞いたことがあるでしょう。でも簡単にできることではありませんよ。課題を如何に設定するかで、その後の明細書のストーリーが決まります。ここには時間をかけることをおすすめします。

課題設定のコツ

 うまく課題設定をするには、発明を十分に理解することが必要です。

 具体的には、本発明と先行技術の構成上の違いと、それによる技術的作用や効果を理解しましょう。

 例えば、特許文献1にはA+B+Cなる構成が開示されていたとします。本願発明は、A+B+C+Dであり、先行技術に対して構成Dを有することで十分な強度が確保されるものであったとしましょう。

 この場合、請求項1にはA+B+C+Dを書くことになります。請求項1の構成が解決できる先行技術に対する課題は、構成Dによって解決される課題です。発明が解決しようとする課題にはこのことを客観的に書くだけで良いです。それ以外は書くべきではありません。

 発明が解決しようとする課題の記載例は以下のような記載となるでしょう。

【発明が解決しようとする課題】

 近年、特許文献1に記載の装置について、より高い強度が求められるようになった。

 そこで、本発明はX装置の強度を向上することを目的とする。

 背景技術+課題でA4半ページ程度が理想です。それ以上書いていた場合、余計なことを書いているかもしれません。

 また、課題設定はクレーム作成と同時に行うことが原則です。下の特許請求の範囲の極意も必ずご覧ください。

課題を解決するための手段の極意

 独立請求項をコピペすべし。

 この項目を従属項(サブクレーム)まで丁寧に書いている先生もいますが、それはページ数稼ぎです。あとここに効果を書いている人も昔はいましたね。それもページ数稼ぎです。クレームのサポートは発明を実施するための形態の欄に開示します。ここは独立クレームの項目だけでよいです。

 請求項1が以下のようなものだったとしましょう。

【請求項1】

 A部と、

 前記A部に隣接して設けられたB部と、

 前記B部に積層されたC部と、

 前記B部の前記C部が設けられた側とは反対側に設けられたD部と、

を有することを特徴とするX装置。

 この場合、課題を解決するための手段の記載はこうです。

【課題を解決するための手段】

 本発明のX装置は、A部と、前記A部に隣接して設けられたB部と、前記B部に積層されたC部と、前記B部の前記C部が設けられた側とは反対側に設けられたD部と、を有することを特徴とする。

 別の独立クレームがあればそれも記載しましょう。その場合、「本発明の他のX装置は、~を特徴とする。」でいいでしょう。

 もう一つ。中間処理などでクレームを補正するときはここも忘れず補正しましょうね。委任省令要件違反をくらう可能性があります。

発明の効果の極意

 課題のコピペを記載すべし。

 発明が解決しようとする課題の欄の最後に、「そこで、本発明は~を目的とする。」という一文があったと思います。

 発明の効果にはそのコピペを書きましょう。今回の例だとこうです。

【発明の効果】

 本発明によれば、X装置の強度を向上することができる。

 これ以外のことは、何も書きません。本発明の効果は設定した課題を解決することに他なりませんからね。

発明を実施するための形態の極意

 各クレームの構成とそれによる効果の繋がりがわかるように記載すべし。

 言い換えましょう。

 まず請求項1の構成から効果が得られる理由を説明し、その後に従属項の構成からさらなる効果が得られる理由を順番に説明すべし

 これを意識するだけで明細書の質は一段上がり、権利としても強くなるはずです。

 まずは請求項1の構成からなぜ「発明が解決しようとする課題」が解決できて「発明の効果」が得られるのか、を書きます。請求項1に対応する「発明の効果」に至るまで、請求項1に挙げた構成以外について言及することは最小限に留めましょう。

 裁判における「発明の課題の認定」は、「発明が解決しようとする課題」の記載のみならず明細書全体が勘案されます。「発明が解決しようとする課題」の記載は悪くないのに、「発明を実施するための形態」がその課題解決に一直線に向かっていないがために発明を限定解釈をされるケースは少なくありません。もちろん審査でも同じです。

 このような事態を防止するために、請求項1の構成とそれによる効果の繋がりが誰にでも理解できるように記載すべきです。

まずい記載が生じやすい具体例

 頭でわかっていても実際にできていない人が多いと思うので一つ例を挙げましょう。

 請求項1の発明は構成A,B,C,Dを有するX装置(構成)で、これにより高強度化が達成できる(効果)とします。請求項1に従属する請求項2では、さらに構成Eを有する(構成)ことが限定され、構成Eによればさらなる高強度化が達成できる(効果)とします。

 この時、「発明を実施するための形態」に、構成A~Eが混然一体となって説明され、全体を通して強度が上がる効果が得られると記載されていた場合、たとえ構成A~Dのみでも一定程度の高強度化の効果が達成されるとしても、裁判所で発明の効果(=高強度化)を得るためには構成Eも必要であると認定されかねません。そうすると均等範囲に影響が出たり、明確性違反で無効となったりします。また、ヨーロッパに出願する場合、上記のような明細書の構成になっていると"essential feature"が欠如しているとして高確率で84条(Clarity)の拒絶を受けます。

好ましい記載例

 ではどのように書けばいいのでしょうか。答えは簡単です。

 請求項1による構成と効果の説明をし終わってから、従属項(サブクレーム)の構成と効果を説明をするようにすればよいのです。このように整理すれば、各クレームの構成と効果の関係が明確に記載できます。

 記載例を挙げましょう。

【発明を実施するための形態】

 以下に、本発明を実施するための形態を図面を用いて説明する。

[実施例1]

 図1は、本実施例のX装置の概略図である。X装置は、A部と、C部と、D部と、E部を有する。

 A部は例えばαやβなどから構成され、B部に隣接して設けられている。B部としてはγなどを用いることができる。また、C部は1または複数のcを含み、B部に積層して設けられている。E部は任意の構成であるが、C部とD部を接続するように設けられている。

 ここで、本実施例のX装置では、D部をB部に設ける際に、B部のC部とは反対側に設けている。これにより、D部をC部と離間させつつ、D部とC部をB部により一体的に保持することが可能となる。

 これにより、X装置の強度を向上させることができる。

 次に、本実施例のX装置における好ましい構成について述べる。

 X装置の強度をより向上するには、本実施例のように、C部とD部を接続するE部をさらに設けることが好ましい。これにより、横揺れに対する堅牢性をより向上する効果が得られ、X装置をより高強度化することができる。

 いくらE部が優れたものであっても、E部のメリットは構成A~Dを説明しきったあとです。請求項1の構成と従属項の構成を混然一体とする記載は避けるべきです。

 請求項1の構成から発明の効果に至る説明が論理的にできない・・・と悩むことがあれば、それは請求項1の発明特定事項が不適切であるか、課題が不適切です。

 このとき、必ず請求項1を下位概念に限定したがる人がいますが、別観点の課題に設定し直すこともぜひ検討してほしいです。

特許請求の範囲の極意

起案タイミング

 請求項1は課題設定と同時に作成すべし。

 特許請求の範囲のうち、請求項1は必ず課題の設定と同時に作成しましょう。請求項1を決めるということは、自分が取得しようとする権利範囲の外縁を決めるということです。ここが決まらないときちんとした明細書は書けないはずです。請求項1が決まらないことには、上で説明した"発明を実施するための形態の極意"を実践することもできません。

 明細書が決まってから全クレームを起案する人がいますが、この場合、請求項1が実施例に引っ張られて限定的になり易くなってしまうため危険です。

 従属項はいつ起案してもいいと思いますが、私は課題と同時に請求項1を書き、明細書がすべて書き終わってからサブクレームを記載するのが一番効率が良いと思っています。サポート不足の問題を生じにくくできますし、明細書を書きながらサブクレームとして有効な構成が浮かんでくることも多くあるためです。

起案の仕方

 前記がつかない構成要件が出てきたら注意すべし。

 この極意は機械的なチェックでクレームを省みることができるので非常におすすめです。

 クレーム中で前記がつかない構成は無駄である可能性が高いです。発明は、その発明を構成する各要素が一体不可分に関連しあってなされるものであるためです。

 発明を文章にしたとき一度しか出てこない構成は他のどの構成とも関連していないということです。このような構成は発明を表現する上で不必要かもしれません。

 例えばさっきのクレームを見てみましょう。

【請求項1】

 A部と、

 前記A部に隣接して設けられたB部と、

 前記B部に積層されたC部と、

 前記B部の前記C部が設けられた側とは反対側に設けられたD部と、

を有することを特徴とするX装置。

 構成AからCは前記がついていますね。少なくとも2回でてきています。

 しかし構成Dは一度しか出てきません。これは注意すべきです。

 今回の場合はよく見てみると、構成Dは構成Bや構成Cと関連があることが理解できます。構成Dはたまたま最後に出てきた構成なので、前記が付かなかっただけということですね。OKな例です。

 この例だとどうでしょうか。

【請求項1】

 A部と、

 前記A部に隣接して設けられたB部と、

 前記B部に積層されたC部と、

 前記B部の前記C部が設けられた側とは反対側に設けられたD部と、

 E部と、

を有することを特徴とするX装置。

 急にE部が出てきました。他の構成との関連もよくわかりません。

 このような請求項の記載だと、E部がどう機能するのかが不明確になりがちです。E部は発明を表現する上で不要でないか検討しましょう。また、E部が必要な構成であるならば、E部がどう機能するかわかるよう、他の構成との関連を記載した方が良いでしょう。

特許技術

 発明カテゴリが十分であるか検討すべし。

 特許技術は特許を扱うスキル、という意味で使われる言葉です。”特許技術職”と言葉が似ていますが、全く異なる意味です。

 カテゴリとは、請求項の「~を特徴とするXXXX。」のXXXXです。「~を特徴とするX装置」ならカテゴリはX装置、「~を特徴とするX方法」であればカテゴリはX方法です(物、方法、製造方法の3つを指してカテゴリだということもあります)。

 例えばあなたが素材メーカー(鉄鋼)の知財部員であったとしましょう。大口の取引先は自動車業界です。あなたの担当する開発部門が、新たな組成の合金を開発しました。この合金は耐熱温度が従来品よりも高いため、より燃焼効率の良いエンジンが開発できる可能性があります。

 クレームに記載すべきカテゴリは「合金」、「合金の製造方法」だけでよいでしょうか?私なら「エンジン」と「自動車」のカテゴリのクレームも作っておきます。

 自社と直接の競合関係がない、業界上の他のレイヤーに属する会社に対しても権利行使できるようにするためです。最も上位と考えられる合金についてクレームできていれば最終製品についても権利行使できるから良いと考えられるかもしれませんが、最終製品クレームがあれば損害算定額が跳ね上がる可能性があります。

 また、一部のエンジンに対する使用を契約上除外する可能性があるのであれば「ガソリンエンジン」のカテゴリと「ディーゼルエンジン」のカテゴリを別に作ります。「合金」カテゴリや「エンジン」カテゴリのクレームがあれば、例えばディーゼルエンジンへの使用を除外するライセンス契約は結べるかもしれませんが、独禁法に抵触する恐れがあります。除外技術についても想定できるのであれば独禁法の特例である特許法の保護を受けておきましょう(某C社のプリンタ関連の出願においてわざわざモノクロとカラーでクレームカテゴリを分けているのはこのためでしょう)。

図面の極意

 クレームの構成要件はすべて付番すべし

 シンプルに米国出願時に必要だからです。付番できない(=図面に構成が書かれていない)のは大問題です。

 でも図面の開示がなくても実務上補正は全然できるので神経質になりすぎないように。

おわりに

 どうでしょうか。特に発明を実施するための形態の極意はある種の雛形とも言えます。これが頭の中にあると明細書作成スピードが愕然と上がります。

 また、出願書類を書くとき、重視すべき優先順位は以下の通りです。ただし、あくまで目安です。例えば請求項1の特許性が低い場合には従属項の設定に多くの時間をかける場合もあります。

独立項>課題>発明を実施するための形態>従属項

 まだまだ極意は書ききれません。今回の内容は国内実務に適合させることを重視しました。外国にも対応するために、という観点でいつか「極意その2」を書きます。

Pythonを使って自動でお金を稼ぐ②

 私は知財系サラリーマンとして企業で働きながら、休日プログラマをやっております。

 今日は昨日の続きで、Pythonを使って小銭稼ぎスクリプトを書きたい、という記事です。

 特許系の記事はこんな感じ。

  • 昨日のおさらい
  • でももう一つ準備
  • プログラムを書く
  • 最後に
続きを読む

Pythonを使って自動でお金を稼ぐ

 私は知財系サラリーマンとして企業で働きながら、休日プログラマをやっております。

 特許系の記事はこんな感じ。

 今日はずばり、Pythonを使って小銭稼ぎスクリプトを書きたい、という内容です。

やりたいこと

 サラリーマンなら一度はあこがれる副収入。でも副収入を得るには時間や場所やお金など、投資が必要なことがほとんどです。

 そんなのめんどくさいしリスクを取りたくないし・・・

 そこで、お遊びプログラミングで小銭(ほんとに小銭)を稼ぐ遊びを考えてみました。

 注目したのは、楽天ウェブ検索です。

楽天検索バーとは

 楽天ウェブ検索とは、楽天の提供する検索ツールです。

 このツールを用いた検索数(口数といいます)に応じて、ユーザには一日125万ポイントが山分けされるのです。

 使い方は極めて簡単で、楽天にログインした状態でこのページ から好きな単語を検索するだけ。

 普通は一日7検索で満口になってしまうのですが、楽天ウェブ検索の拡張機能をインストールしているとなんと満口数が30口まで増えます。これ、意外と知られていない。

 これを使わない手はないですね。


 さて、今回やってみるのは、ブラウザを自動制御して楽天検索バーの口数を稼ぐことです。

必要そうなもの

 必要なものは、

  1. 検索用語をランダムに抽出するためのリスト(できれば1000件くらい)
  2. Chromeを自動で制御するためのライブラリ→Selenium
  3. SeleniumChromeを動かすためのドライバー

 まずはこれらを準備しましょう。

 ちなみに私の環境は以下です。

  • OS: WIndows 10
  • Pythonのバージョン: 3.6.7
  • ブラウザ: Chrome
  • パッケージ管理: conda 4.5.12

 ブラウザをChromeにしたのは楽天Web検索の拡張機能があるからです。自動制御も拡張機能も使えるのでChromeが最適でしょう。

1. 検索用語リスト

 「検索用語ランキング 1000」でググってみたら、こんなサイトがありました。少々古いですがいいでしょう。

 2014年検索キーワードランキング 1,000位まで一挙発表!!

 まずこれを1000件全部コピーしてメモ帳にでも貼りましょう。searchlist.txtって名前にしましょうか。

1
yahoo

2
youtube

3
google

4
ユーチューブ

5
ヤフー
・
・
・

 普通にメモ帳にコピペするとやたら改行が入りますね。あと順位が邪魔ですね。よくよく見てみると増加率みたいなのも含まれています。

 このままでも扱えなくはないですがせっかくなので簡単に整形してsearchword.txtを作ってみましょう。以下がそのコード(seikei.py)です。これを先ほどのsearchlist.txtと同じディレクトリ内に作って実行しましょう。

f = open("searchlist.txt", "r")
line = f.readlines()
f.close()

f = open("searchword.txt", "w")
for i in range(len(line)):
#検索語が出てくるのは3行に1行のみなので、それだけ"searchword.txt"に書き込む
    if i % 3 == 1: 
        f.write(line[i])
f.close()

 これでこんなテキストファイルができたはずです。いい感じですね。

yahoo
youtube
google
ユーチューブ
ヤフー
ntt
楽天
・
・
・

2. Seleniumのインストール

 セレニウムChromeを自動で動かすためのライブラリです。

 以下のコードをコマンドラインに打ってインストールできます。

conda install selenium

 pipならこんな感じですね

pip install selenium

3. chromedriver

 SeleniumChromeを動かすには、Chromedriverというドライバが必要になります。

 Chromedriverはここからダウンロードできます。自分のChromeのバージョンにあったものを選びましょう。私はChromeのバージョンが71.0.3578.98だったのでChromeDriver 2.46をダウンロードしました。

 ダウンロードが完了したら解凍し、中に入っているchromedriver.exesearchword.txtと同じディレクトリにいれておきましょう。

設計図

 次はプログラムの設計図。

 簡単なコード書くときはわざわざ図面は書きませんが、頭の中でこんなフローチャートが思い描かれます。プログラム書くときにフローチャートを意識するのは非常に大事だと思っています。

f:id:ma7pat:20190210161442p:plain

 ポイントは赤字のところですかね。エラー処理を入れたのはネットワークの影響で検索が進まなかったときのための手当てです。

 この設計図に従ってプログラムを組んでいきましょう。

 でも、長くなってきたのでまた明日。

知財部員弁理士資格不要論

 今日は企業内知財部で働くうえで弁理士資格は必要かということについての話です。

 企業内知財部の仕事についてはこちらに。

 企業ごとの知財知財はこちらをどうぞ。

続きを読む

知財的、企業の特色(メーカー中心)

 さて、今日は企業ごとの知財に対する考え方などをまとめます。

 会社ごとの特色は働き方にもかかわっているはずです。

  • 知財的、企業の特色
    • 1. 某自動車メーカー T社
    • 2. 某財総合電気メーカー P社
    • 3. 某精密機器メーカー C社
    • 4. 某医薬メーカー T社
  • おわりに
続きを読む

知財のお仕事②

 今回は特許を扱う仕事がどのようなものであるか説明します。

目次

  • 企業内知財部とは
  • 企業内知財部の仕事内容
    • 1. 一般職の仕事
    • 2. 管理職の仕事
  • 特許事務所との違い
  • おわりに
続きを読む