【事件の表示】
　特願２０１７−　４６６７０「モデル駆動開発を使用するモバイルベースアプリケーションを開発するシステムおよび方法」拒絶査定不服審判事件〔平成２９年１１月　２日出願公開、特開２０１７−１９９３５９〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯
　本願は，平成２９年３月１０日（パリ条約による優先権主張外国庁受理２０１６年３月１１日（以下，「優先日」という。）　インド）の外国語書面出願であって，
　平成２９年７月６日付けで特許法第３６条の２第２項の規定による外国語書面，及び，外国語要約書面の日本語による翻訳文が提出されるとともに審査請求がなされ，平成３０年８月２日付けで審査官により拒絶理由が通知され，これに対して同年１２月２１日付けで意見書が提出されるとともに手続補正がなされたが，令和１年５月２７日付けで拒絶査定（以下，「原査定」という。）がなされ，これに対して同年９月２７日付けで拒絶査定不服審判の請求がなされたものである。
第２　本願発明
　本願の請求項９に係る発明（以下，「本願発明」という。）は，平成３０年１２月２１日付けの手続補正により補正された特許請求の範囲の請求項９に記載された，次のとおりのものである。
「　【請求項９】
　モバイルベースアプリケーションを開発する方法であって、
　メタモデリングモジュール（１１０）を使用して、前記モバイルベースアプリケーションを開発するための、複数の要件を収集するステップ；
　ユーザインターフェイスモデラ（１１２）を使用して、前記モバイルベースアプリケーションの少なくとも１つのスクリーンを設計するステップであって、前記スクリーンは前記複数の要件に基づいて設計されるステップ；
　スクリーンフローモデラ（１１４）を使用して、前記モバイルベースアプリケーションのスクリーン間のナビゲーションを設計するステップ；
　入力デバイス（１０８）を使用して、複数のテクノロジプラットフォームを選択するステップ；
　コード生成器モジュール（１１６）を使用して、前記選択された複数のテクノロジプラットフォームに応じて複数のコードを生成するステップ；および
　モバイルアプリケーションバンドリングモジュール（１１８）を使用して、前記コードをバンドリングすることによって、前記モバイルベースアプリケーションを開発するステップ；および
　開発レポジトリ（１２４）データベースを使用してプラットフォームに独立の方法で複数のコードを記憶するステップ
　を含む、前記方法。」
第３　原査定における拒絶理由の概要
　原査定における拒絶理由の概要は，この出願の請求項１乃至請求項１０に係る発明は，本願の優先日前に日本国内又は外国において，頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献１乃至引用文献３に記載された発明に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない，というものである。
引用文献１．井上　尚紀，ＧＵＩを考慮したＭＤＡ開発手法の提案，情報処理学会研究報告　２０１１（平成２３）年度（１）　［ＣＤ−ＲＯＭ］，日本，一般社団法人情報処理学会，２０１１年６月１５日，ｐｐ．１−８
引用文献２．赤瀬　智也，画面遷移モデルと整合性を保つＧＵＩ設計支援手法，電子情報通信学会技術研究報告，日本，一般社団法人電子情報通信学会，２０１６年２月２５日，第１１５巻，第４８７号，ｐｐ．１３１−１３６
引用文献３．目指せスピード１０倍増！　超高速開発・リノベーションフォーラム２０１３　Ｒｅｖｉｅｗ，日経コンピュータ，日本，日経ＢＰ社，２０１３年６月２７日，第８３７号，ｐｐ．９６−９７
第４　引用文献に記載された事項及び引用発明等
１　引用文献１に記載された事項及び引用発明
（１）原査定における拒絶理由で引用された引用文献１には，関連する図面とともに，以下の事項が記載されている。
（下線は，参考のために当審で付与したものである。また，文献中に記載の丸付き数字は，「○数字：」に置き換えることとした。以下同様。）
Ａ　「１．　研究背景
１．１　はじめに
　ソフトウェアをとりまくビジネス環境や実装技術の進歩は日々変化しており，変化に強いソフトウェア開発が求められている．そこで，近年注目されている開発手法のひとつが標準化団体ＯＭＧ（Object Management Group）が提唱している
ＭＤＡ（Model Driven Architecture：モデル駆動アーキテクチャ）
　一方，業務などに利用されるソフトウェアの開発では，ユーザインターフェイスがどのぐらい分かりやすく使いやすいかがソフトウェアの品質に大きな影響を与える．
　しかし，ＭＤＡにおける
ＧＵＩ（Graphical User Interface）
　評価実験の結果，
本手法は，ＧＵＩレイアウト情報を含めたプラットフォーム独立なＧＰＩＭから，ソースコードを生成することができ，複数のプラットフォームに対応できる
１．２　背景知識
１．２．１　ＭＤＡ
　ＭＤＡはＯＭＧが提唱しているソフトウェア開発手法である．
ＣＩＭ（Computation Independent Model：計算処理非依存モデル）
ＰＩＭ（Platform Independent Mode1：プラットフォーム独立モデル）
ＰＳＭ（Platform Specific Model：プラットフォーム依存モデル）
（第１ページ左欄第１５行−右欄第１８行）
Ｂ　「３．　提案手法
　前章で述べた研究アプローチをもとに，手法の提案を行う．
　３．１　前提条件
　
本手法は，ＭＤＡ開発においてＧＵＩのアプリケーションソフトウェアを開発する為の手法である
画面遷移の問題は扱わない
　３．２　提案手法概要
　提案手法の概要を図３−１に示す．
アプリケーション開発者は最初に作成したＣＩＭを基に抽象ＧＵＩビルダにより抽象ＧＵＩ情報を作成し，並行してＵＭＬモデリングツールによりＰＩＭ（クラス図）を描画する．次にそれぞれを統合したものをＧＰＩＭ（拡張クラス図）とし，ＰＳＭヘモデル変換し，ソースコードを生成する．
　ＰＳＭへの変換とソースコード生成は従来技術を用いる．
　３．３　各ステップ詳細
　３．３．１
○１：ＣＩＭ作成
　
ＣＩＭにはシステムによって扱われる情報のフローを記述し，特に，入力させる情報や選択させる情報を記述する．
処理フロー上の複数の選択肢から，ユーザに何かを選択させる場合は，その選択肢もここで記述する．
　３．３．２
○２：抽象ＧＵＩビルダによる抽象ＧＵＩ情報作成
　
ＣＩＭで示された業務フロー中のコンピュータと人とのやりとりを，具体的にどのような画面構成で実現するかを決定し，抽象ＧＵＩ情報として出力する
（第２ページ右欄第２９行−第３ページ左欄第１８行）
Ｃ　「３．３．３
○３：ＵＭＬモデリングツールによるＰＩＭ作成
　
ＣＩＭを基に，扱いたい情報と機能のみをクラス図によりＰＩＭをモデリングする．
　３．３．４
○４：ＰＩＭと抽象ＧＵＩ情報の統合
　図３−３にＰＩＭと抽象ＧＵＩ情報の統合ルールを示す．
ＰＩＭと抽象ＧＵＩ情報を統合する
（第４ページ左欄第１３行−第２４行）
Ｄ　「３．３．５
○５：ＰＳＭへのモデル変換
　
ＧＰＩＭの表現を，ＧＵＩエレメントについては，抽象的なＧＵＩの情報をプログラミング言語に依存した形に，その他のクラスについては従来技術を用いて変換する．
　３．３．６
○６ソースコード生成
　
ＰＳＭからソースコードを生成する．
ソースコード生成は従来技術を用いる
（第５ページ左欄第１行−右欄第２行）
Ｅ　「５．２　今後の課題
　
今後の課題として，画面遷移のあるプログラムへの適応
●　画面遷移のあるプログラムへの適応
　本研究では対象を，画面遷移のない，比較的小さなソフトウェア作成に限定したが，ＧＵＩソフトウェアの多くは，画面遷移を行っている．これには画面遷移をモデルに表す難しさや，ＰＩＭとの対応関係などの問題があるが，これを解決できればより汎用的で実用的な手法になると考えられる．」
（第８ページ右欄第１行−第８行）
（２）上記Ａ乃至Ｅの記載から，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
「ＭＤＡ（Model Driven Architecture：モデル駆動アーキテクチャ）開発においてＧＵＩ（Graphical User Interface）のアプリケーションソフトウェアを開発する為の手法であって，
　アプリケーション開発者は最初に作成したＣＩＭ（Computation Independent Model：計算処理非依存モデル）を基に抽象ＧＵＩビルダにより抽象ＧＵＩ情報を作成し，並行してＵＭＬモデリングツールによりＰＩＭ（Platform Independent Mode1：プラットフォーム独立モデル）（クラス図）を描画し，次にそれぞれを統合したものをＧＰＩＭ（拡張クラス図）とし，ＰＳＭ（Platform Specific Model：プラットフォーム依存モデル）ヘモデル変換し，ソースコードを生成するものであって，ＧＵＩレイアウト情報を含めたプラットフォーム独立なＧＰＩＭから，ソースコードを生成することができ，複数のプラットフォームに対応できるものであり，
　○１：ＣＩＭ作成において，ＣＩＭにはシステムによって扱われる情報のフローを記述し，特に，入力させる情報や選択させる情報を記述し，
　○２：抽象ＧＵＩビルダによる抽象ＧＵＩ情報作成において，ＣＩＭで示された業務フロー中のコンピュータと人とのやりとりを，具体的にどのような画面構成で実現するかを決定し，抽象ＧＵＩ情報として出力し， 
　○３：ＵＭＬモデリングツールによるＰＩＭ作成において，ＣＩＭを基に，扱いたい情報と機能のみをクラス図によりＰＩＭをモデリングし，
　○４：ＰＩＭと抽象ＧＵＩ情報の統合において，ＰＩＭと抽象ＧＵＩ情報を統合し，ＧＰＩＭ（拡張クラス図）とし，
　○５：ＰＳＭへのモデル変換において，ＧＰＩＭの表現を，ＧＵＩエレメントについては，抽象的なＧＵＩの情報をプログラミング言語に依存した形に，その他のクラスについては従来技術を用いて変換し，
　○６：ソースコード生成において，ＰＳＭからソースコードを生成するものであって，ソースコード生成は従来技術を用いる，
　ＭＤＡ開発手法。」
２　引用文献２に記載された事項及び技術
（１）原査定における拒絶理由で引用された引用文献２には，関連する図面とともに，以下の事項が記載されている。
Ｆ　「２．２．モデル駆動開発とその問題点
　機能設計と整合性を保ったＧＵＩを効率的に生成するための手法として
モデル駆動開発によるＧＵＩ生成
（第１３２ページ左欄第２６行−第２９行）
Ｇ　「
ＧＵＩ設計のプロセスはまず○１：機能設計者が機能モデルとして画面遷移モデルを作成
（第１３２ページ右欄第３５行−第１３３ページ左欄第２行）
Ｈ　「３．１．機能モデルとしての画面遷移モデル
　本研究で利用する既存の
画面遷移モデル
は，次の２つの図により構成される
画面と，その画面内で扱う入出力項目をクラス図の類似記法で表現した
画面構造図
画面遷移をステートマシン図の類似記法で表現した
画面遷移図
（第１３３ページ左欄第１１行−第２０行）
Ｉ　「
      
