astamuse Lab

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

特許とその制度について 特許出願および実用新案登録出願

お久しぶりです。主に特許関連のデータ処理を担当しているBTと申します。 前回、特許及び実用新案の概要についてご説明させて頂きましたが、今回は日本国内における「特許出願」および「実用新案登録出願」についてご説明いたします。 宜しくお願いいたします。

特許出願

まずは、出願から特許をうけるまでの基本的な流れは、以下の図のようになります。

f:id:astamuse:20170118114118j:plain

このうち、「特許出願」について説明します。

発明に対して日本国で特許を受けるためには、特許庁に「特許出願」をする必要があります。その際に以下の書類をそろえて提出する必要があります。

f:id:astamuse:20170118114126j:plain

それぞれの書類について説明していきます。

「願書」

「願書」には発明の内容そのものではなく、発明者の住所と氏名、出願人の住所又は居所と氏名又は名称、添付物件の目録(この「願書」以外の書類の一覧)などを記載します。さらに出願人が外国人や日本に営業所を持たない外国の企業の場合は、代理人(要は日本の弁理士)の住所と氏名も記載することが必要です。

「明細書」

「明細書」には、「発明の詳細な説明」をもうけて、特許を受けようとする発明やその他の発明(特許を受けるまでは考えていないが、特許を受けようとする発明と同時にした関連する発明など)について説明を記載します。その発明の属する技術分野における通常の知識を有する者(つまり、その分野に従事している技術者など)が「明細書」を読んで発明を実施(発明品の製造など)出来る程度に明確かつ十分な内容を記載することが必要とされ、読んでも理解不能であるとか、発明を再現できないような曖昧な記載は認められません。記載する内容としては、発明に到る課題、課題を解決するための手段、発明の効果、発明の具体例である実施例、関連発明(「特許出願」の時に把握している関連する他の発明)などがあり、後で述べる「特許請求の範囲」とは異なり一般的な文章で記載します。

「特許請求の範囲」

「特許請求の範囲」には、特許を受けたい発明について、その発明を特定する為に必要な全ての事項を記載する必要があります。発明が複数ある場合は、「請求項1、請求項2、・・・」のように発明ごとに分けて記載することができますが、一つの「特許出願」の「特許請求の範囲」に含まれる複数の発明は、一定の技術的関係を有する必要があります。これは一つの出願にのなかに無関係な発明が複数含まれていると、その出願の審査や第三者が出願内容を参照する際に混乱をきたすためです。

「特許請求の範囲」は、独特の文体で書かれます(中にはそうなっていない出願もありますが、それは弁理士や特許事務所を代理人とせずに直接出願しているか、弁理士や特許事務所のチェックを受けていない場合が多いようです)。一つの請求項は一つの文で記載するため、構成要素が多い発明や手順などが多い発明の場合、一つの請求項が延々と数ページにわたって続くこともあります。一般的にはとても読みにくい文体のために、特許に関する文書を読んだり書いたりするのが苦手という人も多いと思います。「特許請求の範囲」は、もし特許を受けた場合にその特許の権利範囲を決めるための法的文書としての性質を持つことから、曖昧さを排除して権利範囲を明確にする法律的に有効な文章であることが望ましく、このような文体にせざるおえないという事情があります。

また、「特許請求の範囲」はの記載には、以下の点を守る必要があります。 * 請求項に記載した特許を受けようとする発明が「明細書」の「発明の詳細な説明」に記載されている必要があります。発明について「特許請求の範囲」に記載するだけではなく、「明細書」に方にも記載(通常はより詳細な説明と共に)すること * 特許を受けようとする発明が明確に記載されていること * 請求項ごとの特許を受けようとする発明の記載が簡潔であること * その他経済産業省令で定めるところにより記載されていること

「図面」

「図面」は、「特許出願」における他の出願書類と違って必ず必要というわけではありません。図がないと説明が難しい物の発明では無く図がなくても説明が可能な方法の発明や、化学など発明の分野によっては図をそれほど必要としない分野などで、「図面」を添付しない出願が多いことがありますが、特許を受けようする発明について解りやすく(特に「特許出願」を審査する審査官により深く理解してもらうために)図を用いることが望ましいため、一般的には「図面」が無い出願はほとんどありません。

