ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F |
|---|---|
| 管理番号 | 1310398 |
| 審判番号 | 不服2013-22133 |
| 総通号数 | 195 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2016-03-25 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2013-11-12 |
| 確定日 | 2016-01-27 |
| 事件の表示 | 特願2011-265143「APIに係るコンピュータにより実施される方法及びコンピュータ可読記憶媒体」拒絶査定不服審判事件〔平成24年 4月19日出願公開,特開2012- 79332〕について,次のとおり審決する。 |
| 結論 | 本件審判の請求は,成り立たない。 |
| 理由 |
第1 手続の経緯 本件審判請求に係る出願(以下,「本願」という。)は,平成16年9月10日(パリ条約による優先権主張外国庁受理2003年10月24日(以下,「優先日」という。),米国)に出願した特願2004-264630号の一部を平成23年12月2日に新たな特許出願としたものであって,その手続の経緯は以下のとおりである。 平成23年12月 2日 :出願審査請求書の提出 平成24年12月 4日付け :拒絶理由の通知 平成25年 3月11日 :意見書,手続補正書の提出 平成25年 3月28日付け :拒絶理由の通知(最後) 平成25年 7月 2日 :意見書,手続補正書の提出 平成25年 7月17日付け :拒絶査定 平成25年11月12日 :審判請求書,手続補正書の提出 平成25年12月 4日 :前置報告 平成27年 3月30日付け :拒絶理由の通知(最後) 平成27年 6月26日 :意見書,手続補正書の提出 第2 平成27年6月26日付けの手続補正の適否 1 補正の内容 平成27年6月26日付けの手続補正(以下,「本件補正」という。)の内容は,平成25年11月12日付けの手続補正により補正された特許請求の範囲の請求項1乃至5の記載 「 【請求項1】 セットとして「型」と呼ばれ,本質的に,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する名前空間の生成を,アプリケーションプログラムインターフェース(API)関数を複数の名前空間に分割するAPIレイヤを用いることにより可能にする,コンピュータにより実施される方法であって, 前記APIレイヤは,プレゼンテーションサブシステムの第1名前空間,ウェブサービスの第2名前空間,およびファイルシステムの第3名前空間の3つのルート名前空間を含むように編成され, 前記第1名前空間は,アプリケーション,文書,媒体プレゼンテーション,および他のコンテンツの生成を可能にする型を供給し, 前記第2名前空間は,さまざまなスケールおよび複雑さのメッセージベースアプリケーションを構築する基礎を提供し, 前記第3名前空間は,情報の保管および検索を可能にする型を供給し,且つ,ファイルシステムのデータモデルを定義し, 前記名前空間を使用することによって,設計者が,型のセットを階層名前空間に編成することができる ことを特徴とする方法。 【請求項2】 前記API関数は,文書記述を可能にするAPI関数,人間によって連絡可能なエンティティの識別を可能にするAPI関数,および複数種類の媒体に共通のAPI関数のうちの少なくとも1つであることを特徴とする請求項1に記載の方法。 【請求項3】 前記API関数は,オーディオ媒体固有のAPI関数,ビデオ媒体固有のAPI関数,およびイメージ媒体固有のAPI関数のうちの少なくとも1つであることを特徴とする請求項1に記載の方法。 【請求項4】 前記API関数は,複数種類の媒体に共通のAPI関数,オーディオ媒体固有のAPI関数,ビデオ媒体固有のAPI関数,およびイメージ媒体固有のAPI関数のうちの少なくとも1つであることを特徴とする請求項1に記載の方法。 【請求項5】 コンピュータに請求項1?4の何れか1項に記載の方法を実行させるためのプログラムを記憶したコンピュータ可読記憶媒体。」 (以下,この特許請求の範囲に記載された請求項を「補正前の請求項」という。) を, 「 【請求項1】 セットとして「型」と呼ばれ,本質的に,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する名前空間の生成を,アプリケーションプログラムインターフェース(API)関数を複数の名前空間に分割するAPIレイヤにおいてコンピュータが実施する方法であって, 前記APIレイヤは,プレゼンテーションサブシステムの第1名前空間,ウェブサービスの第2名前空間,およびファイルシステムの第3名前空間の3つのルート名前空間を含むように編成され, 前記第1名前空間は,アプリケーション,文書,媒体プレゼンテーション,および他のコンテンツの生成を可能にする型を供給し, 前記第2名前空間は,さまざまなスケールおよび複雑さのメッセージベースアプリケーションを構築する基礎を提供し, 前記第3名前空間は,情報の保管および検索を可能にする型を供給し,且つ,ファイルシステムのデータモデルを定義し, 前記名前空間を使用することによって,設計者が,型のセットを階層名前空間に編成することができる ことを特徴とする方法。 【請求項2】 前記API関数は,文書記述を可能にするAPI関数,人間によって連絡可能なエンティティの識別を可能にするAPI関数,および複数種類の媒体に共通のAPI関数のうちの少なくとも1つであることを特徴とする請求項1に記載の方法。 【請求項3】 前記API関数は,オーディオ媒体固有のAPI関数,ビデオ媒体固有のAPI関数,およびイメージ媒体固有のAPI関数のうちの少なくとも1つであることを特徴とする請求項1に記載の方法。 【請求項4】 前記API関数は,複数種類の媒体に共通のAPI関数,オーディオ媒体固有のAPI関数,ビデオ媒体固有のAPI関数,およびイメージ媒体固有のAPI関数のうちの少なくとも1つであることを特徴とする請求項1に記載の方法。 【請求項5】 コンピュータに請求項1?4の何れか1項に記載の方法を実行させるためのプログラムを記憶したコンピュータ可読記憶媒体。」 (当審注:下線は,出願人が付与したものである。以下,この特許請求の範囲に記載された請求項を「補正後の請求項」という。) に補正するものである。 そして,本件補正は,願書に最初に添付した明細書,特許請求の範囲又は図面に記載した事項の範囲内においてなされており,特許法第17条の2第3項の規定に適合している。 2 目的要件 本件補正は上記「1 補正の内容」のとおり,当審からの平成27年3月30日付け最後の拒絶理由通知に応じてする補正であり,特許請求の範囲について補正をしようとするものであるから,本件補正が,特許法第17条の2第4項の規定を満たすものであるか否か,すなわち,本件補正が,特許法第17条の2第4項に規定する請求項の削除,特許請求の範囲の減縮(特許法第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって,その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る),誤記の訂正,或いは,明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る)の何れかを目的としたものであるかについて,以下に検討する。 本件補正は,下記の補正事項1よりなるものである。 ＜補正事項1＞ 補正前の請求項1の 「セットとして「型」と呼ばれ,本質的に,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する名前空間の生成を,アプリケーションプログラムインターフェース(API)関数を複数の名前空間に分割するAPIレイヤを用いることにより可能にする,コンピュータにより実施される方法であって,」との記載を, 補正後の請求項1の 「セットとして「型」と呼ばれ,本質的に,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する名前空間の生成を,アプリケーションプログラムインターフェース(API)関数を複数の名前空間に分割するAPIレイヤにおいてコンピュータが実施する方法であって,」に変更する補正。 上記補正事項1について検討すると,上記補正事項1は,当審からの平成27年3月30日付け最後の拒絶理由通知の理由2(請求項1の記載不備)に応じてする補正であるから,明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る)に該当するものである。 したがって,本件補正は,特許法第17条の2第4項の規定に適合している。 3 むすび 本件補正は,特許法第17条の2第3項,第4項の規定に適合する。 第3 本願発明 本件補正は上記のとおり,特許法第17条の2第3項,第4項の規定に適合するから,本願の請求項に係る発明は,上記平成27年6月26日付け手続補正により補正された特許請求の範囲の請求項1乃至5に記載されたとおりのものであると認められるところ,その請求項1に係る発明(以下,「本願発明」という。)は,以下のとおりのものである。 「 セットとして「型」と呼ばれ,本質的に,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する名前空間の生成を,アプリケーションプログラムインターフェース(API)関数を複数の名前空間に分割するAPIレイヤにおいてコンピュータが実施する方法であって, 前記APIレイヤは,プレゼンテーションサブシステムの第1名前空間,ウェブサービスの第2名前空間,およびファイルシステムの第3名前空間の3つのルート名前空間を含むように編成され, 前記第1名前空間は,アプリケーション,文書,媒体プレゼンテーション,および他のコンテンツの生成を可能にする型を供給し, 前記第2名前空間は,さまざまなスケールおよび複雑さのメッセージベースアプリケーションを構築する基礎を提供し, 前記第3名前空間は,情報の保管および検索を可能にする型を供給し,且つ,ファイルシステムのデータモデルを定義し, 前記名前空間を使用することによって,設計者が,型のセットを階層名前空間に編成することができる ことを特徴とする方法。」 第4 引用例 引用例1に記載されている技術的事項および引用発明 (1)本願の優先日前に頒布され,当審からの上記平成27年3月30日付け拒絶理由の通知において引用された,米国特許出願公開第2003/0028685号明細書(2003年2月6日公開,以下,「引用例1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。 (当審注:下線は,参考のために当審で付与したものである。) A 「 [0038] The programming framework 132 is the structure that supports the applications and services developed by application developers. It permits multi-language development and seamless integration by supporting multiple languages. It supports open protocols, such as SOAP, and encapsulates the underlying operating system and object model services. The framework provides a robust and secure execution environment for the multiple programming languages and offers secure, integrated class libraries. [0039] The framework 132 is a multi-tiered architecture that includes an application program interface (API) layer 142, a common language runtime (CLR) layer 144, and an operating system/services layer 146. This layered architecture allows updates and modifications to various layers without impacting other portions of the framework. …(中略)… [0040] The API layer 142 presents groups of functions that the applications 130 can call to access the resources and services provided by layer 146. By exposing the API functions for a network platform, application developers can create Web applications for distributed computing systems that make full use of the network resources and other Web services, without needing to understand the complex interworkings of how those network resources actually operate or are made available. Moreover, the Web applications can be written in any number of programming languages, and translated into an intermediate language supported by the common language runtime 144 and included as part of the common language specification 140. In this way, the API layer 142 can provide methods for a wide and diverse variety of applications.」 (当審仮訳; [0038] プログラミングフレームワーク132は,アプリケーション開発者によって開発されるアプリケーションおよびサービスをサポートする構造である。プログラミングフレームワーク132は,複数の言語をサポートすることによって,マルチ言語開発およびシームレス統合を可能にする。プログラミングフレームワーク132は,SOAPなどのオープンプロトコルをサポートし,基礎になるオペレーティングシステムおよびオブジェクトモデルサービスをカプセル化する。このフレームワークは,複数のプログラミング言語のための堅牢で保護された実行環境を提供し,保護され,統合されたクラスライブラリを提供する。 [0039] フレームワーク132は,アプリケーションプログラムインターフェース(API)レイヤ142,共通言語ランタイム(CLR)レイヤ144,およびオペレーティングシステム/サービスレイヤ146を含むマルチティアアーキテクチャである。この階層アーキテクチャを用いると,フレームワークの他の部分に影響せずに,さまざまなレイヤに対する更新および修正が可能になる。 …(中略)… [0040] APIレイヤ142は,アプリケーション130が,レイヤ146によって提供されるリソースおよびサービスにアクセスするために呼び出す関数のグループを提供する。ネットワークプラットフォームに対するAPI関数を公開することによって,アプリケーション開発者は,それらのネットワークリソースが実際にどのように動作するかまたは使用可能にされるかの複雑な相互作用を理解する必要なしに,ネットワークリソースおよび他のウェブサービスを完全に利用する分散コンピューティングシステム用のウェブアプリケーションを作成することができる。さらに,このウェブアプリケーションは,いくつものプログラミング言語で記述でき,共通言語ランタイムレイヤ144によってサポートされる,中間言語に変換することができ,共通言語仕様140の一部として含むことができる。この形で,APIレイヤ142が,広範囲のさまざまなアプリケーションにメソッドを提供することができる。) B 「 [0046] The API 142 groups API functions into multiple namespaces. Namespaces essentially define a collection of classes, interfaces, delegates, enumerations, and structures, which are collectively called "types", that provide a specific set of related functionality. A class represents managed heap allocated data that has reference assignment semantics. A delegate is an object oriented function pointer. An enumeration is a special kind of value type that represents named constants. A structure represents static allocated data that has value assignment semantics. An interface defines a contract that other types can implement.」 (当審仮訳; [0046] API142は,API関数を複数の名前空間にグループ化する。名前空間は,本質的に,関連する機能の特定のセットを提供し,セットとして「型」と呼ばれる,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する。クラスは,参照割り当てセマンティックス(semantics)を有する,管理されるヒープから割り当てられるデータを表す。委任(delegate)は,オブジェクト指向関数ポインタである。列挙は,名前付き定数を表す特殊な種類の値型である。構造体は,値割り当てセマンティックスを有する,静的に割り当てられたデータを表す。インターフェースは,他の型を実施できるコントラクトを定義する。) C 「 [0047] By using namespaces, a designer can organize a set of types into a hierarchical namespace. The designer is able to create multiple groups from the set of types, with each group containing at least one type that exposes logically related functionality. In the exemplary implementation, the API 142 is organized into four root namespaces: a first namespace 200 for Web applications, a second namespace 202 for client applications, a third namespace 204 for data and XML, and a fourth namespace 206 for base class libraries (BCLs). Each group can then be assigned a name. For instance, types in the Web applications namespace 200 are assigned the name "Web", and types in the data and XML namespace 204 can be assigned names "Data" and "XML" respectively. The named groups can be organized under a single "global root" namespace for system level APIs, such as an overall System namespace. By selecting and prefixing a top level identifier, the types in each group can be easily referenced by a hierarchical name that includes the selected top level identifier prefixed to the name of the group containing the type. For instance, types in the Web applications namespace 200 can be referenced using the hierarchical name "System.Web". In this way, the individual namespaces 200, 202, 204, and 206 become major branches off of the System namespace and can carry a designation where the individual namespaces are prefixed with a designator, such as a "System." prefix. 」 (当審仮訳; [0047] 名前空間を使用することによって,設計者が,型のセットを階層名前空間に編成することができる。設計者は,型のセットから複数のグループを作成することができ,各グループに,論理的に関連する機能性を公開する少なくとも1つの型が含まれる。例示的な実施形態では,API142が,4つのルート名前空間(ウェブアプリケーションの第1名前空間200,クライアントアプリケーションの第2名前空間202,データとXMLの第3名前空間204,ベースクラスライブラリー(BCLｓ)の第4名前空間206)を含むように編成される。各グループに名前を割り当てることができる。たとえば,ウェブアプリケーションの名前空間200の型に,名前「ウェブ」を割り当てることができ,データとXMLの名前空間204の型に,名前「データ」と「XML」を割り当てることができる。名前付きグループを,System名前空間全体などのシステムレベルAPIの単一の「グローバルルート」名前空間の下で編成することができる。トップレベル識別子を選択し,プレフィックシングすることによって,各グループの型を,型を含むグループの名前の前に置かれた選択されたトップレベル識別子を含む階層名によって簡単に参照することができる。たとえば,ウェブアプリケーションの名前空間200 の型を,階層名「System.Web」を使用して参照することができる。このようにして,個々の名前空間200,202,204,および206が,System名前空間からの主要な分岐になり,および個々の名前空間が「System.」プレフィックスなどの指示子(designator)を前に付けられる指定を伝える。) D 「 [0053] The Web applications namespace 200 ("System.Web") defines additional namespaces, including: [0054] A services namespace 300 ("System.Web.Services") containing classes that enable a developer to build and use Web services. …(中略)… The services namespace 300 defines additional namespaces, including …(中略)… and a protocols namespace 306 ("System.Web.Services.Protocols") containing classes that define the protocols used to transmit data across a network during communication between Web service clients and the Web service itself. 」 (当審仮訳; [0053] ウェブアプリケーションの名前空間200("System.Web")は,追加の名前空間を定義し,含む: [0054] 開発者がウェブサービスを構築し,使用することを可能とするクラスを含むサービスの名前空間300 。 …(中略)… サービスの名前空間300は, …(中略)… やウェブサービスクライアントとウェブサービス自体の間の通信中にネットワーク経由でデータを送信するために使用されるプロトコルを定義するクラスを含むプロトコルの名前空間306("System.Web.Services.Protocols")を含む追加の名前空間を定義する。) E 「 [0060] The client applications namespace 202 is composed of two namespaces: …(中略)… [0062] A drawing namespace 328 ("System.Drawing") containing classes for graphics functionality. The drawing namespace 328 includes a 2D drawing namespace 330 ("System.Drawing.Drawing2D") that contains classes and enumerations to provide advanced 2-dimmensional and vector graphics functionality, …(中略)… and a text namespace 336 ("System.Drawing.Text") that contains classes for advanced typography functionality. 」 (当審仮訳; [0060] クライアントアプリケーションの名前空間202は,2つの名前空間で構成される。 …(中略)… [0062] グラフィックス機能のクラスを含む描画名前空間328("System.Drawing") 。描画名前空間328には,高度な2次元のベクトルグラフィックス機能を提供するクラスと列挙が含まれる2D描画の名前空間330("System.Drawing.Drawing2D") …(中略)… や高度なタイポグラフィ機能のクラスが含まれるテキスト名前空間336("System.Drawing.Text"),が含まれる。) F 「 [0063] The data and XML namespace 204 is composed of two namespaces: [0064] A data namespace 340 ("System.Data") containing classes that enable developers to build components that efficiently manage data from multiple data sources. …(中略)… The data namespace 340 also includes …(中略)… and a SQL client namespace 346 that contains types pertaining to data used by SQL clients. The data namespace also includes a SQL types namespace 348 ("System.Data.SqlTypes") that contains classes for native data types within Microsoft's SQL Server. …(中略)… [0065] An XML namespace 350 ("System.XML") containing classes that provide standards-based support for processing XML. …(中略)… The XML namespace 350 includes …(中略)… an Xpath namespace 354 ("System.XML.Xpath") that contains an XPath parser and evaluation engine, …(後略)」 (当審仮訳; [0063] データとXML名前空間204は,2つの名前空間で構成されている。 [0064] 効率的に複数のデータソースからのデータを管理するコンポーネントを開発者に構築することを可能とするクラスを含むデータの名前空間340("System.Data")。 …(中略)… データの名前空間340は,…(中略)… ,SQLクライアントで使用されるデータに関連する型を含むSQLクライアントの名前空間346をも含む。データの名前空間は,MicrosoftのSQL Server内のネイティブデータ型のためのクラスが含まれているSQLタイプの名前空間348( "System.Data.SqlTypes")をも含む。 …(中略)… [0065] XML処理の標準サポートを提供するクラスを含むXML名前空間350("System.XML")。 …(中略)… XML名前空間350は,…(中略)… ,XPathパーサーおよび評価エンジンが含まれているXpathの名前空間354("System.XML.Xpath"), …(中略)… を含む。) (2)ここで,引用例1に記載されている事項を検討する。 ア 上記Aの「プログラミングフレームワーク132は,アプリケーション開発者によって開発されるアプリケーションおよびサービスをサポートする構造である。」,「フレームワーク132は,アプリケーションプログラムインターフェース(API)レイヤ142,共通言語ランタイム(CLR)レイヤ144,およびオペレーティングシステム/サービスレイヤ146を含むマルチティアアーキテクチャである。」,「APIレイヤ142は,アプリケーション130が,レイヤ146によって提供されるリソースおよびサービスにアクセスするために呼び出す関数のグループを提供する。」旨の記載からすると,「APIレイヤ」は,アプリケーション開発者によって開発されるアプリケーションおよびサービスをサポートする構造である「プログラミングフレームワーク」内に存在し,アプリケーションが,オペレーティングシステム/サービスレイヤによって提供されるリソースおよびサービスにアクセスするために呼び出す関数のグループを提供することが読み取れるから,引用例1には, “アプリケーションおよびサービスをサポートする構造であるプログラミングフレームワーク内に,関数のグループを提供するAPIレイヤが存在”すること が記載されていると解される。 イ 上記Bの「API142は,API関数を複数の名前空間にグループ化する。名前空間は,本質的に,関連する機能の特定のセットを提供し,セットとして「型」と呼ばれる,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する。」旨の記載からすると,「名前空間」とは,セットとして「型」と呼ばれ,本質的に,「クラス,インターフェース,委任(delegate),列挙,および構造体のセット」を定義するものであり,コンピュータが「APIレイヤ」において「API関数」を複数の「名前空間」に分割し,生成することは明らかであるから,引用例1には, “コンピュータが,セットとして「型」と呼ばれ,本質的に,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する名前空間の生成を,アプリケーションプログラムインターフェース(API)関数を複数の名前空間に分割するAPIレイヤにおいて実施する方法” が記載されていると解される。 ウ 上記Cの「名前空間を使用することによって,設計者が,型のセットを階層名前空間に編成することができる。設計者は,型のセットから複数のグループを作成することができ,各グループに,論理的に関連する機能性を公開する少なくとも1つの型が含まれる。」,「例示的な実施形態では,API142が,4つのルート名前空間(ウェブアプリケーションの第1名前空間200,クライアントアプリケーションの第2名前空間202,データとXMLの第3名前空間204,ベースクラスライブラリー(BCLｓ)の第4名前空間206)を含むように編成される。」旨の記載からすると,編成される名前空間は,ウェブアプリケーションの第1名前空間,クライアントアプリケーションの第2名前空間,データとXMLの第3名前空間,ベースクラスライブラリーの第4名前空間の4つのルート名前空間を含み,当該名前空間を使用することによって,設計者が,型のセットを階層名前空間に編成することができることが読み取れ,ここでの「API142」は上記イの検討から,「APIレイヤ」を意味していることは明らかであるから,引用例1には, “APIレイヤは,ウェブアプリケーションの第1名前空間,クライアントアプリケーションの第2名前空間,データとXMLの第3名前空間,ベースクラスライブラリーの第4名前空間の4つのルート名前空間を含むように編成され, 前記名前空間を使用することによって,設計者が,型のセットを階層名前空間に編成することができること” が記載されていると解される。 (3)以上,ア乃至ウの検討によれば,引用例1には次の発明(以下,「引用発明」という。)が記載されているものと認める。 「アプリケーションおよびサービスをサポートする構造であるプログラミングフレームワーク内に,関数のグループを提供するAPIレイヤが存在し,コンピュータが,セットとして「型」と呼ばれ,本質的に,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する名前空間の生成を,アプリケーションプログラムインターフェース(API)関数を複数の名前空間に分割するAPIレイヤにおいて実施する方法であって, 前記APIレイヤは,ウェブアプリケーションの第1名前空間,クライアントアプリケーションの第2名前空間,データとXMLの第3名前空間,ベースクラスライブラリーの第4名前空間の4つのルート名前空間を含むように編成され, 前記名前空間を使用することによって,設計者が,型のセットを階層名前空間に編成することができることを特徴とする方法。」 第5 対比 1 本願発明と引用発明とを対比する。 (1)引用発明の「名前空間」は,「セットとして「型」と呼ばれ,本質的に,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する」ことから,本願発明の「名前空間」に相当し,引用発明の「アプリケーションプログラムインターフェース(API)関数」は,「APIレイヤ」において提供されることから,本願発明の「アプリケーションプログラムインターフェース(API)関数」に相当すると言える。 そうすると,引用発明の「コンピュータが,セットとして「型」と呼ばれ,本質的に,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する名前空間の生成を,アプリケーションプログラムインターフェース(API)関数を複数の名前空間に分割するAPIレイヤにおいて実施する方法」は,本願発明の「セットとして「型」と呼ばれ,本質的に,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する名前空間の生成を,アプリケーションプログラムインターフェース(API)関数を複数の名前空間に分割するAPIレイヤにおいてコンピュータが実施する方法」に相当することは明らかである。 (2)引用発明では,「APIレイヤは,ウェブアプリケーションの第1名前空間,クライアントアプリケーションの第2名前空間,データとXMLの第3名前空間,ベースクラスライブラリーの第4名前空間の4つのルート名前空間を含むように編成」されるところ,「4つのルート名前空間」はAPIの種別毎に編成されることから,「APIレイヤ」は,APIの種別により分割された複数のルート名前空間を含むように編成されると解される。 そうすると,引用発明の「APIレイヤは,ウェブアプリケーションの第1名前空間,クライアントアプリケーションの第2名前空間,データとXMLの第3名前空間,ベースクラスライブラリーの第4名前空間の4つのルート名前空間を含むように編成され,前記名前空間を使用することによって,設計者が,型のセットを階層名前空間に編成することができること」と本願発明の「APIレイヤは,プレゼンテーションサブシステムの第1名前空間,ウェブサービスの第2名前空間,およびファイルシステムの第3名前空間の3つのルート名前空間を含むように編成され,前記第1名前空間は,アプリケーション,文書,媒体プレゼンテーション,および他のコンテンツの生成を可能にする型を供給し,前記第2名前空間は,さまざまなスケールおよび複雑さのメッセージベースアプリケーションを構築する基礎を提供し,前記第3名前空間は,情報の保管および検索を可能にする型を供給し,且つ,ファイルシステムのデータモデルを定義し,前記名前空間を使用することによって,設計者が,型のセットを階層名前空間に編成することができる」とは後記する点で相違するものの,“APIレイヤは,APIの種別により分割された複数のルート名前空間を含むように編成され,前記名前空間を使用することによって,設計者が,型のセットを階層名前空間に編成することができる”点で共通すると言える。 2 以上から,本願発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。 ＜一致点＞ 「セットとして「型」と呼ばれ,本質的に,クラス,インターフェース,委任(delegate),列挙,および構造体のセットを定義する名前空間の生成を,アプリケーションプログラムインターフェース(API)関数を複数の名前空間に分割するAPIレイヤにおいてコンピュータが実施する方法であって, 前記APIレイヤは,APIの種別により分割された複数のルート名前空間を含むように編成され, 前記名前空間を使用することによって,設計者が,型のセットを階層名前空間に編成することができることを特徴とする方法。」 ＜相違点＞ APIレイヤに編成されるルート名前空間に関し, 本願発明では,「APIレイヤは,プレゼンテーションサブシステムの第1名前空間,ウェブサービスの第2名前空間,およびファイルシステムの第3名前空間の3つのルート名前空間を含むように編成され,前記第1名前空間は,アプリケーション,文書,媒体プレゼンテーション,および他のコンテンツの生成を可能にする型を供給し,前記第2名前空間は,さまざまなスケールおよび複雑さのメッセージベースアプリケーションを構築する基礎を提供し,前記第3名前空間は,情報の保管および検索を可能にする型を供給し,且つ,ファイルシステムのデータモデルを定義」するのに対して, 引用発明では,「APIレイヤは,ウェブアプリケーションの第1名前空間,クライアントアプリケーションの第2名前空間,データとXMLの第3名前空間,ベースクラスライブラリーの第4名前空間の4つのルート名前空間を含むように編成され」ており,プレゼンテーションサブシステム,ウェブサービス,およびファイルシステムの3つの名前空間を含むことが明記されていない点。 第6 当審の判断 上記相違点について検討する。 引用発明では,「APIレイヤは,ウェブアプリケーションの第1名前空間,クライアントアプリケーションの第2名前空間,データとXMLの第3名前空間,ベースクラスライブラリーの第4名前空間の4つのルート名前空間を含むように編成され」るところ,引用例1の上記Dには,下位階層の名前空間について,ウェブアプリケーションの名前空間は,ウェブサービスクライアント間の通信に関するプロトコル名前空間を含むこと,上記Eには,クライアントアプリケーションの名前空間が画像やテキストの作成に関する描画名前空間を含むこと,上記Fには,データとXMLの名前空間がSQLやXPaｔhに関する名前空間を含むことが記載されており,引用発明の「APIレイヤ」は,プレゼンテーション,ウェブサービス,ファイルシステムに関するAPI関数を下位階層の名前空間に含んでいると言える。 また,APIレイヤの名前空間は,対象とするユーザの利便性などを考慮し,API関数を提供する者が適宜の種別毎に,適宜の数に分割されるべきものであり,APIレイヤの名前空間をどのように分割するかは必要に応じて選択可能な設計的事項であったと言える。 そうすると,引用発明において,APIレイヤの名前空間を,プレゼンテーションサブシステムの第1名前空間,ウェブサービスの第2名前空間,およびファイルシステムの第3名前空間の3つのルート名前空間を含むように編成し,3つのルート名前空間を上記相違点に係る構成とすることは,当業者が容易に想到し得たことである。 上記で検討したごとく,相違点に係る構成は当業者が容易に想到し得たものであり,そして,本願発明の奏する作用効果は,引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。 第7 むすび 以上のとおり,本願の請求項1に係る発明は,特許法第29条第2項の規定により特許を受けることができないものであるから,その余の請求項に係る発明について検討するまでもなく,本願は拒絶すべきものである。 よって,結論のとおり審決する。 |
| 審理終結日 | 2015-08-28 |
| 結審通知日 | 2015-08-31 |
| 審決日 | 2015-09-15 |
| 出願番号 | 特願2011-265143(P2011-265143) |
| 審決分類 |
P
1
8・
121-
WZ
(G06F)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 林 毅 |
| 特許庁審判長 |
高木 進 |
| 特許庁審判官 |
田中 秀人 辻本 泰隆 |
| 発明の名称 | APIに係るコンピュータにより実施される方法及びコンピュータ可読記憶媒体 |
| 代理人 | 大房 直樹 |
| 代理人 | 小野 新次郎 |
| 代理人 | 小林 泰 |
| 代理人 | 末松 亮太 |
| 代理人 | 竹内 茂雄 |
| 代理人 | 山本 修 |
| 代理人 | 中村 彰吾 |
| 代理人 | 松尾 淳一 |
| 代理人 | 鳥居 健一 |
| 代理人 | 大牧 綾子 |
| 代理人 | 中西 基晴 |
| 代理人 | 上田 忠 |