astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

特許とその制度について 拒絶査定後または特許登録後

お久しぶりです。主に特許関連のデータ処理を担当しているBTと申します。
今回は拒絶査定後または特許登録後の流れについてご説明したいと思います。
宜しくお願いいたします。

拒絶査定後

特許出願が審査によって拒絶査定された場合、出願人そこで諦める必要はありません。
出願人は拒絶査定について納得がいかない場合は、特許庁に対して拒絶査定不服審判を請求することが出来ます。
また、この拒絶査定不服審判の請求と同時に出願内容を補正する事も可能で、この場合は拒絶査定不服審判の前に前置審査が行われます。

前置審査

拒絶査定不服審判の請求と同時に出願内容の補正が有る場合、これが実質上出願人にとって最後の補正のチャンスであることから拒絶査定において指摘された拒絶理由に全てについて、その拒絶理由を解消するような大幅な補正を行うことが多くなります。
このため、わざわざ拒絶査定不服審判を行うよりも、すでに審査の過程で内容を理解しているはずの拒絶査定をした審査官が、拒絶査定不服審判を請求と共にした補正内容を確認することで拒絶理由が全て解消しているか否かの判断が容易に可能です。
そこで、拒絶査定不服審判を請求と共に補正があった場合は、拒絶査定をした審査官に補正内容を確認させ、特許査定が可能かどうかの判断をします。これを前置審査と言います。
拒絶査定をした審査官が補正後の出願内容で特許査定が可能と判断した場合は、拒絶査定不服審判を行うこと無く出願人に対して特許査定を通知します。

拒絶査定不服審判

拒絶査定不服審判の請求と同時に出願内容の補正が無い場合、又は補正があっても前置審査の結果拒絶査定をした審査官が特許査定は出来ない(拒絶査定における拒絶理由が解消していないか、補正によって新たな拒絶理由が生じた場合)と判断した場合は、拒絶査定不服審判が開かれます。
拒絶査定不服審判は、3人ないしは5人の審判官(審査官を長年勤めたベテランの特許庁職員の方々)の合議で、拒絶査定をした審査に誤りは無いか、拒絶査定不服審判を請求と共に補正があった場合はその補正後の内容で特許査定が可能か等を判断します。
審判官の判断の結果、主に審決(成立)、審決(不成立)、審査に差し戻しのいずれかの結果が出されます。
審決(成立)の場合は、特許査定と同じですので、出願人は特許登録料と3年分の年金を納めることで特許権を取得できます。
審決(不成立)の場合は、知的財産高等裁判所(東京高等裁判所の特別の支部で、知的財産権に関する裁判を専門的に受け持つ裁判所)に出訴することにより、出願人は裁判で争うことも可能です。
審査に差し戻しの場合は、審査が再度やり直しになります。これは審査の内容に不備や間違いがあった場合にそれを審査のやり直しで正すためですが、審判官が審査官を教育する目的で行われることもあり、出願人にとっては特許になった場合の特許権の有効期間がさらに減ってしまうことになります。

特許登録後

特許出願が審査によって特許査定された後に、出願人は特許登録料と3年分の年金を納めることで特許権を取得できます。
しかし、特許権は一度取得すれば出願から最大20年の間ずっと安泰というわけではありません。最初の3年間を除いてその後の毎年の年金を納め忘れると特許権は消滅しますし、競合者等の請求により特許権が消滅する事もあります。 それらを見ていきます。

特許異議の申し立て

特許登録がなされて特許公報が発行されてから6ヶ月の間は、誰でも自由にその特許登録された内容について異議申し立てをすることが出来ます。
6ヶ月の間に異議が申し立てられた(複数の場合も有り)場合、3人ないしは5人の審判官により異議申し立ての審理及び決定が行われます(異なる複数の異議申し立ての異議の内容が同じだったりすることもあるので、整理分類して同一内容の異議申し立て毎に行われる)。
異議申し立てを認める場合は、その特許は消滅し、特許権は最初から存在しなかったものと見なされます。
異議申し立ても認めない場合は、その特許はそのまま維持されます。

訂正審判

