• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1361203
審判番号 不服2018-17074  
総通号数 245 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2020-05-29 
種別 拒絶査定不服の審決 
審判請求日 2018-12-21 
確定日 2020-03-25 
事件の表示 特願2016-248575「モジュール処理方法およびシステム、並びに記録媒体」拒絶査定不服審判事件〔平成29年 7月 6日出願公開、特開2017-120637〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯

本願は,平成28年12月22日(パリ条約による優先権主張2015年12月31日(以下,「本願優先日」という。),韓国)の出願であって,平成29年11月22日付けで拒絶の理由が通知され,平成30年3月12日に意見書とともに手続補正書が提出され,同年8月14日付けで拒絶査定(謄本送達日同年8月21日)がなされ,これに対して同年12月21日に審判請求がなされると共に手続補正がなされ,平成31年4月8日付けで審査官により特許法164条3項の規定に基づく報告がなされ,令和元年5月30日に上申書が提出されたものである。


第2 平成30年12月21日にされた手続補正についての補正の却下の決定

[補正の却下の決定の結論]

平成30年12月21日にされた手続補正(以下,「本件補正」という。)を却下する。

[理由]
1 本件補正について
(1)本件補正後の特許請求の範囲の記載
本件補正により,特許請求の範囲の請求項1の記載は,次のとおり補正された。(下線部は,補正箇所である。)
「サーバ-クライアント環境でサービスを提供するサーバのモジュール処理方法であって、
前記サーバが、前記サービスのためのサーバ機能を駆動する第1プログラムコード及びクライアントとの接続を管理するためのアクセス管理モジュールを含む第1サーバモジュールファイルの入力を受けて格納および管理する段階、
前記サーバが、クライアントプログラムの開発者から提供され、前記サーバから前記クライアントに前記サービスを提供するためのサービスロジックを処理するための第2プログラムコードが含まれたモジュールを含む第2サーバモジュールファイルの入力を受けて格納および管理する段階、および
前記サーバで、前記第1サーバモジュールファイルに含まれた前記第1プログラムコードを利用して前記サーバ機能を駆動し、前記サーバ機能を通じて前記クライアントとの接続を管理するための前記アクセス管理モジュールを介して接続する前記クライアントに前記サービスを提供するためのサービスロジックを前記第2サーバモジュールファイルに含まれた前記第2プログラムコードを利用して処理する段階を含むことを特徴とする、モジュール処理方法。」

(2)本件補正前の特許請求の範囲
本件補正前の,平成30年3月12日にされた手続補正により補正された特許請求の範囲の請求項1の記載は次のとおりである。
「サーバ-クライアント環境でサービスを提供するサーバのモジュール処理方法であって、
前記サーバが、前記サービスのためのサーバ機能及びクライアントとの接続を管理するためのアクセス管理モジュールを含む第1サーバモジュールファイルの入力を受けて格納および管理する段階、
前記サーバが、クライアントプログラムの開発者から提供された第2サーバモジュールファイルの入力を受けて格納および管理する段階、および
前記サーバで、前記第1サーバモジュールファイルに含まれたプログラムコードを利用して前記サーバ機能を駆動し、前記サーバ機能を通じて前記クライアントとの接続を管理するための前記アクセス管理モジュールを介して接続する前記クライアントに前記サービスを提供するためのサービスロジックを前記第2サーバモジュールファイルに含まれたプログラムコードを利用して処理する段階
を含むことを特徴とする、モジュール処理方法。」

2 補正の適否
本件補正は,本件補正前の請求項1に記載された発明を特定するために必要な事項である「第1サーバモジュールファイル」及び「第2サーバモジュールファイル」について,上記のとおり限定を付加するものであって,補正前の請求項1に記載された発明と補正後の請求項1に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから,特許法17条の2第5項2号の特許請求の範囲の減縮を目的とするものに該当する。
そこで,本件補正後の請求項1に記載される発明(以下「本件補正発明」という。)が同条6項において準用する同法126条7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について,以下,検討する。

(1)本件補正発明
本件補正発明は,上記1(1)に記載したとおりのものである。

(2)引用例
ア 引用例に記載された事項
原査定の拒絶の理由において引用された本願優先日前に既に公知である,特開2003-15870号公報(平成15年1月17日公開。以下,これを「引用例1」という。)には,関連する図面と共に,次の事項が記載されている。(下線は説明のために当審にて付加。以下同様。)

A 「【請求項1】Webアプリケーション開発方法であって、
Webブラウザに1つの表示画面を表示するファイルを生成する役割を持つコンポーネントを表示層のコンポーネントの1つとし、複数の表示画面に対応する複数の表示層のコンポーネントを定義するステップと、
業務処理を行うコンポーネントやデータベースにアクセスする役割を持つコンポーネントを業務シナリオ層として定義するステップと、
複数の表示層のコンポーネントから呼び出される操作と、表示層のコンポーネントにより表示された表示画面で入力された情報や業務シナリオ層で実行された業務処理により得られた値を保存する領域を持つコンポーネントを1つの業務プロセス層として定義するステップとを備えることを特徴とするWebアプリケーション開発方法。」(特許請求の範囲)