」
（第１３３ページ左欄）
（２）上記Ｆ乃至Ｉの記載から，引用文献２には，次の技術が記載されているものと認める。
「モデル駆動開発によるＧＵＩ生成であって，
　ＧＵＩ設計のプロセスは，まず機能設計者が機能モデルとして画面遷移モデルを作成するものであって，
　画面遷移モデルは，画面と，その画面内で扱う入出力項目をクラス図の類似記法で表現した画面構造図と，画面遷移をステートマシン図の類似記法で表現した画面遷移図で構成される，
　モデル駆動開発によるＧＵＩ生成。」
３　引用文献３に記載された事項及び技術
（１）原査定における拒絶理由で引用された引用文献３には，関連する図面とともに，以下の事項が記載されている。
Ｊ　「２０年以上の実績を持つモデルドリブンの開発支援ツール
　ＣＡ　Ｔｅｃｈｎｏｌｏｇｉｅｓが提供する「ＣＡ　Ｇｅｎ」は、
「モデルドリブン開発（モデル駆動開発）」をベースとした統合型アプリケーション開発ツールである。
・・・（中略）・・・
　具体的には、先ず開発者はＰＣやワークステーション上の統合化されたモデリング環境で、ＧＵＩベースのダイヤグラムによってデータモデルやビジネスロジック、画面などを設計、記述する。そして、それらの複数の
モデリング環境で作成されたビジネスロジック、データアクセス定義、ユーザーインタフェースという３つの情報を含むモデルをレポジトリに格納。それに基づいて本番環境の各種プラットフォームをターゲットとしたアプリケーションを自動生成する。
（第９６ページ左欄第１行−中欄第１３行）
（２）上記Ｊの記載から，引用文献３には，次の技術が記載されているものと認める。
「モデルドリブン開発（モデル駆動開発）をベースとした統合型アプリケーション開発ツールであって，
　モデリング環境で作成されたビジネスロジック，データアクセス定義，ユーザーインタフェースという３つの情報を含むモデルをレポジトリに格納し，それに基づいて本番環境の各種プラットフォームをターゲットとしたアプリケーションを自動生成する，
　モデルドリブン開発（モデル駆動開発）をベースとした統合型アプリケーション開発ツール。」
４　参考文献１に記載された事項
　本願の優先日前公知の文献である下記の参考文献１には，関連する図面とともに，以下の事項が記載されている。
参考文献１．越賀　準，Ｅｖｅｎｔ−Ｂによるモデル駆動モバイルアプリケーション開発，電子情報通信学会技術研究報告，日本，一般社団法人電子情報通信学会，２０１２年１１月２３日，第１１２巻，第３３１号，ｐｐ．７−１２
Ｋ　「４．　Ｅｖｅｎｔ−Ｂによるモデル駆動
　本研究では，
モデル駆動アーキテクチャ（ＭＤＡ：Model Driven Architecture）
で言うところのＰＩＭ（Platform-independent model）と呼ばれる，特定のプラットフォームや技術に依存することなく，Ｅｖｅｎｔ−Ｂを用いてモバイルアプリケーション開発のモデル化
　４．１　Ｅｖｅｎｔ−Ｂとモバイルアプリケーション
　本研究では，形式仕様記述言語の１つであるＥｖｅｎｔ−Ｂを用いて，モデル化を行う．
Ｅｖｅｎｔ−Ｂはモデル指向型の仕様記述言語
（第１０ページ右欄第１行−第１２行）
５　参考文献２に記載された事項
　本願の優先日前公知の文献である特表２０１１−５０１２９７号公報（公表日；平成２３年１月６日，以下，これを「参考文献２」という。）には，関連する図面とともに，以下の事項が記載されている。
Ｌ　「【００１４】
　図を初めに参照すると、図１はコンピュータで実現される
ソフトウェアファクトリ仕様化システム１００
メタモデル１１０
ユーザ（例えば、ファクトリ開発者）は、メタモデル１１０と対話処理して、特定のソフトウェアファクトリのためのファクトリスキーマ１３０を定義する
【００１５】
　
ファクトリスキーマ１３０は、対話型開発環境において、
プロダクト（例えば、クライアントアプリケーション、モバイルクライアント、ウェブサービス、その他）の仕様化
を支援する。
６　参考文献３に記載された事項
　本願の優先日前公知の文献である特開２０１４−７１８９９号公報（公開日；平成２６年４月２１日，以下，これを「参考文献３」という。）には，関連する図面とともに，以下の事項が記載されている。
Ｍ　「【００３４】
　本発明によるシステムは、記憶メモリとプロセッサとを有するシステムであって、前記システムは、
複数のソフトウェアコンポーネントのソースコードを記憶するソースコンポーネントリポジトリであって、
各ソフトウェアコンポーネントはどの実行時環境からも実質的に独立である、ソースコンポーネントリポジトリ
第５　対比
　
１　本願発明と引用発明とを対比する。
　
（１）引用発明は，「アプリケーションソフトウェアを開発する為の手法」であるから，本願発明と引用発明とは，後記する点で相違するものの，“アプリケーションを開発する方法”である点で一致している。
（２）引用発明は，「アプリケーション開発者は最初に」「ＣＩＭ（Computation Independent Model：計算処理非依存モデル）」を作成するものであって，「○１：ＣＩＭ作成において，ＣＩＭにはシステムによって扱われる情報のフローを記述し，特に，入力させる情報や選択させる情報を記述」するものである。
　ここで，「ＣＩＭ」に記述される前記「システムによって扱われる情報のフロー」，「入力させる情報や選択させる情報」とは，開発するアプリケーションの仕様に関する複数の情報であって，アプリケーションを開発するための「複数の要件」といえるから，引用発明においても，アプリケーションを開発するための複数の要件を入力，すなわち収集しているといえる。
　よって，本願発明と引用発明とは，後記する点で相違するものの，“前記アプリケーションを開発するための，複数の要件を収集するステップ”を含む点で一致している。
（３）引用発明は，「○２：抽象ＧＵＩビルダによる抽象ＧＵＩ情報作成において，ＣＩＭで示された業務フロー中のコンピュータと人とのやりとりを，具体的にどのような画面構成で実現するかを決定し，抽象ＧＵＩ情報として出力」するものである。
　ここで，前記「画面構成」は，本願発明の「スクリーン」に相当するところ，「ＣＩＭで示された業務フロー中のコンピュータと人とのやりとりを，具体的にどのような画面構成で実現するかを決定」することは，ＣＩＭに基づいて画面構成，すなわち「スクリーン」を設計することに他ならず，また，上記（２）で検討したように，ＣＩＭには「複数の要件」が記述されるものであるから，「複数の要件」に基づいて「スクリーン」を設計することになり，結局，引用発明も，“アプリケーションの少なくとも１つのスクリーンを設計するステップであって，前記スクリーンは前記複数の要件に基づいて設計されるステップ”を含んでいるといえる。
　そして，引用発明は，かかるスクリーンを設計するステップを，「抽象ＧＵＩビルダ」による抽象ＧＵＩ情報作成において行うものであるから，引用発明の「抽象ＧＵＩビルダ」は，本願発明の「ユーザインターフェイスモデラ（１１２）」に相当する。
　よって，本願発明と引用発明とは，後記する点で相違するものの，“ユーザインターフェイスモデラ（１１２）を使用して，前記アプリケーションのスクリーンを設計するステップであって，前記スクリーンは前記複数の要件に基づいて設計されるステップ”を含む点で一致している。
（４）引用発明は，「ＧＵＩレイアウト情報を含めたプラットフォーム独立なＧＰＩＭから，ソースコードを生成することができ，複数のプラットフォームに対応できる」ものであるから，各プラットフォームに対応してソースコードが生成されるものであり，複数のプラットフォームにそれぞれ対応した複数のソースコードが生成されていることは明らかである。
　また，引用発明は，「ソースコード生成は従来技術を用いる」としており，ソースコード生成において従来から一般的に用いられている何らかのコード生成器を使用していることも明らかである。
　よって，本願発明と引用発明とは，後記する点で相違するものの，“コード生成器モジュール（１１６）を使用して，複数のテクノロジプラットフォームに応じて複数のコードを生成するステップ”を含む点で一致している。
２　上記（１）乃至（４）の検討から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
＜一致点＞
「アプリケーションを開発する方法であって，
　前記アプリケーションを開発するための，複数の要件を収集するステップ；
　ユーザインターフェイスモデラ（１１２）を使用して，前記アプリケーションの少なくとも１つのスクリーンを設計するステップであって，前記スクリーンは前記複数の要件に基づいて設計されるステップ；
　コード生成器モジュール（１１６）を使用して，複数のテクノロジプラットフォームに応じて複数のコードを生成するステップ；
　を含む，前記方法。」
＜相違点１＞
　開発するアプリケーションに関し，本願発明では，「モバイル」アプリケーションであるのに対して，引用発明では，「モバイル」アプリケーションであるとは特定されていない点。
＜相違点２＞
　複数の要件を収集するステップに関し，本願発明では，「メタモデリングモジュール（１１０）を使用」するものであるのに対して，引用発明では，「メタモデリングモジュール（１１０）を使用」することが特定されていない点。
＜相違点３＞
　本願発明では，「スクリーンフローモデラ（１１４）を使用して、前記モバイルベースアプリケーションのスクリーン間のナビゲーションを設計するステップ」を含むのに対して，引用発明では，そのようなステップを含んでいない点。
＜相違点４＞
　本願発明では，「入力デバイス（１０８）を使用して、複数のテクノロジプラットフォームを選択するステップ」を含み、コード生成器モジュール（１１６）が「選択された」複数のテクノロジプラットフォームに応じて複数のコードを生成するのに対して，引用発明では，そのようなステップを含むことが特定されておらず，よって，複数のテクノロジプラットフォームが，「選択された」複数のテクノロジプラットフォームであることも特定されていない点。
相違点５
　本願発明では，「モバイルアプリケーションバンドリングモジュール（１１８）を使用して、前記コードをバンドリングすることによって、前記モバイルベースアプリケーションを開発するステップ」を含むのに対して，引用発明では，そのようなステップを含むことが特定されていない点。
＜相違点６＞
　本願発明では，「開発レポジトリ（１２４）データベースを使用してプラットフォームに独立の方法で複数のコードを記憶するステップ」を含むのに対して，引用発明では，そのようなステップを含むことが特定されていない点。
第６　当審の判断
　
１　相違点１について
　引用発明は，「ＭＤＡ（Model Driven Architecture：モデル駆動アーキテクチャ）開発においてＧＵＩ（Graphical User Interface）のアプリケーションソフトウェアを開発する為の手法」であるところ，開発するアプリケーションとしてどのようなアプリケーションを選択するかは，当業者が必要に応じて適宜選択し得る事項にすぎない。
　この点に関して，上記第４　４で示した参考文献１に，モデル駆動アーキテクチャ（ＭＤＡ）を用いて「モバイル」アプリケーションを開発することが開示されているように，モデル駆動アーキテクチャ（ＭＤＡ）を用いて「モバイル」アプリケーションを開発することが従来から行われていたことも鑑みれば，引用発明において，開発するアプリケーションとして，「モバイル」アプリケーションを選択することは，当業者であれば任意になし得た事項に過ぎないと認められる。
２　相違点２について
　引用発明においても，上記第５　１（２）で検討したように，アプリケーションを開発するための複数の要件を収集しているといえるところ，かかる収集をどのような手段を用いて実施するかは，当業者が適宜選択し得た事項にすぎない。
　この点に関して，上記第４　５で示した参考文献２に，ソフトウェアファクトリ仕様化システムにおいて，メタモデルを備え，前記メタモデルがプロダクトの仕様化を支援するファクトリースキーマを定義することが開示されているように，ソフトウェアの仕様を作成する際にメタモデルを用いることが通常行われていたことも鑑みれば，引用発明において，「メタモデリングモジュール」を用いて要件を収集するとすることに格別の創意は見出せない。
３　相違点３について
　上記第４　２（２）で示したように，引用文献２には，次の技術が記載されている。
「モデル駆動開発によるＧＵＩ生成であって，
　ＧＵＩ設計のプロセスは，まず機能設計者が機能モデルとして画面遷移モデルを作成するものであって，
　画面遷移モデルは，画面と，その画面内で扱う入出力項目をクラス図の類似記法で表現した画面構造図と，画面遷移をステートマシン図の類似記法で表現した画面遷移図で構成される，
　モデル駆動開発によるＧＵＩ生成。」
　引用文献２に記載の上記技術は，モデル駆動開発によるＧＵＩ生成において，画面構成図と画面遷移図で構成される画面遷移モデルを作成してＧＵＩを生成するものであり，前記「画面構成図」は，本願発明の「スクリーン」に相当し，「画面遷移図」は画面遷移をステートマシンで表現するのであるから，本願発明の「スクリーン間のナビゲーション」に相当する。
　そして，引用文献２に記載の上記技術においても，「画面構成図」，すなわち「スクリーン間のナビゲーション」を作成している以上，かかる「スクリーン間のナビゲーション」を作成するための何らかの「スクリーンフローモデラ」を備えているといえるので，結局，引用文献２には，“スクリーンフローモデラを使用して，前記アプリケーションのスクリーン間のナビゲーションを設計する”技術が開示されているといえる。
　引用発明と引用文献２に記載の上記技術とは，ともにＧＵＩを考慮したＭＤＡを用いたアプリケーション開発という共通の技術分野に属するものであって，かつ，引用文献１では，上記第４　１（１）Ｅに記載されているように，「画面遷移のあるプログラムへの適応」が「今後の課題」としていることから，かかる「今後の課題」に基づき，引用発明に引用文献２に記載の上記技術を適用することは，当業者であれば容易に想到し得たものである。
　そして，上記１で検討したように，引用発明において，開発するアプリケーションとして，「モバイル」アプリケーションを選択することは，当業者であれば任意になし得る事項に過ぎないから，結局，引用発明において，「スクリーンフローモデラ（１１４）を使用して，前記モバイルベースアプリケーションのスクリーン間のナビゲーションを設計するステップ」を備えるとすることは，引用文献２に記載の上記技術に基づいて当業者であれば容易になし得たものである。
４　相違点４について
　引用発明においても，上記第５　１（４）で検討したように，複数のプラットフォームにそれぞれ対応した複数のソースコードを生成するものである。
　ここで，複数のプラットフォームとして，どのようなプラットフォームを選択するかは当業者が適宜選択し得ることは明らかであるところ，プラットフォームを適宜選択し得るように「入力デバイス（１０８）を使用して，複数のテクノロジプラットフォームを選択するステップ」を設け，「選択された」複数のテクノロジプラットフォームに応じた複数のコードを生成するようにすることは，複数のプラットフォームにそれぞれ対応した複数のソースコードを生成するという作用効果の範囲内において，当業者であれば適宜なし得た事項に過ぎない。
５　相違点５について
　引用発明においても，上記第５　１（４）で検討したように，複数のプラットフォームにそれぞれ対応した複数のソースコードを生成するものである。また，ソフトウェアの開発分野において，生成した複数のコードをバンドリングすることは通常行われていることに過ぎないから，引用発明において，生成した複数のコードを何らかのバンドリングモジュールを使用してバンドリングすることも，当業者であれば適宜なし得る程度の事項に過ぎない。
　してみると，上記１で検討したように，引用発明において，開発するアプリケーションとして，「モバイル」アプリケーションを選択することは，当業者であれば任意になし得る事項に過ぎないところ，生成した複数のコードをバンドリングすることも，前述したように当業者であれば適宜なし得る程度の事項に過ぎないから，結局，引用発明において，「モバイルアプリケーションバンドリングモジュール（１１８）を使用して，前記コードをバンドリングすることによって，前記モバイルベースアプリケーションを開発するステップ」を含むようにすることも，当業者であれば通常の創作活動の範囲内おいて適宜なし得た事項と認められる。
６　相違点６について
　上記第４　３（２）で示したように，引用文献３には，次の技術が記載されている。
「モデルドリブン開発（モデル駆動開発）をベースとした統合型アプリケーション開発ツールであって，
　モデリング環境で作成されたビジネスロジック，データアクセス定義，ユーザーインタフェースという３つの情報を含むモデルをレポジトリに格納し，それに基づいて本番環境の各種プラットフォームをターゲットとしたアプリケーションを自動生成する，
　モデルドリブン開発（モデル駆動開発）をベースとした統合型アプリケーション開発ツール。」
　引用文献３に記載の上記技術は，モデル駆動開発をベースとしたアプリケーション開発において，モデリング環境で作成されたモデルをレポジトリに格納する技術を示すものであって，モデル駆動開発を用いたアプリケーション開発において，作成した情報をレポジトリに格納することは通常行われていることである。
　この点に関して，上記第４　６で示した参考文献３にも，「複数のソフトウェアコンポーネントのソースコードを記憶するソースコンポーネントリポジトリであって，各ソフトウェアコンポーネントはどの実行時環境からも実質的に独立である，ソースコンポーネントリポジトリ」が開示されており，レポジトリを使用してプラットフォームに独立の方法で複数のコードを記憶することも通常行われていることに過ぎないと認められる。
　引用発明においても複数のコードを生成しているところ，引用発明に生成された情報を記憶するための「レポジトリ」を追加し，「開発レポジトリ（１２４）データベースを使用してプラットフォームに独立の方法で複数のコードを記憶するステップ」を含むとすることは，引用文献３，あるいは参考文献３に示される上記技術に基づいて，当業者であれば適宜なし得る事項であると認められる。
７　小括
　上記で検討したごとく，相違点１乃至６に係る構成は当業者が容易に想到し得たものであり，そして，これらの相違点を総合的に勘案しても，本願発明の奏する作用効果は，上記引用発明，引用文献２乃至３，及び参考文献１乃至３に記載の技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本願発明は，上記引用発明，引用文献２乃至３，及び参考文献１乃至３に記載の技術に基づいて，当業者が容易に発明できたものである。
第７　むすび
　以上のとおり，本願の請求項９に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。
　よって，結論のとおり審決する。