• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1368732
審判番号 不服2019-12886  
総通号数 253 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-01-29 
種別 拒絶査定不服の審決 
審判請求日 2019-09-27 
確定日 2020-11-27 
事件の表示 特願2017- 46670「モデル駆動開発を使用するモバイルベースアプリケーションを開発するシステムおよび方法」拒絶査定不服審判事件〔平成29年11月 2日出願公開、特開2017-199359〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1 手続の経緯

本願は,平成29年3月10日(パリ条約による優先権主張外国庁受理2016年3月11日(以下,「優先日」という。) インド)の外国語書面出願であって,
平成29年7月6日付けで特許法第36条の2第2項の規定による外国語書面,及び,外国語要約書面の日本語による翻訳文が提出されるとともに審査請求がなされ,平成30年8月2日付けで審査官により拒絶理由が通知され,これに対して同年12月21日付けで意見書が提出されるとともに手続補正がなされたが,令和1年5月27日付けで拒絶査定(以下,「原査定」という。)がなされ,これに対して同年9月27日付けで拒絶査定不服審判の請求がなされたものである。

第2 本願発明

本願の請求項9に係る発明(以下,「本願発明」という。)は,平成30年12月21日付けの手続補正により補正された特許請求の範囲の請求項9に記載された,次のとおりのものである。

「 【請求項9】
モバイルベースアプリケーションを開発する方法であって、
メタモデリングモジュール(110)を使用して、前記モバイルベースアプリケーションを開発するための、複数の要件を収集するステップ;
ユーザインターフェイスモデラ(112)を使用して、前記モバイルベースアプリケーションの少なくとも1つのスクリーンを設計するステップであって、前記スクリーンは前記複数の要件に基づいて設計されるステップ;
スクリーンフローモデラ(114)を使用して、前記モバイルベースアプリケーションのスクリーン間のナビゲーションを設計するステップ;
入力デバイス(108)を使用して、複数のテクノロジプラットフォームを選択するステップ;
コード生成器モジュール(116)を使用して、前記選択された複数のテクノロジプラットフォームに応じて複数のコードを生成するステップ;および
モバイルアプリケーションバンドリングモジュール(118)を使用して、前記コードをバンドリングすることによって、前記モバイルベースアプリケーションを開発するステップ;および
開発レポジトリ(124)データベースを使用してプラットフォームに独立の方法で複数のコードを記憶するステップ
を含む、前記方法。」

第3 原査定における拒絶理由の概要

原査定における拒絶理由の概要は,この出願の請求項1乃至請求項10に係る発明は,本願の優先日前に日本国内又は外国において,頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献1乃至引用文献3に記載された発明に基づいて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない,というものである。

引用文献1.井上 尚紀,GUIを考慮したMDA開発手法の提案,情報処理学会研究報告 2011(平成23)年度(1) [CD-ROM],日本,一般社団法人情報処理学会,2011年6月15日,ｐｐ.1-8
引用文献2.赤瀬 智也,画面遷移モデルと整合性を保つGUI設計支援手法,電子情報通信学会技術研究報告,日本,一般社団法人電子情報通信学会,2016年2月25日,第115巻,第487号,ｐｐ.131-136
引用文献3.目指せスピード10倍増! 超高速開発・リノベーションフォーラム2013 Reｖieｗ,日経コンピュータ,日本,日経BP社,2013年6月27日,第837号,ｐｐ.96-97

第4 引用文献に記載された事項及び引用発明等

1 引用文献1に記載された事項及び引用発明

(1)原査定における拒絶理由で引用された引用文献1には,関連する図面とともに,以下の事項が記載されている。
(下線は,参考のために当審で付与したものである。また,文献中に記載の丸付き数字は,「○数字:」に置き換えることとした。以下同様。)