すでに登録された特許について、その特許権者は特許の内容について何らかの不備や後で説明する特許無効審判によって特許を無効にされる可能性が高い場合、特許権者はすでに登録済みの特許の内容について訂正を行う訂正審判を特許庁に要求することが出来ます。
上記の特許異議申して立てで申し立てたれた内容について特許の内容について訂正が必要と特許権者が判断した場合も同様です。
訂正審判は、3人ないしは5人の審判官により審理されて、審決(成立)となった場合は特許の内容は訂正後のものに変わります。但し、訂正後の内容は訂正前の特許の内容を超えるものであってはなりません。

特許無効審判

登録された特許に対して、利害関係者等がその特許がで無効であることを確認するために、特許庁に対して特許無効審判を請求することが出来ます。
無効となる理由は、審査等の過程で拒絶すべき事情があったにもかかわらず特許となった場合等が多いです。
特許無効審判は、3人ないしは5人の審判官により審理及び決定が行われます。
審決(成立)の場合は、その特許は無効となり、特許権は最初から存在しなかったものと見なされます。
審決(不成立)の場合は、その特許はそのまま維持されます。
どちらの場合でも、審決の結果に不服がある場合は、知的財産高等裁判所(東京高等裁判所の特別の支部で、知的財産権に関する裁判を専門的に受け持つ裁判所)に出訴することにより、特許権者と特許無効審判の請求人は裁判で争うことも可能です。

その他の裁判

特許権者はその特許発明について、原則その発明を実施する権利を独占的に有していますが、他人にまねされることもあります。
このような場合は、その他人に対して東京地方裁判所または大阪地方裁判所に対して特許侵害訴訟を提訴することが出来ます。
また、その他人の行為によって損害が生じている場合は、同じく東京地方裁判所または大阪地方裁判所に対して損害賠償請求を提訴することが出来ます。

まとめ

以上、拒絶査定後または特許登録後について説明をしてきました。
今回で「特許とその制度について」の一連のシリーズは終了となります。
長い間有難うございました。

最後になりましたが、 アスタミューゼでは現在、エンジニア・デザイナーを募集中です。 興味のある方はぜひ 採用サイト からご応募ください。

参考にした資料など

Linuxでinodeが枯渇した場合にどうやって調査するか

f:id:astamuse:20180314195322j:plain

こんにちは。並河(@namikawa)です。

最近はすっかり暖かい日が続いておりまして、花粉が飛散して本当に悲惨な感じになってしまっているアカウントがこちらになります。

さて、近頃は、GCPへの移行を終えたり、新しいメンバーが続々とジョインしてきてくれていることもあり、本業のインフラ職人業が随分と減ってきていて、やっぱり最近力を入れている採用の話を書こうかなと思ったのですが、そういえば前回は採用向けの話(アスタミューゼの開発組織と採用に関するQAアレコレ)を書いたところだったので、今日はLinux運用環境での小ネタでも書こうかと思います。

「なぜかサーバに書き込めません!」

ある日、とあるサーバのディスク関連のアラートが飛んできて、エンジニアがサーバの状況を確認したところ、ディスクの容量には空きがあるが、なぜか書き込めないという状態になっていました。

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.9G  5.5G  3.9G  59% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            286M  8.0K  286M   1% /dev
tmpfs            59M  348K   59M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            295M     0  295M   0% /run/shm
none            100M     0  100M   0% /run/user

dfコマンドでディスクの使用量を確認するも空き容量はまだ残っている感じ。 エラーを確認すると "No space left on device" とな。

# df -i
Filesystem     Inodes  IUsed IFree IUse% Mounted on
/dev/sda1      655360 654754   606  100% /
none            75426      2 75424    1% /sys/fs/cgroup
udev            72973    405 72568    1% /dev
tmpfs           75426    327 75099    1% /run
none            75426      3 75423    1% /run/lock
none            75426      1 75425    1% /run/shm
none            75426      4 75422    1% /run/user

というわけで、定番の inode 枯渇問題でありました。

たくさんのファイルがどこにあるのかを探す

やり方は色々あるかと思うのですが、地道にルートからたくさんあるディレクトリを探していきます。 地味なやり方ですが、まずは1階層目のレベルで、どこの配下に大量のファイルがあるか探索します。

