判例検索β > 平成31年(行ケ)第10005号
審決取消請求事件 特許権 行政訴訟
事件番号平成31(行ケ)10005
事件名審決取消請求事件
裁判年月日令和元年9月19日
法廷名知的財産高等裁判所
裁判要旨特 判決年月日 令和元年9月19日
許 知財高裁第2部
権 事 件 番 号 平成31年(行ケ)第10005号
○ 発明の名称を「アプリケーション生成支援システムおよびアプリケーション生成支
援プログラム」とする発明に係る特許出願について,引用発明に周知技術を適用する動
機付けは認められないとして,独立特許要件違反(進歩性欠如)がないとされた事例。
(事件類型)審決(拒絶)取消 (結論)審決取消
(関連条文)特許法17条の2第6項,126条7項,29条2項
(関連する権利番号等)特願2017-124385号,不服2018-3406号
判 決 要 旨
1 本件は,発明の名称を「アプリケーション生成支援システムおよびアプリケーション
生成支援プログラム」とする本願発明についての拒絶査定不服審判請求を不成立とした審
決の取消訴訟であり,争点は,独立特許要件違反(進歩性欠如)の有無である。
2 本判決は,以下のとおり判示して,本件補正発明の進歩性を否定した審決を取り消し
た。
(1) 本件補正発明と引用発明との間には,「 設定ファイルを設定するパラメータが ,本
件補正発明では,『携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ』
であるのに対して ,引用発明では, 携帯通信端末の機能を実行させるためのパラメータで
はあるものの,携帯通信端末に固有のネイティブ機能を実行させるためのパラメータであ
ることが特定されていない」という相違点(相違点1)が存在するところ,審決は,引用
発明に引用文献2~5及び参考文献1記載の技術(同技術に乙3文献記載の技術を併せて,
以下「被告主張周知技術」という。)を適用することにより,本件補正発明に想到し得る
と判断していることから,引用発 明に被告主張周知技術を適用する動機付けの有無につい
て検討する。
(2)ア 引用発明は, ア プリケーショ ンサーバ において 検索 できる ネ イティブアプ リケー
ションを簡単に生成することを課題として,同課題を,既存のウェブアプリケーションの
アドレス等の情報を入力するだけで,同ウェブアプリケーションが表示する情報を表示で
きるネイティブアプリケーションを生成することができるようにすることによって解決し
たものであるから,ブログ等の携帯通信端末の動きに伴う動作を行わないウェブアプリケ
ーションの表示内容を表示するネイティブアプリケ ーションを生成しようとする場合, 生
成しようとするネイティブアプリケーションを携帯通信端末の動きに伴う動作を行うよう
にする必要はなく,したがって,設定ファイルを設定する パラメータを「携帯通信端末に
固有のネイティブ機能を実行するためのパラメータ」とする必要はな い。もっとも,引用
文献1の段落【0024】には,ブログ等と並んで「ゲームサイト」が掲げられており,
ゲームにおいては,加速度センサにより横画面と縦画面が切り替わらないように制御する
-1-
必要がある場合が考えられる(引用文献5参照)が, ウェブアプリケーションとして提供
されるゲームは,①常に携帯通信端末の表示画面を固定する必要があるとはいえないこと,
②加速度センサにより,携帯通信端末の姿勢に対応した画面回転表示を制御する機能は携
帯通信端末側に備わっており,端末側の操作によって,表示画面を固定することができ,
そのような操作は一般的に行われていること,③引用文献1の段落【0024】の「ゲー
ムサイト」は,携帯通信端末の表示画面を固定する必要のないブログ,ファンサイト,シ
ョッピングサイトと並んで記載されており,また,引用文献1には,加速度センサにつ い
て何らの記載もないことからすると,当業者は,上記の「ゲームサイト」の記載から,パ
ラメータを「携帯通信端末に固有のネイティブ機能を実行するためのパラメータ」とする
ことの必要性を認識するとまではいえないというべきである。
また,引用発明によって生成されるネイティブアプリケーションは,HTMLやJav
aScriptで記述されるウェブページを表示できるから,引用発明により,乙4に記
載されたHTML5 APIのGeolocationを用いて携帯通信端末の動きに伴
う動作を行うウェブアプリケーションの表示内容を表示する ネイティブアプリケーション
を生成しようとする場合も,生成されるネイティブアプリケーションは,設定情報に含ま
れているウェブアプリケーションのアドレスに基づいて,同ウェブアプリケーションに対
応するウェブページを取得し,取得したウェブページのHTMLやJavaScript
の記述に基づいて,同ウェブアプリケーションの内容を表示でき,したがって,ネイティ
ブアプリケーションの生成に際して,設定ファイルを設定するパラメータを「携帯通信端
末に固有のネイティブ機能を実行させるためのパラメータ」とする必要はない。
さらに,被告主張周知技術に係る各種文献にも,引用発明の上記の構成の技術において,
「携帯通信端末に固有のネイティブ機能を実行させるためのパラメータ」に応じて設定フ
ァイルを設定することの必要性等については何ら記載されていない(甲2~5,7,8,
乙1~3)。
イ 引用発明は,簡易にネイティブアプリケーションを生成することを課題として,
既存のウェブアプリケーションのアドレス 等の情報を入力するだけで,当該 ウェブアプリ
ケーションが表示する情報を表示する ネイティブアプリケーションを生成できるようにし
たところ,PhoneGapによ ってネイティブアプリケーションを生成するためには,
HTMLやJavaScript等を用いてソースコード(プログラム)を書くなどする
必要があるものと認められるから,引用発明に,上記のように,新たにソースコードを書
くなどの行為が要求されるPhoneGapに係る技術を適用することには阻害事由があ
る。
ウ 以上からすると,引用発明に,被告主張周知技術を適用することの動機付けは認
められないというべきである。
-2-
裁判日:西暦2019-09-19
情報公開日2019-09-30 12:00:28
戻る / PDF版
令和元年9月19日判決言渡
平成31年(行ケ)第10005号
口頭弁論終結日

審決取消請求事件

令和元年7月4日
判原決告
株式会社三菱UFJ銀行

同訴訟代理人弁護士

高雄一郎

同訴訟代理人弁理士

橋部実佑季林福被告佳永輔健司
特許庁長官

同指定代理人

泰隆平崎大進田純一英文
特許庁が不服2018-3406号事件について平成30年11月
30日にした審決を取り消す。
訴訟費用は被告の負担とする。
事実及び理由
請求

主文同旨
第2

本豊
第1

巳野2勝松1田辻主須
事案の概要

本件は,特許出願拒絶査定に対する不服審判請求を不成立とした審決の取消訴訟である。争点は,独立特許要件違反(進歩性欠如)の判断の誤りの有無である。1
特許庁における手続の経緯

原告は,発明の名称をアプリケーション生成支援システムおよびアプリケーション生成支援プログラムとする発明につき,
平成29年6月26日,
特許出願
(特
願2017-124385号。請求項の数34。甲9の1~3。以下本願という。
)をしたが,平成30年1月17日付けで拒絶査定(甲13)を受けたので,同年3月8日,拒絶査定不服審判請求をし,同審判請求は,不服2018-3406号として審理された(甲14)

原告は,同年6月19日,特許請求の範囲を補正する手続補正(請求項の数16。甲18)をし,その後,同年9月12日,特許請求の範囲を補正する手続補正(請求項の数2。甲21。以下本件補正という。
)をしたが,特許庁は,同年11月
30日,本件補正を却下した上,

本件審判の請求は,成り立たない。