A 「1. 研究背景
1.1 はじめに
ソフトウェアをとりまくビジネス環境や実装技術の進歩は日々変化しており,変化に強いソフトウェア開発が求められている.そこで,近年注目されている開発手法のひとつが標準化団体OMG(Object Management Group)が提唱しているMDA(Model Driven Architecture:モデル駆動アーキテクチャ)^(1))であり,様々な分野での適用が検討されている.
一方,業務などに利用されるソフトウェアの開発では,ユーザインターフェイスがどのぐらい分かりやすく使いやすいかがソフトウェアの品質に大きな影響を与える.
しかし,MDAにおけるGUI(Graphical User Interface)の扱いは,幾つかの方法が提案されてはいるが,未洗練である.そこで本研究は,GUIを考慮したMDA開発方法を提案する事を目的とする.今回は,特にウィンドウシステムの画面構成に焦点をあて,画面構成に関わる情報をMDAで扱うための一手法について提案する.具体的には,UMLモデリングツールによって作られる通常のPIMに対して,GUIビルダを使用して作られる抽象的なGUI(画面構成)の情報を組み込んだGPIM(拡張PIM)を作成することにより,レイアウト指定の際の手作業の削減とプラットフォームの変化に対応できるようにすることをねらう.
評価実験の結果,本手法は,GUIレイアウト情報を含めたプラットフォーム独立なGPIMから,ソースコードを生成することができ,複数のプラットフォームに対応できる事を確認した.
1.2 背景知識
1.2.1 MDA
MDAはOMGが提唱しているソフトウェア開発手法である.CIM(Computation Independent Model:計算処理非依存モデル)を参考に,実装技術から独立したPIM(Platform Independent Mode1:プラットフォーム独立モデル)を作成し,PSM(Platform Specific Model:プラットフォーム依存モデル)へ変換し,PSMからソースコードを生成する.MDAにおけるプラットフォームとは,Jaｖa,CORBA,XMLのようなプログラミング言語や実現方式等の実装技術を指す.」
(第1ページ左欄第15行-右欄第18行)

B 「3. 提案手法
前章で述べた研究アプローチをもとに,手法の提案を行う.
3.1 前提条件
本手法は,MDA開発においてGUIのアプリケーションソフトウェアを開発する為の手法である.今回はプラットフォーム依存性の高い画面設計をいかにMDAで扱うかという問題にフォーカスする為,画面遷移の問題は扱わないこととする.
3.2 提案手法概要
提案手法の概要を図3-1に示す.アプリケーション開発者は最初に作成したCIMを基に抽象GUIビルダにより抽象GUI情報を作成し,並行してUMLモデリングツールによりPIM(クラス図)を描画する.次にそれぞれを統合したものをGPIM(拡張クラス図)とし,PSMヘモデル変換し,ソースコードを生成する.拡張クラス図とは,GUI情報を扱えるように拡張したクラス図である.
PSMへの変換とソースコード生成は従来技術を用いる.


3.3 各ステップ詳細
3.3.1○1:CIM作成
CIMにはシステムによって扱われる情報のフローを記述し,特に,入力させる情報や選択させる情報を記述する.また本手法では,CIMはアクティビティ図やユースケース図を用いることを想定している.
処理フロー上の複数の選択肢から,ユーザに何かを選択させる場合は,その選択肢もここで記述する.
3.3.2○2:抽象GUIビルダによる抽象GUI情報作成
CIMで示された業務フロー中のコンピュータと人とのやりとりを,具体的にどのような画面構成で実現するかを決定し,抽象GUI情報として出力する.XMLを用いたXMIがモデリングツールとソフトウェア生成ツールの間のモデル交換媒体として一般に使われている為,抽象GUI情報はXML形式とした.」
(第2ページ右欄第29行-第3ページ左欄第18行)

C 「3.3.3○3:UMLモデリングツールによるPIM作成
CIMを基に,扱いたい情報と機能のみをクラス図によりPIMをモデリングする.CIMの業務フロー上に選択肢がある場合は,列挙型を使い選択肢を宣言し,属性の型とする.これは,同じく選択肢があるCIMを基に設計した抽象GUIと対応付ける為である.また,本手法の制約として,クラスは二つでなければならなく,その内一つのクラスは属性(扱いたい情報)のみを持つ.これは,本手法が画面遷移に対応していない為と,一つのクラスがGUIエレメントに変換される為である.
3.3.4○4:PIMと抽象GUI情報の統合
図3-3にPIMと抽象GUI情報の統合ルールを示す.PIMと抽象GUI情報を統合する為に,エレメントの名称とクラスや属性の名称の対応をとる必要がある.今回の実験では名称で対応をとることにしたため,統合する前に,PIMと抽象GUI中のモデル要素の名前をルールで扱えるように変更する.」
(第4ページ左欄第13行-第24行)