B 「【0003】
【発明が解決しようとする課題】近年のシステム開発において、開発サイクルはますます短くなってきている。特に業務系システムや、業務サービスシステムをWeb上で公開する場合、その開発サイクルを短縮することは、顧客ニーズとして強い要求事項である。Webアプリケーションにおいて、HTMLページのデザインや情報を定期的に変更したり、サービスを迅速に拡張したりと短期間に開発を行うことが求められている。それらの開発のニーズに対応し、Webアプリケーションの開発サイクルに対応するためにも、開発作業を軽減させ、かつ、スピードアップを図る必要がある。
【0004】しかし、前述の従来のWebアプリケーション開発方法では、表示する役割を持つコンポーネントが業務処理を行うコンポーネントの操作を呼び出すように構成されているため、表示する役割を持つコンポーネントに追加、変更を施すとその影響は業務処理のコンポーネントにまで及んでいた。例えば、パソコンでは1つの表示画面で操作入力できるが、携帯電話では複数の画面が必要な場合がある。このとき、パソコンの表示層のコンポーネントから業務処理を行うコンポーネントを呼び出す入口と、携帯電話の表示層のコンポーネントから業務処理を行うコンポーネントを呼び出す入口を、それぞれ作らなければいけなかった。したがって、HTMLページの画面仕様などを変更するたびに、業務処理を行うコンポーネントの変更をせざるを得ず、Webアプリケーションの開発サイクルに対応するために手間と時間がかかるという問題があった。本発明は、サーバサイドJava技術を利用したWebアプリケーションの開発において、開発作業の負担を軽減させ、かつスピードアップを図ることを目的とするものである。」

C 「【0015】本実施の形態では、Webアプリケーション開発において、表示層のコンポーネントに呼び出される操作と情報を保存する領域を持つコンポーネントが業務プロセス層として定義される。定義された業務プロセス層は、1つ以上のHTMLページを使ってWebアプリケーションのサービスが行われる場合、現在の画面で入力された情報や、業務シナリオ層の処理により得られた値を、次の画面やその次の画面で使用するために保存する。また、業務プロセス層には、表示層が業務シナリオ層やデータベースにアクセスする役割を持つコンポーネントを呼び出して処理を行う操作が定義されている。これにより、クライアントのWebブラウザに表示するHTMLページを作成する役割を持つ表示層のコンポーネントは、表示するための情報(すでに前の画面などで入力された情報や業務シナリオ層の処理により得られている値)を得るために、共有データ保持クラスに定義されているWebアプリケーションの業務処理を行う操作を呼び出すだけで処理結果を得ることができる。したがって、画面仕様に変更があった場合でも、業務に依存する処理を記述したコンポーネントに変更を加える必要がない。また、クライアントの表示画面が違うとき、例えば、パソコンから利用していたWebアプリケーションを携帯端末からも利用できるようにするときのように、1つのHTMLページを分割したり画面レイアウトが変更したりする場合も、表示層の部分のみを作成するだけで良い。」

D 「【0018】開発対象の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技術のコンポーネントの実行環境が含まれている。
【0019】Webアプリケーションを構成する各プログラムは、実行可能な状態で、サーバ104にあるアプリケーションサーバ106上に配置される。サーバ104に要求が送信されると、要求に応じて該当するコントロールクラス107(コントロール層)が起動される。本実施形態では、サーバサイドJava技術のサーブレットを使ってコントロールクラス107を作成している。コントロールクラス107は、起動されると、Webブラウザ102から入力された情報の解析や画面へ出力するデータを保持する役割を持っているJava BeansやEJBで作成された出力データ保持クラス108に定義されている操作を使うことで、出力データ保持クラス108に処理を依頼する。」

E 「【0020】出力データ保持クラス108は、入力画面の情報やHTMLページ103に表示する処理の結果を保持したり、共有データ保持クラス109(業務プロセス層)やWebアプリケーションの業務処理を行う業務処理クラス110(業務シナリオ層)で定義されている操作を使うことで処理の要求を出す。共有データ保持クラス109や業務処理クラス110は、業務の分析や設計で導出された処理を実装したクラスや、利用可能な既存クラスである。共有データ保持クラス109や業務処理クラス110は、処理した結果を返すか、自分の属性値として保存する。出力データ保持クラス108は、返ってきた値や共有データ保持クラス109や業務処理クラス110の属性値を取得することで、要求した処理の結果を得ることができる。」