「要約書」

「要約書」は、「明細書」、「特許請求の範囲」、「図面」に記載した発明の概要を記載したものです。これは、「特許出願」の数の増大や技術の高度化・複雑化によって情報へのアクセスが困難になっている状況から、出願した内容へのアクセスを容易にして利便性を高めるために必要とされているものです。その性質上、「要約書」の記載内容が「明細書」、「特許請求の範囲」、「図面」に記載した発明とかけ離れていたり、不明瞭である場合は、特許庁によって内容が書き換えられることがあります。

その他の申請書など

その他「特許出願」にあたり特例を受けたい場合は、それぞれの特例の申請書を提出する必要があります。特例の内容については次回に説明したいと思います。

実用新案登録出願

まずは、出願から実用新案登録をうけるまでの基本的な流れは、以下の図のようになります。

f:id:astamuse:20170118114131j:plain

このうち、「実用新案登録出願」について説明します。

発明に対して日本国で特許を受けるためには、特許庁に「実用新案登録出願」をする必要があります。その際に以下の書類をそろえて提出する必要があります。

f:id:astamuse:20170118114135j:plain

「実用新案登録出願」の場合に特許庁に提出する書類は、上記の「特許出願」とほとんど(但し、「特許請求の範囲」は「実用新案登録請求の範囲」という書類名に変わります)同じですが、「実用新案登録出願」の場合は「特許出願」で提出が必須では無かった「図面」が必須となっています。これは、実用新案ではその保護対象が物品の形状、構造又は組合せに限定されており、考案(特許における発明に該当)の説明に「図面」が必要とされているためです。

まとめ

以上、特許と実用新案の出願について説明をしてきました。次回は、出願において申請することが出来る特例や通常出願とは違う特殊な出願について見ていきたいと思います。

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

参考にした資料など

複数サイトを運営する上でのフロントエンドのちょっとしたノウハウ

こんにちは。 デザイン部でフロントエンドエンジニアをしているkitoです。
弊社は、転職ナビというドメインの異なるサイトを300サイト以上運営しています。レアケースであるとは思いますが、運営上のノウハウの一部をご紹介したいと思います。
今回はスタイルシートを量産するフローを書かせて頂きます。

jsonファイルから複数のcssを作成する

転職ナビは数百サイトありますが、ひとつのアプリケーションでほぼ同じテンプレートが使われ、静的なアセットは原則として共有されています。
しかし、それぞれのサイトに固有のスタイルシートを適用しなければならない場面がどうしてもあります。 弊社では、サイト固有のスタイルシートをjsonファイルのデータから量産することでその問題に対処していますが、そのjsonの元ファイルはコミュニケーション上使い勝手のよいcsvファイルでデータが管理されています。 従って、まずcsvファイルをjsonに変換します。

下記のようなcsvファイル、prefecture.csvがあったとします。これをprefecture.jsonに変換します。
domainは文字通りサイトドメインで、R,G,BはそれぞれサイトカラーのRGBの値です。

domain R G B name
hokkaido 0 11 111 北海道
aomori 32 66 66 青森
iwate 4 15 43 岩手
miyagi 55 180 8 宮城
akita 10 20 30 秋田
yamagata 90 0 0 山形
fukushima 10 10 10 福島
ibaraki 40 30 12 茨城
tochigi 68 11 54 栃木
gunma 250 100 40 群馬

csvtojsonというモジュールを使いたいので下記コマンドでインストールしてください。

npm install --save csvtojson

以下作成していくディレクトリは以下のようになります。

├── package.json
├── converter.js
├── template.js
├── prefecture.json
├── Gruntfile.js
├── dev
│   └── unique
│        ├── akita
│        │   └── styles
│        │        ├── sp_unique.scss
│        │        └── unique.scss
│        ├── aomori
│        │   └── styles
│        │        ├── sp_unique.scss
│        │        └── unique.scss
│        以下略
├── tasks
│   └── prefecture_styles.js
├── unique
│   ├── akita
│   │   └── styles
│   │        ├── sp_unique.css
│   │        └── unique.css
│   ├── aomori
│   │   └── styles
│   │        ├── sp_unique.css
│   │        └── unique.css
│   以下略
└── node_modules