D 「3.3.5○5:PSMへのモデル変換
GPIMの表現を,GUIエレメントについては,抽象的なGUIの情報をプログラミング言語に依存した形に,その他のクラスについては従来技術を用いて変換する.具体的には,各エレメントの名称をプログラミング言語に依存した形に変換する.例えば,フレームであるFｒameの場合,Jaｖa依存ではJFｒameに,C#依存ではFｏｒmになる.また,座標系の原点が左上でなく,一般的なピクセル座標系とは違う場合は,座標情報をこの時点で変換する.例えば左下が原点のObjecｔiｖe-Cの場合は,Y座標を反転する.PSMの依存しているプログラミング言語によってメタモデルが違うが,例として図3-5にJaｖaプラットフォーム依存のPSMメタモデルを示す.
3.3.6○6ソースコード生成
PSMからソースコードを生成する.プログラミング言語によって変換ルールは違うが,Jaｖaの場合の例を挙げると,GUIを形成するクラスと,内部処理やメインメソッドを持つクラス,計2つのクラスを生成する.PSMへの変換とソースコード生成は従来技術を用いる.振る舞い部分の生成方式は本提案の本質部分ではないので,手法としては既存技術を使う.」
(第5ページ左欄第1行-右欄第2行)

E 「5.2 今後の課題
今後の課題として,画面遷移のあるプログラムへの適応,解像度の違いへの適応,が挙げられる.
● 画面遷移のあるプログラムへの適応
本研究では対象を,画面遷移のない,比較的小さなソフトウェア作成に限定したが,GUIソフトウェアの多くは,画面遷移を行っている.これには画面遷移をモデルに表す難しさや,PIMとの対応関係などの問題があるが,これを解決できればより汎用的で実用的な手法になると考えられる.」
(第8ページ右欄第1行-第8行)

(2)上記A乃至Eの記載から,引用文献1には,次の発明(以下,「引用発明」という。)が記載されているものと認める。

「MDA(Model Driven Architecture:モデル駆動アーキテクチャ)開発においてGUI(Graphical User Interface)のアプリケーションソフトウェアを開発する為の手法であって,
アプリケーション開発者は最初に作成したCIM(Computation Independent Model:計算処理非依存モデル)を基に抽象GUIビルダにより抽象GUI情報を作成し,並行してUMLモデリングツールによりPIM(Platform Independent Mode1:プラットフォーム独立モデル)(クラス図)を描画し,次にそれぞれを統合したものをGPIM(拡張クラス図)とし,PSM(Platform Specific Model:プラットフォーム依存モデル)ヘモデル変換し,ソースコードを生成するものであって,GUIレイアウト情報を含めたプラットフォーム独立なGPIMから,ソースコードを生成することができ,複数のプラットフォームに対応できるものであり,
○1:CIM作成において,CIMにはシステムによって扱われる情報のフローを記述し,特に,入力させる情報や選択させる情報を記述し,
○2:抽象GUIビルダによる抽象GUI情報作成において,CIMで示された業務フロー中のコンピュータと人とのやりとりを,具体的にどのような画面構成で実現するかを決定し,抽象GUI情報として出力し,
○3:UMLモデリングツールによるPIM作成において,CIMを基に,扱いたい情報と機能のみをクラス図によりPIMをモデリングし,
○4:PIMと抽象GUI情報の統合において,PIMと抽象GUI情報を統合し,GPIM(拡張クラス図)とし,
○5:PSMへのモデル変換において,GPIMの表現を,GUIエレメントについては,抽象的なGUIの情報をプログラミング言語に依存した形に,その他のクラスについては従来技術を用いて変換し,
○6:ソースコード生成において,PSMからソースコードを生成するものであって,ソースコード生成は従来技術を用いる,
MDA開発手法。」

2 引用文献2に記載された事項及び技術

(1)原査定における拒絶理由で引用された引用文献2には,関連する図面とともに,以下の事項が記載されている。

F 「2.2.モデル駆動開発とその問題点
機能設計と整合性を保ったGUIを効率的に生成するための手法としてモデル駆動開発によるGUI生成が挙げられる.」
(第132ページ左欄第26行-第29行)