F 「【0027】Webアプリケーションが処理を行うための情報を保持するためのクラスを設けた図1のようなシステム構成にすることで、コントロールクラス107、レイアウトクラス113、および出力データ保持クラス108のようなHTMLページ103の作成に関する役割を持つ表示層114と、画面レイアウトに依存しない業務処理を行う業務処理クラス110やデータベースにアクセスする役割を持つデータベースアクセスクラス112のようにWebアプリケーションに特有の処理を記述したクラスとの間の依存関係を減らすことができ、各クラスの機能分担を明確にすることができる。また、パーソナルコンピュータから利用していたWebアプリケーションを携帯端末からも利用できるようにするときのように、1つのHTMLページを分割したり、画面レイアウトが変更される場合も、表示層114の部分のみを作成するだけで良い。」

G 「【0058】次に、業務プロセス層の共有データ保持クラス109を作成する流れの詳細について説明する。図9は、図3と図4と図6を使って共有データ保持クラス109のプログラムファイルをプログラム生成装置209によって生成する処理の流れを示したフローチャートである。本実施形態では、ユースケース名称「車を購入する」603に対応している共有データ保持クラス「PurchaseProcessEJB」609を生成するプログラムファイル「PurchaseProcessEJB.java」を、プログラム生成装置209によって生成する例を使って処理の流れを説明する。
【0059】まず、ステップ901で、業務プロセス定義表601を定義表保存装置208からプログラム生成装置209へ読み込む。
【0060】ステップ902では、ステップ901で読み込んだ業務プロセス定義表601のユースケース602からユースケース名称を取得し、プログラムを生成するユースケースを選択する。本実施形態では、プログラムファイル名称「PurchaseProcessEJB.java」のプログラムの生成を行うので、「車を購入する」603を選択する。このプログラムを生成するユースケースの選択処理は、取得したユースケースを端末202に表示して、アプリケーション開発者201にマウスやキーボードを使って選択させても良い。」

イ 引用発明

(ア)上記記載事項Bの,「特に業務系システムや、業務サービスシステムをWeb上で公開する場合、その開発サイクルを短縮することは、顧客ニーズとして強い要求事項である。Webアプリケーションにおいて、HTMLページのデザインや情報を定期的に変更したり、サービスを迅速に拡張したりと短期間に開発を行うことが求められている。それらの開発のニーズに対応し、Webアプリケーションの開発サイクルに対応するためにも、開発作業を軽減させ、かつ、スピードアップを図る必要がある。」との記載,及び「したがって、HTMLページの画面仕様などを変更するたびに、業務処理を行うコンポーネントの変更をせざるを得ず、Webアプリケーションの開発サイクルに対応するために手間と時間がかかるという問題があった。本発明は、サーバサイドJava技術を利用したWebアプリケーションの開発において、開発作業の負担を軽減させ、かつスピードアップを図ることを目的とするものである。」との記載から,引用例1には,“業務系システムや,業務サービスシステムをWeb上で公開する場合,その開発サイクルを短縮することが,顧客ニーズとして強い要求事項であって,Webアプリケーションにおいて,HTMLページのデザインや情報を定期的に変更したり,サービスを迅速に拡張したりと短期間に開発を行うことが求められ,それらの開発のニーズに対応し,Webアプリケーションの開発サイクルに対応するためにも,開発作業を軽減させ,かつ,スピードアップを図る必要があることを背景とし,HTMLページの画面仕様などを変更するたびに,業務処理を行うコンポーネントの変更をせざるを得ず,Webアプリケーションの開発サイクルに対応するために手間と時間がかかるという課題に対し,サーバサイドJava技術を利用したWebアプリケーションの開発において,開発作業の負担を軽減させ,かつスピードアップを図ることを目的と”したものであることが記載されているといえる。

(イ)上記記載事項Aの「Webアプリケーション開発方法であって」との記載,及び記載事項Cの「本実施の形態では、Webアプリケーション開発において、表示層のコンポーネントに呼び出される操作と情報を保存する領域を持つコンポーネントが業務プロセス層として定義される。」との記載から,引用例1には,“Webアプリケーション開発方法”について記載されているといえる。
同じく記載事項Cの「また、業務プロセス層には、表示層が業務シナリオ層やデータベースにアクセスする役割を持つコンポーネントを呼び出して処理を行う操作が定義されている。これにより、クライアントのWebブラウザに表示するHTMLページを作成する役割を持つ表示層のコンポーネントは、表示するための情報(すでに前の画面などで入力された情報や業務シナリオ層の処理により得られている値)を得るために、共有データ保持クラスに定義されているWebアプリケーションの業務処理を行う操作を呼び出すだけで処理結果を得ることができる。」との記載から,引用例1には,“業務プロセス層には,表示層が業務シナリオ層やデータベースにアクセスする役割を持つコンポーネントを呼び出して処理を行う操作が定義され,これにより,クライアントのWebブラウザに表示するHTMLページを作成する役割を持つ表示層のコンポーネントは,表示するための情報を得るために,共有データ保持クラスに定義されているWebアプリケーションの業務処理を行う操作を呼び出すだけで処理結果を得ることができ”ることが記載されているといえる。
同じく記載事項Cの「画面仕様に変更があった場合でも、業務に依存する処理を記述したコンポーネントに変更を加える必要がない。…(中略)…パソコンから利用していたWebアプリケーションを携帯端末からも利用できるようにするときのように、1つのHTMLページを分割したり画面レイアウトが変更したりする場合も、表示層の部分のみを作成するだけで良い。」との記載から,引用例1には,“画面仕様に変更があった場合でも,業務に依存する処理を記述したコンポーネントに変更を加える必要がなく,パソコンから利用していたWebアプリケーションを携帯端末からも利用できるようにするときのように,1つのHTMLページを分割したり画面レイアウトが変更したりする場合も,表示層の部分のみを作成するだけで良”いことが記載されているといえる。