converter.jsを作成して下記のコードを実行してください。csvファイルをjsonに変換します。

var fs = require('fs');
var csv = require("csvtojson");
var converter = csv({});
var csvFile = './prefecture.csv';
var jsonFile = './prefecture.json';

fs.createReadStream(csvFile).pipe(converter);
converter.on("end_parsed", function (jsonArray) { 
  fs.writeFile( jsonFile, JSON.stringify( jsonArray, null, '    ' ),'utf8');
  console.log('csv to json is complete !');
});

下記のようなprefecture.jsonが作成されたと思います。

[
    {
        "domain": "hokkaido",
        "R": 0,
        "G": 11,
        "B": 111,
        "name": "北海道"
    },
    {
        "domain": "aomori",
        "R": 32,
        "G": 66,
        "B": 66,
        "name": "青森"
    },
    以下略
]

弊社はsassを導入しているのでprefecture.jsonからgruntを通じてsassを作成し、それを元にcssを作成するフローになります。
二度手間のように感じるかもしれませんが、他のsassをimportしたり、ユニークなカラーを変数に設定できたりと、使い勝手がよいからです。

sassを量産するprefecture_styles.jsというGruntプラグインを作成します。
tasksディレクトリに、prefecture_styles.jsを作成して下記コードを記入してください。prefecture.jsonと後で作成するテンプレートを元にsassを量産します。

module.exports = function(grunt) {
    var fs = require('fs');
    var json = grunt.config('prefecture_styles').json;
    var data = JSON.parse(fs.readFileSync(json, 'utf8'));

    grunt.registerTask('prefecture_styles', 'task', function() {

        var dir = grunt.config('prefecture_styles').dir;
        var stylesDir = grunt.config('prefecture_styles').stylesDir;
        var name = grunt.config('prefecture_styles').name;
        var template = grunt.config('prefecture_styles').template;
        var sasstmp = require(template);

        Object.keys(data).forEach(function(key, index) {
            var domain = data[key]["domain"]
            var R = data[key]["R"]
            var G = data[key]["G"]
            var B = data[key]["B"]
            var sassObj = new sasstmp(R,G,B);

            name.forEach(function(val, index) {
                grunt.file.write(dir + domain + stylesDir + name[0],sassObj.pc , function(err) {});
                grunt.file.write(dir + domain + stylesDir + name[1],sassObj.sp , function(err) {});
            });
        });
        console.log('generated sass!')
    });
};

grunt.config('prefecture_styles').〇〇で、Gruntfile.jsから設定を読み込んでいます。
jsonはスタイルシートの値が入ったjsonファイル(ここではprefecture.json)、dirはベースとなるディレクトリ、stylesDirはsassが入るディレクトリ名、nameはsassの名前、templateは量産するsassのテンプレートになります。
Object.keys(data).forEachでprefecture.jsonから値を取り出して、それぞれ変数に代入し、grunt.file.writeでpc用とsp用のsassを作成&記述しています。

元となるテンプレート、template.jsを作成します。

var sasstmp = function(R,G,B) {
  this.pc = '@charset "utf-8";\n' + '$uniqueSiteColor:rgb(' + R + ',' + G + ',' + B + ');\n' + '.siteColor{ background-color:rgb(' + R + ',' + G + ',' + B + ')};\n';
  this.sp = '@charset "utf-8";\n' + '$uniqueSiteColor:rgb(' + R + ',' + G + ',' + B + ');\n' + '.siteColor{ background-color:rgb(' + R + ',' + G + ',' + B + ')};\n';
}

module.exports = sasstmp;

次にGruntfile.jsの設定に移ります。
(gruntをインストールについては割愛します。)
下記gruntプラグインをインストールしてください。

npm install grunt-contrib-compass --save-dev
npm install grunt-contrib-clean --save-dev

grunt-contrib-compassはsassをcssにコンパイルするプラグイン、grunt-contrib-cleanはファイルを削除をするプラグインです。