G 「GUI設計のプロセスはまず○1:機能設計者が機能モデルとして画面遷移モデルを作成,○2:UIデザイナがGUI設計ツールを用いて画面遷移モデルを読み込む,○3:UIデザイナはGUI設計ツールで視覚的にレイアウトの編集を行う,○4:レイアウト編集が終了したらレイアウトモデルとして出力する.」
(第132ページ右欄第35行-第133ページ左欄第2行)

H 「3.1.機能モデルとしての画面遷移モデル
本研究で利用する既存の画面遷移モデル[5][6]は,次の2つの図により構成される.第一に,図2に示す画面と,その画面内で扱う入出力項目をクラス図の類似記法で表現したものである.以降,これを画面構造図と呼ぶ,第二に,図3で示す画面遷移をステートマシン図の類似記法で表現したものである.以降,これを画面遷移図と呼ぶ.本研究では画面単位でGUI設計と機能設計の整合性検証を行えるように,これを本研究における機能モデルとして扱う.」
(第133ページ左欄第11行-第20行)

I 「



」
(第133ページ左欄)

(2)上記F乃至Iの記載から,引用文献2には,次の技術が記載されているものと認める。

「モデル駆動開発によるGUI生成であって,
GUI設計のプロセスは,まず機能設計者が機能モデルとして画面遷移モデルを作成するものであって,
画面遷移モデルは,画面と,その画面内で扱う入出力項目をクラス図の類似記法で表現した画面構造図と,画面遷移をステートマシン図の類似記法で表現した画面遷移図で構成される,
モデル駆動開発によるGUI生成。」

3 引用文献3に記載された事項及び技術

(1)原査定における拒絶理由で引用された引用文献3には,関連する図面とともに,以下の事項が記載されている。

J 「20年以上の実績を持つモデルドリブンの開発支援ツール
CA Technｏlｏgieｓが提供する「CA Gen」は、「モデルドリブン開発(モデル駆動開発)」をベースとした統合型アプリケーション開発ツールである。
・・・(中略)・・・
具体的には、先ず開発者はPCやワークステーション上の統合化されたモデリング環境で、GUIベースのダイヤグラムによってデータモデルやビジネスロジック、画面などを設計、記述する。そして、それらの複数のモデリング環境で作成されたビジネスロジック、データアクセス定義、ユーザーインタフェースという3つの情報を含むモデルをレポジトリに格納。それに基づいて本番環境の各種プラットフォームをターゲットとしたアプリケーションを自動生成する。」
(第96ページ左欄第1行-中欄第13行)

(2)上記Jの記載から,引用文献3には,次の技術が記載されているものと認める。

「モデルドリブン開発(モデル駆動開発)をベースとした統合型アプリケーション開発ツールであって,
モデリング環境で作成されたビジネスロジック,データアクセス定義,ユーザーインタフェースという3つの情報を含むモデルをレポジトリに格納し,それに基づいて本番環境の各種プラットフォームをターゲットとしたアプリケーションを自動生成する,
モデルドリブン開発(モデル駆動開発)をベースとした統合型アプリケーション開発ツール。」

4 参考文献1に記載された事項

本願の優先日前公知の文献である下記の参考文献1には,関連する図面とともに,以下の事項が記載されている。

参考文献1.越賀 準,Eｖenｔ-Bによるモデル駆動モバイルアプリケーション開発,電子情報通信学会技術研究報告,日本,一般社団法人電子情報通信学会,2012年11月23日,第112巻,第331号,ｐｐ.7-12

K 「4. Eｖenｔ-Bによるモデル駆動
本研究では,モデル駆動アーキテクチャ(MDA:Model Driven Architecture)[6]で言うところのPIM(Platform-independent model)と呼ばれる,特定のプラットフォームや技術に依存することなく,Eｖenｔ-Bを用いてモバイルアプリケーション開発のモデル化について考えることにする.
4.1 Eｖenｔ-Bとモバイルアプリケーション
本研究では,形式仕様記述言語の1つであるEｖenｔ-Bを用いて,モデル化を行う.Eｖenｔ-Bはモデル指向型の仕様記述言語であり,モバイルアプリケーション開発では,iOSはObjecｔ-C,AndｒｏidはJAVA,WindｏｗｓPhｏneはC#,と全て手続き型言語で実装される.」
(第10ページ右欄第1行-第12行)