(ウ)上記記載事項Dの「開発対象の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技術のコンポーネントの実行環境が含まれている。」との記載から,引用例1には,“開発対象のWebアプリケーションは,クライアント101がWebブラウザ102を使うことによって利用され,Webブラウザ102上には,HTMLページ103が表示され,Webブラウザ102からの要求は,HTTP経由でサーバ104に送信され”ること,及び“サーバ104は,HTTPサーバ105とアプリケーションサーバ106とを有し,アプリケーションサーバ106には,サーバサイドJava技術のコンポーネントの実行環境が含まれて”いることが記載されているといえる。
同じく記載事項Dの「Webアプリケーションを構成する各プログラムは、実行可能な状態で、サーバ104にあるアプリケーションサーバ106上に配置される。サーバ104に要求が送信されると、要求に応じて該当するコントロールクラス107(コントロール層)が起動される。」との記載から,引用例1には“Webアプリケーションを構成する各プログラムは,実行可能な状態で,サーバ104にあるアプリケーションサーバ106上に配置され,サーバ104に要求が送信されると,要求に応じて該当するコントロールクラス107(コントロール層)が起動され”ることが記載されているといえる。

(エ)上記記載事項Eの「出力データ保持クラス108は、入力画面の情報やHTMLページ103に表示する処理の結果を保持したり、共有データ保持クラス109(業務プロセス層)やWebアプリケーションの業務処理を行う業務処理クラス110(業務シナリオ層)で定義されている操作を使うことで処理の要求を出す。共有データ保持クラス109や業務処理クラス110は、業務の分析や設計で導出された処理を実装したクラスや、利用可能な既存クラスである。」との記載から,引用例1には,“出力データ保持クラス108は,入力画面の情報やHTMLページ103に表示する処理の結果を保持したり,共有データ保持クラス109(業務プロセス層)やWebアプリケーションの業務処理を行う業務処理クラス110(業務シナリオ層)で定義されている操作を使うことで処理の要求を出し,共有データ保持クラス109や業務処理クラス110は,業務の分析や設計で導出された処理を実装したクラス”であることが記載されているといえる。

(オ)上記記載事項Fの「Webアプリケーションが処理を行うための情報を保持するためのクラスを設けた図1のようなシステム構成にすることで、コントロールクラス107、レイアウトクラス113、および出力データ保持クラス108のようなHTMLページ103の作成に関する役割を持つ表示層114と、画面レイアウトに依存しない業務処理を行う業務処理クラス110やデータベースにアクセスする役割を持つデータベースアクセスクラス112のようにWebアプリケーションに特有の処理を記述したクラスとの間の依存関係を減らすことができ、各クラスの機能分担を明確にすることができる。」との記載から,引用例1には,“コントロールクラス107,レイアウトクラス113,および出力データ保持クラス108のようなHTMLページ103の作成に関する役割を持つ表示層114と,画面レイアウトに依存しない業務処理を行う業務処理クラス110やデータベースにアクセスする役割を持つデータベースアクセスクラス112のようにWebアプリケーションに特有の処理を記述したクラスとの間の依存関係を減ら”すことが記載されているといえる。

(カ)上記記載事項Gの「本実施形態では、ユースケース名称「車を購入する」603に対応している共有データ保持クラス「PurchaseProcessEJB」609を生成するプログラムファイル「PurchaseProcessEJB.java」を、プログラム生成装置209によって生成する例を使って処理の流れを説明する。」との記載,及び「このプログラムを生成するユースケースの選択処理は、取得したユースケースを端末202に表示して、アプリケーション開発者201にマウスやキーボードを使って選択させても良い。」との記載から,引用例1には,“プログラムファイルを生成する場合,このプログラムを生成するユースケースの選択処理は,ユースケースを端末202に表示して,アプリケーション開発者201がマウスやキーボードを使って選択させて行う”ことが記載されているといえる。

(キ)以上上記(ア)乃至(カ)より,引用例1には,次の発明(以下「引用発明」という。)が記載されているといえる。