との審決(以下本件審決という。
)をし,同審決謄本は,同年12月18日,原告に送達され
た。
2
特許請求の範囲の記載(甲18,21)
(1)本件補正前の本願の特許請求の範囲請求項1の記載は,次のとおりである
(同請求項に係る発明を,以下本件補正前発明という。。

通信端末に固有のネイティブ機能を実行させるためのパラメータに応じて,前記通信端末において実行されるアプリケーションの動作を規定する設定ファイルを設定する設定部と,前記設定ファイルに基づいてアプリケーションパッケージを生成する生成部と,を有するアプリケーション生成支援システム。(2)本件補正後の本願の特許請求の範囲請求項1の記載は,次のとおりである(同請求項に係る発明を,以下本件補正発明という。。

携帯通信端末に固有のネイティブ機能を実行させるためのパラメータに応じて,前記携帯通信端末において実行されるアプリケーションの,前記携帯通信端末の動きに伴う動作を規定する設定ファイルを設定する設定部と,前記設定ファイルに基づいてアプリケーションパッケージを生成する生成部と,を有するアプリケーション生成支援システム。3
本件審決の理由の要旨
(1)引用発明及び周知技術について

主引例

特許第5470500号公報(平成26年4月16日発行。以下引用文献1という。
)には,以下のとおりの発明(以下引用発明という。
)が記載されてい
る。
アプリケーション生成装置1と開発用端末2とがインターネット等のネットワークNを介して通信可能に接続され,スマートフォン等の携帯端末にインストールされるアプリケーションプログラムであるネイティブアプリケーションを生成するアプリケーション生成システムであって,アプリケーション生成装置1は,記憶部11と,受付部12と,生成部13と,変換部14と,送信部15とを備え,記憶部11は,ネイティブアプリケーションのテンプレートであるテンプレートアプリケーション111を記憶し,ここで,テンプレートアプリケーション111は,スマートフォン等の携帯端末にインストールされると,所定のアクセス先にアクセスして情報を取得し,当該端末の表示部に表示させるネイティブアプリケーションのテンプレートであり,テンプレートアプリケーション111は,設定情報112と,1以上のプログラムファイル113とを含んでいて,記憶部11の所定のフォルダ内に格納されており,受付部12は,開発用端末2から,リクエスト用ページ30の取得要求を受け付けると,リクエスト用ページ30を開発用端末2に送信し,ここで,リクエスト用ページ30には,入力欄として,ネイティブアプリケーションがアクセスするウェブアプリケーションのロケーションを示すアドレスの入力欄31が設けられ,また,ネイティブアプリケーションの表示態様情報に係る入力欄として,背景色の入力欄34,及びアイコン画像の入力欄35が設けられており,入力欄31には,ウェブアプリケーションのメインページのURLが入力され,背景色の入力欄34には,カラーコードや背景画像を示すアドレスが入力され,アイコン画像の入力欄35には,画像ファイルのアドレスが入力され,受付部12が,開発用端末2から,ウェブアプリケーションのメインページのアドレス,及び表示態様情報とともに,ネイティブアプリケーションの生成要求を示すリクエストを受け付けると,生成部13は,コピーして新たに生成されたテンプレートアプリケーション111に含まれる設定情報の内容を,受付部12が受け付けたウェブアプリケーションのメインページのアドレス,及び表示態様情報に基づいて書き換えてネイティブアプリケーションを生成し,ここで,生成されたネイティブアプリケーションは,携帯端末にインストールされて実行されると,設定情報に含まれているウェブアプリケーションのアドレスに基づいて,ウェブアプリケーションに対応するウェブページを取得し,設定情報に含まれている表示態様情報に基づいて取得したウェブページの表示態様を変更して,携帯端末の表示部に表示させるものであり,変換部14は,生成部13がネイティブアプリケーションを生成すると,当該ネイティブアプリケーションの設定情報及び1以上のプログラムファイルを格納している所定のフォルダを所定の方式で圧縮し,端末がインストール可能な形式のネイティブアプリケーションファイルに変換し,送信部15は,ネイティブアプリケーションファイルを所定の記憶領域に格納し,当該ファイルのアドレスを表示する送信用ページを開発用端末2に送信し,開発用端末2において,送信用ページ40に設けられているダウンロードボタン41が押下されると,生成したネイティブアプリケーションファイルを開発用端末2に送信する,アプリケーション生成システム。イ
周知技術
(ア)掌田津耶乃AndroidStudioではじめるdプログラミング入門wAndroid第2版AndroidStudio6.0AndroiMarshmallo1.5対応(株式会社秀和システム,平成2

7年12月27日発行)
(以下引用文献2という。甲2)の356頁~368頁
には,以下の記載がある。
a
カメラを利用するためには,アプリケーションに「パーミッション(アクセス権)を用意する必要があります。これは,AndroidManifest.xmlに記述します。AndroidManifest.xmlを開き,<manifest>タグ内の適当なところに以下のタグを追記してください・」・・
(356頁)
b
7.3.3GPS利用のパーミッション設定・・・GPSも,やはりパーミッション関係の情報を用意しなければ利用できないようになっています。AndroidManifest.xmlを開き,<manifest>タグ内に以下のタグを追加してください。(368頁)(イ)三宅理
第7章HTML5+JavaScriptでアプリ開発はじめてのPhoneGap(その1)ここまでできるPhoneGapInterface増刊SmartphoneWorld

Volume.4(CQ出版

株式会社,平成24年6月1日発行)
(以下引用文献3という。甲3,乙1)の
70頁~72頁には,以下の記載がある。
地図とGPSを組み合わせるPhoneGapのすばらしさを体験するのに,地図とGPSを組み合わせたアプリを例に紹介します。・・・スマートフォン上に地図を表示します.さらに,PhoneGapの「Geolocationを使用して,現在位置にマーカーを表示します。」
(ウ)スマホはなぜ動くのか?解説!Point1必ず悩むアプリ開発の6ポイントを徹底ファイルがわかるとスマホアプリの仕組みが見えてくる
日経ソフトウエア2013年6月号(日経BP社,平成25年4月24日発行)(以
下引用文献4という。甲4)の10頁~11頁,14頁,16頁には,以下の記載がある。
a

設定ファイルは,そのアプリのアプリ名やバージョン,対応言語(英語や日本語etc.)などを記述しておくファイルです。(10頁~11頁)

b
設定ファイル「ios_sample-Info.plist

(5)のios_sample-Info.plistはアプリの設定ファイルです。アプリの名前やバージョン,そのアプリが利用するStoryboardのファイル等の情報が記述されています。(14頁)

c
超重要な設定ファイル「AndroidManifest.xml(5)のAndroidManifest.xmlは,頻繁に編集することになる超重要な設定ファイルです(図14)
。この中ではアプリの名前やアイコン,対応
するAndroidのバージョン,
起動時に実行する○○Activityクラス,
そのアプリをネットワークに接続できるようにするか?,SDカードにファイルを保存できるようにするか?などの,様々な項目を設定します。(16頁)」
(エ)掌田津耶乃HTML5とコピペでスマホアプリ開発者デビュー!Part2いよいよデビュースワイプ可能ミニゲームを作る日経ソフトウエ
ア2012年10月号(日経BP社,平成24年8月24日発行)(以下引用文献5という。甲5,乙2)の29頁には,以下の記載がある。横画面に固定するスマートフォンでは端末が縦の姿勢のときと,横の姿勢のときで画面が切り替わります。ただ,ゲームでは画面が切り替わらない方が望ましいので,ここでは横画面に固定する設定を施します。Androidでは,AndroidManifest.xmlに「android:screenOrientation=”1andscape”の1行を追
加します(図5)

iOSでは,左側のリストの青いアイコンのプロジェクト名(MatatabiPakkun)を選択すると,その右側にTARGETSという項目が現れるので,その下にあるMatatabiPakkunを選びます。すると,プロジェクトの各種設定が表示されます。この中にSupportedeDevicOrientationsという項目があるので,
LandscapeeftかLandscapeLRightを選びます。
これで,画面を横向きに固定できます。なお,ここでいうorientationは方向
,landscapeは横方向という意味です。

(オ)Androidエンジニア養成読本現場で役立つノウハウと仕事にしたい人のための必須知識満載!(株式会社技術評論社,
平成23年11月25
日発行)
(以下参考文献1という。甲8)の157頁,162頁には,以下の記載がある。
a

サンプルアプリケーションを起動すると,3Dグラフィクス界ではおなじみのティーポットの3Dモデルが表示されます。端末を傾けると視点が変化して,見る向きを変えることができます。(157頁)

b
■AndroidManifest.xml加速度センサでデバイスの傾きを取得するため,傾けた際に画面のオリエンテーションが変わらないように,android:screenOrientation=”portrait”を追加してportraitで固定します。(162頁)(2)一致点及び相違点
本件補正発明と引用発明との一致点及び相違点は以下のとおりである。ア
一致点

携帯通信端末の所定の機能を実行させるためのパラメータに応じて,前記携帯通信端末において実行されるアプリケーションの動作を規定する設定ファイルを設定する設定部と,前記設定ファイルに基づいてアプリケーションパッケージを生成する生成部と,を有するアプリケーション生成支援システムである点。イ
相違点
(ア)相違点1

設定ファイルを設定するパラメータが,
本件補正発明では,
携帯通信端末に固有のネイティブ機能を実行させるためのパラメータであるのに対して,引用発明では,携帯通信端末の機能を実行させるためのパラメータではあるものの,携帯通信端末に固有のネイティブ機能を実行させるためのパラメータであることが特定されていない点。
(イ)相違点2
設定ファイルが,
本件補正発明では,
アプリケーションの,携帯通信端末の動きに伴う動作を規
定する設定ファイルであるのに対して,
引用発明では,
設定情報が,ネイティブアプリケーションのウェブページ取得
動作や表示動作を規定するものの,
携帯端末の動きに伴う
動作を規定するもので
あることが特定されていない点。
(3)相違点についての判断
事案に鑑み,上記相違点1及び相違点2についてまとめて検討する。ア(ア)相違点1及び相違点2は,アプリケーションの特徴に係わる点で関連しており,本件補正発明のアプリケーション生成システムが生成するアプリケーションが,
ネイティブ機能を利用するアプリケーションであって,携帯通信端末の動きに伴う動作を行うアプリケーションであるのに対して,引用発明のアプリケー
ション生成システムが生成するアプリケーションは,そのようなアプリケーションではなく,携帯端末にインストールされて実行されると,設定情報に含まれているウェブアプリケーションのアドレスに基づいて,ウェブアプリケーションに対応するウェブページを取得し,設定情報に含まれている表示態様情報に基づいて取得したウェブページの表示態様を変更して,携帯端末の表示部に表示させる点である。(イ)ここで,ネイティブアプリケーションの設定ファイルに,引用発明に記載されているウェブアプリケーションのロケーションネイティブアプリケ,ーションの表示態様情報などのパラメータの他にも,以下の文献の記載にもあるように,
ネイティブ機能のパラメータを含む各種のパラメータが設定されることが,本願出願前には当該技術分野における周知技術であった。
a
前記(1)イ(ア)a,bに記載されているカメラを利用するためのパーミッションGPS利用のパーミッションなどのネイティブ機能を実行させ,
るためのパラメータ
b
前記(1)イ(ウ)a~cに記載されている
アプリの名前やバージョン,そのアプリが利用するStoryboardのファイル等の情報アプリの名前,やアイコン,対応するAndroidのバージョン,起動時に実行する○○Activityクラス,そのアプリをネットワークに接続できるようにするか?,SDカードにファイルを保存できるようにするか?などの様々な項目c
前記(1)イ(エ)に記載されている横画面に固定する設定

d
前記(1)イ(オ)bに記載されている
加速度センサでデバイスの傾きを取得するため,傾けた際に画面のオリエンテーションが変わらないように固定するための設定(ウ)また,本件補正発明の携帯通信端末の動きに伴う動作について検討すると,本願の明細書(以下,図面を含めて本件明細書という。)の段落【0
066】【0076】【0137】には,


携帯通信端末の動きに関連すると考え
られる構成として,
GPSと加速度センサが例示されている。

そして,本件補正発明の携帯通信端末の動きが携帯通信端末の移動であるとした場合,
携帯通信端末の移動に伴う動作を行う地図とGPSを組み合わせたアプリは,例えば,前記(1)イ(イ)のとおり,周知であり,GPSに関する前記(1)イ(ア)bの記載も参酌すると,上記地図とGPSを組み合わせたアプリでは,ネイティブ機能であるGPSに関連するパラメータを設定ファイルに設定しているものと認められる。
また,本件補正発明の携帯通信端末の動きが,端末を傾けるような動きであるとすると,
携帯通信端末の傾きに伴う動作を行うアプリは,例えば,前記
(1)イ(オ)aに記載されているように周知であり,前記(1)イ(オ)bの記載を参照すると,このアプリでは,ネイティブ機能である加速度センサに関連するパラメータが設定ファイルに設定されると認められる。
そうすると,
携帯通信端末の動きに伴う動作を行うアプリは,本願の出願前に
当該技術分野において周知であり,加えて,当該アプリが利用するネイティブ機能のパラメータを設定ファイルに設定可能とすることも,本願の出願前には当該技術分野における周知技術であった。
(エ)引用発明は,
リクエスト用ページ30には,入力欄として,ネイティブアプリケーションがアクセスするウェブアプリケーションのロケーションを示すアドレスの入力欄31が設けられ,また,ネイティブアプリケーションの表示態様情報に係る入力欄として,背景色の入力欄34,及びアイコン画像の入力欄35が設けられており入力欄31には,ウェブアプリケーションのメインページのU,RLが入力され,背景色の入力欄34には,カラーコードや背景画像を示すアドレスが入力され,アイコン画像の入力欄35には,画像ファイルのアドレスが入力されるものであるところ,引用文献1の段落【0010】の前記テンプレートアプリケーションは,前記アクセス先を設定する設定情報を含み,前記生成部は,前記受付部が前記リクエストを受け付けたことに応じて,前記テンプレートアプリケーションをコピーし,コピーされた前記テンプレートアプリケーションに含まれる前記設定情報の前記アクセス先を前記受付部が受け付けた前記アドレスに設定することで前記ネイティブアプリケーションを生成するとの記載及びこの発明によれば,アプリケーション生成装置は,設定情報に含まれているアクセス先を,受付部が受け付けたアドレスに変更するという単純な処理によってネイティブアプリケーションを容易に生成することができるとの記載も考慮すると,引用発明は,ネイティブアプリケーションの設定情報(設定ファイル)のパラメータを,リクエスト用ページ30の入力欄,すなわち,GUIを用いて簡単に設定することで,ネイティブアプリケーションを容易に生成できるアプリケーション生成システムであるといえる。
そして,アプリケーション生成システムを用いて携帯端末のネイティブアプリケーションの開発を行う当業者であれば,
携帯通信端末の動きに伴う動作を行うアプリを利用可能であるところ,この周知の携帯通信端末の動きに伴う動作を行うアプリを生成する場合でも,設定ファイルにネイティブ機能のパラメータをGUIを用いて簡単に設定することで,アプリを容易に生成するという課題を解決できることは当然に予測し得たものであるから,引用発明のアプリケーション生成システムを,上記周知の携帯通信端末の動きに伴う動作を行うアプリの生成に用いる動機はあったといえる。
(オ)したがって,引用発明のアプリケーション生成システムを,携帯通信端末の動き(すなわち,携帯通信端末の移動や傾きなどの動き)に伴う動作を行うアプリケーションの生成に用い,その際,当該アプリケーションの設定ファイルに,当該アプリケーションが利用するネイティブ機能のパラメータを設定するように構成すること,すなわち,引用発明において,アプリケーションの設定ファイルを,アプリケーションの,
携帯通信端末の動きに伴う動作を規定する設定ファイル
とし,当該設定ファイルを設定するためのパラメータを,GPSや加速度センサのような携帯通信端末の動きに伴う動作に関連したネイティブ機能を実行させるためのパラメータとすることは,当業者が容易に想到し得たことである。イ
本件補正発明の奏する作用効果は,引用発明と引用文献2~5及び参考
文献1に記載された周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。

よって,本件補正発明は,引用発明と引用文献2~5及び参考文献1に
記載された周知技術に基づいて,当業者が容易に発明をすることができたものであり,特許法29条2項により,特許出願の際独立して特許を受けることができないものであるので,本件補正は却下すべきものである。
(4)本件補正前発明について
本件補正前発明は,本件補正発明から,
通信端末に係る限定事項と,
前記通信端末において実行されるアプリケーションの動作に係る限定事項を削除したものである。
本件補正前発明の発明特定事項をすべて含み,さらに他の事項を付加したものに相当する本件補正発明が,引用発明と引用文献2~5及び参考文献1に記載された周知技術に基づいて,当業者が容易に発明をすることができたのであるから,本件補正前発明も,引用発明と引用文献2~5及び参考文献1に記載された周知技術に基づいて,当業者が容易に発明をすることができたものである。
したがって,本件補正前発明は,特許法29条2項により特許を受けることができない。
第3
1
原告主張の取消事由
取消事由1(本件補正発明についての容易想到性の判断の誤り)
(1)引用発明のアプリケーション生成システムを,
携帯通信端末の動きに伴う動作を行うアプリの生成に用いる動機はないことア
引用文献1の段落
【0002】

【0004】【0007】


【0023】


【0024】によると,引用発明のアプリケーション生成システムは,アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに,CMSにより開発したウェブアプリケーションを利用してもらうことができないという問題に鑑み(段落【0002】【0004】【0005】,CMSによって構築したウ,


ェブアプリケーションと同等の機能を有するネイティブアプリケーションを開発することを提案している(段落【0006】。引用発明は,その提案を前提とした上)
で,
ネイティブアプリケーションの開発には多大な開発工数が必要であることから,ネイティブアプリケーションを容易に生成することができるアプリケーション生成装置を提供することを課題としている(段落【0006】【0007】。,

ここで,ウェブアプリケーションは,一般的に,Webサーバ上で動作し,Webブラウザを用いて利用するアプリケーションとして認識されている(甲22)す

なわち,ウェブアプリケーションは,入力されたデータの管理や,データに基づいて出力する情報を組み立てる処理をインターネット上のWebサーバが行い,ユーザによる情報の入力や,出力された情報の画面表示といった処理を端末側のWebブラウザが行うアプリケーションである(甲23)

このように,ウェブアプリケーションを利用するに当たり,ユーザが操作する端末側の担う処理は,入力されたデータの送信処理と受信したデータの表示処理のみであり,データ処理等の実体的な部分の演算処理は,もっぱらWebサーバ側に任せて実行する構造となっている。
また,ネイティブアプリケーションは,一般的に,端末内の演算装置が直接に演算処理を行う(実行する)タイプのアプリケーションとして認識されている(甲24)
。引用文献1の段落【0004】【0023】に記載されているとおり,ネイテ,
ィブアプリケーションは,端末内で実行されるという性質上,アプリケーションサーバ等のアプリケーション提供元からダウンロードして端末にインストールされる。以上のとおり,ウェブアプリケーションとネイティブアプリケーションとは,技術的に全く異なるタイプのアプリケーションであり,引用発明は,アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに,CMSにより開発したウェブアプリケーションを利用してもらうことを前提とした上で,多大な開発工数を要することなく,ウェブアプリケーションと同等の機能を有するネイティブアプリケーションを容易に生成するという課題を解決するものである。イ
引用文献1の段落
【0025】

【0026】

【0029】【0031】



【0034】~【0036】によると,引用発明のアプリケーション生成システムで生成されたネイティブアプリケーションは,
設定情報に設定されたウェブアプリケーションのロケーションを示すアドレスメニューページに表示するメニ,ュー画像のファイルの格納先アドレスメニュー画像に対応するリンク先のペー,ジのアドレスカラーコード(RGB値を十六進法で表記した文字列)や背景画,像を示すアドレス等のパラメータに応じて,指定された表示態様で指定されたウェブアプリケーションを表示するものであり,上記パラメータは,いずれもスマートフォン等の携帯通信端末の画面にウェブページを表示するためのパラメータに限られており,表示対象のロケーション(所在)を示すためのアドレスのみである。このように,引用発明のアプリケーション生成システムは,ウェブアプリケーションの利用,すなわち,ブログ等の既存のウェブアプリケーションにアクセスし,その表示態様を指定して表示する機能を備えたネイティブアプリケーションを生成するものであるから,表示したいウェブアプリケーションのロケーションを示すアドレスや,所望の背景画像のロケーションを示すアドレス等の簡単なパラメータをGUIに入力するだけで,所望のウェブアプリケーションを表示するネイティブアプリケーションを生成できるのである。
以上のように,引用発明のアプリケーション生成システムは,既存のウェブアプリケーションを利用して所望のコンテンツ(ブログ等)を表示するという機能に特化した構成を備えている。

引用発明のアプリケーション生成システムで生成されたネイティブアプ
リケーションは,ブログ等の既存のウェブアプリケーションにアクセスできるだけであり,Webサーバ上のブログ等のコンテンツを書き換えるものではない。したがって,仮に,設定情報にネイティブ機能(例えば,GPS,加速度センサ等)を実行するためのパラメータをGUIを用いて簡単に設定できたとしても,携帯通信端末で動作するのは表示機能に限定されたWebブラウザにすぎないから,携帯通信端末に固有のネイティブ機能に応じて携帯通信端末の動きに伴う動作を行うネイティブアプリケーションを容易に生成できるとはいえない。したがって,当業者は,設定ファイルにネイティブ機能のパラメータをGUIを用いて簡単に設定することで,アプリを容易に生成するという課題を解決できることは当然に予測し得たということはできない。
エ(ア)前記ア,
イのとおり,引用発明のアプリケーション生成システムは,既
存のウェブアプリケーションを利用しつつ所望の表示態様でコンテンツを表示するという機能に特化した構成を備えているから,引用発明のアプリケーション生成システムを用いてネイティブアプリケーションを生成するためには,目的とするコンテンツを有する既存のウェブアプリケーションが特定されなければならず,引用発明に接した当業者が,ブログ,ショッピングサイト等のコンテンツを表示する既存のウェブアプリケーションを利用するという目的を離れて,引用発明のアプリケーション生成システムを用いて携帯通信端末の動きに伴う動作を行うアプリを生成することはない。
また,前記ウのとおり,当業者は,引用発明のアプリケーション生成システムを用いることにより設定ファイルにネイティブ機能のパラメータをGUIを用いて簡単に設定することで,アプリを容易に生成するという課題を解決できるとは考えないから,引用発明のアプリケーション生成システムを用いて携帯通信端末の動きに伴う動作を行うアプリを生成することはない。(イ)仮に,
当業者が引用発明のアプリケーション生成システムを用いて
携帯通信端末の動きに伴う動作を行うアプリを生成しようと試みたとしても,その際には,既存の携帯通信端末の動きに伴う動作を行うウェブアプリケーションのロケーションを示すアドレスを取得する必要があるところ,
携帯通信端末の動きに伴う動作を行うためには,携帯通信端末の動きを検知して,その動きに応じて動作する機能を備えている必要があるが,ウェブアプリケーションを利用する際に端末側で実行されるWebブラウザには,携帯通信端末の動きを検出する機能はないから,既存のウェブアプリケーションでは携帯通信端末の動きに伴う動作を行うことはできない。(ウ)したがって,当業者が引用発明のアプリケーション生成システムを用いて携帯通信端末の動きに伴う動作を行うアプリを生成することはない。オ
引用発明の課題は,
アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに,CMSにより開発したウェブアプリケーションを利用してもらうこと(段落【0005】
)とネイティブアプリケーションを容易に生成することができるアプリケーション生成装置を提供することである(段落【0006】【0007】。


本件審決は,ネイティブアプリケーションの設定ファイルにネイティブ機能のパラメータを含む各種のパラメータが設定されることは周知技術
(以下
周知技術1
という。
)であるとし,また,携帯通信端末の動きに伴う動作を行うアプリ及び当該アプリが利用するネイティブ機能のパラメータを設定ファイルに設定することは周知技術(以下周知技術2という。
)であるとしている。
周知技術1は,ネイティブアプリケーションに,ネイティブ機能の実行を含む各種の設定を行う場合には,設定ファイルにネイティブ機能のパラメータを含む各種のパラメータを設定するという技術である。すなわち,周知技術1の課題は,ネイティブアプリケーションにネイティブ機能の実行を含む各種の設定を行うことである。
また,周知技術2は,設定ファイルにネイティブ機能のパラメータを設定することにより携帯通信端末の動きに伴う動作を行うアプリケーションである。すなわち,
周知技術2の課題は,
携帯通信端末の動きに伴う動作を行うアプリケーションを提供することである。このように,引用発明が解決しようとする課題と周知技術1及び周知技術2が解決しようとする課題との間に共通性はない。

前記ア~エのとおり,ネイティブアプリケーションの開発を行う当業者
は,
引用発明のアプリケーション生成システムを,
携帯通信端末の動きに伴う動作を行うアプリの生成に用いる動機はない。また,前記オのとおり,引用発明が解決しようとする課題と周知技術(周知技術1及び周知技術2)が解決しようとする課題との間に共通性はないため,その観点からも,
引用発明のアプリケーション生成システムを,
携帯通信端末の動きに伴う動作を行うアプリの生成に用いる動機はない。したがって,引用発明のアプリケーション生成システムを,上記周知の携帯通信端末の動きに伴う動作を行うアプリの生成に用いる動機はあるとした本件審決の判断には誤りがある。
(2)引用発明において,アプリケーションの設定ファイルを,
アプリケーションの,携帯通信端末の動きに伴う動作を規定する設定ファイルとし,当該設定ファイルを設定するためのパラメータを,GPSや加速度センサのような携帯通信端末の動きに伴う動作に関連したネイティブ機能を実行させるためのパラメータとすることは,当業者が容易に想到し得たことではないこと

本件審決は,引用発明のアプリケーション生成システムを,携帯通信端
末の動き(携帯通信端末の移動や傾きなどの動き)に伴う動作を行うアプリケーションの生成に用いることを前提にして,引用発明と周知技術1及び周知技術2を組み合わせたが,前記(1)のとおり,携帯通信端末用のネイティブアプリケーションの開発を行う当業者は,
引用発明のアプリケーション生成システムを用いて,
携帯通信端末の動きに伴う動作を行うアプリの生成を試みる動機はない。イ
引用発明のアプリケーション生成システムにおいて,
当該設定ファイルを設定するためのパラメータすなわちGUIにて設定するパラメータを,
携帯通信端末に固有のネイティブ機能を実行させるためのパラメータに置き換えてしまうと,利用すべきウェブアプリケーションのロケーションを特定することができなくなり,引用発明が前提とするウェブアプリケーションを利用するネイティブアプリケーションを生成することができなくなってしまう。ウ
このように,引用発明と上記各周知技術とを組み合わせる動機付けがな
く,また,引用発明と上記各周知技術の組合せに阻害要因があるが,本件審決の判断は,この点を看過しており,誤りである。
(3)本件補正発明の奏する作用効果は,引用発明と引用文献2~5及び参考文献1に記載された周知技術の奏する作用効果から予測される範囲のものではなく,格別顕著なものであること
本件補正発明の作用効果は,携帯通信端末に固有のネイティブ機能に応じて携帯通信端末の動きに伴う動作を行うネイティブアプリケーションを,少ない開発負担で生成することができるアプリケーション生成支援システムを提供できることである。
前記(1)及び(2)のとおり,
引用発明と引用文献2~5及び参考文献1に記載された
周知技術とを組み合わせる動機がない以上,本件補正発明が奏する作用効果が予測されるはずもない。仮に,それらを組み合わせることができたとしても,引用発明が既存のウェブアプリケーションの利用を前提としている限り,既存のウェブアプリケーションでは実現し得ない動作,すなわち携帯通信端末の動きに伴う動作を実現するネイティブアプリケーションを生成することまでは想定できない。したがって,本件補正発明の奏する作用効果は,引用発明と引用文献2~5及び参考文献1に記載された周知技術の奏する作用効果から予測される範囲のものではなく,格別顕著なものであるから,これと異なる本件審決の判断は,誤っている。(4)被告の主張について

被告は,引用文献1の段落【0005】【0006】の記載に基づき,,

引用発明の課題は,CMS(コンテンツ管理システム)によって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを容易に開発して,アプリケーションサーバにおいてネイティブアプリケーションとして検索可能とすることであると主張する。
しかし,段落【0006】においては,
CMSにより開発したウェブアプリケーションを利用してもらうことができないという問題の解決手段として,CMSによって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを新たに開発することは,適切ではないことを指摘しているのである。引用文献1の段落【0007】【0025】の記載からすると,引用発明は,ア,
プリケーションサーバにおいてネイティブアプリケーションを検索したユーザに,CMSにより開発したウェブアプリケーション(既存のウェブアプリケーション)を利用してもらうことを前提とし,そのためのネイティブアプリケーションを(開発という手段を採らずに)容易に生成することを課題としてされたものである。イ
被告は,PhoneGapは,HTMLやJavaScriptなどの
Web系技術を用いてウェブアプリケーションを作る感覚で容易に作成可能であって,App

Store(アプリケーションサーバ)等で配布可能となるアプリを
作成可能なフレームワークであるから,引用発明の課題を解決する際に利用するには好適なフレームワークであると主張する。
しかし,PhoneGapは,あくまでWeb系技術を用いてネイティブアプリケーションを新たに開発するためのフレームワークであり,目的とするネイティブアプリケーションを新たに開発するためには,HTMLやJavaScript等を用いてソースコード(プログラム)を書く必要があり,PhoneGapを用いることは,目的の機能を備えたネイティブアプリケーションを新たに開発する(新たにソースコードを書く)ことに他ならない。
これに対し,引用発明は,既存のウェブアプリケーションを利用するためのネイティブアプリケーションを容易に生成することを課題とするものであり,PhoneGapのようにソースコードを書くという面倒な作業を要することなく,利用したいウェブアプリケーションのアクセス先アドレス等の情報を入力するだけで,ネイティブアプリケーションを容易に生成することができるのである。したがって,既存のアプリケーションを利用するのではなく,同等の機能を有するネイティブアプリケーションを新たに開発するための手段であるPhoneGapは,引用発明の課題を解決するものではないから,引用発明の課題を解決する際に利用するに当たって好適なフレームワークではない。

被告は,当業者が引用発明を実装するに当たって,アプリ作成フレーム
ワークであるPhoneGapを用いる動機付けがあると主張する。しかし,被告は,引用発明の前提(既存のウェブアプリケーションを利用してもらうこと)を看過し,引用発明の課題を誤って認定している。そして,誤って認定した課題に基づいて,ウェブアプリケーションと同等の機能を有するネイティブアプリケーションを新たに開発するために,PhoneGapが好適であるという誤った結論に至っている。
引用発明は,既存のアプリケーションを利用するためのネイティブアプリケーションを容易に生成する技術であるところ,PhoneGapは,Web系技術を用いて新たにソースコードを書くことにより,既存のアプリケーションと同等の機能を有するネイティブアプリケーションを新たに開発するためのフレームワークであるから,PhoneGapを用いた場合,既存のウェブアプリケーションを利用することはできない。
そして,既存のウェブアプリケーションを利用することができない技術を,既存のアプリケーションを利用する技術に適用することはできないから,引用発明に対してPhoneGapを適用するには,阻害要因がある。
また,引用発明に対してPhoneGapを適用したとすると,目的とするネイティブアプリケーションのソースコードを新たに書くという作業が発生するから,引用発明の課題である既存のウェブアプリケーションを利用するためのネイティブアプリケーションを容易に生成することが達成できなくなってしまう。この観点からも,当業者が引用発明を実装するに当たって,アプリ作成フレームワークであるPhoneGapを用いる動機付けはない。

被告は,スマートフォンでは端末が縦の姿勢のときと,横の姿勢のときで画面が切り替わることは携帯通信端末の動きに伴う動作に他ならず,横画面に固定する設定縦画面に固定する設定いずれも,

は,
アプリケーションの,携帯通信端末の動きに伴う動作を規定するものであるといえ,Androidにおける,AndroidManifest.xmlファイルはアプリケーションの,携帯通信端末の動きに伴う動作を規定する設定ファイルに相当するものであるといえると主張する。
しかし,PhoneGapの横画面に固定する設定や縦画面に固定する設定は,あくまで携帯通信端末の動きにかかわらず,単に横画面又は縦画面に一律に画面の方向を固定するものであるから,
携帯通信端末の動きに伴う動作
を規定
するものではない。

被告は,引用発明のウェブアプリケーションは,HTMLやJavaS
criptで記述されているところ,JavaScriptは,Webブラウザで実行される制御コードを記述するためのスクリプト言語であるから,コンテンツを既存のウェブサイトから取得しているとしても,当該コンテンツに対する制御処理は端末側で実行されるWebブラウザにおいて,JavaScriptに従って行われているといえ,したがって,引用発明は,既存のウェブアプリケーションを利用して所望のコンテンツ(ブログ等)を表示するという機能に特化したものとはいえないと主張する。
しかし,本件審決において認定された引用発明は,ウェブアプリケーションがHTMLやJavaScriptで記述されていること,及び,既存のウェブサイトから取得したコンテンツに対する制御処理が端末側で実行されるWebブラウザにおいてJavaScriptに従って行われていることを構成として有していないから,被告の上記主張は,本件審決において認定された引用発明に基づかないものであり,失当である。
本件審決において認定された引用発明は,
ここで,生成されたネイティブアプリケーションは,携帯端末にインストールされて実行されると,設定情報に含まれているウェブアプリケーションのアドレスに基づいて,ウェブアプリケーションに対応するウェブページを取得し,設定情報に含まれている表示態様情報に基づいて取得したウェブページの表示態様を変更して,携帯端末の表示部に表示させるものでありという構成を有しており,ウェブアプリケーションに対応するウェブページを取得して表示することが特定されているのみである。

被告は,PhoneGapは,引用発明と同様に,HTMLやJava
Script等で記述されたウェブアプリケーションからスマートフォン用アプリを生成可能であると主張する。
しかし,PhoneGapは,HTMLやJavaScriptといったWeb系技術を用いて目的とするネイティブアプリケーションのソースコード(プログラム)を,開発者が自ら新規に書かなければならない。PhoneGapは,既存のウェブアプリケーションからネイティブアプリケーションを容易に生成する技術ではなく,一般的なWeb系技術を用いて,ネイティブアプリケーションをプログラミングすることが可能な技術にすぎない。

被告は,PhoneGapは,設定ファイル(AndroidMani
fest.xmlなど)にネイティブ機能(端末の加速度センサを用いた画面の回転制御)の制御内容を規定するためのパラメータ(landscapeやportrait)を設定していると主張する。
しかし,
前記エのとおり,
PhoneGapにおける
横画面に固定する設定(landscape)や縦画面に固定する設定(portrait)は,携帯通信端末の動きとは無関係に設定されるものであり,
携帯通信端末の動きに伴う動作を規定するものではない。

被告は,引用発明のアプリケーション生成システムにPhoneGap
を適用する場合には,
当該設定ファイルを設定するためのパラメータを携帯通信端末に固有のネイティブ機能を実行させるためのパラメータに置き換えてしまうのではなく,ウェブサーバで提供されるコンテンツにアクセスする際に使用される当該設定ファイルを設定するためのパラメータとは別の携帯通信端末に固有のネイティブ機能を実行させるためのパラメータを追加設定するだけであるから,引用発明が前提とするウェブアプリケーションを利用するネイティブアプリケーションを生成することができなくなることはないと主張する。しかし,
被告は,
携帯通信端末に固有のネイティブ機能を実行させるためのパラメータを具体的にどのように追加するのか立証していないから,被告の上記主張は根拠がない。

被告は,一般的なウェブサイト表示用のウェブアプリケーションは,加
速度センサを備えたスマートフォン等の端末では,加速度センサによって検出した端末の姿勢に基づいて,
端末の姿勢に基づいた画面回転表示制御を行っているから,
一般的なウェブサイト表示用のウェブアプリケーションにおいても,携帯通信端末の動きに伴う動作
(端末の姿勢に基づいた画面回転表示制御)
を実現することが
可能であると主張する。
しかし,端末の姿勢は,あくまで端末に備えられた加速度センサで検出するものであるから,サーバ側で動作するウェブアプリケーションにおいては,端末側の姿勢を知る由もない。端末の姿勢に基づいた画面回転表示制御は,ウェブアプリケーションの機能ではなく,端末側の機能にすぎない。
したがって,一般的なウェブサイト表示用のウェブアプリケーションにおいて,携帯通信端末の動きに伴う動作
(端末の姿勢に基づいた画面回転表示制御)
を実
現することは可能であるとする被告の上記主張は,誤りである。
2
取消事由2(本件補正前発明についての容易想到性の判断の誤り)
本件補正前発明についても,引用発明において,アプリケーションの設定ファイルを,
アプリケーションの動作を規定する設定ファイルに変更し,当該設定ファイルを設定するためのパラメータを,GPSや加速度センサのような携帯通信端末に固有のネイティブ機能を実行させるためのパラメータに変更することには,阻害要因があり,引用発明と引用文献2~5及び参考文献1に記載された周知技術とを組み合わせることはできない。
したがって,本件補正前発明は,当業者が引用発明と引用文献2~5及び参考文献1に記載された周知技術に基づいて容易に想到し得たものではない。第4
1
被告の主張
取消事由1について

(1)周知技術であるPhoneGapの概要
引用文献3(66頁表題,66頁副題,66頁中欄下から2行~右欄3行,66頁表1,66頁右欄13行~67頁左欄13行,70頁右欄6行~最終行,72頁左欄1行~25行)
,引用文献5(16頁左欄7行~27行,29頁左欄1行~16
行,
36頁左下欄下から10行~末行)三宅理

スマートフォン開発倶楽部第5回
WEB+DB

PRESS

Vol.66(株式会社技術評論社,平成24年1月

25日発行)
(以下乙3文献という。甲7,乙3)
(55頁左欄10行~14行,
159頁左欄1行~右欄4行,160頁右欄1行~7行)の記載からすると,周知技術のPhoneGapは以下のような技術であるといえる。
iPhoneやAndroid,WindowsPhoneなどのマルチプラットホームに対応するアプリを作成可能なフレームワークであって,HTMLやJavaScriptなどのWeb系技術を用いてWebアプリを作る感覚で作成可能であり,JavaScriptでPhoneGapのAPI(ライブラリの関数)を呼び出せば,プラグインの仕組みを使って,カメラやGPSなど端末のネイティブ部分にアクセス可能であり,端末のGPS機能にアクセスすることで,GPSで取得した端末の現在位置が中心となるように地図を表示することが可能となり,スマートフォンでは加速度センサを用いて端末の姿勢を検知し,端末が縦の姿勢のときと,横の姿勢のときで画面が切り替わるところ,横画面に固定する設定を施す場合,Androidでは,AndroidManifest.xmlに「android:screenOrientation=”landscape”の
1行を追加することで,
iOSでは,
LandscapeandscapeRight
または
LLeftのアイコンを選択することで横画面に固定可能とな

り,縦画面に固定する設定を施す場合,Androidでは,AndroidManifest.xmlにandroid:screenOrientation=”portrait”の1行を追加することで,iOSでは,portraitのアイコンを選択することで,縦画面に固定可能となり,作成されたアプリの実体はブラウザUIで動くアプリであって,App
Sto

re等で配布可能となるアプリを作成可能なフレームワークであるPhoneGap」
(2)引用発明への周知技術のPhoneGapの適用

動機付け

引用文献1の段落【0004】~【0007】によると,引用発明の課題は,CMS(コンテンツ管理システム)によって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを容易に開発して,アプリケーションサーバにおいてネイティブアプリケーションとして検索可能とすることであるといえる。
ここで,PhoneGapは,HTMLやJavaScriptなどのWeb系技術を用いてWebアプリ(ウェブアプリケーション)を作る感覚で容易に作成可能であって,App
アプリ(App
pp

Store(アプリケーションサーバ)等で配布可能となる

Store等で配布可能となれば,アプリケーションサーバ(A

Store等)
においてネイティブアプリケーションとして検索可能となる)

を作成可能なフレームワークであるから,引用発明の課題を解決する際に利用するには好適なフレームワークであるといえる。
したがって,当業者が引用発明を実装するに当たって,アプリ作成フレームワークであるPhoneGapを用いる動機付けがあるといえる。
イ(ア)PhoneGapでは,JavaScriptでPhoneGapのAPI(ライブラリの関数)を呼び出せば,プラグインの仕組みを使って,GPSなど端末のネイティブ部分にアクセス可能であり,端末のGPS機能にアクセスすることで,GPSで取得した端末の現在位置が中心となるように地図を表示することが可能となるから,
引用発明において地図表示アプリケーションを生成する際に,
PhoneGapのフレームワークを採用することで,ネイティブ機能であるGPS機能が利用可能となり,携帯通信端末の動き(移動)に伴う動作(GPSで取得した端末の現在位置が中心となるように地図を表示する地図表示制御)を設定可能となる。
(イ)また,スマートフォンでは,ネイティブ機能である加速度センサから取得した値を用いて端末姿勢を検出しており,端末が縦の姿勢のときと,横の姿勢のときで画面が切り替わるところ,PhoneGapでは,横画面に固定する設定を施す場合,
Androidでは,
AndroidManifest.
xmlに
android:screenOrientation=”landscape”
の1行を追加することで,
iOSでは,
LandscapeandscapeRightL又はLeftのアイコンを選択することで横画面に固定可能とな
り,縦画面に固定する設定を施す場合,Androidでは,AndroidManifest.xmlにandroid:screenOrientation=”portrait”の1行を追加することで,iOSでは,portraitのアイコンを選択することで,縦画面に固定可能となる。ここで,
スマートフォンでは端末が縦の姿勢のときと,横の姿勢のときで画面が切り替わることは携帯通信端末の動きに伴う動作に他ならず,横画面に固定する設定や縦画面に固定する設定は,いずれも,
アプリケーションの,携帯通信端末の動きに伴う動作を規定するものであるといえ,Androidにおける,AndroidManifest.xmlファイルはアプリケーションの,携帯通信端末の動きに伴う動作を規定する設定ファイルに相当するものであるといえる。

したがって,引用発明において,アプリケーションを生成する際に,P
honeGapのフレームワークを利用することで,
本件補正発明と同様に,
携帯通信端末に固有のネイティブ機能を実行させるためのパラメータに応じて,携帯通信端末において実行されるアプリケーションの,携帯通信端末の動きに伴う動作を規定する設定ファイルを備えることとなる。(3)本件補正発明の作用効果について
地図表示のウェブアプリケーションは,GPS機能を備えた端末では,GPS機能を用いて現在位置を取得し,現在位置を中心とした地図表示を行うことが可能であるから,
地図表示のウェブアプリケーションにおいても,
携帯通信端末の動きに伴う動作
(端末の移動に伴って変化する現在位置を中心とした地図表示制御)を実
現することが可能である(乙4の130頁~134頁)

また,一般的なウェブサイト表示用のウェブアプリケーションは,加速度センサを備えたスマートフォン等の端末では,加速度センサによって検出した端末の姿勢に基づいて,端末の姿勢に基づいた画面回転表示制御を行っているから,一般的なウェブサイト表示用のウェブアプリケーションにおいても,
携帯通信端末の動きに伴う動作
(端末の姿勢に基づいた画面回転表示制御)
を実現することが可能であ
る。
したがって,引用発明にPhoneGapを組み合わせることで,これらのウェブアプリケーションから携帯通信端末の動きに伴う動作を実現するネイティブアプリケーションを生成することが想定可能であるといえるから,本件補正発明の作用効果は格別なものではない。
(4)原告の主張について

原告は,引用発明は,既存のウェブアプリケーションを利用して所望の
コンテンツ(ブログ等)を表示するという機能に特化したものであると主張する。しかし,引用文献1の段落【0024】によると,引用発明のウェブアプリケーションが,HTMLやJavaScriptで記述されており,引用発明のウェブアプリケーションの例として,
ブログだけでなく,
ゲームサイト等も示されている。
ここで,JavaScriptは,Webブラウザで実行される制御コードを記述するためのスクリプト言語である(乙4の26頁下から4行~最終行)から,コンテンツを既存のウェブサイトから取得しているとしても,当該コンテンツに対する制御処理は端末側で実行されるWebブラウザにおいて,JavaScriptに従って行われているといえる。
ウェブアプリケーションのゲームでは,
一般的に,
ユーザからの操作入力を受け付けて,JavaScriptにより記述された制御コードを端末側で実行することでインタラクティブな制御処理を可能としている。したがって,引用発明は,既存のウェブアプリケーションを利用して所望のコンテンツ(ブログ等)を表示するという機能に特化したものとはいえないから,原告の上記主張は誤りである。

原告は,設定ファイルにネイティブ機能のパラメータをGUIを用いて
簡単に設定することで,アプリを容易に生成するという課題を解決できることは当然に予測し得たものでないと主張する。
しかし,前記(1)のとおり,PhoneGapは,引用発明と同様に,HTMLやJavaScript等で記述されたウェブアプリケーションからスマートフォン用アプリを生成可能であり,端末のブラウザUI(Webブラウザ)に,スマートフォンのネイティブ機能(GPSやカメラなど)にアクセスするためのJavaScript関数を実行させることで,プラグインの仕組みを使って,スマートフォンのネイティブ機能(GPSやカメラなど)にアクセス可能となる。また,設定ファイル(AndroidManifest.xmlなど)にネイティブ機能(端末の加速度センサを用いた画面の回転制御)の制御内容を規定するためのパラメータ(パラメータlandscapeやportrait)を設定している。したがって,引用発明にPhoneGapを適用することにより,設定ファイルにネイティブ機能のパラメータをGUIを用いて簡単に設定することで,アプリを容易に生成するという課題を解決できることは当然に予測し得たものであるといえるから,原告の上記主張は誤りである。

原告は,
引用発明のアプリケーション生成システムにおいて,
当該設定ファイルを設定するためのパラメータ
すなわちGUIにて設定するパラメータを,
携帯通信端末に固有のネイティブ機能を実行させるためのパラメータに置き換えてしまうと,利用すべきウェブアプリケーションのロケーションを特定することができなくなり,引用発明が前提とするウェブアプリケーションを利用するネイティブアプリケーションを生成することができなくなってしまうから,引用発明と上記各周知技術との組合せに阻害要因がある旨主張する。
しかし,引用発明のアプリケーション生成システムにPhoneGapを適用する場合には,
当該設定ファイルを設定するためのパラメータを携帯通信端末に固有のネイティブ機能を実行させるためのパラメータに置き換えてしまうのではなく,ウェブサーバで提供されるコンテンツにアクセスする際に使用される当該設定ファイルを設定するためのパラメータとは別の携帯通信端末に固有のネイティブ機能を実行させるためのパラメータを追加設定するだけであるから,引用発明が前提とするウェブアプリケーションを利用するネイティブアプリケーションを生成することができなくなることはない。したがって,原告の上記主張は誤りである。
2
取消事由2について

前記1(4)ウのとおり,引用発明のアプリケーション生成システムとPhoneGapとの組合せに阻害要因はないから,本件補正前の発明は,当業者が引用発明と引用文献2~5及び参考文献1等に記載された周知技術に基づいて容易に想到し得たものである。
したがって,本件審決における,本件補正前発明についての容易想到性の判断に誤りはない。
第5

当裁判所の判断
1
本件明細書の記載

本件明細書には,以下の記載がある(甲9の1・3)

【技術分野】
【0001】本発明は,アプリケーション生成支援システムおよびアプリケーション生成支援プログラムに関する。
【背景技術】
【0002】モバイル用通信端末のアプリケーションとして,さまざまなアプリケーションが開発されている。モバイル用通信端末のアプリケーションは,Webアプリケーション,ネイティブアプリケーション,およびハイブリッドアプリケーションに分類される。Webアプリケーションは,演算処理をネットワーク上のサーバで実行するタイプのアプリケーションである。ネイティブアプリケーションは,演算処理を通信端末上でのみ実行するタイプのアプリケーションである。ネイティブアプリケーションは,例えば,カメラ,GPS,マイク,加速度センサなど,通信端末に固有のネイティブ機能を利用することができる,という特徴を有するアプリケーションである。ハイブリッドアプリケーションは,ネイティブ機能を利用することができ,マルチプラットフォームに対応したアプリケーションを作成することができ,アプリケーションをwebブラウザのように使用するWeb
Viewを用いることができるという特徴を有するアプリケーションである。【0003】上記のように,ハイブリッドアプリケーションは,Webアプリケ
ーションおよびネイティブアプリケーションのそれぞれの利点を備えるため,通信端末用アプリケーションの主流となっている。例えば,業務用の通信端末に用いられるアプリケーションとしてもハイブリッドアプリケーションが広く用いられる。業務用のハイブリッドアプリケーションを作成するためには,業務を行う各組織において業務目的に適したアプリケーションの開発を行う必要がある。【0004】ここで,アプリケーションを開発するためには,アプリケーションをインストールする通信端末のOSに適合した専用端末を準備し,当該OSに適したアプリケーション開発ツールを導入し,当該アプリケーション開発ツールにおけるプログラミング言語を用いたアプリケーション開発をする必要がある。このように,アプリケーション開発のためには,専用端末の準備およびアプリケーション開発ツールの導入などのアプリケーション開発環境の整備,ならびにプログラミング言語などのスキル習得などの多様な初期投資が必要である。
【0005】プログラミング言語のスキル習得の負担を軽減するために,プログラム開発を支援するための技術が開発されている。例えば,プログラム開発をより簡易化するために,特許文献1のようなプログラム開発装置が提案されている。【発明が解決しようとする課題】0007】

しかしながら,
通信端末上で動作し,
通信端末の動作に合わせて動作または画面表示するアプリケーションを作成するためには特許文献1に記載された技術に比べてはるかに高度なプログラミング技術が必要である。さらに,アプリケーションの用途に応じて多様な機能をアプリケーションに組み込む必要があるため,上記のような通信端末上で動作するアプリケーションの開発のために,アプリケーション開発者に費用および時間の面で大きな負担がかかる。
【0008】本発明は,上記実情に鑑み,アプリケーション開発者への開発負担を軽減することができるアプリケーション生成支援システムおよびアプリケーション生成支援プログラムを提供することを目的とする。
【課題を解決するための手段】
【0009】
本発明の一実施形態に係るアプリケー
ション生成支援システムは,通信端末の動作に関連するパラメータに応じてアプリケーションの動作を規定する設定ファイルを設定する設定部と,前記設定ファイルに基づいてアプリケーションパッケージを生成する生成部と,を有する。【0020】前記設定ファイルは,前記通信端末に固有のネイティブ機能を前記通信端末に実行させるプラグインファイルを含んでもよい。
【0037】前記設定ファイルは,前記通信端末に固有のネイティブ機能を前記通信端末に実行させるプラグインファイルを含んでもよい。
【0043】本発明によれば,アプリケーション開発者への開発負担を軽減することができるアプリケーション生成支援システムおよびアプリケーション生成支援プログラムを提供することができる。
【発明を実施するための形態】
〈第1実施形態〉
【0062】
・・・端末通信部33
0は全地球測位システム
(Global

Positioning

System


GPS)機能を有していてもよい。GPS機能は第2通信端末300のネイティブ機能の一つである。GPS機能を有効にするアプリケーションを起動すると,端末通信部330は上空の衛星からの信号を受信し,第2通信端末300の現在位置を知ることができる。
【0064】カメラ350は,ディスプレイ340と反対側に設けられている。つまり,ディスプレイ340が設けられた側を表面とすると,カメラ350は裏面に設けられている。なお,カメラ350とは別個のカメラが表面に設けられていてもよい。カメラ350は,レンズユニットおよび撮像素子を有している。カメラ350の機能は第2通信端末300のネイティブ機能の一つである。カメラ350の機能を有効にするアプリケーションを起動すると,レンズユニットを介して撮像素子で検知される映像がディスプレイ340に表示される。この映像が撮像素子で検知されている間にユーザによって作動指示が入力されると,端末制御部320は,その作動指示に応じて撮像素子で検知された映像の静止画像を取得する。【0101】
LANDSCAPE_LEFT

LANDSCAPE_RIGHTは,第2通信端末300を左横,右横に回転した場合の画面制御を指定する項目である。これらの項目では,第2通信端末300の画面を左横,右横に回転したときに,第2通信端末300の画面上でアプリケーションを正面表示させるか否かをチェックの有無で設定される。
【0102】
PORTRAIT_UPSIDE_DOWNは,第2通信端末3
00を上下逆さに回転した場合の画面制御を指定する項目である。この項目では,第2通信端末300の画面を上下逆さに回転したときに,第2通信端末300の画面上でアプリケーションを正面表示させるか否かをチェックの有無で設定される。【0103】
APP_START_PAGE_URLは,アプリケーションの
スタートページとして指定されるWebページのURLを指定する項目である。この項目では,アプリケーションを起動したときに表示されるWebページのURLを設定するための文字列が設定される。この項目では,URLを表示するために,『http://』や『https://』などの規定の形式の文字列が設定される。
【0104】
APPLICATION_PLISTは,アプリケーション設定
ファイルを指定する項目である。この項目では,アプリケーションに搭載したいアプリケーション設定ファイルを設定し,当該設定ファイルをサーバ100にアップロードする。
APPLICATION_PLIST
において設定されるアプリケ
ーション設定ファイルは,第1通信端末200を操作する第1ユーザによって作成された設定ファイルであってもよく,他の第3ユーザによって作成された設定ファイルであってもよい。
【0109】図10は,本発明の一実施形態に係るアプリケーション生成支援システムのパラメータチェックのシーケンスを説明する図である。図10に示すように,ステップ521で受信されたパラメータのチェックが行われる(ステップ5231)
。ステップ5231では,例えば,設定されたパラメータの形式が規定の形式に適合しているか否か,およびアプリケーション設定ファイルの形式が規定の形式に適合しているか否かなどの設定状態がチェックされる。図8および図9に示した例では,
APP_START_PAGE_URLに入力されたURLが『http://』または『https://』の形式になっているか否かがチェックされる。同様に,
APPLICATION_PLISTでアプリケーション設定ファイルが規定のファイル形式になっているか否かがチェックされる。また,詳細は後述するが,アプリケーションに搭載される機能として第2通信端末300のネイティブ機能に関連するプラグインファイルが規定のファイル形式になっているか否かがチェックされる。
【0115】図13は,本発明の一実施形態に係るアプリケーション生成支援システムの設定ファイルの一例を説明する図である。図13のアイコン指定ア,プリケーション名指定,および画面の回転制御指定はOS設定ファイルに該当
する。
つまり,
図8および図9の
CFBUNDLE_DISPLAY_NAME

INFO_CFBUNDLE_VERSIONLANDSCAPE_LEF,TPORTRAIT_UPSIDE_DOWN,
,およびLANDSCAPE_RIGHTはOS設定ファイルに該当する。これらのOS設定ファイルに係る動作は,複数の第2通信端末300に共通する動作である。図13のアドレスバー表示画面のコピー&ペースト制御通信プロトコル制限無操作タイム,,,アウト指定シングルサインオン設定,
,およびバックボタンの利用制限はア
プリケーション設定ファイルに該当する。つまり,上記の項目はAPPLICATION_PLISTの一例である。これらのアプリケーション設定ファイルに係る動作は,第1通信端末200によって入力された第2通信端末300の動作であり,複数の第2通信端末300に共通する動作であってもよく,特定の第2通信端末300に固有の動作であってもよい。
【0116】換言すると,本実施形態の設定ファイルは,OS設定ファイルおよびアプリケーション設定ファイルを含む。OS設定ファイルは,ビルドシェル150が受信したパラメータに関連し,複数の第2通信端末300の動作に共通するアプリケーションの動作を規定する設定ファイルである。アプリケーション設定ファイルは,ビルドシェル150が受信したパラメータに関連し,第1通信端末200を操作する第1ユーザによって入力された情報に基づくアプリケーションの動作を規定する設定ファイルである。なお,図13に示すOS設定ファイルおよびアプリケーション設定ファイルは一例であり,本発明のAPPLICATION_PLISTを限定するものではない。〈第3実施形態〉
【0135】
[サーバ100Bの機能構成]本実施形態のアプリ
ケーション生成支援システム10Bにおけるサーバ100Bの各機能の構成は,第1実施形態のサーバ100の各機能の構成と同じである。したがって,図5を参照してサーバ100Bの機能部について説明する。アプリケーション生成支援システム10Bのビルドシェル150Bに含まれるファイル設定部155Bは,OS設定ファイルおよびアプリケーション設定ファイルに加えて,第2通信端末300Bのネイティブ機能に関連するプラグインファイルを設定する点において,第1実施形態のファイル設定部155とは相違する。ファイル設定部155Bは,パラメータ受信部151Bが受信したパラメータにプラグインファイルに関連するパラメータが設定されている場合に,OS設定ファイルやアプリケーション設定ファイルと同様にプラグインファイルを設定する。
【0136】ファイル設定部155Bは,図6に示すように,パラメータ確認部1551B,テンプレート関連付け部1553B,およびプログラム更新部1555Bを有する。パラメータ確認部1551Bは,第1実施形態のパラメータ確認部1551と同様の機能を有する。テンプレート関連付け部1553Bは,第1実施形態のテンプレート関連付け部1553と同様の機能に加え,プラグインファイル用のテンプレートをパラメータ確認部1551Bによって選択された他のテンプレートに関連付ける。プログラム更新部1555Bは,第1実施形態のプログラム更新部1555と同様の機能に加え,プラグインファイル用のテンプレートによって規定された動作の各々が,第2通信端末300にインストールされたアプリケーション上で実現可能となるように,当該テンプレートの一部を更新する。【0137】上記のように,プラグインファイルは,例えば,カメラ,GPS,マイク,加速度センサなど,第2通信端末300Bの機器に固有のネイティブ機能をアプリケーションによって第2通信端末300Bに実行させるための設定ファイルである。プラグインファイルは,OS設定ファイルおよびアプリケーション設定ファイルと同様に,ビルドシェル150Bが受信したパラメータに関連する設定ファイルである。
【0139】
[アプリケーション生成支援システム10Bの動作フロー]
図17~
図21を用いて,本実施形態のアプリケーション生成支援システム10Bの各機能ブロックの動作について,フローチャートおよびユーザに表示されるインターフェースの一例を用いて詳しく説明する。
【0140】まず,図17~図19を用いて,第1通信端末200Bによって設定されたパラメータに基づいてアプリケーションを生成し,当該アプリケーションをダウンロード可能に提供する動作について説明する。図17は,本発明の一実施形態に係るアプリケーション生成支援システムのアプリケーション生成動作を示すフローチャートである。図17のフローチャートは図7のフローチャートと類似しているが,図17のフローチャートでは,ステップ527Bとステップ529Bとの間にプラグインファイルを設定するステップ528Bが設けられている点において,図7のフローチャートとは相違する。また,ステップ528Bが設けられていることに伴い,ステップ511Bで第1通信端末200Bに提供されるインターフェース600Bが図8のインターフェース600とは相違する。以下の説明において,図7の動作フローと同じ動作については説明を省略し,図7の動作フローと異なる動作について説明する。
【0141】まず,図17のステップ511Bで第1通信端末200Bに提供されるパラメータ設定GUIについて説明する。図18は,本発明の一実施形態に係るアプリケーション生成支援システムのパラメータ入力動作におけるインターフェースである。図18に示すインターフェース600Bは図8のインターフェース600と類似しているが,図18のインターフェース600Bの項目名620BではAPPLICATION_PLISTの下にPLUGIN_FILESが設けられている点において,図8のインターフェース600とは相違する。【0142】
PLUGIN_FILES
の入力欄630Bはプラグインファイ
ル用のテンプレートが格納された位置を示すアドレスを受け付ける。この入力欄630Bには,
ユーザが直接アドレスを入力してもよく,
ブランクボックスの右の
参照をクリックすることで,参照するアドレスを指定してもよい。なお,プラグインファイル用のテンプレートは,指定されたアドレスに圧縮ファイル形式で格納されている。ただし,当該ファイルは圧縮ファイル形式以外の形式で格納されていてもよい。
【0145】図17に示すように,ステップ527Bのアプリケーション設定ファイルの上書き処理に続いて,プラグインファイルの設定が行われる(ステップ528B)プラグインファイルの設定は,

OS設定ファイルの置換およびアプリケー
ション設定ファイルの上書き処理と同様に,設定ファイルを更新するという場合がある。ここで,ステップ528Bにおいて,プラグインファイルの設定するシーケンスについて図19を用いて説明する。
【図1】
【図10】

【図13】
【図17】
【図18】
【図19】

2(1)引用文献1には,以下のとおりの記載がある(甲1)

【技術分野】
【0001】本発明は,アプリケーション生成装置,アプリケーション生成システム及びアプリケーション生成方法に関する。
【背景技術】
【0002】
近年,
コンテンツマネジメントシステム
(以下,
CMS
(C
ontent

Management

System)という)によりウェブアプ

リケーションとして公開するコンテンツを構築し,
管理することが行われている
(例
えば,特許文献1参照)

【発明が解決しようとする課題】
【0004】ところで,近年,ネイティブアプリケ
ーションをダウンロードしてインストールすることができるスマートフォンが普及している。スマートフォンのユーザは,ネイティブアプリケーションをインストールする場合,アプリケーションを提供する所定のアプリケーションサーバにアクセスし,所望のネイティブアプリケーションを検索する。
【0005】
しかしながら,
CMSによって構築されるウェブアプリケーションは,
ウェブサイトとして構築されるため,検索サイトの検索結果として表示されることがあるものの,
アプリケーションサーバから検索することができない。
したがって,
アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに,CMSにより開発したウェブアプリケーションを利用してもらうことができないという問題がある。
【0006】これに対して,CMSによって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを開発し,当該ネイティブアプリケーションをアプリケーションサーバにアップロードすることも考えられる。しかしながら,ネイティブアプリケーションを新規に開発するには,多大な開発工数が必要であった。
【0007】本発明は,ネイティブアプリケーションを容易に生成することができるアプリケーション生成装置,アプリケーション生成システム及びアプリケーション生成方法を提供することを目的とする。
【課題を解決するための手段】
【0008】
本発明の第1の態様に係るアプリケーシ
ョン生成装置は,端末にインストールされると,所定のアクセス先にアクセスして情報を取得し,前記端末の表示部に表示させるネイティブアプリケーションを生成するアプリケーション生成装置であって,前記ネイティブアプリケーションのテンプレートであるテンプレートアプリケーションを記憶する記憶部と,ウェブアプリケーションのアドレスとともに,ネイティブアプリケーションの生成要求を示すリクエストを受け付ける受付部と,前記受付部が前記リクエストを受け付けたことに応じて,前記テンプレートアプリケーションの前記アクセス先を前記受付部が受け付けた前記アドレスに設定することで前記ネイティブアプリケーションを生成する生成部と,を備えることを特徴とする。
【0009】この発明によれば,アプリケーション生成装置は,生成部がテンプレートアプリケーションのアクセス先を,受付部が受け付けたウェブアプリケーションのアドレスに設定することで,当該テンプレートアプリケーションを,ウェブアプリケーションが表示する情報を表示するネイティブアプリケーションとして機能させることができる。したがって,アプリケーション生成装置は,受付部がウェブアプリケーションのアドレスを受け付けることで,当該ウェブアプリケーションと同等の機能を有するネイティブアプリケーションを容易に生成することができる。【0010】また,前記テンプレートアプリケーションは,前記アクセス先を設定する設定情報を含み,前記生成部は,前記受付部が前記リクエストを受け付けたことに応じて,前記テンプレートアプリケーションをコピーし,コピーされた前記テンプレートアプリケーションに含まれる前記設定情報の前記アクセス先を前記受付部が受け付けた前記アドレスに設定することで前記ネイティブアプリケーションを生成することを特徴とする。
この発明によれば,アプリケーション生成装置は,設定情報に含まれているアクセス先を,受付部が受け付けたアドレスに変更するという単純な処理によってネイティブアプリケーションを容易に生成することができる。
【発明を実施するための形態】
【0022】以下,本発明の実施形態について,図面を参照しながら説明する。<第1の実施形態>
[アプリケーション生成システムSの概要]
図1は,第1の実施形態に係るアプリケーション生成システムSの概要を示す図である。アプリケーション生成システムSは,アプリケーション生成装置1と,アプリケーション生成装置1とインターネット等のネットワークNを介して通信可能に接続された開発用端末2とを備え,ネイティブアプリケーションを生成するシステムである。
【0023】ネイティブアプリケーションは,例えば,スマートフォン等の携帯端末にインストールされるアプリケーションプログラムである。例えば,携帯端末のユーザは,アプリケーション提供サーバ3にアクセスして所望のネイティブアプリケーションを検索する。そして,携帯端末のユーザは,検索結果から所望のネイティブアプリケーションを選択し,アプリケーション提供サーバ3から当該ネイティブアプリケーションを取得して携帯端末にインストールする。
【0024】アプリケーション生成システムSのアプリケーション生成装置1は,例えば,開発用端末2の操作に応じて,ウェブアプリケーションを構築するコンテンツマネジメントシステムである。ここで,ウェブアプリケーションは,ネットワークNを介して実行されるアプリケーションであり,HTMLやJavaScript(登録商標)で記述される1以上のウェブページから構成されている。ウェブアプリケーションは,例えば,ブログ,有名人等のファンサイト,ゲームサイト,ショッピングサイト等である。
【0025】アプリケーション生成装置1は,例えば,ウェブアプリケーションのアドレスと,ネイティブアプリケーションの生成要求を示すリクエストとを受け付けると,受け付けたアドレスをアクセス先とするネイティブアプリケーションを生成して出力する。開発用端末2は,出力されたネイティブアプリケーションを取得し,
ネットワークNを介して,
アプリケーション提供サーバ3にアップロードする。
これにより,携帯端末のユーザは,アプリケーション提供サーバ3において,ウェブアプリケーションの情報を表示するネイティブアプリケーションを検索することができる。
【0026】その後,携帯端末のユーザが,当該ネイティブアプリケーションをアプリケーション提供サーバ3からダウンロードしてインストールを行うと,携帯端末の画面にアプリケーションのアイコンが表示される。携帯端末のユーザが,当該アイコンを実行するとネイティブアプリケーションが実行される。ネイティブアプリケーションは,起動すると,先に設定されたウェブアプリケーションのアドレスにアクセスしてウェブページを取得して表示する。そして,ネイティブアプリケーションは,表示されているウェブアプリケーションのリンク等が選択されると,当該リンク等にアクセスし,ウェブアプリケーションを構成する他のウェブページを取得して表示する。
【0027】
[アプリケーション生成装置1の機能構成]続いて,アプリケーション生成装置1の機能構成について説明する。図2は,第1の実施形態に係るアプリケーション生成装置1及び開発用端末2の機能構成図である。
アプリケーション生成装置1は,記憶部11と,受付部12と,生成部13と,変換部14と,送信部15とを備える。ここで,受付部12,生成部13,変換部14,及び送信部15は,例えば,CPU等により構成されている。【0028】記憶部11は,例えば,ROM(ReadOnlyMemory),RAM(Random
AccessMemory)
,ハードディスク等により構成される。記憶部11は,ネイティブアプリケーションのテンプレートであるテンプレートアプリケーション111を記憶する。
【0029】テンプレートアプリケーション111は,スマートフォン等の携帯端末にインストールされると,所定のアクセス先にアクセスして情報を取得し,当該端末の表示部に表示させるネイティブアプリケーションのテンプレートである。テンプレートアプリケーション111は,設定情報112と,1以上のプログラムファイル113とを含んでおり,記憶部11の所定のフォルダ内に格納されている。テンプレートアプリケーション111は,インストールされる端末のOSに対応して複数種類記憶されている。
【0030】設定情報112は,ネイティブアプリケーションのアクセス先,メニュー画面情報,及び表示態様情報に係る設定項目が含まれている。メニュー画面情報に係る設定項目には,ネイティブアプリケーションのメニュー画面に用いられるメニュー画像と,ネイティブアプリケーションのメニュー画面に表示させるリンク先とが含まれている。
【0031】表示態様とは,背景色,フォントの形状及びアイコン画像の形状等であり,ネイティブアプリケーションの表示態様情報に係る設定項目には,背景色,フォント及びアイコン画像を選択する項目が含まれている。背景色は,ネイティブアプリケーションが端末の表示部に情報を表示させる際の背景色であり,アイコン画像は,ネイティブアプリケーションのアイコンを示す画像である。【0032】1以上のプログラムファイル113は,例えば,汎用性の高い複数の関数プログラムをまとめたライブラリファイルや,設定情報112の各設定項目に基づいて情報を取得するためのプログラムファイル等から構成されている。【0033】受付部12は,開発用端末2から,ウェブアプリケーションのアドレスとともに,ネイティブアプリケーションの生成要求を示すリクエストを受け付ける。具体的には,受付部12は,まず,開発用端末2から,リクエスト用ページの取得要求を受け付けると,
リクエスト用ページを開発用端末2に送信する。
図3は,
第1の実施形態に係る開発用端末2の表示部23に表示されたリクエスト用ページ30の一例を示す図である。
【0034】図3に示すように,リクエスト用ページ30には,入力欄として,ネイティブアプリケーションがアクセスするウェブアプリケーションのロケーションを示すアドレスの入力欄31,ネイティブアプリケーションのメニュー画面に用いられるメニュー画像の入力欄32,及びネイティブアプリケーションのメニュー画面に表示されるリンク先の入力欄33が設けられている。ここで,入力欄32及び入力欄33は,複数設けられていてもよいし,当該リクエスト用ページに入力欄追加ボタンを設け,当該ボタンが押下されたことに応じて追加表示されてもよい。また,リクエスト用ページ30には,ネイティブアプリケーションの表示態様情報に係る入力欄として,背景色の入力欄34,及びアイコン画像の入力欄35が設けられている。
【0035】例えば,入力欄31には,ウェブアプリケーションのメインページのURLが入力される。メニュー画像の入力欄32には,メニューページに表示するメニュー画像のファイルの格納先アドレスが入力され,
リンク先の入力欄33には,
当該メニュー画像に対応するリンク先のページのアドレスが入力される。【0036】背景色の入力欄34には,カラーコード(RGB値を十六進法で表記した文字列)や背景画像を示すアドレスが入力される。アイコン画像の入力欄35には,画像ファイルのアドレスが入力される。ここで,入力欄32から入力欄35に入力する情報は,任意入力であってもよい。
【0037】リクエスト用ページ30には,入力欄の他に,ネイティブアプリケーションを出力するための画像である,出力ボタン36及び37が設けられている。出力ボタン36は,第1種別のOS用のアプリケーションを生成して出力するためのボタンであり,出力ボタン37は,第2種別のOS用のアプリケーションを生成して出力するためのボタンである。なお,リクエスト用ページ30には,他の種別のOS用のアプリケーションを生成して出力するためのボタンが設けられていてもよい。
【0038】開発用端末2のユーザが,入力欄31から入力欄35に各種情報を入力し,ネイティブアプリケーションの出力ボタン36又は37を押下すると,開発用端末2は,ウェブアプリケーションのアドレスを含む各種情報と,ネイティブアプリケーションの生成要求を示すリクエストとを送信する。受付部12は,開発用端末2から,ウェブアプリケーションのメインページのアドレス,メニュー画面情報,表示態様情報及びOSの種別を示す情報とともに,ネイティブアプリケーションの生成要求を示すリクエストを受け付ける。
【0039】生成部13は,受付部12がネイティブアプリケーションの生成要求を示すリクエストを受け付けたことに応じて,テンプレートアプリケーションのアクセス先を受付部12が受け付けたウェブアプリケーションのアドレスに設定することでネイティブアプリケーションを生成する。
【0040】具体的には,生成部13は,受付部12がリクエストを受け付けたことに応じて,テンプレートアプリケーション111をコピーする。そして,生成部13は,リクエストとともに受信したOSの種別を示す情報に基づいて,複数のテンプレートアプリケーション111から,当該OSの種別に対応するテンプレートアプリケーション111を特定する。そして,生成部13は,特定したテンプレートアプリケーション111が格納されている所定のフォルダをコピーすることで,テンプレートアプリケーション111をコピーする。
【0041】そして,生成部13は,コピーして新たに生成されたテンプレートアプリケーション111に含まれる設定情報の内容を書き換え,ネイティブアプリケーションを生成する。生成されたネイティブアプリケーションは,携帯端末にインストールされて実行されると,設定情報に含まれているウェブアプリケーションのアドレスに基づいて,
ウェブアプリケーションに対応するウェブページを取得する。
そして,ネイティブアプリケーションは,設定情報に含まれている表示態様情報に基づいて取得したウェブページの表示態様を変更し,携帯端末の表示部に表示させる。
【0042】より具体的には,生成部13は,コピーされたテンプレートアプリケーション111に含まれる設定情報の設定項目ネイティブアプリケーションのアクセス先に,受付部12が受け付けた,ウェブアプリケーションのアドレスを設定する。
また,生成部13は,設定情報の設定項目表示態様情報に,受付部12が受け付けた表示態様情報(背景色,フォント,アイコン画像)を設定する。【0043】また,生成部13は,受付部12が受け付けたメニュー画像,リンク先のアドレスに基づいて,当該リンク先のアドレスに関連付けられたメニュー画像を複数含むメニューページを生成する。生成部13は,このメニューページを,ネイティブアプリケーションが実行された際に最初に表示されるページとしてもよい。【0044】また,生成部13は,受付部12が受け付けた,ウェブアプリケーションのメインページのアドレスに基づいて,メインページを取得する。そして,生成部13は,取得したメインページに基づいて,ウェブアプリケーションのメニュー情報を生成する。例えば,生成部13は,取得したメインページに対応するウェブページのタグを解析し,
重要度の高いリンクを抽出する。
そして,
生成部13は,
抽出した重要度の高いリンクに含まれるメニュー情報を生成する。ここで,メニュー情報は,グローバルナビゲーションであり,ネイティブアプリケーションを介して表示される各ウェブページとともに表示される情報である。例えば,メニュー情報は,ネイティブアプリケーションを介して表示されたウェブアプリケーションのページの上部に付加される。端末のユーザは,ネイティブアプリケーションを介して表示されたウェブアプリケーションの各ページにおいて,グローバルナビゲーションに含まれる複数のリンクのいずれかを選択することにより,当該リンク先のウェブページに容易にアクセスすることができる。
【0045】変換部14は,生成部13が生成したネイティブアプリケーションを構成する設定情報と,1以上のプログラムファイルとを,端末がインストール可能な形式のファイルに変換する。具体的には,変換部14は,生成部13がネイティブアプリケーションを生成すると,当該ネイティブアプリケーションの設定情報及び1以上のプログラムファイルを格納している所定のフォルダを所定の方式で圧縮し,端末がインストール可能な形式のファイルに変換する。以下,変換したファイルをネイティブアプリケーションファイルともいう。
【0046】送信部15は,ネイティブアプリケーションファイルを所定の記憶領域に格納し,当該ファイルのアドレスを表示する送信用ページを開発用端末2に送信する。図4は,第1の実施形態に係る開発用端末2の表示部23に表示された送信用ページ40の一例を示す図である。図4に示される送信用ページ40は,図3に示されるリクエスト用ページにおいて,第1種別のOS用のアプリケーションを出力するための出力ボタン36が押下されたときの表示例を示す。図4に示されるように,送信用ページ40には,第1種別のOS用のアプリケーションが生成された旨を示す情報と,当該第1種別のOS用のアプリケーションをダウンロードするための画像であるダウンロードボタン41とが表示されている。送信部15は,開発用端末2において,送信用ページ40に設けられているダウンロードボタン41が押下されると,生成したネイティブアプリケーションファイルを開発用端末2に送信する。
【0050】
[処理フロー]続いて,アプリケーション生成装置1の処理の流れについて説明する。図5は,第1の実施形態に係るアプリケーション生成装置1において,ネイティブアプリケーションが開発用端末2に送信されるまでの処理の流れの一例を示すフローチャートである。
【0051】まず,受付部12は,開発用端末2からリクエストを受け付ける(S1)
。具体的には,要求部21が,アプリケーション生成装置1にリクエスト用ページ30の取得要求を行うと,受付部12は,開発用端末2に対してリクエスト用ページを送信し,開発用端末2から,ウェブアプリケーションのメインページのアドレス,メニュー画面情報,表示態様情報,OSの種別,及びネイティブアプリケーションの生成要求を示すリクエストを受け付ける。
【0052】続いて,生成部13は,受付部12がリクエストを受け付けたことに応じて,記憶部11の所定のフォルダに記憶されているテンプレートアプリケーション111をコピーする(S2)
。ここで,生成部13は,S1において受け付けた
OSの種別に対応したテンプレートアプリケーション111をコピーする。【0053】続いて,生成部13は,S1において受け付けたウェブアプリケーションのメインページのアドレス,メニュー画面情報,表示態様情報に基づいて,S2においてコピーしたテンプレートアプリケーション111を構成する設定情報の内容を書き換える(S3)
。これにより,コピーされたテンプレートアプリケーショ
ン111は,ネイティブアプリケーションになる。
【0054】続いて,変換部14は,S3において生成部13が生成したネイティブアプリケーションの設定情報及び1以上のプログラムファイルを格納している所定のフォルダを所定の方式で圧縮し,ネイティブアプリケーションファイルに変換する(S4)

【0055】続いて,送信部15は,ネイティブアプリケーションを開発用端末2に送信する(S5)
。具体的には,送信部15は,ネイティブアプリケーションファ
イルの格納先のアドレス及びダウンロードボタンを表示する送信用ページを開発用端末2に送信し,
開発用端末2において,
当該ダウンロードボタンが押下されると,
ネイティブアプリケーションファイルを開発用端末2に送信する。【0056】
[第1の実施形態における効果]以上,第1の実施形態によれば,アプリケーション生成装置1は,記憶部11が,ネイティブアプリケーションのテンプレートであるテンプレートアプリケーション111を記憶し,受付部12が,ウェブアプリケーションのアドレスとともに,ネイティブアプリケーションの生成要求を示すリクエストを受け付け,生成部13が,リクエストを受け付けたことに応じて,テンプレートアプリケーション111のアクセス先を受付部12が受け付けたアドレスに設定することでネイティブアプリケーションを生成する。【0057】このようにすることで,アプリケーション生成装置1は,生成部13がテンプレートアプリケーション111のアクセス先を,受付部12が受け付けたウェブアプリケーションのアドレスに設定することで,当該テンプレートアプリケーションを,ウェブアプリケーションが表示する情報を表示するネイティブアプリケーションとして機能させることができる。したがって,アプリケーション生成装置1は,受付部12がウェブアプリケーションのアドレスを受け付けることで,当該ウェブアプリケーションと同等の機能を有するネイティブアプリケーションを容易に生成することができる。
【図1】

【図2】
【図3】

【図4】
【図5】

(2)引用文献2には,以下のとおりの記載がある(甲2)


7.2カメラの利用カメラは,アプリケーション制作者がもっとも使いたいと思うハードウェアの一つでしょう。カメラの機能は,単にその機能を呼び出すだけでなく,取り出される映像の処理まで含めた知識が必要です。ここでその基本的な処理の仕方を身につけていきましょう。7.2.1カメラの利用とパーミッションカメラも,アプリケーション内から利用できると応用範囲がグッと広がるハードウェア機能です。単に写真を撮影するだけでなく,AR(拡張現実)などのアプリにもカメラは利用されています。カメラ機能を利用したアプリというのは意外に多いのです。このカメラ機能は,もちろんアプリケーション内から利用することができます。ただし,単に必要なソースコードを書けばOKというわけではないので注意が必要です。カメラを利用するためには,アプリケーションに「パーミッション(アクセス権)を用意する必要があります。これは,AndroidManifest.xmlに記述します。AndroidManifest.xmlを開き,<manifest>タグ内の適当なところに以下のタグを追記してください
(よくわからなければ,
最初の<manifest>の後を改行して記述してください)

リスト7.4
<uses-permission

android:name=”andro

id.permission.CAMERA”/>
<uses-permission

android:name=”andro

id.
permission.
WRITE_EXTERNAL_STORAGE”/

<uses-feature

android:name=”android.
h
ardware.camera”/>
これがカメラを利用する上で最低限必要なタグです。これらはそれぞれ以下のような役割を果たしています。
■<uses-permission>タグ
アプリケーションが必要とする許可を指定するものです。これはアプリケーションをインストールする際にチェックされます。
アプリケーションをインストールする際,
以下のアクセス許可を必要としていますといった表示が現れることがあります。あれは,実はこの<uses-permission>タグで記述されているものなのです。これにより,インストール時にアプリケーションが必要とするアクセス許可が表示され,ユーザーがそれを許可するとインストールされるようになります。
機能によっては,ユーザーがこれは勝手に使われたくないなと思うようなこともあります。そこで,この<uses-permission>タグによりこのアプリはこれこれの重要な機能を使いますが,許可しますか?ということを明記し,
ユーザーがそれを許可しないとインストールできないようにしているのです。■<uses-feature>タグ
アプリケーションで必要とする機能を指定するものです。<uses-permission>タグと異なり,これはユーザーが許可をするようなものではありません。これは,アプリケーションヘのインストールが可能かどうかを決めるのに利用されます。
例えば,この<users-feature>でカメラを指定してあれば,そのアプリはカメラ機能がない端末にはインストールできなくなります。つまりこれこれの機能が用意されている端末でないと動かないということを指定するためのものなのです。
ここでは,<uses-permission>にandroid.permission.CAMERA,<uses-feature>にandroid.hardware.cameraを指定しています。これにより,このアプリはカメラが搭載されている端末でのみ動作すること,カメラ機能を利用するための許可が必要であることが指定されていたのですね。
また,WRITE_EXTERNAL_STORAGEというのは,外部ストレージヘの書き出しを許可するものです。イメージの保存を行うため,これも用意しておきましょう。(356頁15行~357頁31行)


7.3.3GPS利用のパーミッション設定では,実際にGPSを利用したサンプルを作ってみましょう。まず最初に行うのは,AndroidManifest.xmlの変更です。GPSも,やはりパーミッション関係の情報を用意しなければ利用できないようになっています。AndroidManifest.xmlを開き,<manifest>タグ内に以下のタグを追加してください。リスト7.8<uses-permissionandroid:name=”android.permission.ACCESS_FINE_LOCATION”/><uses-featureandroid:name=”android.hardware.Location”/><uses-featureandroid:name=”android.hardware.Location.gps”/><uses-featureandroid:name=”android.hardware.Location.network”/>最初の<uses-permission>では,ACCESS_FINE_LOCATIONへのパーミッションを設定しています。これにより,ユーザーが位置情報へのアクセスを許可しないとアプリがインストールできないようになります。残る3つのタグは,<uses-feature>タグです。すなわち,これらの機能を内蔵するAndroid端末にしかインストールできないようにするものです。これにより,GPSやネットワーク機能がない端末にはアプリケーションをインストールできないようになります。これらのタグは,GPS利用には必須のものと考え,必ず用意してください。(3
68頁11行~29行)
(3)引用文献3には,以下のとおりの記載がある(甲3,乙1)。

第7章HTML5+JavaScriptでアプリ開発はじめてのPhoneGap(その1)ここまでできるPhoneGap(66頁表題)

PhoneGapを利用すると,iPhoneやAndroid,WindowsPhoneなどのマルチプラットホームに対応するアプリを作成できます.特にGPSなどのネイティブ機能にアクセスできる点が注目されています.(66頁副題)

現在同じコードから複数のプラットホームにアプリを生成できる表1のようなフレームワークがあります.ここでは,数あるフレームワークの中からPhoneGapを紹介します(図1).
(66頁中欄下から2行~右欄3行)


PhoneGapでできることPhoneGapでできることは,以下の通りです.①HTML5+CSS+JavaScriptを使用してネイティブアプリを作成②プラグインの仕組みを使って,カメラやGPSなど端末のネイティブ部分にアクセス可能③iOS,Android,BlackBerry,WebOS,WindowsPhone7,Symbian,Bada向けにアプリを作成できる①から分かるように,アプリを作るために必要な知識は,Webに関係する技術のみになります.もっとも注目すべき特徴は②のプラグインの仕組みがあることです.通常,HTML5やJavascriptだけでは,スマートフォンで実現できないことがたくさんあります.例えば,AndroidのIntent機能を使うにはネイティブの実装が必要です.そういった部分をプラグインがカバーすることで,ネイティブの機能を使ってより良いアプリを作ることができます.(66頁右欄13行~67頁左欄13行)

PhoneGapを使って,地図とGPSを組み合わせるPhoneGapのすばらしさを体験するのに,地図とGPSを組み合わせたアプリを例に紹介します.ここでは,GoogleMapsJavaScriptAPIV3(http://以下略)を使ってスマートフォン上に地図を表示します.さらに,PhoneGapの「Geolocationを使用して,現在位置にマーカーを表示します.
リスト4のソースを用意し,先ほど作成したプロジェクトのindex.htmlと置き換えます.マーカー用の20ピクセルの画像をpin.pngという名前で用意します.
各プラットホームでビルドし,実行すると,iPhone(図14),Andro
id(図15)
,WindowsPhone(図16)のように現在値の地図と,現在値のマーカーが表示されます.また,地図をタップするとタップした場所にマーカーが表示されます.
●仕組み
作成したリスト4を解説します.
<script
ogle

type=”text/javascript”の部分でGo

Mapのjsファイルを読み込んでいます.パラメータsensorは
GPSがある端末の場合は,trueを設定します.それ以外の場合は,falseを設定します.アプリのターゲットであるスマートフォンではGPSを搭載しているのでtrueと設定しています.(70頁右欄6行~72頁左欄25行)」
(4)引用文献4には,以下のとおりの記載がある(甲4)


ソースコード,リソース,設定,ライブラリ・・・設定ファイルは,そのアプリのアプリ名やバージョン,対応言語(英語や日本語etc.)などを記述しておくファイルです。中身は細かな項目が多いといえます。一見,そのような情報はソースコードに記述しておけば良いのではないかと思ってしまいますが,設定ファイルとして独立させておくことで,iOSやAndroidはそのアプリがどのような属性を持つアプリなのかをすぐに把握できるようになるわけです。(10頁右欄2行~11頁左欄6行)イ
設定ファイル「ios_sample-Info.plist

(5)のios_sample-Info.plistはアプリの設定ファイルです。アプリの名前やバージョン,そのアプリが利用するStoryboardのファイル等の情報が記述されています。iOSは(5)を読み取ることで,それらの情報を取得します。(14頁左欄下から2行~右欄4行)


超重要な設定ファイル「AndroidManifest.xml
(5)のAndroidManifest.xmlは,頻繁に編集することになる超重要な設定ファイルです(図14)
。この中ではアプリの名前やアイコン,対応する
Androidのバージョン,起動時に実行する○○Activityクラス,そのアプリをネットワークに接続できるようにするか?,SDカードにファイルを保存できるようにするか?などの,様々な項目を設定します。(16頁右欄下から8」
行~末行)
(5)引用文献5には,以下のとおりの記載がある(甲5,乙2)。

JavaScript/HTML5+PhoneGapの組み合わせが一番スマホアプリの作り方といっても,実はいろいろな方法があります(図1)。それらはいずれも一長一短で,快適に動くアプリを作れるけれど作り方が難しい方法もあれば,簡単にアプリを作れるけれど使い勝手の良いアプリは作りづらい方法もあります。日経ソフトウエア編集部では,様々ある方法を「ハードルが一番低そうなものはどれか?という点で吟味しました。その結果,この特集記事ではJavaScriptとHTML5+PhoneGapの組み合わせを採用することにしました。
JavaScriptとHTML5は,主にWebページで使われるテクノロジーです。Webブラウザとテキストエディタさえあればすぐにプログラミングができるので,ハードルは低いと言えるでしょう。
PhoneGap(フォンギャップ)はJavaScriptとHTML5のプログラムをスマホアプリ化する無償のソフトウエアです。Android版もiOS版もあります。
要するに,JavaScriptとHTML5+PhoneGapは,最もとっつきやすく,それでいてちゃんとしたアプリを作れる組み合わせなのです。(16」
頁左欄7行~27行)

ステップ4横画面に固定するスマートフォンでは端末が縦の姿勢のときと,横の姿勢のときで画面が切り替わります。ただ,ゲームでは画面が切り替わらない方が望ましいので,ここでは横画面に固定する設定を施します。Androidでは,AndroidManifest.xmlに「android:screenOrientation=”landscape”の1行を
追加します(図5)

iOSでは,左側のリストの青いアイコンのプロジェクト名(MatatabiPakkun)を選択すると,その右側にTARGETSという項目が現れるので,その下にあるMatatabiPakkunを選びます。すると,プロジェクトの各種設定が表示されます。この中にSupportedeDevicOrientationsという項目があるので,
LandscapeeftかLandscapeLRightを選びます。
これで,画面を横向きに固定できます。なお,ここでいうorientation
は方向
,landscapeは横方向という意味です。(29頁左欄1


~16行)

ステップ4縦画面に固定するこの電子書籍アプリは縦画面に固定します。そこで図6の設定を施してください。Androidでは,AndroidManifest.xmlに「android:screenOrientation=”portrait”の1行を追加
します。
iOSでは,
SupportedDeviceOrientationsの項目でPortraitを選びます。なお,portraitはここでは縦方向の意味です。(36頁左欄下から10行~末行)

(6)参考文献1には,以下のとおりの記載がある(甲8)


3Dグラフィクスと加速度センサ今回のサンプルアプリケーションは,加速度センサとOpenGLESを用いた3Dグラフィクス描画,それに,前のセクションで解説した音声再生を組み合わせたものになります(図1)。サンプルアプリケーションを起動すると,3Dグラフィクス界ではおなじみのティーポットの3Dモデルが表示されます。端末を傾けると視点が変化して,見る向きを変えることができます。また,画面をタッチして左右に指を動かすと,ティーポットを回転させることができます。音声は画面をタップすると再生を開始し,再生している間はティーポットの色が変わります。なお,ネイティブコードのみで実装する関係で,対象となるデバイスはGingerbread(Android2.3),NDKはRevision5以降が対象となります。それでは,今回もすべてのソースコードを含むプロジェクトファイルは,「SoftwareDesign2011年8月号の解説記事Androidエンジニアからの招待状のサポートページ(http://以下略)からダウンロードできますので,そちらをご覧いただきながら本稿を読み進めてもらえればと思います。
センサからの値の取得
デバイスに搭載されている各種センサの値をネイティブコードからも取得することができます。今回は表示するティーポットの向きを決めるために加速度センサを使って重力の方向を求めます。
センサに関するAPIと定数の定義はinclude/android/sensor.hにあります。(157頁左欄1行~右欄末行)


■AndroidManifest.xml加速度センサでデバイスの傾きを取得するため,傾けた際に画面のオリエンテーションが変わらないように,android:screenOrientation=”portrait”を追加してportraitで固定します。<activityandroid:name=”android.app.NativeActivity”android:label=”@string/app_name”android:screenOrientation=”portrait”>(162頁左欄13行~23行)
(7)乙3文献には,以下のとおりの記載がある(甲7,乙3)


PhoneGapは,HTML5,CSS3,JavaScriptなどのWeb標準技術を用いてiOSやAndroidなどのスマートフォン向けのネイティブアプリを開発するためのフレームワークです。(155頁左欄10行~14行)

カメラアプリの作成ここからはHTMLファイルを1つ作成して,各OSで動作することを確認します。今回はカメラで写真を撮影(もしくは,すでにある写真から選択)して,写真を画面に表示するカメラアプリを作ってみます。index.htmlファイルの作成自分の好きなエディタを使って,リスト3のindex.htm1ファイルを作成します。jQueryとjQueryMobileのファイルを使用していますので,必要なファイルをjQueryのWebサイトから取得して展開しておいてください。ポイントは,JavaScript部分のcapturePhoto()関数とgetPhoto()関数の中です。navigator.camera~とあるのは,PhoneGapのライブラリの関数を使用しています。PhoneGap側では,ネイティブの対応する機能を呼び出します。ここでは,カメラの撮影機能とギャラリー機能を呼び出しています(実際に呼び出されるアプリは,OSによって異なります)。これ以外にもJavaScriptでPhoneGapのAPIを呼び出せば,センサーやGPSの機能を使うことができます。これでカメラアプリを作成する準備が整いました。iOS編作成したindex,htmlファイルやjQuery関連のファイルを,HelloWorld作成時に作ったXcodeのプロジェクトの中に入れます。wwwフォルダの下にはindex.htm1ファイルがすでに存在していますので,作成したファイルで置き換えます。置き換えたらXcodeの実行ボタンを押して起動してみましょう。図10のような画面が表示されれば成功です。エミュレータの場合カメラは起動しませんが,その際はエラーが出ていることを確認できるかと思います。iPhoneやiPadで実行するとカメラで写真を撮って,画面に表示するのを確認できます。(159頁左欄1行~右欄4行)

Android編Eclipseを起動して,先ほどのHelloWorldプロジェクトのassets/wwwフォルダの中に「index.htmlやjQuery関連のファイルをコピーします。実行ボタンを押して実行すると,iOSの環境と同じように動いていることが確認できます(図11)」
。(160頁右欄1行~7行)

3
取消事由1(独立特許要件違反の有無―本件補正発明の進歩性の有無)につ
いて
(1)本件補正発明と引用発明との一致点及び相違点

前記2(1)で認定した引用文献1の記載からすると,引用発明の構成は以
下のとおり認められる。
アプリケーション生成装置1と開発用端末2とがインターネット等のネットワークNを介して通信可能に接続され,スマートフォン等の携帯端末にインストールされるアプリケーションプログラムであるネイティブアプリケーションを生成するアプリケーション生成システムであって,アプリケーション生成装置1は,記憶部11と,受付部12と,生成部13と,変換部14と,送信部15とを備え,記憶部11は,ネイティブアプリケーションのテンプレートであるテンプレートアプリケーション111を記憶し,ここで,テンプレートアプリケーション111は,スマートフォン等の携帯端末にインストールされると,所定のアクセス先にアクセスして情報を取得し,当該端末の表示部に表示させるネイティブアプリケーションのテンプレートであり,テンプレートアプリケーション111は,設定情報112と,1以上のプログラムファイル113とを含んでいて,記憶部11の所定のフォルダ内に格納されており,受付部12は,開発用端末2から,リクエスト用ページ30の取得要求を受け付けると,リクエスト用ページ30を開発用端末2に送信し,ここで,リクエスト用ページ30には,入力欄として,ネイティブアプリケーションがアクセスするウェブアプリケーションのロケーションを示すアドレスの入力欄31が設けられ,また,ネイティブアプリケーションの表示態様情報に係る入力欄として,背景色の入力欄34,及びアイコン画像の入力欄35が設けられており,入力欄31には,ウェブアプリケーションのメインページのURLが入力され,背景色の入力欄34には,カラーコードや背景画像を示すアドレスが入力され,アイコン画像の入力欄35には,画像ファイルのアドレスが入力され,受付部12が,開発用端末2から,ウェブアプリケーションのメインページのアドレス,及び表示態様情報とともに,ネイティブアプリケーションの生成要求を示すリクエストを受け付けると,生成部13は,コピーして新たに生成されたテンプレートアプリケーション111に含まれる設定情報の内容を,受付部12が受け付けたウェブアプリケーションのメインページのアドレス,及び表示態様情報に基づいて書き換えてネイティブアプリケーションを生成し,ここで,生成されたネイティブアプリケーションは,携帯端末にインストールされて実行されると,設定情報に含まれているウェブアプリケーションのアドレスに基づいて,ウェブアプリケーションに対応するウェブページを取得し,設定情報に含まれている表示態様情報に基づいて取得したウェブページの表示態様を変更して,携帯端末の表示部に表示させるものであり,変換部14は,生成部13がネイティブアプリケーションを生成すると,当該ネイティブアプリケーションの設定情報及び1以上のプログラムファイルを格納している所定のフォルダを所定の方式で圧縮し,端末がインストール可能な形式のネイティブアプリケーションファイルに変換し,送信部15は,ネイティブアプリケーションファイルを所定の記憶領域に格納し,当該ファイルのアドレスを表示する送信用ページを開発用端末2に送信し,開発用端末2において,送信用ページ40に設けられているダウンロードボタン41が押下されると,生成したネイティブアプリケーションファイルを開発用端末2に送信する,アプリケーション生成システム。イ
前記第2の2(2)で認定した本件補正発明の構成と前記アの引用発明の
構成を比較すると,両発明の一致点及び相違点は以下のとおりとなる。(ア)一致点
携帯通信端末の所定の機能を実行させるためのパラメータに応じて,前記携帯通信端末において実行されるアプリケーションの動作を規定する設定ファイルを設定する設定部と,前記設定ファイルに基づいてアプリケーションパッケージを生成する生成部と,を有するアプリケーション生成支援システムである点。(イ)相違点
a
相違点1

設定ファイルを設定するパラメータが,
本件補正発明では,
携帯通信端末に固有のネイティブ機能を実行させるためのパラメータであるのに対して,引用発明では,携帯通信端末の機能を実行させるためのパラメータではあるものの,携帯通信端末に固有のネイティブ機能を実行させるためのパラメータであることが特定されていない点。
b
相違点2

設定ファイルが,
本件補正発明では,
アプリケーションの,携帯通信端末の動きに伴う動作を規
定する設定ファイルであるのに対して,
引用発明では,
設定情報が,ネイティブアプリケーションのウェブページ取得
動作や表示動作を規定するものの,
携帯端末の動きに伴う
動作を規定するもので
あることが特定されていない点。
(2)相違点1についての判断
本件審決は,引用発明に引用文献2~5及び参考文献1記載の技術(同技術に乙3文献記載の技術を併せて,以下被告主張周知技術という。
)を適用することに
より,本件補正発明に想到し得ると判断していることから,引用発明に被告主張周知技術を適用する動機付けの有無について検討する。

引用発明

前記2(1)のとおり,引用文献1には,
近年,コンテンツマネジメントシステム(以下,CMS(ContentManagementSystem)という)によりウェブアプリケーションとして公開するコンテンツを構築し,管理することが行われている(例えば,特許文献1参照)。ところで,近年,ネイティブアプリケーションをダウンロードしてインストールすることができるスマートフォンが普及している。スマートフォンのユーザは,ネイティブアプリケーションをインストールする場合,アプリケーションを提供する所定のアプリケーションサーバにアクセスし,所望のネイティブアプリケーションを検索する。しかしながら,CMSによって構築されるウェブアプリケーションは,ウェブサイトとして構築されるため,検索サイトの検索結果として表示されることがあるものの,アプリケーションサーバから検索することができない。したがって,アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに,CMSにより開発したウェブアプリケーションを利用してもらうことができないという問題がある。これに対して,CMSによって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを開発し,当該ネイティブアプリケーションをアプリケーションサーバにアップロードすることも考えられる。しかしながら,ネイティブアプリケーションを新規に開発するには,多大な開発工数が必要であった。本発明は,ネイティブアプリケーションを容易に生成することができるアプリケーション生成装置,アプリケーション生成システム及びアプリケーション生成方法を提供することを目的とする。(段落【0002】【0004】~【0007】,
)と記載されており,同
記載からすると,引用発明は,CMSによって構築されるウェブアプリケーションは,アプリケーションサーバから検索することができないため,アプリケーションサーバにおいてネイティブアプリケーションを検索したユーザに,CMSにより開発したウェブアプリケーションを利用してもらうことができないこと及びCMSによって構築したウェブアプリケーションと同等の機能を有するネイティブアプリケーションを新規に開発するには,多大な開発工数が必要となることを課題とし,同課題を解決するためのネイティブアプリケーションを生成する装置であることが認められる。
引用発明は,上記課題を解決するために,前記(1)アで認定したとおり,既存のウェブアプリケーションのロケーションを示すアドレスや所望の背景画像を示すアドレス等の情報を入力するだけで,当該ウェブアプリケーションの表示態様を変更して,同ウェブアプリケーションが表示する情報を表示するネイティブアプリケーションを生成できるようにしたものと認められる。

被告は,携帯通信端末の動きに伴う動作を行うネイティブアプリケーシ
ョンを生成すること,
特に,
PhoneGapに係る技術が周知であると主張する。
(ア)前記アのとおり,
引用発明は,
アプリケーションサーバにおいて検索で
きるネイティブアプリケーションを簡単に生成することを課題として,同課題を,既存のウェブアプリケーションのアドレス等の情報を入力するだけで,同ウェブアプリケーションが表示する情報を表示できるネイティブアプリケーションを生成することができるようにすることによって解決したものであるから,ブログ等の携帯通信端末の動きに伴う動作を行わないウェブアプリケーションの表示内容を表示するネイティブアプリケーションを生成しようとする場合,生成しようとするネイティブアプリケーションを携帯通信端末の動きに伴う動作を行うようにする必要はなく,したがって,設定ファイルを設定するパラメータを携帯通信端末に固有のネイティブ機能を実行するためのパラメータとする必要はない。もっとも,引用文献1の段落【0024】には,ブログ等と並んでゲームサイトが掲げられており,ゲームにおいては,加速度センサにより横画面と縦画面が切り替わらないように制御する必要がある場合が考えられる(引用文献5参照)が,ウェブアプリケーションとして提供されるゲームは,①常に携帯通信端末の表示画面を固定する必要があるとはいえないこと,②加速度センサにより,携帯通信端末の姿勢に対応した画面回転表示を制御する機能は携帯通信端末側に備わっており,端末側の操作によって,表示画面を固定することができ,そのような操作は一般的に行われていること,③引用文献1の段落【0024】のゲームサイトは,携帯通信端末の表示画面を固定する必要のないブログ,ファンサイト,ショッピングサイトと並んで記載されており,また,引用文献1には,加速度センサについて何らの記載もないことからすると,当業者は,上記のゲームサイトの記載から,パラメータを携帯通信端末に固有のネイティブ機能を実行するためのパラメータとすることの必要性を認識するとまではいえないというべきである。
また,引用発明によって生成されるネイティブアプリケーションは,HTMLやJavaScriptで記述されるウェブページを表示できるから,引用発明により,乙4に記載されたHTML5

APIのGeolocationを用いて携帯

通信端末の動きに伴う動作を行うウェブアプリケーションの表示内容を表示するネイティブアプリケーションを生成しようとする場合も,生成されるネイティブアプリケーションは,設定情報に含まれているウェブアプリケーションのアドレスに基づいて,同ウェブアプリケーションに対応するウェブページを取得し,取得したウェブページのHTMLやJavaScriptの記述に基づいて,同ウェブアプリケーションの内容を表示でき,したがって,ネイティブアプリケーションの生成に際して,設定ファイルを設定するパラメータを携帯通信端末に固有のネイティブ機能を実行させるためのパラメータとする必要はない。さらに,被告主張周知技術に係る各種文献にも,引用発明の上記の構成の技術において,
携帯通信端末に固有のネイティブ機能を実行させるためのパラメータに
応じて設定ファイルを設定することの必要性等については何ら記載されていない(甲2~5,7,8,乙1~3)

(イ)前記アのとおり,
引用発明は,
簡易にネイティブアプリケーションを生
成することを課題として,既存のウェブアプリケーションのアドレス等の情報を入力するだけで,当該ウェブアプリケーションが表示する情報を表示するネイティブアプリケーションを生成できるようにしたのであり,具体的には,前記(1)アのとおり,入力しようとするウェブアプリケーションのロケーションを示すアドレス及び表示態様に基づいて,テンプレートアプリケーション111に含まれる設定情報の内容を書き換えるだけで目的とするウェブアプリケーションの表示する情報を表示できるネイティブアプリケーションを生成でき,テンプレートアプリケーション111に含まれるプログラムファイル113については,新たにソースコードを書く必要はないところ,証拠(甲3,5,7,乙1~3)によると,PhoneGapによってネイティブアプリケーションを生成するためには,HTMLやJavaScript等を用いてソースコード(プログラム)を書くなどする必要があるものと認められるから,引用発明に,上記のように,新たにソースコードを書くなどの行為が要求されるPhoneGapに係る技術を適用することには阻害事由があるというべきである。
被告は,①PhoneGapでは,PhoneGapのプラグインの仕組みを使って,GPSなど端末のネイティブ部分にアクセス可能であり,端末のGPS機能にアクセスすることで,GPSで取得した端末の現在位置が中心となるように地図を表示することが可能となるから,引用発明において地図表示アプリケーションを生成する際に,PhoneGapのフレームワークを採用することで,ネイティブ機能であるGPS機能が利用可能となり,携帯通信端末の動きに伴う動作を設定可能となり,また,②AndroidManifest.xmlにandroid:screenOrientation=”landscape”の1行を追加し
たり(Androidの場合)Landscape,dscapeRight又はLanLeftのアイコンを選択すること(iOSの場合)で,スマー
トフォンの画面を横画面に固定可能となり,縦画面に固定する設定を施す場合,AndroidManifest.xmlにandroid:screenOrientation=”portrait”の1行を追加したり(Android
の場合)portraitのアイコンを選択すること(iOSの場合)で,ス,
マートフォンの画面を縦画面に固定可能となるから,引用発明において,アプリケーションを生成する際に,PhoneGapのフレームワークを利用することで,携帯通信端末に固有のネイティブ機能を実行させるためのパラメータに応じて,
携帯通信端末において実行されるアプリケーションの,携帯通信端末の動きに伴う動作を規定する設定ファイルを備えることとなると主張する。しかし,上記のとおり,引用発明にPhoneGapの技術を適用することの動機付けはないから,
被告の上記主張は,
その前提を欠くものであって,
理由がない。
(ウ)以上からすると,
引用発明に,
被告主張周知技術を適用することの動機
付けは認められないというべきである。

以上のとおり,引用発明に被告主張周知技術を適用することの動機付け
はないから,引用発明に被告主張周知技術を適用して,相違点1の構成について,本件補正発明の構成とすることは容易に想到することはできず,したがって,本件補正発明は,引用発明及び被告主張周知技術に基づいて容易に発明することができたということはできない。
(3)したがって,取消事由1は理由がある。
第6

結論

よって,主文のとおり判決する。

知的財産高等裁判所第2部

裁判長裁判官
森義之
裁判官
佐野熊谷信
裁判官
大輔
トップに戻る

saiban.in