5 参考文献2に記載された事項

本願の優先日前公知の文献である特表2011-501297号公報(公表日;平成23年1月6日,以下,これを「参考文献2」という。)には,関連する図面とともに,以下の事項が記載されている。

L 「【0014】
図を初めに参照すると、図1はコンピュータで実現されるソフトウェアファクトリ仕様化システム100を示している。システム100は、メタモデル110と、ユーザインタフェースコンポーネント120と、ファクトリスキーマ130(すなわち、メタモデル110のインスタンス)とを含む。ユーザインタフェースコンポーネント120を介して、ユーザ(例えば、ファクトリ開発者)は、メタモデル110と対話処理して、特定のソフトウェアファクトリのためのファクトリスキーマ130を定義する。1つの実施形態において、当該ユーザインタフェースコンポーネント120は対話型開発環境を含む。
【0015】
ファクトリスキーマ130は、対話型開発環境において、当該エディタ、記述されたタスクテンプレート及びアセットと一緒に用いられて、プロダクト(例えば、クライアントアプリケーション、モバイルクライアント、ウェブサービス、その他)の仕様化、開発、配備及び保守を支援する。ファクトリスキーマ130と、まとめて説明されたエディタ、タスクテンプレート及びアセットとは、「ソフトウェアファクトリ」すなわち単に「ファクトリ」を形成し、かかる「ファクトリ」は、ソフトウェア資産の組織的な再利用を可能とすることによってソフトウェア開発チームの生産性を改善するのに用いられることができ、当該ソフトウェア資産は、良く定義された変容可能な特性(point)を活用することによって、特定タイプのソフトウェアシステムの広範囲な変容物を作成するのに適用され得る。」

6 参考文献3に記載された事項

本願の優先日前公知の文献である特開2014-71899号公報(公開日;平成26年4月21日,以下,これを「参考文献3」という。)には,関連する図面とともに,以下の事項が記載されている。

M 「【0034】
本発明によるシステムは、記憶メモリとプロセッサとを有するシステムであって、前記システムは、複数のソフトウェアコンポーネントのソースコードを記憶するソースコンポーネントリポジトリであって、各ソフトウェアコンポーネントのソースコードは個別に編集可能であり、各ソフトウェアコンポーネントは単一の機能を完全に実行するものであり、各ソフトウェアコンポーネントはどの実行時環境からも実質的に独立である、ソースコンポーネントリポジトリと、前記複数のソフトウェアコンポーネントのバイナリコードを記憶するバイナリコンポーネントリポジトリであって、各ソフトウェアコンポーネントのバイナリコードは個別にダウンロード可能である、バイナリコンポーネントリポジトリとを記憶し、前記システムは、複数のソフトウェアコンポーネントのうちの一コンポーネントのソースコードが編集されると、前記複数のソフトウェアコンポーネントのうちの少なくとも1つの他のコンポーネントのバイナリコードをダウンロードし、前記編集されたコンポーネントと、前記少なくとも1つのダウンロードされたコンポーネントとから、ターゲットアプリケーションを生成するように構成されている。」

第5 対比

1 本願発明と引用発明とを対比する。

(1)引用発明は,「アプリケーションソフトウェアを開発する為の手法」であるから,本願発明と引用発明とは,後記する点で相違するものの,“アプリケーションを開発する方法”である点で一致している。

(2)引用発明は,「アプリケーション開発者は最初に」「CIM(Computation Independent Model:計算処理非依存モデル)」を作成するものであって,「○1:CIM作成において,CIMにはシステムによって扱われる情報のフローを記述し,特に,入力させる情報や選択させる情報を記述」するものである。
ここで,「CIM」に記述される前記「システムによって扱われる情報のフロー」,「入力させる情報や選択させる情報」とは,開発するアプリケーションの仕様に関する複数の情報であって,アプリケーションを開発するための「複数の要件」といえるから,引用発明においても,アプリケーションを開発するための複数の要件を入力,すなわち収集しているといえる。
よって,本願発明と引用発明とは,後記する点で相違するものの,“前記アプリケーションを開発するための,複数の要件を収集するステップ”を含む点で一致している。