「業務系システムや,業務サービスシステムをWeb上で公開する場合,その開発サイクルを短縮することが,顧客ニーズとして強い要求事項であって,Webアプリケーションにおいて,HTMLページのデザインや情報を定期的に変更したり,サービスを迅速に拡張したりと短期間に開発を行うことが求められ,それらの開発のニーズに対応し,Webアプリケーションの開発サイクルに対応するためにも,開発作業を軽減させ,かつ,スピードアップを図る必要があることを背景とし,HTMLページの画面仕様などを変更するたびに,業務処理を行うコンポーネントの変更をせざるを得ず,Webアプリケーションの開発サイクルに対応するために手間と時間がかかるという課題に対し,サーバサイドJava技術を利用したWebアプリケーションの開発において,開発作業の負担を軽減させ,かつスピードアップを図ることを目的としたWebアプリケーション開発方法であって,
業務プロセス層には,表示層が業務シナリオ層やデータベースにアクセスする役割を持つコンポーネントを呼び出して処理を行う操作が定義され,これにより,クライアントのWebブラウザに表示するHTMLページを作成する役割を持つ表示層のコンポーネントは,表示するための情報を得るために,共有データ保持クラスに定義されているWebアプリケーションの業務処理を行う操作を呼び出すだけで処理結果を得ることができ,
画面仕様に変更があった場合でも,業務に依存する処理を記述したコンポーネントに変更を加える必要がなく,パソコンから利用していたWebアプリケーションを携帯端末からも利用できるようにするときのように,1つの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アプリケーション開発方法。」

(3)対比
本件補正発明と引用発明とを対比する。

ア 引用発明の「開発対象の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アプリケーション開発方法」と本件補正発明の「サーバ-クライアント環境でサービスを提供するサーバのモジュール処理方法」とは,下記の点(相違点1)で相違するものの,“サーバ-クライアント環境でサービスを提供するサーバにおける方法”である点で一致する。

イ 引用発明の「サーバ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上に配置され」ていることから,上記アの「サービス」に関する認定と合わせ考慮すれば,引用発明は,本件補正発明の「前記サーバが、前記サービスのためのサーバ機能を駆動する第1プログラムコード」に相当する構成を有していることも当業者に明らかである。
そして,引用発明の「サーバ104」が,「クライアントとの接続を管理する」機能を有し,またそのための「アクセス管理モジュール」,及び,「前記サーバが、前記サービスのためのサーバ機能を駆動する第1プログラムコード」に相当する構成を有し,「クライアントとの接続を管理する」機能や「前記サービスのためのサーバ機能」を実現するためには,当該「サーバ104」にそのための実装が行われることは当業者にとって自明であり,そして,当該実装に際しては,「アプリケーションサーバ106」に,「サーバサイドJava技術のコンポーネントの実行環境が含まれ」ていることから,当該「サーバサイドJava技術のコンポーネント」に対応した,何らかの「サーバモジュールファイル」が「入力」され,「格納および管理」されることも自明である。
したがって,引用発明と本件補正発明とは,“前記サーバが,前記サービスのためのサーバ機能を駆動する第1プログラムコード及びクライアントとの接続を管理するためのアクセス管理モジュールを含む第1サーバモジュールファイルの入力を受けて格納および管理する段階”を含む点で一致するといえる。

ウ 上記イの認定から,引用発明においては,本件補正発明の「前記第1サーバモジュールファイルに含まれた前記第1プログラムコード」を利用して「前記サーバ機能を駆動」していることから,引用発明と本件補正発明の「前記サーバで、前記第1サーバモジュールファイルに含まれた前記第1プログラムコードを利用して前記サーバ機能を駆動し、前記サーバ機能を通じて前記クライアントとの接続を管理するための前記アクセス管理モジュールを介して接続する前記クライアントに前記サービスを提供するためのサービスロジックを前記第2サーバモジュールファイルに含まれた前記第2プログラムコードを利用して処理する段階」とは,下記の点で相違するものの,“前記サーバで,前記第1サーバモジュールファイルに含まれた前記第1プログラムコードを利用して前記サーバ機能を駆動する段階”を含む点で一致するといえる。

エ 以上,ア乃至ウの検討から,引用発明と本件補正発明とは,次の一致点及び相違点を有する。

〈一致点〉
「サーバ-クライアント環境でサービスを提供するサーバにおける方法であって,
前記サーバが,前記サービスのためのサーバ機能を駆動する第1プログラムコード及びクライアントとの接続を管理するためのアクセス管理モジュールを含む第1サーバモジュールファイルの入力を受けて格納および管理する段階,および
前記サーバで,前記第1サーバモジュールファイルに含まれた前記第1プログラムコードを利用して前記サーバ機能を駆動する段階を含む,サーバにおける方法。」

〈相違点1〉
本件補正発明が,「モジュール処理方法」であるのに対し,引用発明は,「Webアプリケーション開発方法」である点。

〈相違点2〉
本件補正発明が,「前記サーバが、クライアントプログラムの開発者から提供され、前記サーバから前記クライアントに前記サービスを提供するためのサービスロジックを処理するための第2プログラムコードが含まれたモジュールを含む第2サーバモジュールファイルの入力を受けて格納および管理する段階」を含むのに対し,引用発明は,そのような段階を含むことが特定されていない点。