# find / -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -nr
 489278 usr
  14308 lib
   3287 var
   1818 data
    826 etc
    293 boot
    130 sbin
    128 bin
     94 home
      5 root
      3 tmp
      1 swap

こんな感じで、"/usr"配下のどこかにたくさんファイルが存在していることがわかりました。 あとは同じ要領で機械的に2階層目・・・と探していけばよいです。

# find /usr -xdev -type f | cut -d "/" -f 3 | sort | uniq -c | sort -nr
 460742 src
  15060 share
  12806 lib
    544 bin
    121 sbin
      5 include

"/usr"配下を対象に2階層目を探索した結果がこちら。"/usr/src"にたくさん溢れている、、、というところでピンときますね。

# ll /usr/src
total 188
drwxr-xr-x 47 root root 4096 Dec 15 06:45 ./
drwxr-xr-x 10 root root 4096 Nov 14  2015 ../
drwxr-xr-x 24 root root 4096 Jul 15  2016 linux-headers-3.16.0-77/
drwxr-xr-x  7 root root 4096 Jul 15  2016 linux-headers-3.16.0-77-generic/
drwxr-xr-x 27 root root 4096 Nov 21 06:33 linux-headers-4.4.0-101/
drwxr-xr-x  7 root root 4096 Nov 21 06:33 linux-headers-4.4.0-101-generic/
drwxr-xr-x 27 root root 4096 Dec  8 06:50 linux-headers-4.4.0-103/
drwxr-xr-x  7 root root 4096 Dec  8 06:50 linux-headers-4.4.0-103-generic/
drwxr-xr-x  7 root root 4096 Dec 15 06:45 linux-headers-4.4.0-104-generic/
drwxr-xr-x 27 root root 4096 Feb 23  2017 linux-headers-4.4.0-64/
drwxr-xr-x  7 root root 4096 Feb 23  2017 linux-headers-4.4.0-64-generic/
drwxr-xr-x 27 root root 4096 Mar  9  2017 linux-headers-4.4.0-66/
drwxr-xr-x  7 root root 4096 Mar  9  2017 linux-headers-4.4.0-66-generic/
drwxr-xr-x 27 root root 4096 Mar 16  2017 linux-headers-4.4.0-67/
drwxr-xr-x  7 root root 4096 Mar 16  2017 linux-headers-4.4.0-67-generic/
drwxr-xr-x 27 root root 4096 Mar 28  2017 linux-headers-4.4.0-70/
drwxr-xr-x  7 root root 4096 Mar 28  2017 linux-headers-4.4.0-70-generic/
drwxr-xr-x 27 root root 4096 Mar 31  2017 linux-headers-4.4.0-71/
drwxr-xr-x  7 root root 4096 Mar 31  2017 linux-headers-4.4.0-71-generic/
drwxr-xr-x 27 root root 4096 Apr  5  2017 linux-headers-4.4.0-72/
drwxr-xr-x  7 root root 4096 Apr  5  2017 linux-headers-4.4.0-72-generic/
drwxr-xr-x 27 root root 4096 Apr 25  2017 linux-headers-4.4.0-75/
drwxr-xr-x  7 root root 4096 Apr 25  2017 linux-headers-4.4.0-75-generic/
drwxr-xr-x 27 root root 4096 May 18  2017 linux-headers-4.4.0-78/
drwxr-xr-x  7 root root 4096 May 18  2017 linux-headers-4.4.0-78-generic/
drwxr-xr-x 27 root root 4096 Jun  7  2017 linux-headers-4.4.0-79/
drwxr-xr-x  7 root root 4096 Jun  7  2017 linux-headers-4.4.0-79-generic/
drwxr-xr-x 27 root root 4096 Jun 20  2017 linux-headers-4.4.0-81/
drwxr-xr-x  7 root root 4096 Jun 20  2017 linux-headers-4.4.0-81-generic/
drwxr-xr-x 27 root root 4096 Jun 29  2017 linux-headers-4.4.0-83/
drwxr-xr-x  7 root root 4096 Jun 29  2017 linux-headers-4.4.0-83-generic/
drwxr-xr-x 27 root root 4096 Jul 25 06:41 linux-headers-4.4.0-87/
drwxr-xr-x  7 root root 4096 Jul 25 06:41 linux-headers-4.4.0-87-generic/
drwxr-xr-x 27 root root 4096 Aug  4 06:32 linux-headers-4.4.0-89/
drwxr-xr-x  7 root root 4096 Aug  4 06:32 linux-headers-4.4.0-89-generic/
drwxr-xr-x 27 root root 4096 Aug 12 06:55 linux-headers-4.4.0-91/
drwxr-xr-x  7 root root 4096 Aug 12 06:55 linux-headers-4.4.0-91-generic/
drwxr-xr-x 27 root root 4096 Aug 16 06:35 linux-headers-4.4.0-92/
drwxr-xr-x  7 root root 4096 Aug 16 06:35 linux-headers-4.4.0-92-generic/
drwxr-xr-x 27 root root 4096 Aug 29 06:34 linux-headers-4.4.0-93/
drwxr-xr-x  7 root root 4096 Aug 29 06:34 linux-headers-4.4.0-93-generic/
drwxr-xr-x 27 root root 4096 Sep 19 06:32 linux-headers-4.4.0-96/
drwxr-xr-x  7 root root 4096 Sep 19 06:32 linux-headers-4.4.0-96-generic/
drwxr-xr-x 27 root root 4096 Oct 11 06:49 linux-headers-4.4.0-97/
drwxr-xr-x  7 root root 4096 Oct 11 06:49 linux-headers-4.4.0-97-generic/
drwxr-xr-x 27 root root 4096 Oct 31 06:39 linux-headers-4.4.0-98/
drwxr-xr-x  7 root root 4096 Oct 31 06:39 linux-headers-4.4.0-98-generic/