(3)引用発明は,「○2:抽象GUIビルダによる抽象GUI情報作成において,CIMで示された業務フロー中のコンピュータと人とのやりとりを,具体的にどのような画面構成で実現するかを決定し,抽象GUI情報として出力」するものである。
ここで,前記「画面構成」は,本願発明の「スクリーン」に相当するところ,「CIMで示された業務フロー中のコンピュータと人とのやりとりを,具体的にどのような画面構成で実現するかを決定」することは,CIMに基づいて画面構成,すなわち「スクリーン」を設計することに他ならず,また,上記(2)で検討したように,CIMには「複数の要件」が記述されるものであるから,「複数の要件」に基づいて「スクリーン」を設計することになり,結局,引用発明も,“アプリケーションの少なくとも1つのスクリーンを設計するステップであって,前記スクリーンは前記複数の要件に基づいて設計されるステップ”を含んでいるといえる。
そして,引用発明は,かかるスクリーンを設計するステップを,「抽象GUIビルダ」による抽象GUI情報作成において行うものであるから,引用発明の「抽象GUIビルダ」は,本願発明の「ユーザインターフェイスモデラ(112)」に相当する。
よって,本願発明と引用発明とは,後記する点で相違するものの,“ユーザインターフェイスモデラ(112)を使用して,前記アプリケーションのスクリーンを設計するステップであって,前記スクリーンは前記複数の要件に基づいて設計されるステップ”を含む点で一致している。

(4)引用発明は,「GUIレイアウト情報を含めたプラットフォーム独立なGPIMから,ソースコードを生成することができ,複数のプラットフォームに対応できる」ものであるから,各プラットフォームに対応してソースコードが生成されるものであり,複数のプラットフォームにそれぞれ対応した複数のソースコードが生成されていることは明らかである。
また,引用発明は,「ソースコード生成は従来技術を用いる」としており,ソースコード生成において従来から一般的に用いられている何らかのコード生成器を使用していることも明らかである。
よって,本願発明と引用発明とは,後記する点で相違するものの,“コード生成器モジュール(116)を使用して,複数のテクノロジプラットフォームに応じて複数のコードを生成するステップ”を含む点で一致している。

2 上記(1)乃至(4)の検討から,本願発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

＜一致点＞
「アプリケーションを開発する方法であって,
前記アプリケーションを開発するための,複数の要件を収集するステップ;
ユーザインターフェイスモデラ(112)を使用して,前記アプリケーションの少なくとも1つのスクリーンを設計するステップであって,前記スクリーンは前記複数の要件に基づいて設計されるステップ;
コード生成器モジュール(116)を使用して,複数のテクノロジプラットフォームに応じて複数のコードを生成するステップ;
を含む,前記方法。」

＜相違点1＞
開発するアプリケーションに関し,本願発明では,「モバイル」アプリケーションであるのに対して,引用発明では,「モバイル」アプリケーションであるとは特定されていない点。

＜相違点2＞
複数の要件を収集するステップに関し,本願発明では,「メタモデリングモジュール(110)を使用」するものであるのに対して,引用発明では,「メタモデリングモジュール(110)を使用」することが特定されていない点。

＜相違点3＞
本願発明では,「スクリーンフローモデラ(114)を使用して、前記モバイルベースアプリケーションのスクリーン間のナビゲーションを設計するステップ」を含むのに対して,引用発明では,そのようなステップを含んでいない点。

＜相違点4＞
本願発明では,「入力デバイス(108)を使用して、複数のテクノロジプラットフォームを選択するステップ」を含み、コード生成器モジュール(116)が「選択された」複数のテクノロジプラットフォームに応じて複数のコードを生成するのに対して,引用発明では,そのようなステップを含むことが特定されておらず,よって,複数のテクノロジプラットフォームが,「選択された」複数のテクノロジプラットフォームであることも特定されていない点。

<相違点5>
本願発明では,「モバイルアプリケーションバンドリングモジュール(118)を使用して、前記コードをバンドリングすることによって、前記モバイルベースアプリケーションを開発するステップ」を含むのに対して,引用発明では,そのようなステップを含むことが特定されていない点。