〈相違点3〉
本件補正発明が,「前記サーバ機能を通じて前記クライアントとの接続を管理するための前記アクセス管理モジュールを介して接続する前記クライアントに前記サービスを提供するためのサービスロジックを前記第2サーバモジュールファイルに含まれた前記第2プログラムコードを利用して処理する段階」を含むのに対し,引用発明は,そのような段階を含むことが特定されていない点。

(4)判断
上記相違点につき検討する。

ア 相違点1について
まず相違点1について検討する。
引用発明は,「業務プロセス層には,表示層が業務シナリオ層やデータベースにアクセスする役割を持つコンポーネントを呼び出して処理を行う操作が定義され」ており,これにより,「クライアントのWebブラウザに表示するHTMLページを作成する役割を持つ表示層のコンポーネント」が,「表示するための情報を得るために,共有データ保持クラスに定義されているWebアプリケーションの業務処理を行う操作を呼び出すだけで処理結果を得ることができ」るものである。そして,これらの「業務プロセス層」,「表示層」,「業務シナリオ層」は,所定の「コンポーネント」を単位として管理されているといえ,当該「コンポーネント」は,処理単位として“モジュール”ともいい得るものであることから,引用発明の「Webアプリケーション開発方法」と,本件補正発明の「モジュール処理方法」との間に,実質的な相違はなく,本相違は格別なものとはいえない。