Gruntfile.jsを下記のように記述してください。 実際に業務で使うときのGruntfile.jsは、sassの変更をwatchしたりwebpackを使ってjsをバンドルしたりと他のタスクを追加することになりますが、今回は必要最小限の構成にしてあります。

var grunt = require('grunt');

module.exports = function(grunt) {

    grunt.initConfig({

        pkg: grunt.file.readJSON('package.json'),

        clean: {
            build: {
                src: [
                    '.sass-cache',
                    './dev/build/unique/'
                ]
            },
            release: {
                src: [
                    '.sass-cache',
                    './unique/**/styles/*.css'
                ]
            }
        },

        prefecture_styles: {
            dir: './dev/unique/',
            json: './prefecture.json',
            template: '../template.js',
            stylesDir: '/styles/',
            name: [
                'unique.scss',
                'sp_unique.scss'
            ]
        },

        compass: {
            prod: {
                options: {
                    sassDir: './dev/unique',
                    cssDir: './unique',
                    environment: 'production'
                }
            }
        }
    });


    //ローカルにあるprefecture_styles.jsを読み込んでいる。
    grunt.task.loadTasks('tasks');

    grunt.loadNpmTasks('grunt-contrib-watch');
    grunt.loadNpmTasks('grunt-contrib-compass');
    grunt.loadNpmTasks('grunt-contrib-clean');

    grunt.registerTask('build', ['clean:release', ' prefecture_styles', 'compass:prod']);

};

grunt.initConfig({})の中に prefecture_styles.jsの設定を記述します。
compass:{}には prefecture_styles.js作成したsassをcssにコンパイルする設定を行っています。
grunt.task.loadTasks('tasks')は、コメントにあるように先程作成したprefecture_styles.jsをロードしています。
Nodeモジュールとして公開しておけば、grunt.loadNpmTasks(' prefecture_styles')で読み込めるでしょう。

下記でGruntを実行してください。

grunt build

uniqueディレクトリが作成され、それぞれのドメイン名以下に、unique.css、sp_unique.cssが作成されていれば成功です。
cssを量産するタスクを実施する際に、本稿を参考にして頂ければ幸いです。今回は以上になります。

アスタミューゼでは、エンジニア・デザイナーを募集中です。ご興味のある方は遠慮なく採用サイトからご応募ください。お待ちしています。

Blue Ocean on Jenkins

お久しぶりでございます。scalaでバックエンドを開発しているaxtstar(@axtstart)でございます。

前回はExcelにはVBAがある! の話をしましたが、今回は、、、、 やっとScalaの話…ではなく、Scalaは私よりも詳しい方にお任せして ご存じ、今年、新しくJenkinsに仲間入りしたJenkins Blue Oceanの話をしてみます。

Jenkinsあれ

弊社ではCI・CDツールとしてJenkinsを使用しています。

最近までは、GUIによる設定を行っていました。

↓よくあるこんな感じ↓

f:id:astamuse:20161219163520p:plain

最近、遅ればせながら、Jenkins PipelineとBlue Oceanを使いだしているので、その紹介と活用方法を書いてみたいと思います。

Jenkins Pipeline

jenkins.io

Jenkins Pipelineとは、かつて Workflow Pluginと呼ばれていた、Jenkins内でGroovyによって記述できるワークフロープラグインです。

このプラグインは、

  • Jenkins 2.x以上で動作
  • Code as Config
  • Groovy
  • Versatile
  • Durable

説明されています

通常のJobと異なり、Jobの定義に言語(Groovy)を使用することで、 今までGUIで設定していた部分をコードで記述することができます。 SCM内にJenkinsfileと呼ばれる設定ファイルを保存することが可能であり、レビューが(通常のJOBと比較して)容易です。 ファイルであるためコピーが可能で、GUIを用いた連携では全くできないような処理も記述できます。 *1

↓おなじみHello World

f:id:astamuse:20161220193451p:plain

node
{
  echo 'Hello World'
}

gitから取得する場合

f:id:astamuse:20161220193700p:plain

Jenkinsfileと呼ばれるファイルに処理を記述し、例えばgithubで管理できます。

例:

node {
  try { 
    //def array = ["a", "b", "c"] as String[]
    stage('prepare'){
      sh 'uname -a'
    }
    stage ('git'){
      checkout scm
    }
    stage ('build'){
      parallel 'sbt build':{
         sh 'sbt compile'
      }, 'node build':{
          sh 'npm -v'
      }
    }
    stage ('test'){
      sh 'sbt test'
    }
    stage ('staging deploy'){
      sh 'sbt publish'
    }
    stage ('test after staging deploy'){
      parallel 'chrome':{
         sh 'echo test'
      }, 'firefox':{
         sh 'echo test'
      }, 'edge':{
         sh 'echo test'
      }
    }
    stage ('puroduction deploy'){
      sh 'echo test'
    }
    stage ('test after production deploy'){
      parallel 'chrome':{
         sh 'echo test'
      }, 'firefox':{
         sh 'echo test'
      }, 'edge':{
         sh 'echo test'
      }
    }
    stage('Archive result') {
      sh 'touch dummy.xml'
      archiveArtifacts 'dummy.xml'
    }
  } catch(e){
    //slackSend (channel: '#general', color: '#FF0000', message: 'Error happened!')
    throw e
  }
}

こちらに置いておきました。

↓上記pipeline実行の様子

f:id:astamuse:20161220155148p:plain

stageと記載したブロックごとの状況と履歴が一目瞭然のビューになっています。

また、通常のJobと異なり、PipelineはJenkinsが落ちても処理を継続できるように設計されています。

担当プロジェクトではまず、Webからのトランザクションテストを別々のJOBとして、起動していたのですが、 プラグインで置き換えることで、ひとまとめの処理として閲覧できるようになりました。

Jenkinsの設定が比較的多かったプロジェクトなのでかなり効果を発揮しています。

ハマったところ

以下の2点は少しハマりました。

  • In-process Script Approval

RejectedAccessExceptionという例外が発生して落ちる。 Jenkinsの管理 -> In-process Script Approvalで許可する必要がある。

  • シリアル化エラー

NotSerializableExceptionという例外が発生して落ちる。 落ちる箇所をメソッドにして「@NonCPS」アノテーションを与える必要がある。

上記ともこちらに説明があります。

Blue Ocean

Jenkins Blue OceanはJenkinsのUIを変えるプラグインで、Jenkins Worldの資料 *2 を見ると、それまであまり変更の無かった、UX部分に手を加えることで、昨今のDevOpsChatOpsといった要請にこたえていくという方向性のようです。

デフォルトでは導入されていないので、Jenkinsの管理->プラグインの管理->利用可能 に行き、フィルターで「Blue Ocean」と入力してBlue Ocean betaをインストールすれば、 必要なプラグインを合わせてインストールしてくれます。

f:id:astamuse:20161220203856p:plain

インストールが成功すると、下記のようにBlue Ocean UXへのリンクができますので、それをクリックすれば、Blue OceanのUXに行けます。 元々のViewも無くなるわけではありません。

f:id:astamuse:20161220204128p:plain

Pipeline Pluginの結果をBlue OceanのViewで見ると、昨今のCIツールであるTravis CIなどが提供している画面に似た画面が表示されます。

f:id:astamuse:20161220172033p:plain

f:id:astamuse:20161220185603p:plain

このよう感じで今風の画面が出てきて、個々のビルド結果とその詳細が見れます。

f:id:astamuse:20161220171820p:plain

f:id:astamuse:20161220205321p:plain

stage内でパラレルで実行した処理に関しては、デフォルトのViewではわからないのですが、

Blue Oceanの場合はそういった部分もパラレルである様に表示されています。

また該当部分のエラーにも素早く移動することができます。

さていかがだったでしょうか?

最後に

今年最後の投稿になってしまいました。

寒い時節が続きますが、皆様もお体にお気をつけてよいお年をお迎えください。

Have a good new year!

*1:まだまだ発展途上で全プラグインがPipeline上で動くとかそういうレベルではないようです。

*2:Jenkins WorldでのBlue Oceanのプレゼンビデオyoutube

Copyright © astamuse company, ltd. all rights reserved.