はい、このサーバはセキュリティ関連の自動アップデートが動いているサーバでしたね・・・。

ということで、不要なパッケージを apt-get purge 等で綺麗にしたのでした。

おわりに

弊社には大量のデータがあるので、本当はファイルがたくさんあって大変、みたいな話に無理やり結びつけようとも思ったのですが、そもそも基本的には各種データストアに入れているし、Rawデータの置き場はGCSのお世話になっているので、inodeに影響を及ぼす様なことは基本的にはありません。

ということで、割とありきたりなネタで恐縮でしたが、何かのお役に立てれば幸いです。

最後に、弊社ではエンジニア・デザイナーを絶賛大募集しておりますので、少しでも気になれば、カジュアルにランチでもしながらお話ししましょう。疑問・質問などございましたら、お手数ですが (@namikawa) まで気軽にDM等いただければと思います。

それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

アスタミューゼ開発部の新人育成の話

こんにちはnishikawaです。今年度もあと少しで終了です。花粉が辛い今日この頃ですが、巷では新年度に向けて色んな仕事が舞い込んできているのではないでしょうか。

さて、新年度といえば学生が社会人になる時期でもあります。新しい環境下で始まる社会人生活に緊張や不安を抱いている新社会人も中には居ることでしょう。

一方、採用側の企業はというと、こちらも色々と緊張していると思います。「えっ?採用側も緊張するの?」と思うかもしれないですが、『新人が会社になじむにはどうしたらいいのか』『研修はうまく行くのか』等々、心配事は尽きません。nishikawaの上司は新しい人が入る度に最初のコミュニケーションをどうしようか凄く考えています。それは周りにいる同僚も同様で新人の方が初めて出社した日はオフィスにいつも以上の緊張感があります。

そんなアスタミューゼの開発部ですが、今年はIT業界での業務経験がない方が入社されました。その方は大学も文系卒でプログラミングとは無縁の経歴だったため、新人を教育するにあたり、研修内容をどうしたらいのかというところが部の一番の悩みでした。

そこで、私が提案させていただいたのがジャストシステムさんの開発の方が利用されているJava100本ノックというドキュメントです。これは、Javaを利用する上で必要となる知識や、よく利用するライブラリ、フレームワークについて学習するために作られた問題集です。

Java 100本ノック: https://github.com/JustSystems/java-100practices