イ 相違点2及び3について
次に相違点2及び3をまとめて検討する。
本件補正発明の「前記サーバから前記クライアントに前記サービスを提供するためのサービスロジックを処理するための第2プログラムコード」が何を意味するものかをまず検討する。
本件補正後の請求項3には,「前記サービスはゲームサービスを含み、
前記サービスロジックは、前記ゲームサービスを通じて提供されるゲームのルールにしたがって前記クライアントで前記ゲームが行われるように制御するためのロジックであって、前記第2サーバモジュールファイルに含まれた前記第2プログラムコードにしたがって前記サーバによって制御される」と記載されている。
また,本願明細書の段落27乃至28には,
「【0027】
サーバ350、360それぞれは、複数の電子機器310、320、330、340とネットワーク370を介して通信して命令、コード、ファイル、コンテンツ、サービスなどを提供するコンピュータ装置または複数のコンピュータ装置によって実現されてもよい。
【0028】
一例として、サーバ360は、ネットワーク370を介して接続した電子機器1(310)にアプリケーションのインストールのためのファイルを提供してもよい。この場合、電子機器1(310)は、サーバ360から提供されたファイルを利用してアプリケーションをインストールしてもよい。また、電子機器1(310)が含むオペレーティングシステム(Oｐeｒaｔing Sｙｓｔem:OS)および少なくとも1つのプログラム(一例として、ブラウザや前記インストールされたアプリケーション)の制御にしたがってサーバ350に接続し、サーバ350が提供するサービスやコンテンツの提供を受けてもよい。例えば、電子機器1(310)がアプリケーションの制御にしたがってネットワーク370を介してサービス要請メッセージをサーバ350に送信すると、サーバ350はサービス要請メッセージに対応するコードを電子機器1(310)に送信してもよく、電子機器1(310)はアプリケーションの制御にしたがってコードに基づく画面を構成して表示することによってユーザにコンテンツを提供してもよい。他の例として、サーバ350は、メッセージングサービスのための通信セッションを設定し、設定された通信セッションを通じて複数の電子機器310、320、330、340間のメッセージ送受信をルーティングしてもよい。また他の例として、サーバ350は、複数の電子機器310、320、330、340間の映像通話を中継してもよい。さらに他の例として、サーバ350は、複数の電子機器310、320、330、340にゲームサービスを提供してもよい。」
と記載され,また同段落38及び46に,
「【0038】
段階610で、プロセッサ422は、モジュール処理方法のためのプログラムのファイルに格納されたプログラムコードをメモリ421にロードしてもよい。例えば、プログラムは、サービスの提供のために必要なファイルを管理し、該当のファイルに含まれたプログラムコードもメモリ421にロードするためにサーバ350に予め設定されたプログラムであってもよい。サーバ350に予めインストールされているプログラムが実行された場合、プロセッサ422は、プログラムのファイルからプログラムコードをメモリ421にロードしてもよい。」及び,
「【0046】
段階660で、ロジック処理部520は、第1サーバモジュールファイルに含まれたプログラムコードを利用してサービスのためのサーバ機能を駆動するが、サーバ機能を通じて接続するクライアントにサービスを提供するためのサービスロジックを第2サーバモジュールファイルに含まれたプログラムコードを利用して処理してもよい。例えば、サービスはゲームサービスを含んでもよい。ここで、サービスロジックは、ゲームサービスを通じて提供されるゲームのルールにしたがってクライアントでゲームが行われるように制御するためのロジックであって、第2サーバモジュールファイルに含まれたプログラムコードにしたがってサーバ350によって制御されてもよい。」
と記載されている。
上記記載のうち,特に下線部に着目すると,本願明細書には,
「サーバは,複数の電子機器とネットワークを介して通信してサービスなどを提供するコンピュータ装置または複数のコンピュータ装置であって,
前記電子機器は,前記電子機器が含むオペレーティングシステム(Oｐeｒaｔing Sｙｓｔem:OS)および少なくとも1つのプログラム(一例として,ブラウザや前記インストールされたアプリケーション)の制御にしたがって前記サーバに接続して前記サーバが提供するサービスの提供を受け,
前記サーバは,前記複数の電子機器にゲームサービスを提供する」こと及び,
「プロセッサは,モジュール処理方法のためのプログラムのファイルに格納されたプログラムコードをメモリにロードし,
前記プログラムは,サービスの提供のために必要なファイルを管理し,該当のファイルに含まれたプログラムコードもメモリにロードするためにサーバに予め設定されたプログラム」であることを読み取ることができる。
そしてまた,
「サーバ機能を通じて接続するクライアントにサービスを提供するためのサービスロジックを第2サーバモジュールファイルに含まれたプログラムコードを利用して処理し,前記サービスはゲームサービスを含み,前記サービスロジックは,前記ゲームサービスを通じて提供されるゲームのルールにしたがって前記クライアントでゲームが行われるように制御するためのロジックであって,第2サーバモジュールファイルに含まれたプログラムコードにしたがってサーバによって制御される」ことについても読み取ることができる。
以上のことから,本件補正発明の「前記サーバから前記クライアントに前記サービスを提供するためのサービスロジックを処理するための第2プログラムコード」とは,「サーバ」が提供する「サービス」(例えばゲームサービス)を実現するプログラムのプログラムコードを意味し,このようなプログラムのプログラムコードを含む「第2サーバモジュールファイル」によって当該サービスが提供されるものであることが理解される。
一方,引用発明は,「Webアプリケーション」を実現するための「Webアプリケーション開発方法」であるものの,当該「Webアプリケーション」は,「サーバ104」において実行されて,「クライアント」が「処理結果を得る」ものであることに鑑みれば,本件補正発明と同様,「サーバ」によって「サービス」が提供される点において共通するものといえ,当然にその「サービス」が提供されるためのプログラムの「入力」,「格納」,および「管理」,さらに「処理」も行われることは明らかである。
してみれば,相違点2及び3は,「サーバ」によって提供される「サービス」を実行するためのプログラムが,「サーバモジュールファイル」という,「モジュール」と呼ばれる形式で取り扱われていて,さらに,当該「サーバモジュールファイル」が,「クライアントプログラムの開発者から提供され」るか否かの点に帰着する。
上記アで指摘したとおり引用発明においても“コンポーネント”を用いて処理を行っていることに鑑みれば,引用発明において「サーバ104」によって提供されるサービスを実行するためのプログラムを,サーバモジュールファイルという“モジュール”と呼ばれる形式で取り扱うことに格別困難性はなく,さらに上記(3)イで判断したとおり,引用発明においても,当該サーバモジュールファイルが入力され,格納および管理されることも自明である。
そしてまた,引用発明は,「コントロールクラス107,レイアウトクラス113,および出力データ保持クラス108のようなHTMLページ103の作成に関する役割を持つ表示層114と,画面レイアウトに依存しない業務処理を行う業務処理クラス110やデータベースにアクセスする役割を持つデータベースアクセスクラス112のようにWebアプリケーションに特有の処理を記述したクラスとの間の依存関係を減ら」すものであって,「画面仕様に変更があった場合でも,業務に依存する処理を記述したコンポーネントに変更を加える必要」をなくし,「表示層の部分のみを作成するだけで良く」したものであり,「プログラムファイルを生成する」場合に,「プログラムを生成するユースケースの選択処理」において「ユースケースを端末202に表示して,アプリケーション開発者201がマウスやキーボードを使って選択させて行う」ものでもあることから,当該「アプリケーション開発者201」によって,「プログラムを生成するユースケース」の選択がなされるものである。このような選択によって,プログラムが生成されることはすなわち,引用発明においては,少なくとも“プログラムの開発者”が当該プログラムの提供に関わっているといえ,さらに引用発明は,「業務系システムや,業務サービスシステムをWeb上で公開する場合,その開発サイクルを短縮することが,顧客ニーズとして強い要求事項であって,Webアプリケーションにおいて,HTMLページのデザインや情報を定期的に変更したり,サービスを迅速に拡張したりと短期間に開発を行うことが求められ,それらの開発のニーズに対応し,Webアプリケーションの開発サイクルに対応するためにも,開発作業を軽減させ,かつ,スピードアップを図る必要があることを背景とし,HTMLページの画面仕様などを変更するたびに,業務処理を行うコンポーネントの変更をせざるを得ず,Webアプリケーションの開発サイクルに対応するために手間と時間がかかるという課題」を有するものであって,とりわけ「HTMLページのデザインや情報」の「定期的」な「変更」を行うことは,「開発のニーズ」,すなわち顧客たるクライアント側での対応を求められていることから,当該プログラムの開発者を「クライアントプログラムの開発者」とすることに十分な動機付けがあったものと認められる。
したがって,引用発明において,上記相違点2及び3に係る構成,すなわち,「前記サーバから前記クライアントに前記サービスを提供するためのサービスロジックを処理するための第2プログラムコードが含まれたモジュールを含む第2サーバモジュールファイル」の「入力」,「格納」,および「管理」,さらに「処理」を行い,また当該「第2サーバモジュールファイル」に相当するものを,「クライアントプログラムの開発者から提供」するよう構成することは,当業者が容易になし得たものである。

