【事件の表示】
　特願２０１６−２４８５７５「モジュール処理方法およびシステム、並びに記録媒体」拒絶査定不服審判事件〔平成２９年　７月　６日出願公開、特開２０１７−１２０６３７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は，平成２８年１２月２２日（パリ条約による優先権主張２０１５年１２月３１日（以下，「本願優先日」という。），韓国）の出願であって，平成２９年１１月２２日付けで拒絶の理由が通知され，平成３０年３月１２日に意見書とともに手続補正書が提出され，同年８月１４日付けで拒絶査定（謄本送達日同年８月２１日）がなされ，これに対して同年１２月２１日に審判請求がなされると共に手続補正がなされ，平成３１年４月８日付けで審査官により特許法１６４条３項の規定に基づく報告がなされ，令和元年５月３０日に上申書が提出されたものである。
第２　平成３０年１２月２１日にされた手続補正についての補正の却下の決定
［補正の却下の決定の結論］
　平成３０年１２月２１日にされた手続補正（以下，「本件補正」という。）を却下する。
［理由］
１　本件補正について
（１）本件補正後の特許請求の範囲の記載
　本件補正により，特許請求の範囲の請求項１の記載は，次のとおり補正された。（下線部は，補正箇所である。）
　「サーバ−クライアント環境でサービスを提供するサーバのモジュール処理方法であって、
　前記サーバが、前記サービスのためのサーバ機能
を駆動する第１プログラムコード
　前記サーバが、クライアントプログラムの開発者から提供され
、前記サーバから前記クライアントに前記サービスを提供するためのサービスロジックを処理するための第２プログラムコードが含まれたモジュールを含む
　前記サーバで、前記第１サーバモジュールファイルに含まれた
前記第１
前記第２
　
（２）本件補正前の特許請求の範囲
　本件補正前の，平成３０年３月１２日にされた手続補正により補正された特許請求の範囲の請求項１の記載は次のとおりである。
　「サーバ−クライアント環境でサービスを提供するサーバのモジュール処理方法であって、
　前記サーバが、前記サービスのためのサーバ機能及びクライアントとの接続を管理するためのアクセス管理モジュールを含む第１サーバモジュールファイルの入力を受けて格納および管理する段階、
　前記サーバが、クライアントプログラムの開発者から提供された第２サーバモジュールファイルの入力を受けて格納および管理する段階、および
　前記サーバで、前記第１サーバモジュールファイルに含まれたプログラムコードを利用して前記サーバ機能を駆動し、前記サーバ機能を通じて前記クライアントとの接続を管理するための前記アクセス管理モジュールを介して接続する前記クライアントに前記サービスを提供するためのサービスロジックを前記第２サーバモジュールファイルに含まれたプログラムコードを利用して処理する段階
　を含むことを特徴とする、モジュール処理方法。」
２　補正の適否
　本件補正は，本件補正前の請求項１に記載された発明を特定するために必要な事項である「第１サーバモジュールファイル」及び「第２サーバモジュールファイル」について，上記のとおり限定を付加するものであって，補正前の請求項１に記載された発明と補正後の請求項１に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから，特許法１７条の２第５項２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで，本件補正後の請求項１に記載される発明（以下「本件補正発明」という。）が同条６項において準用する同法１２６条７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について，以下，検討する。
（１）本件補正発明
　本件補正発明は，上記１（１）に記載したとおりのものである。
　
（２）引用例
ア　引用例に記載された事項
　原査定の拒絶の理由において引用された本願優先日前に既に公知である，特開２００３−１５８７０号公報（平成１５年１月１７日公開。以下，これを「引用例１」という。）には，関連する図面と共に，次の事項が記載されている。（下線は説明のために当審にて付加。以下同様。）
Ａ　「【請求項１】
Webアプリケーション開発方法
Webブラウザに１つの表示画面を表示するファイルを生成する役割を持つコンポーネントを表示層のコンポーネントの１つとし、複数の表示画面に対応する複数の表示層のコンポーネントを定義するステップと、
業務処理を行うコンポーネントやデータベースにアクセスする役割を持つコンポーネントを業務シナリオ層として定義するステップと、
複数の表示層のコンポーネントから呼び出される操作と、表示層のコンポーネントにより表示された表示画面で入力された情報や業務シナリオ層で実行された業務処理により得られた値を保存する領域を持つコンポーネントを１つの業務プロセス層として定義するステップとを備えることを特徴とするWebアプリケーション開発方法。」（特許請求の範囲）
Ｂ　「【０００３】
【発明が解決しようとする課題】近年のシステム開発において、開発サイクルはますます短くなってきている。特に
業務系システムや、業務サービスシステムをWeb上で公開する場合、その開発サイクルを短縮することは、顧客ニーズとして強い要求事項である。Webアプリケーションにおいて、HTMLページのデザインや情報を定期的に変更したり、サービスを迅速に拡張したりと短期間に開発を行うことが求められている。それらの開発のニーズに対応し、Webアプリケーションの開発サイクルに対応するためにも、開発作業を軽減させ、かつ、スピードアップを図る必要がある
【０００４】しかし、前述の従来のWebアプリケーション開発方法では、表示する役割を持つコンポーネントが業務処理を行うコンポーネントの操作を呼び出すように構成されているため、表示する役割を持つコンポーネントに追加、変更を施すとその影響は業務処理のコンポーネントにまで及んでいた。例えば、パソコンでは１つの表示画面で操作入力できるが、携帯電話では複数の画面が必要な場合がある。このとき、パソコンの表示層のコンポーネントから業務処理を行うコンポーネントを呼び出す入口と、携帯電話の表示層のコンポーネントから業務処理を行うコンポーネントを呼び出す入口を、それぞれ作らなければいけなかった。したがって、
HTMLページの画面仕様などを変更するたびに、業務処理を行うコンポーネントの変更をせざるを得ず、Webアプリケーションの開発サイクルに対応するために手間と時間がかかるという問題があった。本発明は、サーバサイドJava技術を利用したWebアプリケーションの開発において、開発作業の負担を軽減させ、かつスピードアップを図ることを目的とする
Ｃ　「【００１５】本実施の形態では、
Webアプリケーション開発
業務プロセス層には、表示層が業務シナリオ層やデータベースにアクセスする役割を持つコンポーネントを呼び出して処理を行う操作が定義されている
これにより、クライアントのWebブラウザに表示するHTMLページを作成する役割を持つ表示層のコンポーネントは、表示するための情報
を得るために、共有データ保持クラスに定義されているWebアプリケーションの業務処理を行う操作を呼び出すだけで処理結果を得ることができ
画面仕様に変更があった場合でも、業務に依存する処理を記述したコンポーネントに変更を加える必要がない
パソコンから利用していたWebアプリケーションを携帯端末からも利用できるようにするときのように、１つのHTMLページを分割したり画面レイアウトが変更したりする場合も、表示層の部分のみを作成するだけで良い
Ｄ　「【００１８】
開発対象のWebアプリケーションは、クライアント101がWebブラウザ102を使うことによって利用され
Webブラウザ102上には、HTMLページ103が表示され
Webブラウザ102からの要求は、HTTP経由でサーバ104に送信され
サーバ104は、HTTPサーバ105とアプリケーションサーバ106とを有する
アプリケーションサーバ106には、
サーバサイドJava技術のコンポーネントの実行環境が含まれている
【００１９】
Webアプリケーションを構成する各プログラムは、実行可能な状態で、サーバ104にあるアプリケーションサーバ106上に配置され
サーバ104に要求が送信されると、要求に応じて該当するコントロールクラス107（コントロール層）が起動され
Ｅ　「【００２０】
出力データ保持クラス108は、入力画面の情報やHTMLページ103に表示する処理の結果を保持したり、共有データ保持クラス109（業務プロセス層）やWebアプリケーションの業務処理を行う業務処理クラス110（業務シナリオ層）で定義されている操作を使うことで処理の要求を出す
共有データ保持クラス109や業務処理クラス110は、業務の分析や設計で導出された処理を実装したクラス
Ｆ　「【００２７】Webアプリケーションが処理を行うための情報を保持するためのクラスを設けた図１のようなシステム構成にすることで、
コントロールクラス107、レイアウトクラス113、および出力データ保持クラス108のようなHTMLページ103の作成に関する役割を持つ表示層114と、画面レイアウトに依存しない業務処理を行う業務処理クラス110やデータベースにアクセスする役割を持つデータベースアクセスクラス112のようにWebアプリケーションに特有の処理を記述したクラスとの間の依存関係を減らす
Ｇ　「【００５８】次に、業務プロセス層の共有データ保持クラス109を作成する流れの詳細について説明する。図９は、図３と図４と図６を使って共有データ保持クラス109のプログラムファイルをプログラム生成装置209によって生成する処理の流れを示したフローチャートである。本実施形態では、ユースケース名称「車を購入する」603に対応している共有データ保持クラス「PurchaseProcessEJB」609を生成する
プログラムファイル
を、
生成する
【００５９】まず、ステップ901で、業務プロセス定義表601を定義表保存装置208からプログラム生成装置209へ読み込む。
【００６０】ステップ902では、ステップ901で読み込んだ業務プロセス定義表601のユースケース602からユースケース名称を取得し、プログラムを生成するユースケースを選択する。本実施形態では、プログラムファイル名称「PurchaseProcessEJB.java」のプログラムの生成を行うので、「車を購入する」603を選択する。
このプログラムを生成するユースケースの選択処理は、
ユースケースを端末202に表示して、アプリケーション開発者201にマウスやキーボードを使って選択させても良い
イ　引用発明
（ア）上記記載事項Ｂの，「特に業務系システムや、業務サービスシステムをWeb上で公開する場合、その開発サイクルを短縮することは、顧客ニーズとして強い要求事項である。Webアプリケーションにおいて、HTMLページのデザインや情報を定期的に変更したり、サービスを迅速に拡張したりと短期間に開発を行うことが求められている。それらの開発のニーズに対応し、Webアプリケーションの開発サイクルに対応するためにも、開発作業を軽減させ、かつ、スピードアップを図る必要がある。」との記載，及び「したがって、HTMLページの画面仕様などを変更するたびに、業務処理を行うコンポーネントの変更をせざるを得ず、Webアプリケーションの開発サイクルに対応するために手間と時間がかかるという問題があった。本発明は、サーバサイドJava技術を利用したWebアプリケーションの開発において、開発作業の負担を軽減させ、かつスピードアップを図ることを目的とするものである。」との記載から，引用例１には，“業務系システムや，業務サービスシステムをWeb上で公開する場合，その開発サイクルを短縮することが，顧客ニーズとして強い要求事項であって，Webアプリケーションにおいて，HTMLページのデザインや情報を定期的に変更したり，サービスを迅速に拡張したりと短期間に開発を行うことが求められ，それらの開発のニーズに対応し，Webアプリケーションの開発サイクルに対応するためにも，開発作業を軽減させ，かつ，スピードアップを図る必要があることを背景とし，HTMLページの画面仕様などを変更するたびに，業務処理を行うコンポーネントの変更をせざるを得ず，Webアプリケーションの開発サイクルに対応するために手間と時間がかかるという課題に対し，サーバサイドJava技術を利用したWebアプリケーションの開発において，開発作業の負担を軽減させ，かつスピードアップを図ることを目的と”したものであることが記載されているといえる。
（イ）上記記載事項Ａの「Webアプリケーション開発方法であって」との記載，及び記載事項Ｃの「本実施の形態では、Webアプリケーション開発において、表示層のコンポーネントに呼び出される操作と情報を保存する領域を持つコンポーネントが業務プロセス層として定義される。」との記載から，引用例１には，“Webアプリケーション開発方法”について記載されているといえる。
　同じく記載事項Ｃの「また、業務プロセス層には、表示層が業務シナリオ層やデータベースにアクセスする役割を持つコンポーネントを呼び出して処理を行う操作が定義されている。これにより、クライアントのWebブラウザに表示するHTMLページを作成する役割を持つ表示層のコンポーネントは、表示するための情報（すでに前の画面などで入力された情報や業務シナリオ層の処理により得られている値）を得るために、共有データ保持クラスに定義されているWebアプリケーションの業務処理を行う操作を呼び出すだけで処理結果を得ることができる。」との記載から，引用例１には，“業務プロセス層には，表示層が業務シナリオ層やデータベースにアクセスする役割を持つコンポーネントを呼び出して処理を行う操作が定義され，これにより，クライアントのWebブラウザに表示するHTMLページを作成する役割を持つ表示層のコンポーネントは，表示するための情報を得るために，共有データ保持クラスに定義されているWebアプリケーションの業務処理を行う操作を呼び出すだけで処理結果を得ることができ”ることが記載されているといえる。
　同じく記載事項Ｃの「画面仕様に変更があった場合でも、業務に依存する処理を記述したコンポーネントに変更を加える必要がない。…（中略）…パソコンから利用していたWebアプリケーションを携帯端末からも利用できるようにするときのように、１つのHTMLページを分割したり画面レイアウトが変更したりする場合も、表示層の部分のみを作成するだけで良い。」との記載から，引用例１には，“画面仕様に変更があった場合でも，業務に依存する処理を記述したコンポーネントに変更を加える必要がなく，パソコンから利用していたWebアプリケーションを携帯端末からも利用できるようにするときのように，１つのHTMLページを分割したり画面レイアウトが変更したりする場合も，表示層の部分のみを作成するだけで良”いことが記載されているといえる。
（ウ）上記記載事項Ｄの「開発対象のWebアプリケーションは、クライアント101がWebブラウザ102を使うことによって利用される。Webブラウザ102上には、HTMLページ103が表示される。Webブラウザ102からの要求は、HTTP経由でサーバ104に送信される。サーバ104は、HTTPサーバ105とアプリケーションサーバ106とを有する。アプリケーションサーバ106には、サーブレット、JSP(Java Server Pages)、Java Beans、EJB(Enterprise Java Beans)など、サーバサイドJava技術のコンポーネントの実行環境が含まれている。」との記載から，引用例１には，“開発対象のWebアプリケーションは，クライアント101がWebブラウザ102を使うことによって利用され，Webブラウザ102上には，HTMLページ103が表示され，Webブラウザ102からの要求は，HTTP経由でサーバ104に送信され”ること，及び“サーバ104は，HTTPサーバ105とアプリケーションサーバ106とを有し，アプリケーションサーバ106には，サーバサイドJava技術のコンポーネントの実行環境が含まれて”いることが記載されているといえる。
　同じく記載事項Ｄの「Webアプリケーションを構成する各プログラムは、実行可能な状態で、サーバ104にあるアプリケーションサーバ106上に配置される。サーバ104に要求が送信されると、要求に応じて該当するコントロールクラス107（コントロール層）が起動される。」との記載から，引用例１には“Webアプリケーションを構成する各プログラムは，実行可能な状態で，サーバ104にあるアプリケーションサーバ106上に配置され，サーバ104に要求が送信されると，要求に応じて該当するコントロールクラス107（コントロール層）が起動され”ることが記載されているといえる。
（エ）上記記載事項Ｅの「出力データ保持クラス108は、入力画面の情報やHTMLページ103に表示する処理の結果を保持したり、共有データ保持クラス109（業務プロセス層）やWebアプリケーションの業務処理を行う業務処理クラス110（業務シナリオ層）で定義されている操作を使うことで処理の要求を出す。共有データ保持クラス109や業務処理クラス110は、業務の分析や設計で導出された処理を実装したクラスや、利用可能な既存クラスである。」との記載から，引用例１には，“出力データ保持クラス108は，入力画面の情報やHTMLページ103に表示する処理の結果を保持したり，共有データ保持クラス109（業務プロセス層）やWebアプリケーションの業務処理を行う業務処理クラス110（業務シナリオ層）で定義されている操作を使うことで処理の要求を出し，共有データ保持クラス109や業務処理クラス110は，業務の分析や設計で導出された処理を実装したクラス”であることが記載されているといえる。
（オ）上記記載事項Ｆの「Webアプリケーションが処理を行うための情報を保持するためのクラスを設けた図１のようなシステム構成にすることで、コントロールクラス107、レイアウトクラス113、および出力データ保持クラス108のようなHTMLページ103の作成に関する役割を持つ表示層114と、画面レイアウトに依存しない業務処理を行う業務処理クラス110やデータベースにアクセスする役割を持つデータベースアクセスクラス112のようにWebアプリケーションに特有の処理を記述したクラスとの間の依存関係を減らすことができ、各クラスの機能分担を明確にすることができる。」との記載から，引用例１には，“コントロールクラス107，レイアウトクラス113，および出力データ保持クラス108のようなHTMLページ103の作成に関する役割を持つ表示層114と，画面レイアウトに依存しない業務処理を行う業務処理クラス110やデータベースにアクセスする役割を持つデータベースアクセスクラス112のようにWebアプリケーションに特有の処理を記述したクラスとの間の依存関係を減ら”すことが記載されているといえる。
（カ）上記記載事項Ｇの「本実施形態では、ユースケース名称「車を購入する」603に対応している共有データ保持クラス「PurchaseProcessEJB」609を生成するプログラムファイル「PurchaseProcessEJB.java」を、プログラム生成装置209によって生成する例を使って処理の流れを説明する。」との記載，及び「このプログラムを生成するユースケースの選択処理は、取得したユースケースを端末202に表示して、アプリケーション開発者201にマウスやキーボードを使って選択させても良い。」との記載から，引用例１には，“プログラムファイルを生成する場合，このプログラムを生成するユースケースの選択処理は，ユースケースを端末202に表示して，アプリケーション開発者201がマウスやキーボードを使って選択させて行う”ことが記載されているといえる。
（キ）以上上記（ア）乃至（カ）より，引用例１には，次の発明（以下「引用発明」という。）が記載されているといえる。
「業務系システムや，業務サービスシステムをWeb上で公開する場合，その開発サイクルを短縮することが，顧客ニーズとして強い要求事項であって，Webアプリケーションにおいて，HTMLページのデザインや情報を定期的に変更したり，サービスを迅速に拡張したりと短期間に開発を行うことが求められ，それらの開発のニーズに対応し，Webアプリケーションの開発サイクルに対応するためにも，開発作業を軽減させ，かつ，スピードアップを図る必要があることを背景とし，HTMLページの画面仕様などを変更するたびに，業務処理を行うコンポーネントの変更をせざるを得ず，Webアプリケーションの開発サイクルに対応するために手間と時間がかかるという課題に対し，サーバサイドJava技術を利用したWebアプリケーションの開発において，開発作業の負担を軽減させ，かつスピードアップを図ることを目的としたWebアプリケーション開発方法であって，
　業務プロセス層には，表示層が業務シナリオ層やデータベースにアクセスする役割を持つコンポーネントを呼び出して処理を行う操作が定義され，これにより，クライアントのWebブラウザに表示するHTMLページを作成する役割を持つ表示層のコンポーネントは，表示するための情報を得るために，共有データ保持クラスに定義されているWebアプリケーションの業務処理を行う操作を呼び出すだけで処理結果を得ることができ，
　画面仕様に変更があった場合でも，業務に依存する処理を記述したコンポーネントに変更を加える必要がなく，パソコンから利用していたWebアプリケーションを携帯端末からも利用できるようにするときのように，１つのHTMLページを分割したり画面レイアウトが変更したりする場合も，表示層の部分のみを作成するだけで良く，
　開発対象のWebアプリケーションは，クライアント101がWebブラウザ102を使うことによって利用され，Webブラウザ102上には，HTMLページ103が表示され，Webブラウザ102からの要求は，HTTP経由でサーバ104に送信され，
　サーバ104は，HTTPサーバ105とアプリケーションサーバ106とを有し，アプリケーションサーバ106には，サーバサイドJava技術のコンポーネントの実行環境が含まれており，
　Webアプリケーションを構成する各プログラムは，実行可能な状態で，サーバ104にあるアプリケーションサーバ106上に配置され，サーバ104に要求が送信されると，要求に応じて該当するコントロールクラス107（コントロール層）が起動され，
　出力データ保持クラス108は，入力画面の情報やHTMLページ103に表示する処理の結果を保持したり，共有データ保持クラス109（業務プロセス層）やWebアプリケーションの業務処理を行う業務処理クラス110（業務シナリオ層）で定義されている操作を使うことで処理の要求を出し，共有データ保持クラス109や業務処理クラス110は，業務の分析や設計で導出された処理を実装したクラスであり，
　コントロールクラス107，レイアウトクラス113，および出力データ保持クラス108のようなHTMLページ103の作成に関する役割を持つ表示層114と，画面レイアウトに依存しない業務処理を行う業務処理クラス110やデータベースにアクセスする役割を持つデータベースアクセスクラス112のようにWebアプリケーションに特有の処理を記述したクラスとの間の依存関係を減らし，
　プログラムファイルを生成する場合，このプログラムを生成するユースケースの選択処理は，ユースケースを端末202に表示して，アプリケーション開発者201がマウスやキーボードを使って選択させて行う
　Webアプリケーション開発方法。」
（３）対比
　本件補正発明と引用発明とを対比する。
ア　引用発明の「開発対象のWebアプリケーション」は，「クライアント101がWebブラウザ102を使うことによって利用され」るものであり，「Webブラウザ102からの要求は，HTTP経由でサーバ104に送信され」，さらに，「サーバ104は，HTTPサーバ105とアプリケーションサーバ106とを有し，アプリケーションサーバ106には，サーバサイドJava技術のコンポーネントの実行環境が含まれて」いることから，当該「クライアント101」と「サーバ104」からなる環境は，「サーバ−クライアント環境」と言い得，また引用発明の「サーバ104」は，本件補正発明の「サーバ」に相当するといえる。
　また，引用発明の「アプリケーションサーバ106」には，「サーバサイドJava技術のコンポーネントの実行環境」が含まれ，「Webアプリケーションを構成する各プログラムは，実行可能な状態で，サーバ104にあるアプリケーションサーバ106上に配置され，サーバ104に要求が送信されると，要求に応じて該当するコントロールクラス107（コントロール層）が起動され」る一方，「Webアプリケーションの業務処理を行う業務処理クラス110（業務シナリオ層）」においては，「業務の分析や設計で導出された処理」が行われ，「クライアント101」の「Webブラウザ102上」に表示される，「HTMLページ103」は，上記「業務処理クラス110（業務シナリオ層）」において「業務の分析や設計で導出された処理」の結果が表示され，そのような表示がなされることは，「サービス」が「提供」されているといい得ることから，引用発明の「Webアプリケーション開発方法」と本件補正発明の「サーバ−クライアント環境でサービスを提供するサーバのモジュール処理方法」とは，下記の点（相違点１）で相違するものの，“サーバ−クライアント環境でサービスを提供するサーバにおける方法”である点で一致する。
イ　引用発明の「サーバ104」は，「HTTPサーバ105」を有するものである。また，引用発明は，「開発対象のWebアプリケーションは，クライアント101がWebブラウザ102を使うことによって利用され，Webブラウザ102上には，HTMLページ103が表示され，Webブラウザ102からの要求は，HTTP経由でサーバ104に送信され」るものであって，当該「クライアント101」の「Webブラウザ102からの要求」が，「HTTP経由でサーバ104に送信され」ると，上記「HTTPサーバ105」において処理が行われることから，引用発明の「サーバ104」は，本件補正発明の「クライアントとの接続を管理する」機能を有し，またそのための本件補正発明の「アクセス管理モジュール」に相当する構成を有することは明らかである。
　そして，引用発明の「サーバ104」は，「アプリケーションサーバ106」も有するものであるが，当該「アプリケーションサーバ106」には，「サーバサイドJava技術のコンポーネントの実行環境が含まれ」るとともに，「Webアプリケーションを構成する各プログラムは，実行可能な状態で，サーバ104にあるアプリケーションサーバ106上に配置され」ていることから，上記アの「サービス」に関する認定と合わせ考慮すれば，引用発明は，本件補正発明の「前記サーバが、前記サービスのためのサーバ機能を駆動する第１プログラムコード」に相当する構成を有していることも当業者に明らかである。
　そして，引用発明の「サーバ104」が，「クライアントとの接続を管理する」機能を有し，またそのための「アクセス管理モジュール」，及び，「前記サーバが、前記サービスのためのサーバ機能を駆動する第１プログラムコード」に相当する構成を有し，「クライアントとの接続を管理する」機能や「前記サービスのためのサーバ機能」を実現するためには，当該「サーバ104」にそのための実装が行われることは当業者にとって自明であり，そして，当該実装に際しては，「アプリケーションサーバ106」に，「サーバサイドJava技術のコンポーネントの実行環境が含まれ」ていることから，当該「サーバサイドJava技術のコンポーネント」に対応した，何らかの「サーバモジュールファイル」が「入力」され，「格納および管理」されることも自明である。
　したがって，引用発明と本件補正発明とは，“前記サーバが，前記サービスのためのサーバ機能を駆動する第１プログラムコード及びクライアントとの接続を管理するためのアクセス管理モジュールを含む第１サーバモジュールファイルの入力を受けて格納および管理する段階”を含む点で一致するといえる。
ウ　上記イの認定から，引用発明においては，本件補正発明の「前記第１サーバモジュールファイルに含まれた前記第１プログラムコード」を利用して「前記サーバ機能を駆動」していることから，引用発明と本件補正発明の「前記サーバで、前記第１サーバモジュールファイルに含まれた前記第１プログラムコードを利用して前記サーバ機能を駆動し、前記サーバ機能を通じて前記クライアントとの接続を管理するための前記アクセス管理モジュールを介して接続する前記クライアントに前記サービスを提供するためのサービスロジックを前記第２サーバモジュールファイルに含まれた前記第２プログラムコードを利用して処理する段階」とは，下記の点で相違するものの，“前記サーバで，前記第１サーバモジュールファイルに含まれた前記第１プログラムコードを利用して前記サーバ機能を駆動する段階”を含む点で一致するといえる。
エ　以上，ア乃至ウの検討から，引用発明と本件補正発明とは，次の一致点及び相違点を有する。
〈一致点〉
「サーバ−クライアント環境でサービスを提供するサーバにおける方法であって，
　前記サーバが，前記サービスのためのサーバ機能を駆動する第１プログラムコード及びクライアントとの接続を管理するためのアクセス管理モジュールを含む第１サーバモジュールファイルの入力を受けて格納および管理する段階，および
　前記サーバで，前記第１サーバモジュールファイルに含まれた前記第１プログラムコードを利用して前記サーバ機能を駆動する段階を含む，サーバにおける方法。」
〈相違点１〉
　本件補正発明が，「モジュール処理方法」であるのに対し，引用発明は，「Webアプリケーション開発方法」である点。
〈相違点２〉
　本件補正発明が，「前記サーバが、クライアントプログラムの開発者から提供され、前記サーバから前記クライアントに前記サービスを提供するためのサービスロジックを処理するための第２プログラムコードが含まれたモジュールを含む第２サーバモジュールファイルの入力を受けて格納および管理する段階」を含むのに対し，引用発明は，そのような段階を含むことが特定されていない点。
〈相違点３〉
　本件補正発明が，「前記サーバ機能を通じて前記クライアントとの接続を管理するための前記アクセス管理モジュールを介して接続する前記クライアントに前記サービスを提供するためのサービスロジックを前記第２サーバモジュールファイルに含まれた前記第２プログラムコードを利用して処理する段階」を含むのに対し，引用発明は，そのような段階を含むことが特定されていない点。
（４）判断
　上記相違点につき検討する。
ア　相違点１について
　まず相違点１について検討する。
　引用発明は，「業務プロセス層には，表示層が業務シナリオ層やデータベースにアクセスする役割を持つコンポーネントを呼び出して処理を行う操作が定義され」ており，これにより，「クライアントのWebブラウザに表示するHTMLページを作成する役割を持つ表示層のコンポーネント」が，「表示するための情報を得るために，共有データ保持クラスに定義されているWebアプリケーションの業務処理を行う操作を呼び出すだけで処理結果を得ることができ」るものである。そして，これらの「業務プロセス層」，「表示層」，「業務シナリオ層」は，所定の「コンポーネント」を単位として管理されているといえ，当該「コンポーネント」は，処理単位として“モジュール”ともいい得るものであることから，引用発明の「Webアプリケーション開発方法」と，本件補正発明の「モジュール処理方法」との間に，実質的な相違はなく，本相違は格別なものとはいえない。
イ　相違点２及び３について
　次に相違点２及び３をまとめて検討する。
　本件補正発明の「前記サーバから前記クライアントに前記サービスを提供するためのサービスロジックを処理するための第２プログラムコード」が何を意味するものかをまず検討する。
　本件補正後の請求項３には，「前記サービスはゲームサービスを含み、
　前記サービスロジックは、前記ゲームサービスを通じて提供されるゲームのルールにしたがって前記クライアントで前記ゲームが行われるように制御するためのロジックであって、前記第２サーバモジュールファイルに含まれた前記第２プログラムコードにしたがって前記サーバによって制御される」と記載されている。
　また，本願明細書の段落２７乃至２８には，
「【００２７】
　
サーバ
は、複数の電子機器
とネットワーク
を介して通信して
サービスなどを提供するコンピュータ装置または複数のコンピュータ装置
【００２８】
　一例として、サーバ３６０は、ネットワーク３７０を介して接続した電子機器１（３１０）にアプリケーションのインストールのためのファイルを提供してもよい。この場合、電子機器１（３１０）は、サーバ３６０から提供されたファイルを利用してアプリケーションをインストールしてもよい。また、
電子機器
が含むオペレーティングシステム（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ：ＯＳ）および少なくとも１つのプログラム（一例として、ブラウザや前記インストールされたアプリケーション）の制御にしたがってサーバ
に接続し、サーバ
が提供するサービス
の提供を受けてもよい
サーバ
は、複数の電子機器
にゲームサービスを提供してもよい
と記載され，また同段落３８及び４６に，
「【００３８】
　段階６１０で、
プロセッサ
は、モジュール処理方法のためのプログラムのファイルに格納されたプログラムコードをメモリ４２１にロードして
プログラムは、サービスの提供のために必要なファイルを管理し、該当のファイルに含まれたプログラムコードもメモリ４２１にロードするためにサーバ３５０に予め設定されたプログラムであってもよい
「【００４６】
　段階６６０で、ロジック処理部５２０は、第１サーバモジュールファイルに含まれたプログラムコードを利用してサービスのためのサーバ機能を駆動するが、
サーバ機能を通じて接続するクライアントにサービスを提供するためのサービスロジックを第２サーバモジュールファイルに含まれたプログラムコードを利用して処理してもよい
サービスはゲームサービスを含んでもよい。ここで、サービスロジックは、ゲームサービスを通じて提供されるゲームのルールにしたがってクライアントでゲームが行われるように制御するためのロジックであって、第２サーバモジュールファイルに含まれたプログラムコードにしたがってサーバ３５０によって制御されてもよい
と記載されている。
　上記記載のうち，特に下線部に着目すると，本願明細書には，
「サーバは，複数の電子機器とネットワークを介して通信してサービスなどを提供するコンピュータ装置または複数のコンピュータ装置であって，
　前記電子機器は，前記電子機器が含むオペレーティングシステム（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ：ＯＳ）および少なくとも１つのプログラム（一例として，ブラウザや前記インストールされたアプリケーション）の制御にしたがって前記サーバに接続して前記サーバが提供するサービスの提供を受け，
　前記サーバは，前記複数の電子機器にゲームサービスを提供する」こと及び，
「プロセッサは，モジュール処理方法のためのプログラムのファイルに格納されたプログラムコードをメモリにロードし，
　前記プログラムは，サービスの提供のために必要なファイルを管理し，該当のファイルに含まれたプログラムコードもメモリにロードするためにサーバに予め設定されたプログラム」であることを読み取ることができる。
　そしてまた，
「サーバ機能を通じて接続するクライアントにサービスを提供するためのサービスロジックを第２サーバモジュールファイルに含まれたプログラムコードを利用して処理し，前記サービスはゲームサービスを含み，前記サービスロジックは，前記ゲームサービスを通じて提供されるゲームのルールにしたがって前記クライアントでゲームが行われるように制御するためのロジックであって，第２サーバモジュールファイルに含まれたプログラムコードにしたがってサーバによって制御される」ことについても読み取ることができる。
　以上のことから，本件補正発明の「前記サーバから前記クライアントに前記サービスを提供するためのサービスロジックを処理するための第２プログラムコード」とは，「サーバ」が提供する「サービス」（例えばゲームサービス）を実現するプログラムのプログラムコードを意味し，このようなプログラムのプログラムコードを含む「第２サーバモジュールファイル」によって当該サービスが提供されるものであることが理解される。
　一方，引用発明は，「Webアプリケーション」を実現するための「Webアプリケーション開発方法」であるものの，当該「Webアプリケーション」は，「サーバ104」において実行されて，「クライアント」が「処理結果を得る」ものであることに鑑みれば，本件補正発明と同様，「サーバ」によって「サービス」が提供される点において共通するものといえ，当然にその「サービス」が提供されるためのプログラムの「入力」，「格納」，および「管理」，さらに「処理」も行われることは明らかである。
　してみれば，相違点２及び３は，「サーバ」によって提供される「サービス」を実行するためのプログラムが，「サーバモジュールファイル」という，「モジュール」と呼ばれる形式で取り扱われていて，さらに，当該「サーバモジュールファイル」が，「クライアントプログラムの開発者から提供され」るか否かの点に帰着する。
　上記アで指摘したとおり引用発明においても“コンポーネント”を用いて処理を行っていることに鑑みれば，引用発明において「サーバ104」によって提供されるサービスを実行するためのプログラムを，サーバモジュールファイルという“モジュール”と呼ばれる形式で取り扱うことに格別困難性はなく，さらに上記（３）イで判断したとおり，引用発明においても，当該サーバモジュールファイルが入力され，格納および管理されることも自明である。
　そしてまた，引用発明は，「コントロールクラス107，レイアウトクラス113，および出力データ保持クラス108のようなHTMLページ103の作成に関する役割を持つ表示層114と，画面レイアウトに依存しない業務処理を行う業務処理クラス110やデータベースにアクセスする役割を持つデータベースアクセスクラス112のようにWebアプリケーションに特有の処理を記述したクラスとの間の依存関係を減ら」すものであって，「画面仕様に変更があった場合でも，業務に依存する処理を記述したコンポーネントに変更を加える必要」をなくし，「表示層の部分のみを作成するだけで良く」したものであり，「プログラムファイルを生成する」場合に，「プログラムを生成するユースケースの選択処理」において「ユースケースを端末202に表示して，アプリケーション開発者201がマウスやキーボードを使って選択させて行う」ものでもあることから，当該「アプリケーション開発者201」によって，「プログラムを生成するユースケース」の選択がなされるものである。このような選択によって，プログラムが生成されることはすなわち，引用発明においては，少なくとも“プログラムの開発者”が当該プログラムの提供に関わっているといえ，さらに引用発明は，「業務系システムや，業務サービスシステムをWeb上で公開する場合，その開発サイクルを短縮することが，顧客ニーズとして強い要求事項であって，Webアプリケーションにおいて，HTMLページのデザインや情報を定期的に変更したり，サービスを迅速に拡張したりと短期間に開発を行うことが求められ，それらの開発のニーズに対応し，Webアプリケーションの開発サイクルに対応するためにも，開発作業を軽減させ，かつ，スピードアップを図る必要があることを背景とし，HTMLページの画面仕様などを変更するたびに，業務処理を行うコンポーネントの変更をせざるを得ず，Webアプリケーションの開発サイクルに対応するために手間と時間がかかるという課題」を有するものであって，とりわけ「HTMLページのデザインや情報」の「定期的」な「変更」を行うことは，「開発のニーズ」，すなわち顧客たるクライアント側での対応を求められていることから，当該プログラムの開発者を「クライアントプログラムの開発者」とすることに十分な動機付けがあったものと認められる。
　したがって，引用発明において，上記相違点２及び３に係る構成，すなわち，「前記サーバから前記クライアントに前記サービスを提供するためのサービスロジックを処理するための第２プログラムコードが含まれたモジュールを含む第２サーバモジュールファイル」の「入力」，「格納」，および「管理」，さらに「処理」を行い，また当該「第２サーバモジュールファイル」に相当するものを，「クライアントプログラムの開発者から提供」するよう構成することは，当業者が容易になし得たものである。
ウ　小括
　以上検討したとおり，相違点１乃至３はいずれも格別なものではなく，またそのことによる効果も，当業者であれば普通に想起し得る程度のことに過ぎない。
　したがって，本件補正発明は，引用発明に基づいて当業者が容易に発明をすることができたものであり，特許法２９条２項の規定により，特許出願の際独立して特許を受けることができないものである。
３　本件補正についてのむすび
　以上のとおり，本件補正は特許法１７条の２第６項において準用する同法１２６条７項の規定に違反するので，同法１５９条１項において読み替えて準用する同法５３条１項の規定により却下すべきものである。
　よって，上記補正の却下の決定の結論のとおり決定する。
第３　本願発明について
１　本願発明
　本件補正は，上記のとおり却下されたので，本願の請求項に係る発明は，平成３０年３月１２日にされた手続補正により補正された特許請求の範囲に記載された事項により特定されるものであるところ，その請求項１に係る発明（以下，「本願発明」という。）は，明細書及び図面の記載からみて，その請求項１に記載された事項により特定される，前記第２［理由］１（２）に記載のとおりのものである。再掲すれば，次のとおり。
「サーバ−クライアント環境でサービスを提供するサーバのモジュール処理方法であって、
　前記サーバが、前記サービスのためのサーバ機能及びクライアントとの接続を管理するためのアクセス管理モジュールを含む第１サーバモジュールファイルの入力を受けて格納および管理する段階、
　前記サーバが、クライアントプログラムの開発者から提供された第２サーバモジュールファイルの入力を受けて格納および管理する段階、および
　前記サーバで、前記第１サーバモジュールファイルに含まれたプログラムコードを利用して前記サーバ機能を駆動し、前記サーバ機能を通じて前記クライアントとの接続を管理するための前記アクセス管理モジュールを介して接続する前記クライアントに前記サービスを提供するためのサービスロジックを前記第２サーバモジュールファイルに含まれたプログラムコードを利用して処理する段階
　を含むことを特徴とする、モジュール処理方法。」
２　原査定の拒絶の理由
　原査定の拒絶の理由は，この出願の請求項１乃至１３に係る発明は，本願優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用例１に記載された発明及び引用例２乃至６に記載された周知技術に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができない，というものである。
　そして，とりわけ本願請求項１に係る発明は，引用例１に記載された発明に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができない，というものである。
引用例１：特開２００３−１５８７０号公報
引用例２：国際公開第２０１５／０１１７６２号
引用例３：特開２０１５−１６７７３７号公報
引用例４：武本　充治　他，「分散並行オブジェクト指向モデルによるＡＴＭ交換プログラム」，電子情報通信学会技術研究報告，社団法人電子情報通信学会，１９９５年８月２５日，第９５巻　第２１６号，第５７頁−第６２頁
引用例５：高野　善雄，「「サンフランシスコ・プロジェクト」の全貌」，日経ソフトウエア，日経ＢＰ社，１９９８年８月１５日，第１巻　第４号，第１３２頁−第１３９頁
引用例６：西林　孝，「ＪａｖａＳｃｒｉｐｔ今ドキ活用術　サーバサイドでＪａｖａＳｃｒｉｐｔ」，ＷＥＢ＋ＤＢ　ＰＲＥＳＳ，（株）技術評論社，２０１０年３月２５日，第５５巻　第１版，第１７３頁−第１７９頁
３　引用例
　原査定の拒絶の理由で引用された引用例１の記載事項は，前記第２の［理由］２（２）に記載したとおりである。
４　対比・判断
　本願発明は，前記第２の［理由］２（１）で検討した本件補正発明から，「第１サーバモジュールファイル」及び「第２サーバモジュールファイル」に係る限定事項を削除したものである。
　そうすると，本願発明の発明特定事項を全て含み，さらに他の事項を付加したものに相当する本件補正発明が，前記第２の［理由］２（３），（４）に記載したとおり，引用発明に基づいて，当業者が容易に発明をすることができたものであるから，本願発明も，同様の理由により，引用発明に基づいて，当業者が容易に発明することができたものである。
第４　むすび
　以上のとおり，本願発明は，本願優先日前に頒布された引用例１に記載された発明に基づいて当業者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができない。
　したがって，その余の請求項に係る発明について論及するまでもなく，本願は拒絶すべきものである。
　よって，結論のとおり審決する。