この問題集、GitHubに公開されており、初歩的なJavaの操作から言語仕様、コアAPI、ライブラリ、フレームワークととにかく基本を意識した問題が多いのが特徴です。

この問題集を今回弊社では試用期間中に最低2巡することを目標にカリキュラムを組み現在実施中です。

今回は弊社でやっているJava 100本ノックの進め方を記載したいと思います。

  • 1巡目 (現在実施中)
    • とにかく問題を流しでやってみる。分からなかったらすぐ解答・解説を読む
    • 問題文、解答・解説を読んでも分からないところ、それ以外の箇所での分からないところはOJT指導者に質問する
  • 2巡目
    • 1巡目で得た知識を踏まえて問題を解く
    • コーディング規約を意識する
    • テストを書く

1巡目

1巡目はとにかく全体を俯瞰させるためにとにかく問題をやらせています。少し考えて何も閃かなかったらすぐに解答と解説を読むことを推奨し、その上で分からないことを些細なことでも質問させています。

プログラミング経験がないということなので、ターミナルの使い方やbashの話などJavaには全く関係ないことについても質問を受け付け、それに対して実例も見せながら解説しています。1日に解説している時間は2〜3時間程度で、その時間で収まるように新人の方には質問の要点を絞らせ、まとめさせることを強く意識させています。

1巡目のねらいは、Javaの全体像の把握と問題・課題の深掘りによる問題解決能力の育成があります。問題を解いてJavaを理解することは重要ですが、それよりも何が分からないのか、分からないのは何が問題になっているからなのかの把握と追求が一番重要だと考えております。

2巡目

1巡目を踏まえて、今度はJavaを集中して体得するのがねらいです。そのため、2巡目では問題文が求めていることを精査し、それを実現するための手法を考えることに重きを置いています。また、2巡目ではすべてのコードに対してテストコードを書いてもらおうかと考えています。

Java 100本ノックをやってみての感想

1ヶ月間、Java 100本ノックを新人にやらせてみて振り返ってみると色んなものが見えてきました。

良かった点

  • Java のコーディングの仕方、機能の使い方が分かる
  • 業務上では使わない機能も問題に取り上げられている
  • ちゃんとやればやるほど、教える側と教わる側、それぞれの勉強になるような問題が多い

Java 100本ノックの効果は教える側と教わる側がそれぞれいるときに最も享受できると思います。教える側と教わる側がそれぞれ顔を付き合わせて問題に取り組むことで両者とも知識が深められます。

ポイントは

  • 問題の意図をちゃんと理解する
  • 解答・解説を理解し、コードを1行ずつしっかり追って理解する

です。nishikawaも色々と教える上で分からないことに直面する機会が多かったのでとても勉強になりました。

良くなかった点

  • プログラミング初心者向けではない
  • Javaを独学で勉強する場合には効果が薄い

良くなかった点はこの問題集は初心者向けに作られていないところだと思います。問題自体はある程度Javaもしくは何かのプログラム言語を使ったことがある人を前提にして居る節があるため、本当の初心者がやるには少し辛いと思います。ですので、この問題をやる場合はJavaの入門書を事前にある程度やっていることをお勧めします。

また、独学でやる場合理解が中途半端になる可能性があるので注意が必要だと思います。学習全般に言えると思いますが、クロスチェックはある程度必要なので、これも例外ではないと思います。

結局どうだったのか?

現在、1巡目を行なっていますが、結論から言うとかなりの成果が出ています。新人の方がとても優秀だと言うこともありますが、分からないところへの分析がよくできるようになってきているため質問が問題を解くごとに少なくなっています。

問題を解くことに関しては、まだ知識や経験が不足しているため、自力では難しいですが、コードを読んで分からない箇所を自信で調査し独力で理解するという行動ができるようになってきています。

以上を踏まえると、申し分ない成果が出ていると思います。しかし、今回新しく入った新人の方が優秀だということも多分にあるため、今後も様々な育成をやっていく中でastamuse開発部の育成方法をちゃんと確立できるように試行錯誤していきたいと思います。

Copyright © astamuse company, ltd. all rights reserved.