＜相違点6＞
本願発明では,「開発レポジトリ(124)データベースを使用してプラットフォームに独立の方法で複数のコードを記憶するステップ」を含むのに対して,引用発明では,そのようなステップを含むことが特定されていない点。

第6 当審の判断

1 相違点1について
引用発明は,「MDA(Model Driven Architecture:モデル駆動アーキテクチャ)開発においてGUI(Graphical User Interface)のアプリケーションソフトウェアを開発する為の手法」であるところ,開発するアプリケーションとしてどのようなアプリケーションを選択するかは,当業者が必要に応じて適宜選択し得る事項にすぎない。
この点に関して,上記第4 4で示した参考文献1に,モデル駆動アーキテクチャ(MDA)を用いて「モバイル」アプリケーションを開発することが開示されているように,モデル駆動アーキテクチャ(MDA)を用いて「モバイル」アプリケーションを開発することが従来から行われていたことも鑑みれば,引用発明において,開発するアプリケーションとして,「モバイル」アプリケーションを選択することは,当業者であれば任意になし得た事項に過ぎないと認められる。

2 相違点2について
引用発明においても,上記第5 1(2)で検討したように,アプリケーションを開発するための複数の要件を収集しているといえるところ,かかる収集をどのような手段を用いて実施するかは,当業者が適宜選択し得た事項にすぎない。
この点に関して,上記第4 5で示した参考文献2に,ソフトウェアファクトリ仕様化システムにおいて,メタモデルを備え,前記メタモデルがプロダクトの仕様化を支援するファクトリースキーマを定義することが開示されているように,ソフトウェアの仕様を作成する際にメタモデルを用いることが通常行われていたことも鑑みれば,引用発明において,「メタモデリングモジュール」を用いて要件を収集するとすることに格別の創意は見出せない。

3 相違点3について
上記第4 2(2)で示したように,引用文献2には,次の技術が記載されている。
「モデル駆動開発によるGUI生成であって,
GUI設計のプロセスは,まず機能設計者が機能モデルとして画面遷移モデルを作成するものであって,
画面遷移モデルは,画面と,その画面内で扱う入出力項目をクラス図の類似記法で表現した画面構造図と,画面遷移をステートマシン図の類似記法で表現した画面遷移図で構成される,
モデル駆動開発によるGUI生成。」

引用文献2に記載の上記技術は,モデル駆動開発によるGUI生成において,画面構成図と画面遷移図で構成される画面遷移モデルを作成してGUIを生成するものであり,前記「画面構成図」は,本願発明の「スクリーン」に相当し,「画面遷移図」は画面遷移をステートマシンで表現するのであるから,本願発明の「スクリーン間のナビゲーション」に相当する。
そして,引用文献2に記載の上記技術においても,「画面構成図」,すなわち「スクリーン間のナビゲーション」を作成している以上,かかる「スクリーン間のナビゲーション」を作成するための何らかの「スクリーンフローモデラ」を備えているといえるので,結局,引用文献2には,“スクリーンフローモデラを使用して,前記アプリケーションのスクリーン間のナビゲーションを設計する”技術が開示されているといえる。
引用発明と引用文献2に記載の上記技術とは,ともにGUIを考慮したMDAを用いたアプリケーション開発という共通の技術分野に属するものであって,かつ,引用文献1では,上記第4 1(1)Eに記載されているように,「画面遷移のあるプログラムへの適応」が「今後の課題」としていることから,かかる「今後の課題」に基づき,引用発明に引用文献2に記載の上記技術を適用することは,当業者であれば容易に想到し得たものである。
そして,上記1で検討したように,引用発明において,開発するアプリケーションとして,「モバイル」アプリケーションを選択することは,当業者であれば任意になし得る事項に過ぎないから,結局,引用発明において,「スクリーンフローモデラ(114)を使用して,前記モバイルベースアプリケーションのスクリーン間のナビゲーションを設計するステップ」を備えるとすることは,引用文献2に記載の上記技術に基づいて当業者であれば容易になし得たものである。