ウ 小括
以上検討したとおり,相違点1乃至3はいずれも格別なものではなく,またそのことによる効果も,当業者であれば普通に想起し得る程度のことに過ぎない。
したがって,本件補正発明は,引用発明に基づいて当業者が容易に発明をすることができたものであり,特許法29条2項の規定により,特許出願の際独立して特許を受けることができないものである。

3 本件補正についてのむすび
以上のとおり,本件補正は特許法17条の2第6項において準用する同法126条7項の規定に違反するので,同法159条1項において読み替えて準用する同法53条1項の規定により却下すべきものである。
よって,上記補正の却下の決定の結論のとおり決定する。


第3 本願発明について
1 本願発明
本件補正は,上記のとおり却下されたので,本願の請求項に係る発明は,平成30年3月12日にされた手続補正により補正された特許請求の範囲に記載された事項により特定されるものであるところ,その請求項1に係る発明(以下,「本願発明」という。)は,明細書及び図面の記載からみて,その請求項1に記載された事項により特定される,前記第2[理由]1(2)に記載のとおりのものである。再掲すれば,次のとおり。

「サーバ-クライアント環境でサービスを提供するサーバのモジュール処理方法であって、
前記サーバが、前記サービスのためのサーバ機能及びクライアントとの接続を管理するためのアクセス管理モジュールを含む第1サーバモジュールファイルの入力を受けて格納および管理する段階、
前記サーバが、クライアントプログラムの開発者から提供された第2サーバモジュールファイルの入力を受けて格納および管理する段階、および
前記サーバで、前記第1サーバモジュールファイルに含まれたプログラムコードを利用して前記サーバ機能を駆動し、前記サーバ機能を通じて前記クライアントとの接続を管理するための前記アクセス管理モジュールを介して接続する前記クライアントに前記サービスを提供するためのサービスロジックを前記第2サーバモジュールファイルに含まれたプログラムコードを利用して処理する段階
を含むことを特徴とする、モジュール処理方法。」

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

引用例1:特開2003-15870号公報
引用例2:国際公開第2015/011762号
引用例3:特開2015-167737号公報
引用例4:武本 充治 他,「分散並行オブジェクト指向モデルによるATM交換プログラム」,電子情報通信学会技術研究報告,社団法人電子情報通信学会,1995年8月25日,第95巻 第216号,第57頁-第62頁
引用例5:高野 善雄,「「サンフランシスコ・プロジェクト」の全貌」,日経ソフトウエア,日経BP社,1998年8月15日,第1巻 第4号,第132頁-第139頁
引用例6:西林 孝,「JaｖaScｒiｐｔ今ドキ活用術 サーバサイドでJaｖaScｒiｐｔ」,WEB+DB PRESS,(株)技術評論社,2010年3月25日,第55巻 第1版,第173頁-第179頁

3 引用例
原査定の拒絶の理由で引用された引用例1の記載事項は,前記第2の[理由]2(2)に記載したとおりである。

4 対比・判断
本願発明は,前記第2の[理由]2(1)で検討した本件補正発明から,「第1サーバモジュールファイル」及び「第2サーバモジュールファイル」に係る限定事項を削除したものである。
そうすると,本願発明の発明特定事項を全て含み,さらに他の事項を付加したものに相当する本件補正発明が,前記第2の[理由]2(3),(4)に記載したとおり,引用発明に基づいて,当業者が容易に発明をすることができたものであるから,本願発明も,同様の理由により,引用発明に基づいて,当業者が容易に発明することができたものである。


第4 むすび
以上のとおり,本願発明は,本願優先日前に頒布された引用例1に記載された発明に基づいて当業者が容易に発明をすることができたものであるから,特許法29条2項の規定により特許を受けることができない。
したがって,その余の請求項に係る発明について論及するまでもなく,本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
別掲
 
審理終結日 2019-10-28 
結審通知日 2019-10-29 
審決日 2019-11-12 
出願番号 特願2016-248575(P2016-248575)
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 575- Z (G06F)
最終処分 不成立  
前審関与審査官 三坂 敏夫  
特許庁審判長 辻本 泰隆
特許庁審判官 山崎 慎一
松平 英
発明の名称 モジュール処理方法およびシステム、並びに記録媒体  
代理人 特許業務法人高橋・林アンドパートナーズ  
代理人 特許業務法人高橋・林アンドパートナーズ  

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