令和元年９月１９日判決言渡
平成３１年（行ケ）第１０００５号審決取消請求事件
口頭弁論終結日令和元年７月４日
判決
原告株式会社三菱ＵＦＪ銀行
同訴訟代理人弁護士高橋雄一郎
阿部実佑季
同訴訟代理人弁理士林佳輔
福永健司
被告特許庁長官
同指定代理人須田勝巳
辻本泰隆
松平英
野崎大進
豊田純一
主文
１ 特許庁が不服２０１８－３４０６号事件について平成３０年１１月３０日にした審決を取り消す。
２ 訴訟費用は被告の負担とする。
事実及び理由
第１ 請求
主文同旨
第２ 事案の概要
本件は，特許出願拒絶査定に対する不服審判請求を不成立とした審決の取消訴訟である。争点は，独立特許要件違反（進歩性欠如）の判断の誤りの有無である。
１ 特許庁における手続の経緯
原告は，発明の名称を「アプリケーション生成支援システムおよびアプリケーション生成支援プログラム」とする発明につき，平成２９年６月２６日，特許出願（特願２０１７－１２４３８５号。請求項の数３４。甲９の１～３。以下「本願」という。）をしたが，平成３０年１月１７日付けで拒絶査定（甲１３）を受けたので，同年３月８日，拒絶査定不服審判請求をし，同審判請求は，不服２０１８－３４０６号として審理された（甲１４）。
原告は，同年６月１９日，特許請求の範囲を補正する手続補正（請求項の数１６。甲１８）をし，その後，同年９月１２日，特許請求の範囲を補正する手続補正（請求項の数２。甲２１。以下「本件補正」という。）をしたが，特許庁は，同年１１月３０日，本件補正を却下した上，「本件審判の請求は，成り立たない。」との審決（以下「本件審決」という。）をし，同審決謄本は，同年１２月１８日，原告に送達された。
２ 特許請求の範囲の記載（甲１８，２１）
(1) 本件補正前の本願の特許請求の範囲請求項１の記載は，次のとおりである（同請求項に係る発明を，以下「本件補正前発明」という。）。
「通信端末に固有のネイティブ機能を実行させるためのパラメータに応じて，前記通信端末において実行されるアプリケーションの動作を規定する設定ファイルを設定する設定部と，
前記設定ファイルに基づいてアプリケーションパッケージを生成する生成部と，を有するアプリケーション生成支援システム。」
(2) 本件補正後の本願の特許請求の範囲請求項１の記載は，次のとおりである（同請求項に係る発明を，以下「本件補正発明」という。）。
「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータに応じて，前記携帯通信端末において実行されるアプリケーションの，前記携帯通信端末の動きに伴う動作を規定する設定ファイルを設定する設定部と，
前記設定ファイルに基づいてアプリケーションパッケージを生成する生成部と，を有するアプリケーション生成支援システム。」
３ 本件審決の理由の要旨
(1) 引用発明及び周知技術について
ア 主引例
特許第５４７０５００号公報（平成２６年４月１６日発行。以下「引用文献１」という。）には，以下のとおりの発明（以下「引用発明」という。）が記載されている。
「アプリケーション生成装置１と開発用端末２とがインターネット等のネットワークＮを介して通信可能に接続され，スマートフォン等の携帯端末にインストールされるアプリケーションプログラムであるネイティブアプリケーションを生成するアプリケーション生成システムであって，
アプリケーション生成装置１は，記憶部１１と，受付部１２と，生成部１３と，変換部１４と，送信部１５とを備え，
記憶部１１は，ネイティブアプリケーションのテンプレートであるテンプレートアプリケーション１１１を記憶し，
ここで，テンプレートアプリケーション１１１は，スマートフォン等の携帯端末にインストールされると，所定のアクセス先にアクセスして情報を取得し，当該端末の表示部に表示させるネイティブアプリケーションのテンプレートであり，テンプレートアプリケーション１１１は，設定情報１１２と，１以上のプログラムファイル１１３とを含んでいて，記憶部１１の所定のフォルダ内に格納されており，
受付部１２は，開発用端末２から，リクエスト用ページ３０の取得要求を受け付けると，リクエスト用ページ３０を開発用端末２に送信し，
ここで，リクエスト用ページ３０には，入力欄として，ネイティブアプリケーションがアクセスするウェブアプリケーションのロケーションを示すアドレスの入力欄３１が設けられ，また，ネイティブアプリケーションの表示態様情報に係る入力欄として，背景色の入力欄３４，及びアイコン画像の入力欄３５が設けられており，入力欄３１には，ウェブアプリケーションのメインページのＵＲＬが入力され，背景色の入力欄３４には，カラーコードや背景画像を示すアドレスが入力され，アイコン画像の入力欄３５には，画像ファイルのアドレスが入力され，
受付部１２が，開発用端末２から，ウェブアプリケーションのメインページのアドレス，及び表示態様情報とともに，ネイティブアプリケーションの生成要求を示すリクエストを受け付けると，生成部１３は，コピーして新たに生成されたテンプレートアプリケーション１１１に含まれる設定情報の内容を，受付部１２が受け付けたウェブアプリケーションのメインページのアドレス，及び表示態様情報に基づいて書き換えてネイティブアプリケーションを生成し，
ここで，生成されたネイティブアプリケーションは，携帯端末にインストールされて実行されると，設定情報に含まれているウェブアプリケーションのアドレスに基づいて，ウェブアプリケーションに対応するウェブページを取得し，設定情報に含まれている表示態様情報に基づいて取得したウェブページの表示態様を変更して，携帯端末の表示部に表示させるものであり，
変換部１４は，生成部１３がネイティブアプリケーションを生成すると，当該ネイティブアプリケーションの設定情報及び１以上のプログラムファイルを格納している所定のフォルダを所定の方式で圧縮し，端末がインストール可能な形式のネイティブアプリケーションファイルに変換し，
送信部１５は，ネイティブアプリケーションファイルを所定の記憶領域に格納し，当該ファイルのアドレスを表示する送信用ページを開発用端末２に送信し，開発用端末２において，送信用ページ４０に設けられているダウンロードボタン４１が押下されると，生成したネイティブアプリケーションファイルを開発用端末２に送信する，
アプリケーション生成システム。」
イ 周知技術
(ｱ) 掌田津耶乃「ＡｎｄｒｏｉｄＳｔｕｄｉｏではじめるＡｎｄｒｏｉｄプログラミング入門第２版Ａｎｄｒｏｉｄ６．０Ｍａｒｓｈｍａｌｌｏ
ｗ ＡｎｄｒｏｉｄＳｔｕｄｉｏ１．５対応」（株式会社秀和システム，平成２７年１２月２７日発行）（以下「引用文献２」という。甲２）の３５６頁～３６８頁には，以下の記載がある。
ａ 「カメラを利用するためには，アプリケーションに「パーミッション（アクセス権）」を用意する必要があります。これは，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌに記述します。ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌを開き，＜ｍａｎｉｆｅｓｔ＞タグ内の適当なところに以下のタグを追記してください・・・」（３５６頁）
ｂ 「７．３．３ＧＰＳ利用のパーミッション設定
・・・
ＧＰＳも，やはりパーミッション関係の情報を用意しなければ利用できないようになっています。ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌを開き，＜ｍａｎｉｆｅｓｔ＞タグ内に以下のタグを追加してください。」（３６８頁）
(ｲ) 三宅理「第７章ＨＴＭＬ５＋ＪａｖａＳｃｒｉｐｔでアプリ開発はじめてのＰｈｏｎｅＧａｐ（その１）ここまでできるＰｈｏｎｅＧａｐ」Ｉｎｔｅｒｆａｃｅ増刊ＳｍａｒｔｐｈｏｎｅＷｏｒｌｄＶｏｌｕｍｅ．４（ＣＱ出版株式会社，平成２４年６月１日発行）（以下「引用文献３」という。甲３，乙１）の７０頁～７２頁には，以下の記載がある。
「地図とＧＰＳを組み合わせる
ＰｈｏｎｅＧａｐのすばらしさを体験するのに，地図とＧＰＳを組み合わせたアプリを例に紹介します。
・・・スマートフォン上に地図を表示します．さらに，ＰｈｏｎｅＧａｐの「Ｇｅｏｌｏｃａｔｉｏｎ」を使用して，現在位置にマーカーを表示します。」(ｳ) 「スマホはなぜ動くのか？必ず悩むアプリ開発の６ポイントを徹底解説！Ｐｏｉｎｔ１ファイルがわかるとスマホアプリの仕組みが見えてくる」日経ソフトウエア２０１３年６月号（日経ＢＰ社，平成２５年４月２４日発行）（以下「引用文献４」という。甲４）の１０頁～１１頁，１４頁，１６頁には，以下の記載がある。
ａ 「設定ファイルは，そのアプリのアプリ名やバージョン，対応言語（英語や日本語ｅｔｃ．）などを記述しておくファイルです。」（１０頁～１１頁）
ｂ 「設定ファイル「ｉｏｓ＿ｓａｍｐｌｅ－Ｉｎｆｏ．ｐｌｉｓｔ」（５）のｉｏｓ＿ｓａｍｐｌｅ－Ｉｎｆｏ．ｐｌｉｓｔはアプリの設定ファイルです。アプリの名前やバージョン，そのアプリが利用するＳｔｏｒｙｂｏａｒｄのファイル等の情報が記述されています。」（１４頁）
ｃ 「超重要な設定ファイル「ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌ」（５）のＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌは，頻繁に編集することになる超重要な設定ファイルです（図１４）。この中ではアプリの名前やアイコン，対応するＡｎｄｒｏｉｄのバージョン，起動時に実行する○○Ａｃｔｉｖｉｔｙクラス，そのアプリをネットワークに接続できるようにするか？，ＳＤカードにファイルを保存できるようにするか？などの，様々な項目を設定します。」（１６頁）(ｴ) 掌田津耶乃「ＨＴＭＬ５とコピペでスマホアプリ開発者デビュー！Ｐａｒｔ２いよいよデビュースワイプ可能ミニゲームを作る」日経ソフトウエア２０１２年１０月号（日経ＢＰ社，平成２４年８月２４日発行）（以下「引用文献５」という。甲５，乙２）の２９頁には，以下の記載がある。
「横画面に固定する
スマートフォンでは端末が縦の姿勢のときと，横の姿勢のときで画面が切り替わります。ただ，ゲームでは画面が切り替わらない方が望ましいので，ここでは横画面に固定する設定を施します。
Ａｎｄｒｏｉｄでは，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌに「ａｎｄｒｏｉｄ：ｓｃｒｅｅｎＯｒｉｅｎｔａｔｉｏｎ＝”１ａｎｄｓｃａｐｅ”」の１行を追加します（図５）。
ｉＯＳでは，左側のリストの青いアイコンのプロジェクト名（ＭａｔａｔａｂｉＰａｋｋｕｎ）を選択すると，その右側に「ＴＡＲＧＥＴＳ」という項目が現れるので，その下にある「ＭａｔａｔａｂｉＰａｋｋｕｎ」を選びます。すると，プロジェクトの各種設定が表示されます。この中に「ＳｕｐｐｏｒｔｅｄＤｅｖｉｃ
ｅ Ｏｒｉｅｎｔａｔｉｏｎｓ」という項目があるので，「ＬａｎｄｓｃａｐｅＬｅｆｔ」か「ＬａｎｄｓｃａｐｅＲｉｇｈｔ」を選びます。
これで，画面を横向きに固定できます。なお，ここでいうｏｒｉｅｎｔａｔｉｏｎは「方向」，ｌａｎｄｓｃａｐｅは「横方向」という意味です。」
(ｵ) 「Ａｎｄｒｏｉｄエンジニア養成読本現場で役立つノウハウと仕事にしたい人のための必須知識満載！」（株式会社技術評論社，平成２３年１１月２５日発行）（以下「参考文献１」という。甲８）の１５７頁，１６２頁には，以下の記載がある。
ａ 「サンプルアプリケーションを起動すると，３Ｄグラフィクス界ではおなじみのティーポットの３Ｄモデルが表示されます。端末を傾けると視点が変化して，見る向きを変えることができます。」（１５７頁）
ｂ 「■ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌ
加速度センサでデバイスの傾きを取得するため，傾けた際に画面のオリエンテーションが変わらないように，ａｎｄｒｏｉｄ：ｓｃｒｅｅｎＯｒｉｅｎｔａｔｉｏ
ｎ ＝”ｐｏｒｔｒａｉｔ”を追加してｐｏｒｔｒａｉｔで固定します。」（１６２頁）
(2) 一致点及び相違点
本件補正発明と引用発明との一致点及び相違点は以下のとおりである。
ア 一致点
「携帯通信端末の所定の機能を実行させるためのパラメータに応じて，前記携帯通信端末において実行されるアプリケーションの動作を規定する設定ファイルを設定する設定部と，
前記設定ファイルに基づいてアプリケーションパッケージを生成する生成部と，を有するアプリケーション生成支援システム」である点。
イ 相違点
(ｱ) 相違点１
設定ファイルを設定するパラメータが，
本件補正発明では，「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」であるのに対して，
引用発明では，携帯通信端末の機能を実行させるためのパラメータではあるものの，携帯通信端末に固有のネイティブ機能を実行させるためのパラメータであることが特定されていない点。
(ｲ) 相違点２
設定ファイルが，
本件補正発明では，「アプリケーションの，携帯通信端末の動きに伴う動作」を規定する「設定ファイル」であるのに対して，
引用発明では，「設定情報」が，ネイティブアプリケーションのウェブページ取得動作や表示動作を規定するものの，「携帯端末の動きに伴う」動作を規定するものであることが特定されていない点。
(3) 相違点についての判断
事案に鑑み，上記相違点１及び相違点２についてまとめて検討する。
ア(ｱ) 相違点１及び相違点２は，アプリケーションの特徴に係わる点で関連しており，本件補正発明のアプリケーション生成システムが生成するアプリケーションが，「ネイティブ機能を利用するアプリケーションであって，携帯通信端末の動きに伴う動作を行うアプリケーション」であるのに対して，引用発明のアプリケーション生成システムが生成するアプリケーションは，そのようなアプリケーションではなく，携帯端末にインストールされて実行されると，設定情報に含まれているウェブアプリケーションのアドレスに基づいて，ウェブアプリケーションに対応するウェブページを取得し，設定情報に含まれている表示態様情報に基づいて取得したウェブページの表示態様を変更して，携帯端末の表示部に表示させる点である。(ｲ) ここで，ネイティブアプリケーションの設定ファイルに，引用発明に記載されている「ウェブアプリケーションのロケーション」，「ネイティブアプリケーションの表示態様情報」などのパラメータの他にも，以下の文献の記載にもあるように，ネイティブ機能のパラメータを含む各種のパラメータが設定されることが，本願出願前には当該技術分野における周知技術であった。
ａ 前記(1)イ(ｱ)ａ，ｂに記載されている「カメラを利用するためのパーミッション」，「ＧＰＳ利用のパーミッション」などのネイティブ機能を実行させるためのパラメータ
ｂ 前記(1)イ(ｳ)ａ～ｃに記載されている「アプリの名前やバージョン，そのアプリが利用するＳｔｏｒｙｂｏａｒｄのファイル等の情報」，「アプリの名前やアイコン，対応するＡｎｄｒｏｉｄのバージョン，起動時に実行する○○Ａｃｔｉｖｉｔｙクラス，そのアプリをネットワークに接続できるようにするか？，ＳＤカードにファイルを保存できるようにするか？などの様々な項目」
ｃ 前記(1)イ(ｴ)に記載されている「横画面に固定する設定」
ｄ 前記(1)イ(ｵ)ｂに記載されている「加速度センサでデバイスの傾きを取得するため，傾けた際に画面のオリエンテーションが変わらないように固定するための設定」
(ｳ) また，本件補正発明の「携帯通信端末の動きに伴う動作」について検討すると，本願の明細書（以下，図面を含めて「本件明細書」という。）の段落【００６６】，【００７６】，【０１３７】には，「携帯通信端末の動き」に関連すると考えられる構成として，「ＧＰＳ」と「加速度センサ」が例示されている。そして，本件補正発明の「携帯通信端末の動き」が「携帯通信端末の移動」であるとした場合，「携帯通信端末の移動に伴う動作」を行う「地図とＧＰＳを組み合わせたアプリ」は，例えば，前記(1)イ(ｲ)のとおり，周知であり，ＧＰＳに関する前記(1)イ(ｱ)ｂの記載も参酌すると，上記「地図とＧＰＳを組み合わせたアプリ」では，ネイティブ機能であるＧＰＳに関連するパラメータを設定ファイルに設定しているものと認められる。
また，本件補正発明の「携帯通信端末の動き」が，端末を傾けるような「動き」であるとすると，「携帯通信端末の傾き」に伴う動作を行うアプリは，例えば，前記(1)イ(ｵ)ａに記載されているように周知であり，前記(1)イ(ｵ)ｂの記載を参照すると，このアプリでは，ネイティブ機能である加速度センサに関連するパラメータが設定ファイルに設定されると認められる。
そうすると，「携帯通信端末の動きに伴う動作を行うアプリ」は，本願の出願前に当該技術分野において周知であり，加えて，当該アプリが利用するネイティブ機能のパラメータを設定ファイルに設定可能とすることも，本願の出願前には当該技術分野における周知技術であった。
(ｴ) 引用発明は，「リクエスト用ページ３０には，入力欄として，ネイティブアプリケーションがアクセスするウェブアプリケーションのロケーションを示すアドレスの入力欄３１が設けられ，また，ネイティブアプリケーションの表示態様情報に係る入力欄として，背景色の入力欄３４，及びアイコン画像の入力欄３５が設けられており」，「入力欄３１には，ウェブアプリケーションのメインページのＵＲＬが入力され，背景色の入力欄３４には，カラーコードや背景画像を示すアドレスが入力され，アイコン画像の入力欄３５には，画像ファイルのアドレスが入力され」るものであるところ，引用文献１の段落【００１０】の「前記テンプレートアプリケーションは，前記アクセス先を設定する設定情報を含み，前記生成部は，前記受付部が前記リクエストを受け付けたことに応じて，前記テンプレートアプリケーションをコピーし，コピーされた前記テンプレートアプリケーションに含まれる前記設定情報の前記アクセス先を前記受付部が受け付けた前記アドレスに設定することで前記ネイティブアプリケーションを生成する」との記載及び「この発明によれば，アプリケーション生成装置は，設定情報に含まれているアクセス先を，受付部が受け付けたアドレスに変更するという単純な処理によってネイティブアプリケーションを容易に生成することができる」との記載も考慮すると，引用発明は，ネイティブアプリケーションの設定情報（設定ファイル）のパラメータを，リクエスト用ページ３０の入力欄，すなわち，ＧＵＩを用いて簡単に設定することで，ネイティブアプリケーションを容易に生成できるアプリケーション生成システムであるといえる。
そして，アプリケーション生成システムを用いて「携帯端末」の「ネイティブアプリケーション」の開発を行う当業者であれば，「携帯通信端末の動きに伴う動作を行うアプリ」を利用可能であるところ，この周知の「携帯通信端末の動きに伴う動作を行うアプリ」を生成する場合でも，設定ファイルにネイティブ機能のパラメータをＧＵＩを用いて簡単に設定することで，アプリを容易に生成するという課題を解決できることは当然に予測し得たものであるから，引用発明のアプリケーション生成システムを，上記周知の「携帯通信端末の動きに伴う動作を行うアプリ」の生成に用いる動機はあったといえる。
(ｵ) したがって，引用発明のアプリケーション生成システムを，「携帯通信端末の動き（すなわち，携帯通信端末の移動や傾きなどの動き）に伴う動作」を行うアプリケーションの生成に用い，その際，当該アプリケーションの設定ファイルに，当該アプリケーションが利用するネイティブ機能のパラメータを設定するように構成すること，すなわち，引用発明において，アプリケーションの設定ファイルを，「アプリケーションの，携帯通信端末の動きに伴う動作を規定する設定ファイル」とし，当該設定ファイルを設定するためのパラメータを，ＧＰＳや加速度センサのような携帯通信端末の動きに伴う動作に関連したネイティブ機能を実行させるためのパラメータとすることは，当業者が容易に想到し得たことである。
イ 本件補正発明の奏する作用効果は，引用発明と引用文献２～５及び参考文献１に記載された周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
ウ よって，本件補正発明は，引用発明と引用文献２～５及び参考文献１に記載された周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法２９条２項により，特許出願の際独立して特許を受けることができないものであるので，本件補正は却下すべきものである。
(4) 本件補正前発明について
本件補正前発明は，本件補正発明から，「通信端末」に係る限定事項と，「前記通信端末において実行されるアプリケーションの動作」に係る限定事項を削除したものである。
本件補正前発明の発明特定事項をすべて含み，さらに他の事項を付加したものに相当する本件補正発明が，引用発明と引用文献２～５及び参考文献１に記載された周知技術に基づいて，当業者が容易に発明をすることができたのであるから，本件補正前発明も，引用発明と引用文献２～５及び参考文献１に記載された周知技術に基づいて，当業者が容易に発明をすることができたものである。
したがって，本件補正前発明は，特許法２９条２項により特許を受けることができない。
第３ 原告主張の取消事由
１ 取消事由１（本件補正発明についての容易想到性の判断の誤り）
(1) 引用発明のアプリケーション生成システムを，「携帯通信端末の動きに伴う動作を行うアプリ」の生成に用いる動機はないこと
ア 引用文献１の段落【０００２】，【０００４】～【０００７】，【００２３】，【００２４】によると，引用発明のアプリケーション生成システムは，アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに，ＣＭＳにより開発したウェブアプリケーションを利用してもらうことができないという問題に鑑み（段落【０００２】，【０００４】，【０００５】），ＣＭＳによって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを開発することを提案している（段落【０００６】）。引用発明は，その提案を前提とした上で，ネイティブアプリケーションの開発には多大な開発工数が必要であることから，ネイティブアプリケーションを容易に生成することができるアプリケーション生成装置を提供することを課題としている（段落【０００６】，【０００７】）。ここで，ウェブアプリケーションは，一般的に，Ｗｅｂサーバ上で動作し，Ｗｅｂブラウザを用いて利用するアプリケーションとして認識されている（甲２２）。すなわち，ウェブアプリケーションは，入力されたデータの管理や，データに基づいて出力する情報を組み立てる処理をインターネット上のＷｅｂサーバが行い，ユーザによる情報の入力や，出力された情報の画面表示といった処理を端末側のＷｅｂブラウザが行うアプリケーションである（甲２３）。
このように，ウェブアプリケーションを利用するに当たり，ユーザが操作する端末側の担う処理は，入力されたデータの送信処理と受信したデータの表示処理のみであり，データ処理等の実体的な部分の演算処理は，もっぱらＷｅｂサーバ側に任せて実行する構造となっている。
また，ネイティブアプリケーションは，一般的に，端末内の演算装置が直接に演算処理を行う（実行する）タイプのアプリケーションとして認識されている（甲２４）。引用文献１の段落【０００４】，【００２３】に記載されているとおり，ネイティブアプリケーションは，端末内で実行されるという性質上，アプリケーションサーバ等のアプリケーション提供元からダウンロードして端末にインストールされる。以上のとおり，ウェブアプリケーションとネイティブアプリケーションとは，技術的に全く異なるタイプのアプリケーションであり，引用発明は，アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに，ＣＭＳにより開発したウェブアプリケーションを利用してもらうことを前提とした上で，多大な開発工数を要することなく，ウェブアプリケーションと同等の機能を有するネイティブアプリケーションを容易に生成するという課題を解決するものである。
イ 引用文献１の段落【００２５】，【００２６】，【００２９】～【００３１】，【００３４】～【００３６】によると，引用発明のアプリケーション生成システムで生成されたネイティブアプリケーションは，「設定情報」に設定された「ウェブアプリケーションのロケーションを示すアドレス」，「メニューページに表示するメニュー画像のファイルの格納先アドレス」，「メニュー画像に対応するリンク先のページのアドレス」，「カラーコード（ＲＧＢ値を十六進法で表記した文字列）や背景画像を示すアドレス」等のパラメータに応じて，指定された表示態様で指定されたウェブアプリケーションを表示するものであり，上記パラメータは，いずれもスマートフォン等の携帯通信端末の画面にウェブページを表示するためのパラメータに限られており，表示対象のロケーション（所在）を示すためのアドレスのみである。このように，引用発明のアプリケーション生成システムは，ウェブアプリケーションの利用，すなわち，ブログ等の既存のウェブアプリケーションにアクセスし，その表示態様を指定して表示する機能を備えたネイティブアプリケーションを生成するものであるから，表示したいウェブアプリケーションのロケーションを示すアドレスや，所望の背景画像のロケーションを示すアドレス等の簡単なパラメータをＧＵＩに入力するだけで，所望のウェブアプリケーションを表示するネイティブアプリケーションを生成できるのである。
以上のように，引用発明のアプリケーション生成システムは，既存のウェブアプリケーションを利用して所望のコンテンツ（ブログ等）を表示するという機能に特化した構成を備えている。
ウ 引用発明のアプリケーション生成システムで生成されたネイティブアプリケーションは，ブログ等の既存のウェブアプリケーションにアクセスできるだけであり，Ｗｅｂサーバ上のブログ等のコンテンツを書き換えるものではない。したがって，仮に，設定情報にネイティブ機能（例えば，ＧＰＳ，加速度センサ等）を実行するためのパラメータをＧＵＩを用いて簡単に設定できたとしても，携帯通信端末で動作するのは表示機能に限定されたＷｅｂブラウザにすぎないから，「携帯通信端末に固有のネイティブ機能に応じて携帯通信端末の動きに伴う動作を行うネイティブアプリケーション」を容易に生成できるとはいえない。
したがって，当業者は，設定ファイルにネイティブ機能のパラメータをＧＵＩを用いて簡単に設定することで，アプリを容易に生成するという課題を解決できることは当然に予測し得たということはできない。
エ(ｱ) 前記ア，イのとおり，引用発明のアプリケーション生成システムは，既存のウェブアプリケーションを利用しつつ所望の表示態様でコンテンツを表示するという機能に特化した構成を備えているから，引用発明のアプリケーション生成システムを用いてネイティブアプリケーションを生成するためには，目的とするコンテンツを有する既存のウェブアプリケーションが特定されなければならず，引用発明に接した当業者が，ブログ，ショッピングサイト等のコンテンツを表示する既存のウェブアプリケーションを利用するという目的を離れて，引用発明のアプリケーション生成システムを用いて「携帯通信端末の動きに伴う動作を行うアプリ」を生成することはない。
また，前記ウのとおり，当業者は，引用発明のアプリケーション生成システムを用いることにより「設定ファイルにネイティブ機能のパラメータをＧＵＩを用いて簡単に設定することで，アプリを容易に生成するという課題を解決できる」とは考えないから，引用発明のアプリケーション生成システムを用いて「携帯通信端末の動きに伴う動作を行うアプリ」を生成することはない。
(ｲ) 仮に，当業者が引用発明のアプリケーション生成システムを用いて「携帯通信端末の動きに伴う動作を行うアプリ」を生成しようと試みたとしても，その際には，既存の「携帯通信端末の動きに伴う動作を行うウェブアプリケーション」のロケーションを示すアドレスを取得する必要があるところ，「携帯通信端末の動きに伴う動作を行う」ためには，携帯通信端末の動きを検知して，その動きに応じて動作する機能を備えている必要があるが，ウェブアプリケーションを利用する際に端末側で実行されるＷｅｂブラウザには，携帯通信端末の動きを検出する機能はないから，既存のウェブアプリケーションでは「携帯通信端末の動きに伴う動作を行う」ことはできない。
(ｳ) したがって，当業者が引用発明のアプリケーション生成システムを用いて「携帯通信端末の動きに伴う動作を行うアプリ」を生成することはない。
オ 引用発明の課題は，「アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに，ＣＭＳにより開発したウェブアプリケーションを利用してもらうこと」（段落【０００５】）と「ネイティブアプリケーションを容易に生成することができるアプリケーション生成装置を提供すること」である（段落【０００６】，【０００７】）。
本件審決は，ネイティブアプリケーションの設定ファイルにネイティブ機能のパラメータを含む各種のパラメータが設定されることは周知技術（以下「周知技術１」という。）であるとし，また，携帯通信端末の動きに伴う動作を行うアプリ及び当該アプリが利用するネイティブ機能のパラメータを設定ファイルに設定することは周知技術（以下「周知技術２」という。）であるとしている。
周知技術１は，ネイティブアプリケーションに，ネイティブ機能の実行を含む各種の設定を行う場合には，設定ファイルにネイティブ機能のパラメータを含む各種のパラメータを設定するという技術である。すなわち，周知技術１の課題は，「ネイティブアプリケーションにネイティブ機能の実行を含む各種の設定を行うこと」である。
また，周知技術２は，設定ファイルにネイティブ機能のパラメータを設定することにより携帯通信端末の動きに伴う動作を行うアプリケーションである。すなわち，周知技術２の課題は，「携帯通信端末の動きに伴う動作を行うアプリケーションを提供すること」である。
このように，引用発明が解決しようとする課題と周知技術１及び周知技術２が解決しようとする課題との間に共通性はない。
カ 前記ア～エのとおり，ネイティブアプリケーションの開発を行う当業者は，引用発明のアプリケーション生成システムを，「携帯通信端末の動きに伴う動作を行うアプリ」の生成に用いる動機はない。
また，前記オのとおり，引用発明が解決しようとする課題と周知技術（周知技術１及び周知技術２）が解決しようとする課題との間に共通性はないため，その観点からも，引用発明のアプリケーション生成システムを，「携帯通信端末の動きに伴う動作を行うアプリ」の生成に用いる動機はない。
したがって，引用発明のアプリケーション生成システムを，上記周知の「携帯通信端末の動きに伴う動作を行うアプリ」の生成に用いる動機はあるとした本件審決の判断には誤りがある。
(2) 引用発明において，アプリケーションの設定ファイルを，「アプリケーションの，携帯通信端末の動きに伴う動作を規定する設定ファイル」とし，当該設定ファイルを設定するためのパラメータを，ＧＰＳや加速度センサのような携帯通信端末の動きに伴う動作に関連したネイティブ機能を実行させるためのパラメータとすることは，当業者が容易に想到し得たことではないこと
ア 本件審決は，引用発明のアプリケーション生成システムを，携帯通信端末の動き（携帯通信端末の移動や傾きなどの動き）に伴う動作を行うアプリケーションの生成に用いることを前提にして，引用発明と周知技術１及び周知技術２を組み合わせたが，前記(1)のとおり，携帯通信端末用のネイティブアプリケーションの開発を行う当業者は，引用発明のアプリケーション生成システムを用いて，「携帯通信端末の動きに伴う動作を行うアプリ」の生成を試みる動機はない。
イ 引用発明のアプリケーション生成システムにおいて，「当該設定ファイルを設定するためのパラメータ」，すなわちＧＵＩにて設定するパラメータを「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」に置き換えてしまうと，利用すべきウェブアプリケーションのロケーションを特定することができなくなり，引用発明が前提とする「ウェブアプリケーションを利用するネイティブアプリケーション」を生成することができなくなってしまう。
ウ このように，引用発明と上記各周知技術とを組み合わせる動機付けがなく，また，引用発明と上記各周知技術の組合せに阻害要因があるが，本件審決の判断は，この点を看過しており，誤りである。
(3) 本件補正発明の奏する作用効果は，引用発明と引用文献２～５及び参考文献１に記載された周知技術の奏する作用効果から予測される範囲のものではなく，格別顕著なものであること
本件補正発明の作用効果は，携帯通信端末に固有のネイティブ機能に応じて携帯通信端末の動きに伴う動作を行うネイティブアプリケーションを，少ない開発負担で生成することができるアプリケーション生成支援システムを提供できることである。
前記(1)及び(2)のとおり，引用発明と引用文献２～５及び参考文献１に記載された周知技術とを組み合わせる動機がない以上，本件補正発明が奏する作用効果が予測されるはずもない。仮に，それらを組み合わせることができたとしても，引用発明が既存のウェブアプリケーションの利用を前提としている限り，既存のウェブアプリケーションでは実現し得ない動作，すなわち「携帯通信端末の動きに伴う動作」を実現するネイティブアプリケーションを生成することまでは想定できない。したがって，本件補正発明の奏する作用効果は，引用発明と引用文献２～５及び参考文献１に記載された周知技術の奏する作用効果から予測される範囲のものではなく，格別顕著なものであるから，これと異なる本件審決の判断は，誤っている。
(4) 被告の主張について
ア 被告は，引用文献１の段落【０００５】，【０００６】の記載に基づき，引用発明の課題は，ＣＭＳ（コンテンツ管理システム）によって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを容易に開発して，アプリケーションサーバにおいてネイティブアプリケーションとして検索可能とすることであると主張する。
しかし，段落【０００６】においては，「ＣＭＳにより開発したウェブアプリケーションを利用してもらうことができないという問題」の解決手段として，ＣＭＳによって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを新たに開発することは，適切ではないことを指摘しているのである。引用文献１の段落【０００７】，【００２５】の記載からすると，引用発明は，アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに，ＣＭＳにより開発したウェブアプリケーション（既存のウェブアプリケーション）を利用してもらうことを前提とし，そのためのネイティブアプリケーションを（開発という手段を採らずに）容易に生成することを課題としてされたものである。
イ 被告は，ＰｈｏｎｅＧａｐは，ＨＴＭＬやＪａｖａＳｃｒｉｐｔなどのＷｅｂ系技術を用いてウェブアプリケーションを作る感覚で容易に作成可能であって，ＡｐｐＳｔｏｒｅ（アプリケーションサーバ）等で配布可能となるアプリを作成可能なフレームワークであるから，引用発明の課題を解決する際に利用するには好適なフレームワークであると主張する。
しかし，ＰｈｏｎｅＧａｐは，あくまでＷｅｂ系技術を用いてネイティブアプリケーションを新たに開発するためのフレームワークであり，目的とするネイティブアプリケーションを新たに開発するためには，ＨＴＭＬやＪａｖａＳｃｒｉｐｔ等を用いてソースコード（プログラム）を書く必要があり，ＰｈｏｎｅＧａｐを用いることは，目的の機能を備えたネイティブアプリケーションを新たに開発する（新たにソースコードを書く）ことに他ならない。
これに対し，引用発明は，既存のウェブアプリケーションを利用するためのネイティブアプリケーションを容易に生成することを課題とするものであり，ＰｈｏｎｅＧａｐのようにソースコードを書くという面倒な作業を要することなく，利用したいウェブアプリケーションのアクセス先アドレス等の情報を入力するだけで，ネイティブアプリケーションを容易に生成することができるのである。
したがって，既存のアプリケーションを利用するのではなく，同等の機能を有するネイティブアプリケーションを新たに開発するための手段であるＰｈｏｎｅＧａｐは，引用発明の課題を解決するものではないから，引用発明の課題を解決する際に利用するに当たって好適なフレームワークではない。
ウ 被告は，当業者が引用発明を実装するに当たって，アプリ作成フレームワークであるＰｈｏｎｅＧａｐを用いる動機付けがあると主張する。
しかし，被告は，引用発明の前提（既存のウェブアプリケーションを利用してもらうこと）を看過し，引用発明の課題を誤って認定している。そして，誤って認定した課題に基づいて，ウェブアプリケーションと同等の機能を有するネイティブアプリケーションを新たに開発するために，ＰｈｏｎｅＧａｐが好適であるという誤った結論に至っている。
引用発明は，既存のアプリケーションを利用するためのネイティブアプリケーションを容易に生成する技術であるところ，ＰｈｏｎｅＧａｐは，Ｗｅｂ系技術を用いて新たにソースコードを書くことにより，既存のアプリケーションと同等の機能を有するネイティブアプリケーションを新たに開発するためのフレームワークであるから，ＰｈｏｎｅＧａｐを用いた場合，既存のウェブアプリケーションを利用することはできない。
そして，既存のウェブアプリケーションを利用することができない技術を，既存のアプリケーションを利用する技術に適用することはできないから，引用発明に対してＰｈｏｎｅＧａｐを適用するには，阻害要因がある。
また，引用発明に対してＰｈｏｎｅＧａｐを適用したとすると，目的とするネイティブアプリケーションのソースコードを新たに書くという作業が発生するから，引用発明の課題である既存のウェブアプリケーションを利用するためのネイティブアプリケーションを容易に生成することが達成できなくなってしまう。この観点からも，当業者が引用発明を実装するに当たって，アプリ作成フレームワークであるＰｈｏｎｅＧａｐを用いる動機付けはない。
エ 被告は，スマートフォンでは端末が縦の姿勢のときと，横の姿勢のときで画面が切り替わることは「携帯通信端末の動きに伴う動作」に他ならず，「横画面に固定する設定」や「縦画面に固定する設定」は，いずれも，「アプリケーションの，携帯通信端末の動きに伴う動作」を規定するものであるといえ，Ａｎｄｒｏｉｄにおける，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌファイルは「アプリケーションの，携帯通信端末の動きに伴う動作」を規定する設定ファイルに相当するものであるといえると主張する。
しかし，ＰｈｏｎｅＧａｐの「横画面に固定する設定」や「縦画面に固定する設定」は，あくまで携帯通信端末の動きにかかわらず，単に横画面又は縦画面に一律に画面の方向を固定するものであるから，「携帯通信端末の動きに伴う動作」を規定するものではない。
オ 被告は，引用発明のウェブアプリケーションは，ＨＴＭＬやＪａｖａＳｃｒｉｐｔで記述されているところ，ＪａｖａＳｃｒｉｐｔは，Ｗｅｂブラウザで実行される制御コードを記述するためのスクリプト言語であるから，コンテンツを既存のウェブサイトから取得しているとしても，当該コンテンツに対する制御処理は端末側で実行されるＷｅｂブラウザにおいて，ＪａｖａＳｃｒｉｐｔに従って行われているといえ，したがって，引用発明は，既存のウェブアプリケーションを利用して所望のコンテンツ（ブログ等）を表示するという機能に特化したものとはいえないと主張する。
しかし，本件審決において認定された引用発明は，ウェブアプリケーションがＨＴＭＬやＪａｖａＳｃｒｉｐｔで記述されていること，及び，既存のウェブサイトから取得したコンテンツに対する制御処理が端末側で実行されるＷｅｂブラウザにおいてＪａｖａＳｃｒｉｐｔに従って行われていることを構成として有していないから，被告の上記主張は，本件審決において認定された引用発明に基づかないものであり，失当である。
本件審決において認定された引用発明は，「ここで，生成されたネイティブアプリケーションは，携帯端末にインストールされて実行されると，設定情報に含まれているウェブアプリケーションのアドレスに基づいて，ウェブアプリケーションに対応するウェブページを取得し，設定情報に含まれている表示態様情報に基づいて取得したウェブページの表示態様を変更して，携帯端末の表示部に表示させるものであり」という構成を有しており，ウェブアプリケーションに対応するウェブページを取得して表示することが特定されているのみである。
カ 被告は，ＰｈｏｎｅＧａｐは，引用発明と同様に，ＨＴＭＬやＪａｖａＳｃｒｉｐｔ等で記述されたウェブアプリケーションからスマートフォン用アプリを生成可能であると主張する。
しかし，ＰｈｏｎｅＧａｐは，ＨＴＭＬやＪａｖａＳｃｒｉｐｔといったＷｅｂ系技術を用いて目的とするネイティブアプリケーションのソースコード（プログラム）を，開発者が自ら新規に書かなければならない。ＰｈｏｎｅＧａｐは，既存のウェブアプリケーションからネイティブアプリケーションを容易に生成する技術ではなく，一般的なＷｅｂ系技術を用いて，ネイティブアプリケーションをプログラミングすることが可能な技術にすぎない。
キ 被告は，ＰｈｏｎｅＧａｐは，設定ファイル（ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌなど）にネイティブ機能（端末の加速度センサを用いた画面の回転制御）の制御内容を規定するためのパラメータ（ｌａｎｄｓｃａｐｅやｐｏｒｔｒａｉｔ）を設定していると主張する。
しかし，前記エのとおり，ＰｈｏｎｅＧａｐにおける「横画面に固定する設定（ｌａｎｄｓｃａｐｅ）」や「縦画面に固定する設定（ｐｏｒｔｒａｉｔ）」は，携帯通信端末の動きとは無関係に設定されるものであり，「携帯通信端末の動きに伴う動作」を規定するものではない。
ク 被告は，引用発明のアプリケーション生成システムにＰｈｏｎｅＧａｐを適用する場合には，「当該設定ファイルを設定するためのパラメータ」を「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」に置き換えてしまうのではなく，ウェブサーバで提供されるコンテンツにアクセスする際に使用される「当該設定ファイルを設定するためのパラメータ」とは別の「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」を追加設定するだけであるから，引用発明が前提とする「ウェブアプリケーションを利用するネイティブアプリケーション」を生成することができなくなることはないと主張する。
しかし，被告は，「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」を具体的にどのように追加するのか立証していないから，被告の上記主張は根拠がない。
ケ 被告は，一般的なウェブサイト表示用のウェブアプリケーションは，加速度センサを備えたスマートフォン等の端末では，加速度センサによって検出した端末の姿勢に基づいて，端末の姿勢に基づいた画面回転表示制御を行っているから，一般的なウェブサイト表示用のウェブアプリケーションにおいても，「携帯通信端末の動きに伴う動作」（端末の姿勢に基づいた画面回転表示制御）を実現することが可能であると主張する。
しかし，端末の姿勢は，あくまで端末に備えられた加速度センサで検出するものであるから，サーバ側で動作するウェブアプリケーションにおいては，端末側の姿勢を知る由もない。端末の姿勢に基づいた画面回転表示制御は，ウェブアプリケーションの機能ではなく，端末側の機能にすぎない。
したがって，一般的なウェブサイト表示用のウェブアプリケーションにおいて，「携帯通信端末の動きに伴う動作」（端末の姿勢に基づいた画面回転表示制御）を実現することは可能であるとする被告の上記主張は，誤りである。
２ 取消事由２（本件補正前発明についての容易想到性の判断の誤り）本件補正前発明についても，引用発明において，アプリケーションの設定ファイルを，「アプリケーションの動作を規定する設定ファイル」に変更し，当該設定ファイルを設定するためのパラメータを，ＧＰＳや加速度センサのような携帯通信端末に固有のネイティブ機能を実行させるためのパラメータに変更することには，阻害要因があり，引用発明と引用文献２～５及び参考文献１に記載された周知技術とを組み合わせることはできない。
したがって，本件補正前発明は，当業者が引用発明と引用文献２～５及び参考文献１に記載された周知技術に基づいて容易に想到し得たものではない。
第４ 被告の主張
１ 取消事由１について
(1) 周知技術であるＰｈｏｎｅＧａｐの概要
引用文献３（６６頁表題，６６頁副題，６６頁中欄下から２行～右欄３行，６６頁表１，６６頁右欄１３行～６７頁左欄１３行，７０頁右欄６行～最終行，７２頁左欄１行～２５行），引用文献５（１６頁左欄７行～２７行，２９頁左欄１行～１６行，３６頁左下欄下から１０行～末行），三宅理「スマートフォン開発倶楽部第５回」ＷＥＢ＋ＤＢＰＲＥＳＳＶｏｌ．６６（株式会社技術評論社，平成２４年１月２５日発行）（以下「乙３文献」という。甲７，乙３）（５５頁左欄１０行～１４行，１５９頁左欄１行～右欄４行，１６０頁右欄１行～７行）の記載からすると，周知技術のＰｈｏｎｅＧａｐは以下のような技術であるといえる。
「ｉＰｈｏｎｅやＡｎｄｒｏｉｄ，ＷｉｎｄｏｗｓＰｈｏｎｅなどのマルチプラットホームに対応するアプリを作成可能なフレームワークであって，
ＨＴＭＬやＪａｖａＳｃｒｉｐｔなどのＷｅｂ系技術を用いてＷｅｂアプリを作る感覚で作成可能であり，
ＪａｖａＳｃｒｉｐｔでＰｈｏｎｅＧａｐのＡＰＩ（ライブラリの関数）を呼び出せば，プラグインの仕組みを使って，カメラやＧＰＳなど端末のネイティブ部分にアクセス可能であり，
端末のＧＰＳ機能にアクセスすることで，ＧＰＳで取得した端末の現在位置が中心となるように地図を表示することが可能となり，
スマートフォンでは加速度センサを用いて端末の姿勢を検知し，端末が縦の姿勢のときと，横の姿勢のときで画面が切り替わるところ，横画面に固定する設定を施す場合，Ａｎｄｒｏｉｄでは，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌに「ａｎｄｒｏｉｄ：ｓｃｒｅｅｎＯｒｉｅｎｔａｔｉｏｎ＝”ｌａｎｄｓｃａｐｅ”」の１行を追加することで，ｉＯＳでは，「ＬａｎｄｓｃａｐｅＲｉｇｈｔ」または「ＬａｎｄｓｃａｐｅＬｅｆｔ」のアイコンを選択することで横画面に固定可能となり，縦画面に固定する設定を施す場合，Ａｎｄｒｏｉｄでは，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌに「ａｎｄｒｏｉｄ：ｓｃｒｅｅｎＯｒｉｅｎｔａｔｉｏｎ＝”ｐｏｒｔｒａｉｔ”」の１行を追加することで，ｉＯＳでは，「ｐｏｒｔｒａｉｔ」のアイコンを選択することで，縦画面に固定可能となり，
作成されたアプリの実体はブラウザＵＩで動くアプリであって，ＡｐｐＳｔｏｒｅ等で配布可能となるアプリを作成可能なフレームワークであるＰｈｏｎｅＧａｐ」
(2) 引用発明への周知技術のＰｈｏｎｅＧａｐの適用
ア 動機付け
引用文献１の段落【０００４】～【０００７】によると，引用発明の課題は，ＣＭＳ（コンテンツ管理システム）によって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを容易に開発して，アプリケーションサーバにおいてネイティブアプリケーションとして検索可能とすることであるといえる。
ここで，ＰｈｏｎｅＧａｐは，ＨＴＭＬやＪａｖａＳｃｒｉｐｔなどのＷｅｂ系技術を用いてＷｅｂアプリ（ウェブアプリケーション）を作る感覚で容易に作成可能であって，ＡｐｐＳｔｏｒｅ（アプリケーションサーバ）等で配布可能となるアプリ（ＡｐｐＳｔｏｒｅ等で配布可能となれば，アプリケーションサーバ（ＡｐｐＳｔｏｒｅ等）においてネイティブアプリケーションとして検索可能となる）を作成可能なフレームワークであるから，引用発明の課題を解決する際に利用するには好適なフレームワークであるといえる。
したがって，当業者が引用発明を実装するに当たって，アプリ作成フレームワークであるＰｈｏｎｅＧａｐを用いる動機付けがあるといえる。
イ(ｱ) ＰｈｏｎｅＧａｐでは，ＪａｖａＳｃｒｉｐｔでＰｈｏｎｅＧａｐのＡＰＩ（ライブラリの関数）を呼び出せば，プラグインの仕組みを使って，ＧＰＳなど端末のネイティブ部分にアクセス可能であり，端末のＧＰＳ機能にアクセスすることで，ＧＰＳで取得した端末の現在位置が中心となるように地図を表示することが可能となるから，引用発明において地図表示アプリケーションを生成する際に，ＰｈｏｎｅＧａｐのフレームワークを採用することで，ネイティブ機能であるＧＰＳ機能が利用可能となり，携帯通信端末の動き（移動）に伴う動作（ＧＰＳで取得した端末の現在位置が中心となるように地図を表示する地図表示制御）を設定可能となる。
(ｲ) また，スマートフォンでは，ネイティブ機能である加速度センサから取得した値を用いて端末姿勢を検出しており，端末が縦の姿勢のときと，横の姿勢のときで画面が切り替わるところ，ＰｈｏｎｅＧａｐでは，横画面に固定する設定を施す場合，Ａｎｄｒｏｉｄでは，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌに「ａｎｄｒｏｉｄ：ｓｃｒｅｅｎＯｒｉｅｎｔａｔｉｏｎ＝”ｌａｎｄｓｃａｐｅ”」の１行を追加することで，ｉＯＳでは，「ＬａｎｄｓｃａｐｅＲｉｇｈｔ」又は「ＬａｎｄｓｃａｐｅＬｅｆｔ」のアイコンを選択することで横画面に固定可能となり，縦画面に固定する設定を施す場合，Ａｎｄｒｏｉｄでは，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌに「ａｎｄｒｏｉｄ：ｓｃｒｅｅｎＯｒｉｅｎｔａｔｉｏｎ＝”ｐｏｒｔｒａｉｔ”」の１行を追加することで，ｉＯＳでは，「ｐｏｒｔｒａｉｔ」のアイコンを選択することで，縦画面に固定可能となる。
ここで，「スマートフォンでは端末が縦の姿勢のときと，横の姿勢のときで画面が切り替わる」ことは「携帯通信端末の動きに伴う動作」に他ならず，「横画面に固定する設定」や「縦画面に固定する設定」は，いずれも，「アプリケーションの，携帯通信端末の動きに伴う動作」を規定するものであるといえ，Ａｎｄｒｏｉｄにおける，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌファイルは「アプリケーションの，携帯通信端末の動きに伴う動作」を規定する「設定ファイル」に相当するものであるといえる。
ウ したがって，引用発明において，アプリケーションを生成する際に，ＰｈｏｎｅＧａｐのフレームワークを利用することで，本件補正発明と同様に，「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」に応じて，携帯通信端末において実行される「アプリケーションの，携帯通信端末の動きに伴う動作」を規定する「設定ファイル」を備えることとなる。
(3) 本件補正発明の作用効果について
地図表示のウェブアプリケーションは，ＧＰＳ機能を備えた端末では，ＧＰＳ機能を用いて現在位置を取得し，現在位置を中心とした地図表示を行うことが可能であるから，地図表示のウェブアプリケーションにおいても，「携帯通信端末の動きに伴う動作」（端末の移動に伴って変化する現在位置を中心とした地図表示制御）を実現することが可能である（乙４の１３０頁～１３４頁）。
また，一般的なウェブサイト表示用のウェブアプリケーションは，加速度センサを備えたスマートフォン等の端末では，加速度センサによって検出した端末の姿勢に基づいて，端末の姿勢に基づいた画面回転表示制御を行っているから，一般的なウェブサイト表示用のウェブアプリケーションにおいても，「携帯通信端末の動きに伴う動作」（端末の姿勢に基づいた画面回転表示制御）を実現することが可能である。
したがって，引用発明にＰｈｏｎｅＧａｐを組み合わせることで，これらのウェブアプリケーションから「携帯通信端末の動きに伴う動作」を実現するネイティブアプリケーションを生成することが想定可能であるといえるから，本件補正発明の作用効果は格別なものではない。
(4) 原告の主張について
ア 原告は，引用発明は，既存のウェブアプリケーションを利用して所望のコンテンツ（ブログ等）を表示するという機能に特化したものであると主張する。しかし，引用文献１の段落【００２４】によると，引用発明のウェブアプリケーションが，ＨＴＭＬやＪａｖａＳｃｒｉｐｔで記述されており，引用発明のウェブアプリケーションの例として，ブログだけでなく，ゲームサイト等も示されている。ここで，ＪａｖａＳｃｒｉｐｔは，Ｗｅｂブラウザで実行される制御コードを記述するためのスクリプト言語である（乙４の２６頁下から４行～最終行）から，コンテンツを既存のウェブサイトから取得しているとしても，当該コンテンツに対する制御処理は端末側で実行されるＷｅｂブラウザにおいて，ＪａｖａＳｃｒｉｐｔに従って行われているといえる。ウェブアプリケーションのゲームでは，一般的に，ユーザからの操作入力を受け付けて，ＪａｖａＳｃｒｉｐｔにより記述された制御コードを端末側で実行することでインタラクティブな制御処理を可能としている。したがって，引用発明は，既存の「ウェブアプリケーション」を利用して所望のコンテンツ（ブログ等）を表示するという機能に特化したものとはいえないから，原告の上記主張は誤りである。
イ 原告は，設定ファイルにネイティブ機能のパラメータをＧＵＩを用いて簡単に設定することで，アプリを容易に生成するという課題を解決できることは当然に予測し得たものでないと主張する。
しかし，前記(1)のとおり，ＰｈｏｎｅＧａｐは，引用発明と同様に，ＨＴＭＬやＪａｖａＳｃｒｉｐｔ等で記述されたウェブアプリケーションからスマートフォン用アプリを生成可能であり，端末のブラウザＵＩ（Ｗｅｂブラウザ）に，スマートフォンのネイティブ機能（ＧＰＳやカメラなど）にアクセスするためのＪａｖａＳｃｒｉｐｔ関数を実行させることで，プラグインの仕組みを使って，スマートフォンのネイティブ機能（ＧＰＳやカメラなど）にアクセス可能となる。また，設定ファイル（ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌなど）にネイティブ機能（端末の加速度センサを用いた画面の回転制御）の制御内容を規定するためのパラメータ（パラメータｌａｎｄｓｃａｐｅやｐｏｒｔｒａｉｔ）を設定している。したがって，引用発明にＰｈｏｎｅＧａｐを適用することにより，設定ファイルにネイティブ機能のパラメータをＧＵＩを用いて簡単に設定することで，アプリを容易に生成するという課題を解決できることは当然に予測し得たものであるといえるから，原告の上記主張は誤りである。
ウ 原告は，引用発明のアプリケーション生成システムにおいて，「当該設定ファイルを設定するためのパラメータ」すなわちＧＵＩにて設定するパラメータを，「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」に置き換えてしまうと，利用すべきウェブアプリケーションのロケーションを特定することができなくなり，引用発明が前提とする「ウェブアプリケーションを利用するネイティブアプリケーション」を生成することができなくなってしまうから，引用発明と上記各周知技術との組合せに阻害要因がある旨主張する。
しかし，引用発明のアプリケーション生成システムにＰｈｏｎｅＧａｐを適用する場合には，「当該設定ファイルを設定するためのパラメータ」を「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」に置き換えてしまうのではなく，ウェブサーバで提供されるコンテンツにアクセスする際に使用される「当該設定ファイルを設定するためのパラメータ」とは別の「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」を追加設定するだけであるから，引用発明が前提とする「ウェブアプリケーションを利用するネイティブアプリケーション」を生成することができなくなることはない。
したがって，原告の上記主張は誤りである。
２ 取消事由２について
前記１(4)ウのとおり，引用発明のアプリケーション生成システムとＰｈｏｎｅＧａｐとの組合せに阻害要因はないから，本件補正前の発明は，当業者が引用発明と引用文献２～５及び参考文献１等に記載された周知技術に基づいて容易に想到し得たものである。
したがって，本件審決における，本件補正前発明についての容易想到性の判断に誤りはない。
第５ 当裁判所の判断
１ 本件明細書の記載
本件明細書には，以下の記載がある（甲９の１・３）。
【技術分野】【０００１】本発明は，アプリケーション生成支援システムおよびアプリケーション生成支援プログラムに関する。
【背景技術】【０００２】モバイル用通信端末のアプリケーションとして，さまざまなアプリケーションが開発されている。モバイル用通信端末のアプリケーションは，Ｗｅｂアプリケーション，ネイティブアプリケーション，およびハイブリッドアプリケーションに分類される。Ｗｅｂアプリケーションは，演算処理をネットワーク上のサーバで実行するタイプのアプリケーションである。ネイティブアプリケーションは，演算処理を通信端末上でのみ実行するタイプのアプリケーションである。ネイティブアプリケーションは，例えば，カメラ，ＧＰＳ，マイク，加速度センサなど，通信端末に固有のネイティブ機能を利用することができる，という特徴を有するアプリケーションである。ハイブリッドアプリケーションは，ネイティブ機能を利用することができ，マルチプラットフォームに対応したアプリケーションを作成することができ，アプリケーションをｗｅｂブラウザのように使用するＷｅ
ｂ Ｖｉｅｗを用いることができるという特徴を有するアプリケーションである。【０００３】上記のように，ハイブリッドアプリケーションは，Ｗｅｂアプリケーションおよびネイティブアプリケーションのそれぞれの利点を備えるため，通信端末用アプリケーションの主流となっている。例えば，業務用の通信端末に用いられるアプリケーションとしてもハイブリッドアプリケーションが広く用いられる。業務用のハイブリッドアプリケーションを作成するためには，業務を行う各組織において業務目的に適したアプリケーションの開発を行う必要がある。
【０００４】ここで，アプリケーションを開発するためには，アプリケーションをインストールする通信端末のＯＳに適合した専用端末を準備し，当該ＯＳに適したアプリケーション開発ツールを導入し，当該アプリケーション開発ツールにおけるプログラミング言語を用いたアプリケーション開発をする必要がある。このように，アプリケーション開発のためには，専用端末の準備およびアプリケーション開発ツールの導入などのアプリケーション開発環境の整備，ならびにプログラミング言語などのスキル習得などの多様な初期投資が必要である。
【０００５】プログラミング言語のスキル習得の負担を軽減するために，プログラム開発を支援するための技術が開発されている。例えば，プログラム開発をより簡易化するために，特許文献１のようなプログラム開発装置が提案されている。【発明が解決しようとする課題】【０００７】しかしながら，通信端末上で動作し，通信端末の動作に合わせて動作または画面表示するアプリケーションを作成するためには特許文献１に記載された技術に比べてはるかに高度なプログラミング技術が必要である。さらに，アプリケーションの用途に応じて多様な機能をアプリケーションに組み込む必要があるため，上記のような通信端末上で動作するアプリケーションの開発のために，アプリケーション開発者に費用および時間の面で大きな負担がかかる。
【０００８】本発明は，上記実情に鑑み，アプリケーション開発者への開発負担を軽減することができるアプリケーション生成支援システムおよびアプリケーション生成支援プログラムを提供することを目的とする。
【課題を解決するための手段】【０００９】本発明の一実施形態に係るアプリケーション生成支援システムは，通信端末の動作に関連するパラメータに応じてアプリケーションの動作を規定する設定ファイルを設定する設定部と，前記設定ファイルに基づいてアプリケーションパッケージを生成する生成部と，を有する。【００２０】前記設定ファイルは，前記通信端末に固有のネイティブ機能を前記通信端末に実行させるプラグインファイルを含んでもよい。
【００３７】前記設定ファイルは，前記通信端末に固有のネイティブ機能を前記通信端末に実行させるプラグインファイルを含んでもよい。
【００４３】本発明によれば，アプリケーション開発者への開発負担を軽減することができるアプリケーション生成支援システムおよびアプリケーション生成支援プログラムを提供することができる。
【発明を実施するための形態】〈第 1 実施形態〉【００６２】・・・端末通信部３３０は全地球測位システム（ＧｌｏｂａｌＰｏｓｉｔｉｏｎｉｎｇＳｙｓｔｅｍ；ＧＰＳ）機能を有していてもよい。ＧＰＳ機能は第２通信端末３００のネイティブ機能の一つである。ＧＰＳ機能を有効にするアプリケーションを起動すると，端末通信部３３０は上空の衛星からの信号を受信し，第２通信端末３００の現在位置を知ることができる。
【００６４】カメラ３５０は，ディスプレイ３４０と反対側に設けられている。つまり，ディスプレイ３４０が設けられた側を表面とすると，カメラ３５０は裏面に設けられている。なお，カメラ３５０とは別個のカメラが表面に設けられていてもよい。カメラ３５０は，レンズユニットおよび撮像素子を有している。カメラ３５０の機能は第２通信端末３００のネイティブ機能の一つである。カメラ３５０の機能を有効にするアプリケーションを起動すると，レンズユニットを介して撮像素子で検知される映像がディスプレイ３４０に表示される。この映像が撮像素子で検知されている間にユーザによって作動指示が入力されると，端末制御部３２０は，その作動指示に応じて撮像素子で検知された映像の静止画像を取得する。【０１０１】「ＬＡＮＤＳＣＡＰＥ＿ＬＥＦＴ」，「ＬＡＮＤＳＣＡＰＥ＿ＲＩＧＨＴ」は，第２通信端末３００を左横，右横に回転した場合の画面制御を指定する項目である。これらの項目では，第２通信端末３００の画面を左横，右横に回転したときに，第２通信端末３００の画面上でアプリケーションを正面表示させるか否かをチェックの有無で設定される。
【０１０２】「ＰＯＲＴＲＡＩＴ＿ＵＰＳＩＤＥ＿ＤＯＷＮ」は，第２通信端末３００を上下逆さに回転した場合の画面制御を指定する項目である。この項目では，第２通信端末３００の画面を上下逆さに回転したときに，第２通信端末３００の画面上でアプリケーションを正面表示させるか否かをチェックの有無で設定される。【０１０３】「ＡＰＰ＿ＳＴＡＲＴ＿ＰＡＧＥ＿ＵＲＬ」は，アプリケーションのスタートページとして指定されるＷｅｂページのＵＲＬを指定する項目である。この項目では，アプリケーションを起動したときに表示されるＷｅｂページのＵＲＬを設定するための文字列が設定される。この項目では，ＵＲＬを表示するために，『ｈｔｔｐ：／／』や『ｈｔｔｐｓ：／／』などの規定の形式の文字列が設定される。
【０１０４】「ＡＰＰＬＩＣＡＴＩＯＮ＿ＰＬＩＳＴ」は，アプリケーション設定ファイルを指定する項目である。この項目では，アプリケーションに搭載したいアプリケーション設定ファイルを設定し，当該設定ファイルをサーバ１００にアップロードする。「ＡＰＰＬＩＣＡＴＩＯＮ＿ＰＬＩＳＴ」において設定されるアプリケーション設定ファイルは，第１通信端末２００を操作する第１ユーザによって作成された設定ファイルであってもよく，他の第３ユーザによって作成された設定ファイルであってもよい。
【０１０９】図１０は，本発明の一実施形態に係るアプリケーション生成支援システムのパラメータチェックのシーケンスを説明する図である。図１０に示すように，ステップ５２１で受信されたパラメータのチェックが行われる（ステップ５２３１）。ステップ５２３１では，例えば，設定されたパラメータの形式が規定の形式に適合しているか否か，およびアプリケーション設定ファイルの形式が規定の形式に適合しているか否かなどの設定状態がチェックされる。図８および図９に示した例では，「ＡＰＰ＿ＳＴＡＲＴ＿ＰＡＧＥ＿ＵＲＬ」に入力されたＵＲＬが『ｈｔｔｐ：／／』または『ｈｔｔｐｓ：／／』の形式になっているか否かがチェックされる。同様に，「ＡＰＰＬＩＣＡＴＩＯＮ＿ＰＬＩＳＴ」でアプリケーション設定ファイルが規定のファイル形式になっているか否かがチェックされる。また，詳細は後述するが，アプリケーションに搭載される機能として第２通信端末３００のネイティブ機能に関連するプラグインファイルが規定のファイル形式になっているか否かがチェックされる。
【０１１５】図１３は，本発明の一実施形態に係るアプリケーション生成支援システムの設定ファイルの一例を説明する図である。図１３の「アイコン指定」，「アプリケーション名指定」，および「画面の回転制御指定」はＯＳ設定ファイルに該当する。つまり，図８および図９の「ＣＦＢＵＮＤＬＥ＿ＤＩＳＰＬＡＹ＿ＮＡＭＥ」，「ＩＮＦＯ＿ＣＦＢＵＮＤＬＥ＿ＶＥＲＳＩＯＮ」，「ＬＡＮＤＳＣＡＰＥ＿ＬＥＦＴ」，「ＰＯＲＴＲＡＩＴ＿ＵＰＳＩＤＥ＿ＤＯＷＮ」，および「ＬＡＮＤＳＣＡＰＥ＿ＲＩＧＨＴ」はＯＳ設定ファイルに該当する。これらのＯＳ設定ファイルに係る動作は，複数の第２通信端末３００に共通する動作である。図１３の「アドレスバー表示」，「画面のコピー＆ペースト制御」，「通信プロトコル制限」，「無操作タイムアウト指定」，「シングルサインオン設定」，および「バックボタンの利用制限」はアプリケーション設定ファイルに該当する。つまり，上記の項目は「ＡＰＰＬＩＣＡＴＩＯＮ＿ＰＬＩＳＴ」の一例である。これらのアプリケーション設定ファイルに係る動作は，第１通信端末２００によって入力された第２通信端末３００の動作であり，複数の第２通信端末３００に共通する動作であってもよく，特定の第２通信端末３００に固有の動作であってもよい。
【０１１６】換言すると，本実施形態の設定ファイルは，ＯＳ設定ファイルおよびアプリケーション設定ファイルを含む。ＯＳ設定ファイルは，ビルドシェル１５０が受信したパラメータに関連し，複数の第２通信端末３００の動作に共通するアプリケーションの動作を規定する設定ファイルである。アプリケーション設定ファイルは，ビルドシェル１５０が受信したパラメータに関連し，第１通信端末２００を操作する第１ユーザによって入力された情報に基づくアプリケーションの動作を規定する設定ファイルである。なお，図１３に示すＯＳ設定ファイルおよびアプリケーション設定ファイルは一例であり，本発明の「ＡＰＰＬＩＣＡＴＩＯＮ＿ＰＬＩＳＴ」を限定するものではない。
〈第３実施形態〉【０１３５】［サーバ１００Ｂの機能構成］本実施形態のアプリケーション生成支援システム１０Ｂにおけるサーバ１００Ｂの各機能の構成は，第１実施形態のサーバ１００の各機能の構成と同じである。したがって，図５を参照してサーバ１００Ｂの機能部について説明する。アプリケーション生成支援システム１０Ｂのビルドシェル１５０Ｂに含まれるファイル設定部１５５Ｂは，ＯＳ設定ファイルおよびアプリケーション設定ファイルに加えて，第２通信端末３００Ｂのネイティブ機能に関連するプラグインファイルを設定する点において，第１実施形態のファイル設定部１５５とは相違する。ファイル設定部１５５Ｂは，パラメータ受信部１５１Ｂが受信したパラメータにプラグインファイルに関連するパラメータが設定されている場合に，ＯＳ設定ファイルやアプリケーション設定ファイルと同様にプラグインファイルを設定する。
【０１３６】ファイル設定部１５５Ｂは，図６に示すように，パラメータ確認部１５５１Ｂ，テンプレート関連付け部１５５３Ｂ，およびプログラム更新部１５５５Ｂを有する。パラメータ確認部１５５１Ｂは，第１実施形態のパラメータ確認部１５５１と同様の機能を有する。テンプレート関連付け部１５５３Ｂは，第１実施形態のテンプレート関連付け部１５５３と同様の機能に加え，プラグインファイル用のテンプレートをパラメータ確認部１５５１Ｂによって選択された他のテンプレートに関連付ける。プログラム更新部１５５５Ｂは，第１実施形態のプログラム更新部１５５５と同様の機能に加え，プラグインファイル用のテンプレートによって規定された動作の各々が，第２通信端末３００にインストールされたアプリケーション上で実現可能となるように，当該テンプレートの一部を更新する。【０１３７】上記のように，プラグインファイルは，例えば，カメラ，ＧＰＳ，マイク，加速度センサなど，第２通信端末３００Ｂの機器に固有のネイティブ機能をアプリケーションによって第２通信端末３００Ｂに実行させるための設定ファイルである。プラグインファイルは，ＯＳ設定ファイルおよびアプリケーション設定ファイルと同様に，ビルドシェル１５０Ｂが受信したパラメータに関連する設定ファイルである。
【０１３９】［アプリケーション生成支援システム１０Ｂの動作フロー］図１７～図２１を用いて，本実施形態のアプリケーション生成支援システム１０Ｂの各機能ブロックの動作について，フローチャートおよびユーザに表示されるインターフェースの一例を用いて詳しく説明する。
【０１４０】まず，図１７～図１９を用いて，第１通信端末２００Ｂによって設定されたパラメータに基づいてアプリケーションを生成し，当該アプリケーションをダウンロード可能に提供する動作について説明する。図１７は，本発明の一実施形態に係るアプリケーション生成支援システムのアプリケーション生成動作を示すフローチャートである。図１７のフローチャートは図７のフローチャートと類似しているが，図１７のフローチャートでは，ステップ５２７Ｂとステップ５２９Ｂとの間にプラグインファイルを設定するステップ５２８Ｂが設けられている点において，図７のフローチャートとは相違する。また，ステップ５２８Ｂが設けられていることに伴い，ステップ５１１Ｂで第１通信端末２００Ｂに提供されるインターフェース６００Ｂが図８のインターフェース６００とは相違する。以下の説明において，図７の動作フローと同じ動作については説明を省略し，図７の動作フローと異なる動作について説明する。
【０１４１】まず，図１７のステップ５１１Ｂで第１通信端末２００Ｂに提供されるパラメータ設定ＧＵＩについて説明する。図１８は，本発明の一実施形態に係るアプリケーション生成支援システムのパラメータ入力動作におけるインターフェースである。図１８に示すインターフェース６００Ｂは図８のインターフェース６００と類似しているが，図１８のインターフェース６００Ｂの項目名６２０Ｂでは「ＡＰＰＬＩＣＡＴＩＯＮ＿ＰＬＩＳＴ」の下に「ＰＬＵＧＩＮ＿ＦＩＬＥＳ」が設けられている点において，図８のインターフェース６００とは相違する。【０１４２】「ＰＬＵＧＩＮ＿ＦＩＬＥＳ」の入力欄６３０Ｂはプラグインファイル用のテンプレートが格納された位置を示すアドレスを受け付ける。この入力欄６３０Ｂには，ユーザが直接アドレスを入力してもよく，ブランクボックスの右の「参照」をクリックすることで，参照するアドレスを指定してもよい。なお，プラグインファイル用のテンプレートは，指定されたアドレスに圧縮ファイル形式で格納されている。ただし，当該ファイルは圧縮ファイル形式以外の形式で格納されていてもよい。
【０１４５】図１７に示すように，ステップ５２７Ｂのアプリケーション設定ファイルの上書き処理に続いて，プラグインファイルの設定が行われる（ステップ５２８Ｂ）。プラグインファイルの設定は，ＯＳ設定ファイルの置換およびアプリケーション設定ファイルの上書き処理と同様に，設定ファイルを更新するという場合がある。ここで，ステップ５２８Ｂにおいて，プラグインファイルの設定するシーケンスについて図１９を用いて説明する。
【図１】
【図１０】
【図１３】
【図１７】
【図１８】
【図１９】
２(1) 引用文献１には，以下のとおりの記載がある（甲１）。
【技術分野】【０００１】本発明は，アプリケーション生成装置，アプリケーション生成システム及びアプリケーション生成方法に関する。
【背景技術】【０００２】近年，コンテンツマネジメントシステム（以下，ＣＭＳ（ＣｏｎｔｅｎｔＭａｎａｇｅｍｅｎｔＳｙｓｔｅｍ）という）によりウェブアプリケーションとして公開するコンテンツを構築し，管理することが行われている（例えば，特許文献１参照）。
【発明が解決しようとする課題】【０００４】ところで，近年，ネイティブアプリケーションをダウンロードしてインストールすることができるスマートフォンが普及している。スマートフォンのユーザは，ネイティブアプリケーションをインストールする場合，アプリケーションを提供する所定のアプリケーションサーバにアクセスし，所望のネイティブアプリケーションを検索する。
【０００５】しかしながら，ＣＭＳによって構築されるウェブアプリケーションは，ウェブサイトとして構築されるため，検索サイトの検索結果として表示されることがあるものの，アプリケーションサーバから検索することができない。したがって，アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに，ＣＭＳにより開発したウェブアプリケーションを利用してもらうことができないという問題がある。
【０００６】これに対して，ＣＭＳによって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを開発し，当該ネイティブアプリケーションをアプリケーションサーバにアップロードすることも考えられる。しかしながら，ネイティブアプリケーションを新規に開発するには，多大な開発工数が必要であった。
【０００７】本発明は，ネイティブアプリケーションを容易に生成することができるアプリケーション生成装置，アプリケーション生成システム及びアプリケーション生成方法を提供することを目的とする。
【課題を解決するための手段】【０００８】本発明の第１の態様に係るアプリケーション生成装置は，端末にインストールされると，所定のアクセス先にアクセスして情報を取得し，前記端末の表示部に表示させるネイティブアプリケーションを生成するアプリケーション生成装置であって，前記ネイティブアプリケーションのテンプレートであるテンプレートアプリケーションを記憶する記憶部と，ウェブアプリケーションのアドレスとともに，ネイティブアプリケーションの生成要求を示すリクエストを受け付ける受付部と，前記受付部が前記リクエストを受け付けたことに応じて，前記テンプレートアプリケーションの前記アクセス先を前記受付部が受け付けた前記アドレスに設定することで前記ネイティブアプリケーションを生成する生成部と，を備えることを特徴とする。
【０００９】この発明によれば，アプリケーション生成装置は，生成部がテンプレートアプリケーションのアクセス先を，受付部が受け付けたウェブアプリケーションのアドレスに設定することで，当該テンプレートアプリケーションを，ウェブアプリケーションが表示する情報を表示するネイティブアプリケーションとして機能させることができる。したがって，アプリケーション生成装置は，受付部がウェブアプリケーションのアドレスを受け付けることで，当該ウェブアプリケーションと同等の機能を有するネイティブアプリケーションを容易に生成することができる。【００１０】また，前記テンプレートアプリケーションは，前記アクセス先を設定する設定情報を含み，前記生成部は，前記受付部が前記リクエストを受け付けたことに応じて，前記テンプレートアプリケーションをコピーし，コピーされた前記テンプレートアプリケーションに含まれる前記設定情報の前記アクセス先を前記受付部が受け付けた前記アドレスに設定することで前記ネイティブアプリケーションを生成することを特徴とする。
この発明によれば，アプリケーション生成装置は，設定情報に含まれているアクセス先を，受付部が受け付けたアドレスに変更するという単純な処理によってネイティブアプリケーションを容易に生成することができる。
【発明を実施するための形態】
【００２２】以下，本発明の実施形態について，図面を参照しながら説明する。＜第１の実施形態＞
［アプリケーション生成システムＳの概要］
図１は，第１の実施形態に係るアプリケーション生成システムＳの概要を示す図である。アプリケーション生成システムＳは，アプリケーション生成装置１と，アプリケーション生成装置１とインターネット等のネットワークＮを介して通信可能に接続された開発用端末２とを備え，ネイティブアプリケーションを生成するシステムである。
【００２３】ネイティブアプリケーションは，例えば，スマートフォン等の携帯端末にインストールされるアプリケーションプログラムである。例えば，携帯端末のユーザは，アプリケーション提供サーバ３にアクセスして所望のネイティブアプリケーションを検索する。そして，携帯端末のユーザは，検索結果から所望のネイティブアプリケーションを選択し，アプリケーション提供サーバ３から当該ネイティブアプリケーションを取得して携帯端末にインストールする。
【００２４】アプリケーション生成システムＳのアプリケーション生成装置１は，例えば，開発用端末２の操作に応じて，ウェブアプリケーションを構築するコンテンツマネジメントシステムである。ここで，ウェブアプリケーションは，ネットワークＮを介して実行されるアプリケーションであり，ＨＴＭＬやＪａｖａＳｃｒｉｐｔ（登録商標）で記述される１以上のウェブページから構成されている。ウェブアプリケーションは，例えば，ブログ，有名人等のファンサイト，ゲームサイト，ショッピングサイト等である。
【００２５】アプリケーション生成装置１は，例えば，ウェブアプリケーションのアドレスと，ネイティブアプリケーションの生成要求を示すリクエストとを受け付けると，受け付けたアドレスをアクセス先とするネイティブアプリケーションを生成して出力する。開発用端末２は，出力されたネイティブアプリケーションを取得し，ネットワークＮを介して，アプリケーション提供サーバ３にアップロードする。これにより，携帯端末のユーザは，アプリケーション提供サーバ３において，ウェブアプリケーションの情報を表示するネイティブアプリケーションを検索することができる。
【００２６】その後，携帯端末のユーザが，当該ネイティブアプリケーションをアプリケーション提供サーバ３からダウンロードしてインストールを行うと，携帯端末の画面にアプリケーションのアイコンが表示される。携帯端末のユーザが，当該アイコンを実行するとネイティブアプリケーションが実行される。ネイティブアプリケーションは，起動すると，先に設定されたウェブアプリケーションのアドレスにアクセスしてウェブページを取得して表示する。そして，ネイティブアプリケーションは，表示されているウェブアプリケーションのリンク等が選択されると，当該リンク等にアクセスし，ウェブアプリケーションを構成する他のウェブページを取得して表示する。
【００２７】［アプリケーション生成装置１の機能構成］続いて，アプリケーション生成装置１の機能構成について説明する。図２は，第１の実施形態に係るアプリケーション生成装置１及び開発用端末２の機能構成図である。
アプリケーション生成装置１は，記憶部１１と，受付部１２と，生成部１３と，変換部１４と，送信部１５とを備える。ここで，受付部１２，生成部１３，変換部１４，及び送信部１５は，例えば，ＣＰＵ等により構成されている。
【００２８】記憶部１１は，例えば，ＲＯＭ（Read Only Memory），ＲＡＭ（RandomAccess Memory），ハードディスク等により構成される。記憶部１１は，ネイティブアプリケーションのテンプレートであるテンプレートアプリケーション１１１を記憶する。
【００２９】テンプレートアプリケーション１１１は，スマートフォン等の携帯端末にインストールされると，所定のアクセス先にアクセスして情報を取得し，当該端末の表示部に表示させるネイティブアプリケーションのテンプレートである。テンプレートアプリケーション１１１は，設定情報１１２と，１以上のプログラムファイル１１３とを含んでおり，記憶部１１の所定のフォルダ内に格納されている。テンプレートアプリケーション１１１は，インストールされる端末のＯＳに対応して複数種類記憶されている。
【００３０】設定情報１１２は，ネイティブアプリケーションのアクセス先，メニュー画面情報，及び表示態様情報に係る設定項目が含まれている。
メニュー画面情報に係る設定項目には，ネイティブアプリケーションのメニュー画面に用いられるメニュー画像と，ネイティブアプリケーションのメニュー画面に表示させるリンク先とが含まれている。
【００３１】表示態様とは，背景色，フォントの形状及びアイコン画像の形状等であり，ネイティブアプリケーションの表示態様情報に係る設定項目には，背景色，フォント及びアイコン画像を選択する項目が含まれている。背景色は，ネイティブアプリケーションが端末の表示部に情報を表示させる際の背景色であり，アイコン画像は，ネイティブアプリケーションのアイコンを示す画像である。
【００３２】１以上のプログラムファイル１１３は，例えば，汎用性の高い複数の関数プログラムをまとめたライブラリファイルや，設定情報１１２の各設定項目に基づいて情報を取得するためのプログラムファイル等から構成されている。【００３３】受付部１２は，開発用端末２から，ウェブアプリケーションのアドレスとともに，ネイティブアプリケーションの生成要求を示すリクエストを受け付ける。具体的には，受付部１２は，まず，開発用端末２から，リクエスト用ページの取得要求を受け付けると，リクエスト用ページを開発用端末２に送信する。図３は，第１の実施形態に係る開発用端末２の表示部２３に表示されたリクエスト用ページ３０の一例を示す図である。
【００３４】図３に示すように，リクエスト用ページ３０には，入力欄として，ネイティブアプリケーションがアクセスするウェブアプリケーションのロケーションを示すアドレスの入力欄３１，ネイティブアプリケーションのメニュー画面に用いられるメニュー画像の入力欄３２，及びネイティブアプリケーションのメニュー画面に表示されるリンク先の入力欄３３が設けられている。ここで，入力欄３２及び入力欄３３は，複数設けられていてもよいし，当該リクエスト用ページに入力欄追加ボタンを設け，当該ボタンが押下されたことに応じて追加表示されてもよい。また，リクエスト用ページ３０には，ネイティブアプリケーションの表示態様情報に係る入力欄として，背景色の入力欄３４，及びアイコン画像の入力欄３５が設けられている。
【００３５】例えば，入力欄３１には，ウェブアプリケーションのメインページのＵＲＬが入力される。メニュー画像の入力欄３２には，メニューページに表示するメニュー画像のファイルの格納先アドレスが入力され，リンク先の入力欄３３には，当該メニュー画像に対応するリンク先のページのアドレスが入力される。【００３６】背景色の入力欄３４には，カラーコード（ＲＧＢ値を十六進法で表記した文字列）や背景画像を示すアドレスが入力される。アイコン画像の入力欄３５には，画像ファイルのアドレスが入力される。ここで，入力欄３２から入力欄３５に入力する情報は，任意入力であってもよい。
【００３７】リクエスト用ページ３０には，入力欄の他に，ネイティブアプリケーションを出力するための画像である，出力ボタン３６及び３７が設けられている。出力ボタン３６は，第１種別のＯＳ用のアプリケーションを生成して出力するためのボタンであり，出力ボタン３７は，第２種別のＯＳ用のアプリケーションを生成して出力するためのボタンである。なお，リクエスト用ページ３０には，他の種別のＯＳ用のアプリケーションを生成して出力するためのボタンが設けられていてもよい。
【００３８】開発用端末２のユーザが，入力欄３１から入力欄３５に各種情報を入力し，ネイティブアプリケーションの出力ボタン３６又は３７を押下すると，開発用端末２は，ウェブアプリケーションのアドレスを含む各種情報と，ネイティブアプリケーションの生成要求を示すリクエストとを送信する。受付部１２は，開発用端末２から，ウェブアプリケーションのメインページのアドレス，メニュー画面情報，表示態様情報及びＯＳの種別を示す情報とともに，ネイティブアプリケーションの生成要求を示すリクエストを受け付ける。
【００３９】生成部１３は，受付部１２がネイティブアプリケーションの生成要求を示すリクエストを受け付けたことに応じて，テンプレートアプリケーションのアクセス先を受付部１２が受け付けたウェブアプリケーションのアドレスに設定することでネイティブアプリケーションを生成する。
【００４０】具体的には，生成部１３は，受付部１２がリクエストを受け付けたことに応じて，テンプレートアプリケーション１１１をコピーする。そして，生成部１３は，リクエストとともに受信したＯＳの種別を示す情報に基づいて，複数のテンプレートアプリケーション１１１から，当該ＯＳの種別に対応するテンプレートアプリケーション１１１を特定する。そして，生成部１３は，特定したテンプレートアプリケーション１１１が格納されている所定のフォルダをコピーすることで，テンプレートアプリケーション１１１をコピーする。
【００４１】そして，生成部１３は，コピーして新たに生成されたテンプレートアプリケーション１１１に含まれる設定情報の内容を書き換え，ネイティブアプリケーションを生成する。生成されたネイティブアプリケーションは，携帯端末にインストールされて実行されると，設定情報に含まれているウェブアプリケーションのアドレスに基づいて，ウェブアプリケーションに対応するウェブページを取得する。そして，ネイティブアプリケーションは，設定情報に含まれている表示態様情報に基づいて取得したウェブページの表示態様を変更し，携帯端末の表示部に表示させる。
【００４２】より具体的には，生成部１３は，コピーされたテンプレートアプリケーション１１１に含まれる設定情報の設定項目「ネイティブアプリケーションのアクセス先」に，受付部１２が受け付けた，ウェブアプリケーションのアドレスを設定する。
また，生成部１３は，設定情報の設定項目「表示態様情報」に，受付部１２が受け付けた表示態様情報（背景色，フォント，アイコン画像）を設定する。【００４３】また，生成部１３は，受付部１２が受け付けたメニュー画像，リンク先のアドレスに基づいて，当該リンク先のアドレスに関連付けられたメニュー画像を複数含むメニューページを生成する。生成部１３は，このメニューページを，ネイティブアプリケーションが実行された際に最初に表示されるページとしてもよい。【００４４】また，生成部１３は，受付部１２が受け付けた，ウェブアプリケーションのメインページのアドレスに基づいて，メインページを取得する。そして，生成部１３は，取得したメインページに基づいて，ウェブアプリケーションのメニュー情報を生成する。例えば，生成部１３は，取得したメインページに対応するウェブページのタグを解析し，重要度の高いリンクを抽出する。そして，生成部１３は，抽出した重要度の高いリンクに含まれるメニュー情報を生成する。ここで，メニュー情報は，グローバルナビゲーションであり，ネイティブアプリケーションを介して表示される各ウェブページとともに表示される情報である。例えば，メニュー情報は，ネイティブアプリケーションを介して表示されたウェブアプリケーションのページの上部に付加される。端末のユーザは，ネイティブアプリケーションを介して表示されたウェブアプリケーションの各ページにおいて，グローバルナビゲーションに含まれる複数のリンクのいずれかを選択することにより，当該リンク先のウェブページに容易にアクセスすることができる。
【００４５】変換部１４は，生成部１３が生成したネイティブアプリケーションを構成する設定情報と，１以上のプログラムファイルとを，端末がインストール可能な形式のファイルに変換する。具体的には，変換部１４は，生成部１３がネイティブアプリケーションを生成すると，当該ネイティブアプリケーションの設定情報及び１以上のプログラムファイルを格納している所定のフォルダを所定の方式で圧縮し，端末がインストール可能な形式のファイルに変換する。以下，変換したファイルをネイティブアプリケーションファイルともいう。
【００４６】送信部１５は，ネイティブアプリケーションファイルを所定の記憶領域に格納し，当該ファイルのアドレスを表示する送信用ページを開発用端末２に送信する。図４は，第１の実施形態に係る開発用端末２の表示部２３に表示された送信用ページ４０の一例を示す図である。図４に示される送信用ページ４０は，図３に示されるリクエスト用ページにおいて，第１種別のＯＳ用のアプリケーションを出力するための出力ボタン３６が押下されたときの表示例を示す。図４に示されるように，送信用ページ４０には，第１種別のＯＳ用のアプリケーションが生成された旨を示す情報と，当該第１種別のＯＳ用のアプリケーションをダウンロードするための画像であるダウンロードボタン４１とが表示されている。送信部１５は，開発用端末２において，送信用ページ４０に設けられているダウンロードボタン４１が押下されると，生成したネイティブアプリケーションファイルを開発用端末２に送信する。
【００５０】［処理フロー］続いて，アプリケーション生成装置１の処理の流れについて説明する。図５は，第１の実施形態に係るアプリケーション生成装置１において，ネイティブアプリケーションが開発用端末２に送信されるまでの処理の流れの一例を示すフローチャートである。
【００５１】まず，受付部１２は，開発用端末２からリクエストを受け付ける（Ｓ１）。具体的には，要求部２１が，アプリケーション生成装置１にリクエスト用ページ３０の取得要求を行うと，受付部１２は，開発用端末２に対してリクエスト用ページを送信し，開発用端末２から，ウェブアプリケーションのメインページのアドレス，メニュー画面情報，表示態様情報，ＯＳの種別，及びネイティブアプリケーションの生成要求を示すリクエストを受け付ける。
【００５２】続いて，生成部１３は，受付部１２がリクエストを受け付けたことに応じて，記憶部１１の所定のフォルダに記憶されているテンプレートアプリケーション１１１をコピーする（Ｓ２）。ここで，生成部１３は，Ｓ１において受け付けたＯＳの種別に対応したテンプレートアプリケーション１１１をコピーする。【００５３】続いて，生成部１３は，Ｓ１において受け付けたウェブアプリケーションのメインページのアドレス，メニュー画面情報，表示態様情報に基づいて，Ｓ２においてコピーしたテンプレートアプリケーション１１１を構成する設定情報の内容を書き換える（Ｓ３）。これにより，コピーされたテンプレートアプリケーション１１１は，ネイティブアプリケーションになる。
【００５４】続いて，変換部１４は，Ｓ３において生成部１３が生成したネイティブアプリケーションの設定情報及び１以上のプログラムファイルを格納している所定のフォルダを所定の方式で圧縮し，ネイティブアプリケーションファイルに変換する（Ｓ４）。
【００５５】続いて，送信部１５は，ネイティブアプリケーションを開発用端末２に送信する（Ｓ５）。具体的には，送信部１５は，ネイティブアプリケーションファイルの格納先のアドレス及びダウンロードボタンを表示する送信用ページを開発用端末２に送信し，開発用端末２において，当該ダウンロードボタンが押下されると，ネイティブアプリケーションファイルを開発用端末２に送信する。
【００５６】［第１の実施形態における効果］以上，第１の実施形態によれば，アプリケーション生成装置１は，記憶部１１が，ネイティブアプリケーションのテンプレートであるテンプレートアプリケーション１１１を記憶し，受付部１２が，ウェブアプリケーションのアドレスとともに，ネイティブアプリケーションの生成要求を示すリクエストを受け付け，生成部１３が，リクエストを受け付けたことに応じて，テンプレートアプリケーション１１１のアクセス先を受付部１２が受け付けたアドレスに設定することでネイティブアプリケーションを生成する。
【００５７】このようにすることで，アプリケーション生成装置１は，生成部１３がテンプレートアプリケーション１１１のアクセス先を，受付部１２が受け付けたウェブアプリケーションのアドレスに設定することで，当該テンプレートアプリケーションを，ウェブアプリケーションが表示する情報を表示するネイティブアプリケーションとして機能させることができる。したがって，アプリケーション生成装置１は，受付部１２がウェブアプリケーションのアドレスを受け付けることで，当該ウェブアプリケーションと同等の機能を有するネイティブアプリケーションを容易に生成することができる。
【図１】
【図２】
【図３】
【図４】
【図５】
(2) 引用文献２には，以下のとおりの記載がある（甲２）。
ア 「７．２カメラの利用
カメラは，アプリケーション制作者がもっとも使いたいと思うハードウェアの一つでしょう。カメラの機能は，単にその機能を呼び出すだけでなく，取り出される映像の処理まで含めた知識が必要です。ここでその基本的な処理の仕方を身につけていきましょう。
７．２．１カメラの利用とパーミッション
カメラも，アプリケーション内から利用できると応用範囲がグッと広がるハードウェア機能です。単に写真を撮影するだけでなく，ＡＲ（拡張現実）などのアプリにもカメラは利用されています。カメラ機能を利用したアプリというのは意外に多いのです。
このカメラ機能は，もちろんアプリケーション内から利用することができます。ただし，単に必要なソースコードを書けばＯＫというわけではないので注意が必要です。
カメラを利用するためには，アプリケーションに「パーミッション（アクセス権）」を用意する必要があります。これは，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌに記述します。ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌを開き，＜ｍａｎｉｆｅｓｔ＞タグ内の適当なところに以下のタグを追記してください（よくわからなければ，最初の＜ｍａｎｉｆｅｓｔ＞の後を改行して記述してください）。
リスト７．４
＜ｕｓｅｓ－ｐｅｒｍｉｓｓｉｏｎａｎｄｒｏｉｄ：ｎａｍｅ＝”ａｎｄｒｏｉｄ．ｐｅｒｍｉｓｓｉｏｎ．ＣＡＭＥＲＡ”／＞
＜ｕｓｅｓ－ｐｅｒｍｉｓｓｉｏｎａｎｄｒｏｉｄ：ｎａｍｅ＝”ａｎｄｒｏｉｄ．ｐｅｒｍｉｓｓｉｏｎ．ＷＲＩＴＥ＿ＥＸＴＥＲＮＡＬ＿ＳＴＯＲＡＧＥ”／＞
＜ｕｓｅｓ－ｆｅａｔｕｒｅａｎｄｒｏｉｄ：ｎａｍｅ＝”ａｎｄｒｏｉｄ．ｈａｒｄｗａｒｅ．ｃａｍｅｒａ”／＞
これがカメラを利用する上で最低限必要なタグです。これらはそれぞれ以下のような役割を果たしています。
■＜ｕｓｅｓ－ｐｅｒｍｉｓｓｉｏｎ＞タグ
アプリケーションが必要とする許可を指定するものです。これはアプリケーションをインストールする際にチェックされます。
アプリケーションをインストールする際，「以下のアクセス許可を必要としています」といった表示が現れることがあります。あれは，実はこの＜ｕｓｅｓ－ｐｅｒｍｉｓｓｉｏｎ＞タグで記述されているものなのです。これにより，インストール時にアプリケーションが必要とするアクセス許可が表示され，ユーザーがそれを許可するとインストールされるようになります。
機能によっては，ユーザーが「これは勝手に使われたくないな」と思うようなこともあります。そこで，この＜ｕｓｅｓ－ｐｅｒｍｉｓｓｉｏｎ＞タグにより「このアプリはこれこれの重要な機能を使いますが，許可しますか？」ということを明記し，ユーザーがそれを許可しないとインストールできないようにしているのです。■＜ｕｓｅｓ－ｆｅａｔｕｒｅ＞タグ
アプリケーションで必要とする機能を指定するものです。＜ｕｓｅｓ－ｐｅｒｍｉｓｓｉｏｎ＞タグと異なり，これはユーザーが許可をするようなものではありません。これは，アプリケーションヘのインストールが可能かどうかを決めるのに利用されます。
例えば，この＜ｕｓｅｒｓ－ｆｅａｔｕｒｅ＞でカメラを指定してあれば，そのアプリはカメラ機能がない端末にはインストールできなくなります。つまり「これこれの機能が用意されている端末でないと動かない」ということを指定するためのものなのです。
ここでは，＜ｕｓｅｓ－ｐｅｒｍｉｓｓｉｏｎ＞にａｎｄｒｏｉｄ．ｐｅｒｍｉｓｓｉｏｎ．ＣＡＭＥＲＡ，＜ｕｓｅｓ－ｆｅａｔｕｒｅ＞にａｎｄｒｏｉｄ．ｈａｒｄｗａｒｅ．ｃａｍｅｒａを指定しています。これにより，このアプリはカメラが搭載されている端末でのみ動作すること，カメラ機能を利用するための許可が必要であることが指定されていたのですね。
また，ＷＲＩＴＥ＿ＥＸＴＥＲＮＡＬ＿ＳＴＯＲＡＧＥというのは，外部ストレージヘの書き出しを許可するものです。イメージの保存を行うため，これも用意しておきましょう。」（３５６頁１５行～３５７頁３１行）
イ 「７．３．３ＧＰＳ利用のパーミッション設定
では，実際にＧＰＳを利用したサンプルを作ってみましょう。まず最初に行うのは，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌの変更です。
ＧＰＳも，やはりパーミッション関係の情報を用意しなければ利用できないようになっています。ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌを開き，＜ｍａｎｉｆｅｓｔ＞タグ内に以下のタグを追加してください。
リスト７．８
＜ｕｓｅｓ－ｐｅｒｍｉｓｓｉｏｎａｎｄｒｏｉｄ：ｎａｍｅ＝”ａｎｄｒｏｉｄ．ｐｅｒｍｉｓｓｉｏｎ．ＡＣＣＥＳＳ＿ＦＩＮＥ＿ＬＯＣＡＴＩＯＮ”／＞＜ｕｓｅｓ－ｆｅａｔｕｒｅａｎｄｒｏｉｄ：ｎａｍｅ＝”ａｎｄｒｏｉｄ．ｈａｒｄｗａｒｅ．Ｌｏｃａｔｉｏｎ”／＞
＜ｕｓｅｓ－ｆｅａｔｕｒｅａｎｄｒｏｉｄ：ｎａｍｅ＝”ａｎｄｒｏｉｄ．ｈａｒｄｗａｒｅ．Ｌｏｃａｔｉｏｎ．ｇｐｓ”／＞
＜ｕｓｅｓ－ｆｅａｔｕｒｅａｎｄｒｏｉｄ：ｎａｍｅ＝”ａｎｄｒｏｉｄ．ｈａｒｄｗａｒｅ．Ｌｏｃａｔｉｏｎ．ｎｅｔｗｏｒｋ”／＞
最初の＜ｕｓｅｓ－ｐｅｒｍｉｓｓｉｏｎ＞では，ＡＣＣＥＳＳ＿ＦＩＮＥ＿ＬＯＣＡＴＩＯＮへのパーミッションを設定しています。これにより，ユーザーが位置情報へのアクセスを許可しないとアプリがインストールできないようになります。残る３つのタグは，＜ｕｓｅｓ－ｆｅａｔｕｒｅ＞タグです。すなわち，これらの機能を内蔵するＡｎｄｒｏｉｄ端末にしかインストールできないようにするものです。これにより，ＧＰＳやネットワーク機能がない端末にはアプリケーションをインストールできないようになります。
これらのタグは，ＧＰＳ利用には必須のものと考え，必ず用意してください。」（３６８頁１１行～２９行）
(3) 引用文献３には，以下のとおりの記載がある（甲３，乙１）。
ア 「第７章ＨＴＭＬ５＋ＪａｖａＳｃｒｉｐｔでアプリ開発
はじめてのＰｈｏｎｅＧａｐ（その１）
ここまでできる
ＰｈｏｎｅＧａｐ」（６６頁表題）
イ 「ＰｈｏｎｅＧａｐを利用すると，ｉＰｈｏｎｅやＡｎｄｒｏｉｄ，ＷｉｎｄｏｗｓＰｈｏｎｅなどのマルチプラットホームに対応するアプリを作成できます．特にＧＰＳなどのネイティブ機能にアクセスできる点が注目されています．」（６６頁副題）
ウ 「現在同じコードから複数のプラットホームにアプリを生成できる表１のようなフレームワークがあります．
ここでは，数あるフレームワークの中からＰｈｏｎｅＧａｐを紹介します（図１）．」（６６頁中欄下から２行～右欄３行）
エ 「ＰｈｏｎｅＧａｐでできること
ＰｈｏｎｅＧａｐでできることは，以下の通りです．
①ＨＴＭＬ５＋ＣＳＳ＋ＪａｖａＳｃｒｉｐｔを使用してネイティブアプリを作成
②プラグインの仕組みを使って，カメラやＧＰＳなど端末のネイティブ部分にアクセス可能
③ｉＯＳ，Ａｎｄｒｏｉｄ，ＢｌａｃｋＢｅｒｒｙ，ＷｅｂＯＳ，ＷｉｎｄｏｗｓＰｈｏｎｅ７，Ｓｙｍｂｉａｎ，Ｂａｄａ向けにアプリを作成できる①から分かるように，アプリを作るために必要な知識は，Ｗｅｂに関係する技術のみになります．
もっとも注目すべき特徴は②のプラグインの仕組みがあることです．通常，ＨＴＭＬ５やＪａｖａｓｃｒｉｐｔだけでは，スマートフォンで実現できないことがたくさんあります．例えば，ＡｎｄｒｏｉｄのＩｎｔｅｎｔ機能を使うにはネイティブの実装が必要です．そういった部分をプラグインがカバーすることで，ネイティブの機能を使ってより良いアプリを作ることができます．」（６６頁右欄１３行～６７頁左欄１３行）
オ 「ＰｈｏｎｅＧａｐを使って，
地図とＧＰＳを組み合わせる
ＰｈｏｎｅＧａｐのすばらしさを体験するのに，地図とＧＰＳを組み合わせたアプリを例に紹介します．
ここでは，ＧｏｏｇｌｅＭａｐｓＪａｖａＳｃｒｉｐｔＡＰＩＶ３（ｈｔｔｐ：／／以下略）を使ってスマートフォン上に地図を表示します．さらに，ＰｈｏｎｅＧａｐの「Ｇｅｏｌｏｃａｔｉｏｎ」を使用して，現在位置にマーカーを表示します．
リスト４のソースを用意し，先ほど作成したプロジェクトのｉｎｄｅｘ．ｈｔｍｌと置き換えます．マーカー用の２０ピクセルの画像をｐｉｎ．ｐｎｇという名前で用意します．
各プラットホームでビルドし，実行すると，ｉＰｈｏｎｅ（図１４），Ａｎｄｒｏｉｄ（図１５），ＷｉｎｄｏｗｓＰｈｏｎｅ（図１６）のように現在値の地図と，現在値のマーカーが表示されます．また，地図をタップするとタップした場所にマーカーが表示されます．
●仕組み
作成したリスト４を解説します．
＜ｓｃｒｉｐｔｔｙｐｅ＝”ｔｅｘｔ／ｊａｖａｓｃｒｉｐｔ”の部分でＧｏｏｇｌｅＭａｐのｊｓファイルを読み込んでいます．パラメータｓｅｎｓｏｒはＧＰＳがある端末の場合は，ｔｒｕｅを設定します．それ以外の場合は，ｆａｌｓｅを設定します．アプリのターゲットであるスマートフォンではＧＰＳを搭載しているのでｔｒｕｅと設定しています．」（７０頁右欄６行～７２頁左欄２５行）
(4) 引用文献４には，以下のとおりの記載がある（甲４）。
ア 「ソースコード，リソース，設定，ライブラリ
・・・
設定ファイルは，そのアプリのアプリ名やバージョン，対応言語（英語や日本語ｅｔｃ．）などを記述しておくファイルです。中身は細かな項目が多いといえます。一見，そのような情報はソースコードに記述しておけば良いのではないかと思ってしまいますが，設定ファイルとして独立させておくことで，ｉＯＳやＡｎｄｒｏｉｄはそのアプリがどのような属性を持つアプリなのかをすぐに把握できるようになるわけです。」（１０頁右欄２行～１１頁左欄６行）
イ 「設定ファイル「ｉｏｓ＿ｓａｍｐｌｅ－Ｉｎｆｏ．ｐｌｉｓｔ」(5)のｉｏｓ＿ｓａｍｐｌｅ－Ｉｎｆｏ．ｐｌｉｓｔはアプリの設定ファイルです。アプリの名前やバージョン，そのアプリが利用するＳｔｏｒｙｂｏａｒｄのファイル等の情報が記述されています。ｉＯＳは（５）を読み取ることで，それらの情報を取得します。」（１４頁左欄下から２行～右欄４行）
ウ 「超重要な設定ファイル「ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌ」(5)のＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌは，頻繁に編集することになる超重要な設定ファイルです（図１４）。この中ではアプリの名前やアイコン，対応するＡｎｄｒｏｉｄのバージョン，起動時に実行する○○Ａｃｔｉｖｉｔｙクラス，そのアプリをネットワークに接続できるようにするか？，ＳＤカードにファイルを保存できるようにするか？などの，様々な項目を設定します。」（１６頁右欄下から８行～末行）
(5) 引用文献５には，以下のとおりの記載がある（甲５，乙２）。
ア 「ＪａｖａＳｃｒｉｐｔ／ＨＴＭＬ５＋ＰｈｏｎｅＧａｐの
組み合わせが一番
スマホアプリの作り方といっても，実はいろいろな方法があります（図１）。それらはいずれも一長一短で，快適に動くアプリを作れるけれど作り方が難しい方法もあれば，簡単にアプリを作れるけれど使い勝手の良いアプリは作りづらい方法もあります。
日経ソフトウエア編集部では，様々ある方法を「ハードルが一番低そうなものはどれか？」という点で吟味しました。その結果，この特集記事では「ＪａｖａＳｃｒｉｐｔとＨＴＭＬ５＋ＰｈｏｎｅＧａｐの組み合わせ」を採用することにしました。
ＪａｖａＳｃｒｉｐｔとＨＴＭＬ５は，主にＷｅｂページで使われるテクノロジーです。Ｗｅｂブラウザとテキストエディタさえあればすぐにプログラミングができるので，ハードルは低いと言えるでしょう。
ＰｈｏｎｅＧａｐ（フォンギャップ）はＪａｖａＳｃｒｉｐｔとＨＴＭＬ５のプログラムをスマホアプリ化する無償のソフトウエアです。Ａｎｄｒｏｉｄ版もｉＯＳ版もあります。
要するに，ＪａｖａＳｃｒｉｐｔとＨＴＭＬ５＋ＰｈｏｎｅＧａｐは，最もとっつきやすく，それでいてちゃんとしたアプリを作れる組み合わせなのです。」（１６頁左欄７行～２７行）
イ 「ステップ４
横画面に固定する
スマートフォンでは端末が縦の姿勢のときと，横の姿勢のときで画面が切り替わります。ただ，ゲームでは画面が切り替わらない方が望ましいので，ここでは横画面に固定する設定を施します。
Ａｎｄｒｏｉｄでは，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌに「ａｎｄｒｏｉｄ：ｓｃｒｅｅｎＯｒｉｅｎｔａｔｉｏｎ＝”ｌａｎｄｓｃａｐｅ”」の１行を追加します（図５）。
ｉＯＳでは，左側のリストの青いアイコンのプロジェクト名（ＭａｔａｔａｂｉＰａｋｋｕｎ）を選択すると，その右側に「ＴＡＲＧＥＴＳ」という項目が現れるので，その下にある「ＭａｔａｔａｂｉＰａｋｋｕｎ」を選びます。すると，プロジェクトの各種設定が表示されます。この中に「ＳｕｐｐｏｒｔｅｄＤｅｖｉｃ
ｅ Ｏｒｉｅｎｔａｔｉｏｎｓ」という項目があるので，「ＬａｎｄｓｃａｐｅＬｅｆｔ」か「ＬａｎｄｓｃａｐｅＲｉｇｈｔ」を選びます。
これで，画面を横向きに固定できます。なお，ここでいうｏｒｉｅｎｔａｔｉｏ
ｎ は「方向」，ｌａｎｄｓｃａｐｅは「横方向」という意味です。」（２９頁左欄１～１６行）
ウ 「ステップ４
縦画面に固定する
この電子書籍アプリは縦画面に固定します。そこで図６の設定を施してください。Ａｎｄｒｏｉｄでは，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌに「ａｎｄｒｏｉｄ：ｓｃｒｅｅｎＯｒｉｅｎｔａｔｉｏｎ＝”ｐｏｒｔｒａｉｔ”」の１行を追加します。ｉＯＳでは，「ＳｕｐｐｏｒｔｅｄＤｅｖｉｃｅＯｒｉｅｎｔａｔｉｏｎｓ」の項目で「Ｐｏｒｔｒａｉｔ」を選びます。なお，ｐｏｒｔｒａｉｔはここでは「縦方向」の意味です。」（３６頁左欄下から１０行～末行）
(6) 参考文献１には，以下のとおりの記載がある（甲８）。
ア 「３Ｄグラフィクスと
加速度センサ
今回のサンプルアプリケーションは，加速度センサとＯｐｅｎＧＬＥＳを用いた３Ｄグラフィクス描画，それに，前のセクションで解説した音声再生を組み合わせたものになります（図１）。
サンプルアプリケーションを起動すると，３Ｄグラフィクス界ではおなじみのティーポットの３Ｄモデルが表示されます。端末を傾けると視点が変化して，見る向きを変えることができます。また，画面をタッチして左右に指を動かすと，ティーポットを回転させることができます。音声は画面をタップすると再生を開始し，再生している間はティーポットの色が変わります。
なお，ネイティブコードのみで実装する関係で，対象となるデバイスはＧｉｎｇｅｒｂｒｅａｄ（Ａｎｄｒｏｉｄ２．３），ＮＤＫはＲｅｖｉｓｉｏｎ５以降が対象となります。
それでは，今回もすべてのソースコードを含むプロジェクトファイルは，「ＳｏｆｔｗａｒｅＤｅｓｉｇｎ」２０１１年８月号の解説記事「Ａｎｄｒｏｉｄエンジニアからの招待状」のサポートページ（ｈｔｔｐ：／／以下略）からダウンロードできますので，そちらをご覧いただきながら本稿を読み進めてもらえればと思います。
センサからの値の取得
デバイスに搭載されている各種センサの値をネイティブコードからも取得することができます。今回は表示するティーポットの向きを決めるために加速度センサを使って重力の方向を求めます。
センサに関するＡＰＩと定数の定義はｉｎｃｌｕｄｅ／ａｎｄｒｏｉｄ／ｓｅｎｓｏｒ．ｈにあります。」（１５７頁左欄１行～右欄末行）
イ 「■ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌ
加速度センサでデバイスの傾きを取得するため，傾けた際に画面のオリエンテーションが変わらないように，ａｎｄｒｏｉｄ：ｓｃｒｅｅｎＯｒｉｅｎｔａｔｉｏ
ｎ ＝”ｐｏｒｔｒａｉｔ”を追加してｐｏｒｔｒａｉｔで固定します。＜ａｃｔｉｖｉｔｙａｎｄｒｏｉｄ：ｎａｍｅ＝
”ａｎｄｒｏｉｄ．ａｐｐ．ＮａｔｉｖｅＡｃｔｉｖｉｔｙ”
ａｎｄｒｏｉｄ：ｌａｂｅｌ＝
”＠ｓｔｒｉｎｇ／ａｐｐ＿ｎａｍｅ”
ａｎｄｒｏｉｄ：ｓｃｒｅｅｎＯｒｉｅｎｔａｔｉｏｎ＝
”ｐｏｒｔｒａｉｔ”＞」（１６２頁左欄１３行～２３行）
(7) 乙３文献には，以下のとおりの記載がある（甲７，乙３）。
ア 「ＰｈｏｎｅＧａｐは，ＨＴＭＬ５，ＣＳＳ３，ＪａｖａＳｃｒｉｐｔなどのＷｅｂ標準技術を用いてｉＯＳやＡｎｄｒｏｉｄなどのスマートフォン向けのネイティブアプリを開発するためのフレームワークです。」（１５５頁左欄１０行～１４行）
イ 「カメラアプリの作成
ここからはＨＴＭＬファイルを１つ作成して，各ＯＳで動作することを確認します。今回はカメラで写真を撮影（もしくは，すでにある写真から選択）して，写真を画面に表示するカメラアプリを作ってみます。
ｉｎｄｅｘ．ｈｔｍｌファイルの作成
自分の好きなエディタを使って，リスト３のｉｎｄｅｘ．ｈｔｍ１ファイルを作成します。ｊＱｕｅｒｙとｊＱｕｅｒｙＭｏｂｉｌｅのファイルを使用していますので，必要なファイルをｊＱｕｅｒｙのＷｅｂサイトから取得して展開しておいてください。
ポイントは，ＪａｖａＳｃｒｉｐｔ部分のｃａｐｔｕｒｅＰｈｏｔｏ（）関数とｇｅｔＰｈｏｔｏ（）関数の中です。ｎａｖｉｇａｔｏｒ．ｃａｍｅｒａ～とあるのは，ＰｈｏｎｅＧａｐのライブラリの関数を使用しています。
ＰｈｏｎｅＧａｐ側では，ネイティブの対応する機能を呼び出します。ここでは，カメラの撮影機能とギャラリー機能を呼び出しています（実際に呼び出されるアプリは，ＯＳによって異なります）。
これ以外にもＪａｖａＳｃｒｉｐｔでＰｈｏｎｅＧａｐのＡＰＩを呼び出せば，センサーやＧＰＳの機能を使うことができます。
これでカメラアプリを作成する準備が整いました。
ｉＯＳ編
作成したｉｎｄｅｘ，ｈｔｍｌファイルやｊＱｕｅｒｙ関連のファイルを，ＨｅｌｌｏＷｏｒｌｄ作成時に作ったＸｃｏｄｅのプロジェクトの中に入れます。ｗｗｗフォルダの下にはｉｎｄｅｘ．ｈｔｍ１ファイルがすでに存在していますので，作成したファイルで置き換えます。
置き換えたらＸｃｏｄｅの実行ボタンを押して起動してみましょう。図１０のような画面が表示されれば成功です。エミュレータの場合カメラは起動しませんが，その際はエラーが出ていることを確認できるかと思います。
ｉＰｈｏｎｅやｉＰａｄで実行するとカメラで写真を撮って，画面に表示するのを確認できます。」（１５９頁左欄１行～右欄４行）
ウ 「Ａｎｄｒｏｉｄ編
Ｅｃｌｉｐｓｅを起動して，先ほどのＨｅｌｌｏＷｏｒｌｄプロジェクトのａｓｓｅｔｓ／ｗｗｗフォルダの中に「ｉｎｄｅｘ．ｈｔｍｌ」やｊＱｕｅｒｙ関連のファイルをコピーします。実行ボタンを押して実行すると，ｉＯＳの環境と同じように動いていることが確認できます（図１１）。」（１６０頁右欄１行～７行）
３ 取消事由１（独立特許要件違反の有無―本件補正発明の進歩性の有無）について
(1) 本件補正発明と引用発明との一致点及び相違点
ア 前記２(1)で認定した引用文献１の記載からすると，引用発明の構成は以下のとおり認められる。
「アプリケーション生成装置１と開発用端末２とがインターネット等のネットワークＮを介して通信可能に接続され，スマートフォン等の携帯端末にインストールされるアプリケーションプログラムであるネイティブアプリケーションを生成するアプリケーション生成システムであって，
アプリケーション生成装置１は，記憶部１１と，受付部１２と，生成部１３と，変換部１４と，送信部１５とを備え，
記憶部１１は，ネイティブアプリケーションのテンプレートであるテンプレートアプリケーション１１１を記憶し，
ここで，テンプレートアプリケーション１１１は，スマートフォン等の携帯端末にインストールされると，所定のアクセス先にアクセスして情報を取得し，当該端末の表示部に表示させるネイティブアプリケーションのテンプレートであり，テンプレートアプリケーション１１１は，設定情報１１２と，１以上のプログラムファイル１１３とを含んでいて，記憶部１１の所定のフォルダ内に格納されており，
受付部１２は，開発用端末２から，リクエスト用ページ３０の取得要求を受け付けると，リクエスト用ページ３０を開発用端末２に送信し，
ここで，リクエスト用ページ３０には，入力欄として，ネイティブアプリケーションがアクセスするウェブアプリケーションのロケーションを示すアドレスの入力欄３１が設けられ，また，ネイティブアプリケーションの表示態様情報に係る入力欄として，背景色の入力欄３４，及びアイコン画像の入力欄３５が設けられており，入力欄３１には，ウェブアプリケーションのメインページのＵＲＬが入力され，背景色の入力欄３４には，カラーコードや背景画像を示すアドレスが入力され，アイコン画像の入力欄３５には，画像ファイルのアドレスが入力され，
受付部１２が，開発用端末２から，ウェブアプリケーションのメインページのアドレス，及び表示態様情報とともに，ネイティブアプリケーションの生成要求を示すリクエストを受け付けると，生成部１３は，コピーして新たに生成されたテンプレートアプリケーション１１１に含まれる設定情報の内容を，受付部１２が受け付けたウェブアプリケーションのメインページのアドレス，及び表示態様情報に基づいて書き換えてネイティブアプリケーションを生成し，
ここで，生成されたネイティブアプリケーションは，携帯端末にインストールされて実行されると，設定情報に含まれているウェブアプリケーションのアドレスに基づいて，ウェブアプリケーションに対応するウェブページを取得し，設定情報に含まれている表示態様情報に基づいて取得したウェブページの表示態様を変更して，携帯端末の表示部に表示させるものであり，
変換部１４は，生成部１３がネイティブアプリケーションを生成すると，当該ネイティブアプリケーションの設定情報及び１以上のプログラムファイルを格納している所定のフォルダを所定の方式で圧縮し，端末がインストール可能な形式のネイティブアプリケーションファイルに変換し，
送信部１５は，ネイティブアプリケーションファイルを所定の記憶領域に格納し，当該ファイルのアドレスを表示する送信用ページを開発用端末２に送信し，開発用端末２において，送信用ページ４０に設けられているダウンロードボタン４１が押下されると，生成したネイティブアプリケーションファイルを開発用端末２に送信する，
アプリケーション生成システム。」
イ 前記第２の２(2)で認定した本件補正発明の構成と前記アの引用発明の構成を比較すると，両発明の一致点及び相違点は以下のとおりとなる。(ｱ) 一致点
「携帯通信端末の所定の機能を実行させるためのパラメータに応じて，前記携帯通信端末において実行されるアプリケーションの動作を規定する設定ファイルを設定する設定部と，
前記設定ファイルに基づいてアプリケーションパッケージを生成する生成部と，を有するアプリケーション生成支援システム」である点。
(ｲ) 相違点
ａ 相違点１
設定ファイルを設定するパラメータが，
本件補正発明では，「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」であるのに対して，
引用発明では，携帯通信端末の機能を実行させるためのパラメータではあるものの，携帯通信端末に固有のネイティブ機能を実行させるためのパラメータであることが特定されていない点。
ｂ 相違点２
設定ファイルが，
本件補正発明では，「アプリケーションの，携帯通信端末の動きに伴う動作」を規定する「設定ファイル」であるのに対して，
引用発明では，「設定情報」が，ネイティブアプリケーションのウェブページ取得動作や表示動作を規定するものの，「携帯端末の動きに伴う」動作を規定するものであることが特定されていない点。
(2) 相違点１についての判断
本件審決は，引用発明に引用文献２～５及び参考文献１記載の技術（同技術に乙３文献記載の技術を併せて，以下「被告主張周知技術」という。）を適用することにより，本件補正発明に想到し得ると判断していることから，引用発明に被告主張周知技術を適用する動機付けの有無について検討する。
ア 引用発明
前記２(1)のとおり，引用文献１には，「近年，コンテンツマネジメントシステム（以下，ＣＭＳ（ＣｏｎｔｅｎｔＭａｎａｇｅｍｅｎｔＳｙｓｔｅｍ）という）によりウェブアプリケーションとして公開するコンテンツを構築し，管理することが行われている（例えば，特許文献１参照）。ところで，近年，ネイティブアプリケーションをダウンロードしてインストールすることができるスマートフォンが普及している。スマートフォンのユーザは，ネイティブアプリケーションをインストールする場合，アプリケーションを提供する所定のアプリケーションサーバにアクセスし，所望のネイティブアプリケーションを検索する。しかしながら，ＣＭＳによって構築されるウェブアプリケーションは，ウェブサイトとして構築されるため，検索サイトの検索結果として表示されることがあるものの，アプリケーションサーバから検索することができない。したがって，アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに，ＣＭＳにより開発したウェブアプリケーションを利用してもらうことができないという問題がある。これに対して，ＣＭＳによって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを開発し，当該ネイティブアプリケーションをアプリケーションサーバにアップロードすることも考えられる。しかしながら，ネイティブアプリケーションを新規に開発するには，多大な開発工数が必要であった。本発明は，ネイティブアプリケーションを容易に生成することができるアプリケーション生成装置，アプリケーション生成システム及びアプリケーション生成方法を提供することを目的とする。」（段落【０００２】，【０００４】～【０００７】）と記載されており，同記載からすると，引用発明は，ＣＭＳによって構築されるウェブアプリケーションは，アプリケーションサーバから検索することができないため，アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに，ＣＭＳにより開発したウェブアプリケーションを利用してもらうことができないこと及びＣＭＳによって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを新規に開発するには，多大な開発工数が必要となることを課題とし，同課題を解決するためのネイティブアプリケーションを生成する装置であることが認められる。
引用発明は，上記課題を解決するために，前記(1)アで認定したとおり，既存のウェブアプリケーションのロケーションを示すアドレスや所望の背景画像を示すアドレス等の情報を入力するだけで，当該ウェブアプリケーションの表示態様を変更して，同ウェブアプリケーションが表示する情報を表示するネイティブアプリケーションを生成できるようにしたものと認められる。
イ 被告は，携帯通信端末の動きに伴う動作を行うネイティブアプリケーションを生成すること，特に，ＰｈｏｎｅＧａｐに係る技術が周知であると主張する。(ｱ) 前記アのとおり，引用発明は，アプリケーションサーバにおいて検索できるネイティブアプリケーションを簡単に生成することを課題として，同課題を，既存のウェブアプリケーションのアドレス等の情報を入力するだけで，同ウェブアプリケーションが表示する情報を表示できるネイティブアプリケーションを生成することができるようにすることによって解決したものであるから，ブログ等の携帯通信端末の動きに伴う動作を行わないウェブアプリケーションの表示内容を表示するネイティブアプリケーションを生成しようとする場合，生成しようとするネイティブアプリケーションを携帯通信端末の動きに伴う動作を行うようにする必要はなく，したがって，設定ファイルを設定するパラメータを「携帯通信端末に固有のネイティブ機能を実行するためのパラメータ」とする必要はない。もっとも，引用文献１の段落【００２４】には，ブログ等と並んで「ゲームサイト」が掲げられており，ゲームにおいては，加速度センサにより横画面と縦画面が切り替わらないように制御する必要がある場合が考えられる（引用文献５参照）が，ウェブアプリケーションとして提供されるゲームは，①常に携帯通信端末の表示画面を固定する必要があるとはいえないこと，②加速度センサにより，携帯通信端末の姿勢に対応した画面回転表示を制御する機能は携帯通信端末側に備わっており，端末側の操作によって，表示画面を固定することができ，そのような操作は一般的に行われていること，③引用文献１の段落【００２４】の「ゲームサイト」は，携帯通信端末の表示画面を固定する必要のないブログ，ファンサイト，ショッピングサイトと並んで記載されており，また，引用文献１には，加速度センサについて何らの記載もないことからすると，当業者は，上記の「ゲームサイト」の記載から，パラメータを「携帯通信端末に固有のネイティブ機能を実行するためのパラメータ」とすることの必要性を認識するとまではいえないというべきである。
また，引用発明によって生成されるネイティブアプリケーションは，ＨＴＭＬやＪａｖａＳｃｒｉｐｔで記述されるウェブページを表示できるから，引用発明により，乙４に記載されたＨＴＭＬ５ＡＰＩのＧｅｏｌｏｃａｔｉｏｎを用いて携帯通信端末の動きに伴う動作を行うウェブアプリケーションの表示内容を表示するネイティブアプリケーションを生成しようとする場合も，生成されるネイティブアプリケーションは，設定情報に含まれているウェブアプリケーションのアドレスに基づいて，同ウェブアプリケーションに対応するウェブページを取得し，取得したウェブページのＨＴＭＬやＪａｖａＳｃｒｉｐｔの記述に基づいて，同ウェブアプリケーションの内容を表示でき，したがって，ネイティブアプリケーションの生成に際して，設定ファイルを設定するパラメータを「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」とする必要はない。
さらに，被告主張周知技術に係る各種文献にも，引用発明の上記の構成の技術において，「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」に応じて設定ファイルを設定することの必要性等については何ら記載されていない（甲２～５，７，８，乙１～３）。
(ｲ) 前記アのとおり，引用発明は，簡易にネイティブアプリケーションを生成することを課題として，既存のウェブアプリケーションのアドレス等の情報を入力するだけで，当該ウェブアプリケーションが表示する情報を表示するネイティブアプリケーションを生成できるようにしたのであり，具体的には，前記(1)アのとおり，入力しようとするウェブアプリケーションのロケーションを示すアドレス及び表示態様に基づいて，テンプレートアプリケーション１１１に含まれる設定情報の内容を書き換えるだけで目的とするウェブアプリケーションの表示する情報を表示できるネイティブアプリケーションを生成でき，テンプレートアプリケーション１１１に含まれるプログラムファイル１１３については，新たにソースコードを書く必要はないところ，証拠（甲３，５，７，乙１～３）によると，ＰｈｏｎｅＧａｐによってネイティブアプリケーションを生成するためには，ＨＴＭＬやＪａｖａＳｃｒｉｐｔ等を用いてソースコード（プログラム）を書くなどする必要があるものと認められるから，引用発明に，上記のように，新たにソースコードを書くなどの行為が要求されるＰｈｏｎｅＧａｐに係る技術を適用することには阻害事由があるというべきである。
被告は，①ＰｈｏｎｅＧａｐでは，ＰｈｏｎｅＧａｐのプラグインの仕組みを使って，ＧＰＳなど端末のネイティブ部分にアクセス可能であり，端末のＧＰＳ機能にアクセスすることで，ＧＰＳで取得した端末の現在位置が中心となるように地図を表示することが可能となるから，引用発明において地図表示アプリケーションを生成する際に，ＰｈｏｎｅＧａｐのフレームワークを採用することで，ネイティブ機能であるＧＰＳ機能が利用可能となり，携帯通信端末の動きに伴う動作を設定可能となり，また，②ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌに「ａｎｄｒｏｉｄ：ｓｃｒｅｅｎＯｒｉｅｎｔａｔｉｏｎ＝”ｌａｎｄｓｃａｐｅ”」の１行を追加したり（Ａｎｄｒｏｉｄの場合），「ＬａｎｄｓｃａｐｅＲｉｇｈｔ」又は「ＬａｎｄｓｃａｐｅＬｅｆｔ」のアイコンを選択すること（ｉＯＳの場合）で，スマートフォンの画面を横画面に固定可能となり，縦画面に固定する設定を施す場合，ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌに「ａｎｄｒｏｉｄ：ｓｃｒｅｅｎＯｒｉｅｎｔａｔｉｏｎ＝”ｐｏｒｔｒａｉｔ”」の１行を追加したり（Ａｎｄｒｏｉｄの場合），「ｐｏｒｔｒａｉｔ」のアイコンを選択すること（ｉＯＳの場合）で，スマートフォンの画面を縦画面に固定可能となるから，引用発明において，アプリケーションを生成する際に，ＰｈｏｎｅＧａｐのフレームワークを利用することで，「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」に応じて，携帯通信端末において実行される「アプリケーションの，携帯通信端末の動きに伴う動作」を規定する設定ファイルを備えることとなると主張する。
しかし，上記のとおり，引用発明にＰｈｏｎｅＧａｐの技術を適用することの動機付けはないから，被告の上記主張は，その前提を欠くものであって，理由がない。(ｳ) 以上からすると，引用発明に，被告主張周知技術を適用することの動機付けは認められないというべきである。
ウ 以上のとおり，引用発明に被告主張周知技術を適用することの動機付けはないから，引用発明に被告主張周知技術を適用して，相違点１の構成について，本件補正発明の構成とすることは容易に想到することはできず，したがって，本件補正発明は，引用発明及び被告主張周知技術に基づいて容易に発明することができたということはできない。
(3) したがって，取消事由１は理由がある。
第６ 結論
よって，主文のとおり判決する。
知的財産高等裁判所第２部
裁判長裁判官
森義之
裁判官
佐野信
裁判官
熊谷大輔
出典：裁判所ウェブサイト「裁判例検索」（https://www.courts.go.jp/hanrei/88939/detail7/index.html）。本文は同サイト掲載の判決書PDFからTaiLexi AIがテキスト化・整形したもの（正確な文言は原本PDFを参照）。判示事項・裁判要旨・参照法条は裁判所の公表どおり。