4 相違点4について
引用発明においても,上記第5 1(4)で検討したように,複数のプラットフォームにそれぞれ対応した複数のソースコードを生成するものである。
ここで,複数のプラットフォームとして,どのようなプラットフォームを選択するかは当業者が適宜選択し得ることは明らかであるところ,プラットフォームを適宜選択し得るように「入力デバイス(108)を使用して,複数のテクノロジプラットフォームを選択するステップ」を設け,「選択された」複数のテクノロジプラットフォームに応じた複数のコードを生成するようにすることは,複数のプラットフォームにそれぞれ対応した複数のソースコードを生成するという作用効果の範囲内において,当業者であれば適宜なし得た事項に過ぎない。

5 相違点5について
引用発明においても,上記第5 1(4)で検討したように,複数のプラットフォームにそれぞれ対応した複数のソースコードを生成するものである。また,ソフトウェアの開発分野において,生成した複数のコードをバンドリングすることは通常行われていることに過ぎないから,引用発明において,生成した複数のコードを何らかのバンドリングモジュールを使用してバンドリングすることも,当業者であれば適宜なし得る程度の事項に過ぎない。
してみると,上記1で検討したように,引用発明において,開発するアプリケーションとして,「モバイル」アプリケーションを選択することは,当業者であれば任意になし得る事項に過ぎないところ,生成した複数のコードをバンドリングすることも,前述したように当業者であれば適宜なし得る程度の事項に過ぎないから,結局,引用発明において,「モバイルアプリケーションバンドリングモジュール(118)を使用して,前記コードをバンドリングすることによって,前記モバイルベースアプリケーションを開発するステップ」を含むようにすることも,当業者であれば通常の創作活動の範囲内おいて適宜なし得た事項と認められる。

6 相違点6について
上記第4 3(2)で示したように,引用文献3には,次の技術が記載されている。
「モデルドリブン開発(モデル駆動開発)をベースとした統合型アプリケーション開発ツールであって,
モデリング環境で作成されたビジネスロジック,データアクセス定義,ユーザーインタフェースという3つの情報を含むモデルをレポジトリに格納し,それに基づいて本番環境の各種プラットフォームをターゲットとしたアプリケーションを自動生成する,
モデルドリブン開発(モデル駆動開発)をベースとした統合型アプリケーション開発ツール。」

引用文献3に記載の上記技術は,モデル駆動開発をベースとしたアプリケーション開発において,モデリング環境で作成されたモデルをレポジトリに格納する技術を示すものであって,モデル駆動開発を用いたアプリケーション開発において,作成した情報をレポジトリに格納することは通常行われていることである。
この点に関して,上記第4 6で示した参考文献3にも,「複数のソフトウェアコンポーネントのソースコードを記憶するソースコンポーネントリポジトリであって,各ソフトウェアコンポーネントはどの実行時環境からも実質的に独立である,ソースコンポーネントリポジトリ」が開示されており,レポジトリを使用してプラットフォームに独立の方法で複数のコードを記憶することも通常行われていることに過ぎないと認められる。
引用発明においても複数のコードを生成しているところ,引用発明に生成された情報を記憶するための「レポジトリ」を追加し,「開発レポジトリ(124)データベースを使用してプラットフォームに独立の方法で複数のコードを記憶するステップ」を含むとすることは,引用文献3,あるいは参考文献3に示される上記技術に基づいて,当業者であれば適宜なし得る事項であると認められる。

7 小括
上記で検討したごとく,相違点1乃至6に係る構成は当業者が容易に想到し得たものであり,そして,これらの相違点を総合的に勘案しても,本願発明の奏する作用効果は,上記引用発明,引用文献2乃至3,及び参考文献1乃至3に記載の技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。
したがって,本願発明は,上記引用発明,引用文献2乃至3,及び参考文献1乃至3に記載の技術に基づいて,当業者が容易に発明できたものである。

第7 むすび

以上のとおり,本願の請求項9に係る発明は,特許法第29条第2項の規定により特許を受けることができないものであるから,その余の請求項に係る発明について検討するまでもなく,本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
別掲
 
審理終結日 2020-07-01 
結審通知日 2020-07-02 
審決日 2020-07-15 
出願番号 特願2017-46670(P2017-46670)
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 漆原 孝治  
特許庁審判長 田中 秀人
特許庁審判官 月野 洋一郎
山崎 慎一
発明の名称 モデル駆動開発を使用するモバイルベースアプリケーションを開発するシステムおよび方法  
代理人 葛和 清司  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