【事件の表示】
　特願２０１２−５４２０２６「Ｗｅｂアプリケーションとブラウザーの外部のプロセスとの間の通信チャンネル」拒絶査定不服審判事件〔平成２３年　６月　９日国際公開、ＷＯ２０１１／０６８６２９、平成２５年　４月１８日国内公表、特表２０１３−５１３１６０、請求項の数（１８）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　
　本願は、２０１０年１１月５日（パリ条約による優先権主張外国庁受理　２００９年１２月３日）を国際出願日とする出願であって、平成２６年９月２９日付けで拒絶理由が通知され、同年１２月２６日付けで手続補正がなされたが、平成２７年１月２３日付けで拒絶査定がなされ、これに対し、同年５月２７日に拒絶査定不服審判の請求がなされたものである。　
　
第２　本願発明
　
　本願の請求項１−１８に係る発明は、平成２６年１２月２６日付けの手続補正で補正された特許請求の範囲の請求項１−１８に記載された事項により特定されるものと認められるところ、本願の請求項１に係る発明（以下、「本願発明」という。）は以下のとおりである。
　
「【請求項１】
　コンピューティング装置上で動作しているプロセスにＷｅｂアプリケーションから要求を安全に中継するためのシステムであって、
　コンピューティング装置に対しローカルのブラウザー環境内で動作しているＷｅｂアプリケーション内にインストールされたブリッジメッセージクライアントコンポーネントであって、
　ブリッジサーバーコンポーネントと同一のソースから由来するものとして前記ブリッジメッセージクライアントコンポーネントが識別された場合に前記ブリッジサーバーコンポーネントが前記Ｗｅｂアプリケーションからの要求を信頼することを可能にするブリッジメッセージクライアント識別子を使用することに基づいて、ブリッジサーバーコンポーネントとの安全なローカル接続を確立し、
　前記ブラウザー環境の外の前記コンピューティング装置上で動作するプロセスへルーティングするため、前記Ｗｅｂアプリケーションからの要求を前記安全なローカル接続を通して前記ブリッジサーバーコンポーネントに中継する、
ように構成されたブリッジメッセージクライアントコンポーネント、
を含む、システム。」
　
第３　原査定の理由の概要
　
　この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　記　　　（引用文献等については引用文献等一覧参照）
　
請求項：１−３，５−８，１０−１３，１６，１８−２０
引用文献：１−３
備考
　引用文献１（第６欄第２１行目〜第２６行目、第１８欄第２１行目〜第３６行目、第１９欄第５行目〜第３５行目、第３０欄第３２行目〜３９行目、第５Ａ図）には、end-user-computer （本願の「コンピューティング装置」）で動作しているprocess（「プロセス」）への要求を中継するシステムであって、end-user-computerで動作しているWeb browserにdownload されたapplet（「ブリッジメッセージクライアントコンポーネント」）が、applet の各々に関連するACLを利用するsecure service proxy（「ブリッジサーバコンポーネント」）からsecurity controlを受けた後、前記process に対する要求をsecure service proxyに送信するシステム、ついて記載されている。
　アプレットを経由してアプリケーションが他のリソースに安全にアクセスすることは、引用文献２の第１１頁、１２頁（「ＳＳＬ未対応アプリケーションの利用も従来より簡単に！」）に記載されているように周知技術である。
　また、ACL を利用した認証を行う際に識別子を利用することについても、引用文献３の【０００９】，【００１０】段落に記載されているように周知技術である。
　してみると、引用文献１に記載の発明に引用文献２，３に記載の周知技術を適用して請求項１−３，５−８，１０−１３，１６，１８−２０に係る発明とすることは、当業者が容易に為し得たことである。
　
請求項：４，１４，１５
引用文献：１−３
備考
　引用文献１に記載の発明において、end-user-computer 上で動作するアプリケーションとして、どのようなものを採用するかは、当業者が適宜選択し得る設計的事項である。
　
請求項：９，１７
引用文献：１−４
備考
　クライアントにインストールするモジュールを信頼性の高い第三者機関からダウンロードすることは、引用文献４の【００６５】段落に記載されているように周知技術である。
  　
　拒絶の理由が新たに発見された場合には拒絶の理由が通知される。
　
　　　　　　　　　　　引　用　文　献　等　一　覧
　
１.米国特許第７３４６６４９号明細書
２.榊原  康，新勢力  ＳＳＬでＶＰＮを構築できる製品が相次ぎ登場，日経システム構築  ｎｏ．１２１  SYSTEM INTEGRATION，日本，日経ＢＰ社  Nikkei Business Publications,Inc.，２００３年　４月２６日，第16-18頁
３.特開２００４−００５６４７号公報
４.特開２００７−１１６６４１号公報
　
第４　当審の判断　
１．刊行物の記載事項
　 
　原査定の拒絶の理由に引用された米国特許７３４６６４９号公報（以下、「刊行物１」という。）には、次の記載がある。（下線は着目箇所を示している。）
　　
ア．「FIELD OF INVENTION 
　The present invention generally relates to communication of multimedia content using computer networks. The invention relates more specifically to a method and apparatus providing improved network content distribution using a personal server approach.」
（当審仮訳：発明の分野
　本発明は、一般に、コンピュータ・ネットワークを使用したマルチメディア・コンテンツの通信に関するものである。特に、パーソナルサーバアプローチを使用して、改良されたネットワークコンテンツ配信を提供する方法および装置に関する。
　 
イ．「BACKGROUND OF THE INVENTION 」
・・・（中略）・・・
　A document that is delivered to a Web browser may include one or more embedded applets. In general, an applet is a relatively compact executable program that is received over a network and executed locally at an end-user computer under the control of a local interpreter or virtual machine. The JavaR language, for example, may be used to write applets that are communicated from a server over a network to a client computer. A Java Virtual machine executes the applets. The Java Virtual Machine typically is integrated with a client computer network application such as a Web browser.
　A security concern associated with applets is that an applet received from an untrusted server may attempt to cause the client computer to carry out unauthorized operations, such as deletion of files, reading configuration information or personal user data and forwarding such data to the server, etc. Accordingly, most Web browsers execute applets within a confined security domain or “sandbox” that restricts the resources that an applet can use. For example, a Web browser may restrict access of applets to security domains such as local persistent storage on the end-user computer and network connectivity to arbitrary servers on the Internet. Typically, the only external access allowed the applet is network connectivity to the server from which the Web browser loaded the applet.
　Web browsers sometimes allow the security restrictions or boundaries of the sandbox to be configured by the operator, but with quite coarse granularity. For example, in one prior approach, the only permitted configuration operation is to enable or disable access to local persistent storage and network connectivity.
　Based on the foregoing, there is a clear need for a method that provides for fine-grained security control over applets restricted to a sandbox.」
　
（当審仮訳：発明の背景
・・・（中略）・・・
　
Webブラウザに供給されるドキュメントは、1つまたは複数の埋め込まれたアプレットを含むであろう。一般に、アプレットは、ネットワークを介して受信され、ローカルのインタープリタ(interpreter)または仮想マシンの制御下でエンド・ユーザ・コンピュータでローカルに実行される比較的小型の実行可能プログラムである
　アプレットに関連するセキュリティ問題は、信頼されていないサーバから受け取られたアプレットは、クライアントコンピュータに、ファイルの削除などを実行させる不正操作や、構成情報や個人データを読み出してサーバにこれらのデータを転送することなどを引き起こそうとするであろう。したがって、ほとんどのウェブ・ブラウザは、限定されたセキュリティドメイン内、またはアプレットが使用できるリソースを制限する「サンドボックス」内でアプレットを実行する。例えば、ウェブブラウザは、インターネット上の任意のサーバへの接続や、エンド・ユーザ・コンピュータ内のローカルで頑強な記憶装置のみにアプレットのアクセスを制限している。典型的には、ウェブ・ブラウザは、アプレットの外部アクセスを、アプレットがロードされたサーバにのみに制限する。
　ウェブ・ブラウザは、サンドボックスのセキュリティ制限または境界を、オペレータによって設定することを許すが、それは非常に大まかなものである。例えば、1つの従来のアプローチでは、許可された設定の動作は、ローカルな頑強な記憶装置とネットワーク接続へのアクセスを有効または無効にするかのみである。
　以上に鑑みて、
サンドボックスで制限されているアプレットに対して、きめ細かなセキュリティ制御を提供する方法が明らかに必要である
　
ウ．「SUMMARY OF THE INVENTION
　 
　・・・（中略）・・・
　
　According to another feature, an applet can access network servers other than the one from which it was loaded. In another feature, applets can access local resources like other processes and local storage. In the present approach, cross-applet communication is enabled regardless of the browser.」
（当審仮訳：発明の概要
・・・（中略）・・・
　別の特徴によれば、アプレットは、アプレットがロードされたサーバ以外のネットワークサーバにアクセスすることができる。
別の特徴では、アプレットは、他のプロセス及びローカルストレージ等のローカル・リソースにアクセスすることができる
　
エ．「H. Secure Service Proxy
　
　Secure service proxy  215  facilitates providing applications with more expansive yet secure access to system resources. As described herein in the Background section, a security concern associated with applets is that an applet received from an untrusted server may attempt to cause the client computer to carry out unauthorized operations. Accordingly, most Web browsers execute applets within a confined security domain or #sandbox# that restricts the resources that an applet can use. Web browsers sometimes allow the security restrictions or boundaries of the sandbox to be configured by the operator, but with quite coarse granularity. Secure service proxy  215  provides a mechanism for enabling more fine-grained control of security access for an applet that is subject to sandbox control by a Web browser.
　
　・・・（中略）・・・
　
　FIG. 5A  is a block diagram of a system providing enhanced security control over applet programs.
　An end-user computer  104  executes a Web browser  108 . An application program such as applet  502  is executed within the browser. Applet  502  is communicatively coupled by network connection  508  to secure service proxy  215 . The connection of the applet  502  to the secure service proxy  515  is subject to security controls such that the applet may access only resources located within logical sandbox  506 .
　Secure service proxy  215  has access to one or more local resources  504 . The secure service proxy  215  also may establish network connections  510 ,  512  to server computer  306 , server computer  514 , or other network elements.
　FIG. 5B  is a flow diagram of a process of using the system of  FIG. 5A  for carrying out enhanced security control over application programs.
　In block  520 , one or more of the applets begin executing. For example, applet  502  is received at end-user computer  102  over a network connection, temporarily stored at the end-user computer, loaded into memory from such temporary storage, and executes in the end-user computer under control of browser  206 . Since the applet has been loaded from the local host, sandbox controls permit each applet to have network access only to the local host, as indicated by block  522 . For example, where the applet is a Java# program, such sandbox controls form an inherent part of the Java Virtual Machine that executes as part of the browser to control and manage execution of the applet. Meanwhile, concurrently or before execution of the applet, the secure service proxy is configured with one or more access restrictions, as indicated by block  524 .
　At some later point after the foregoing preparatory stages, in the context of the personal server, the secure service proxy operates to permit applets serving as rendering contexts to access local and remote security domains. In one example implementation, as indicated by block  530 , the secure service proxy, which may be a component of the personal server or a standalone process, binds to a designated port number and listens for incoming connections from applets. In block  532 , an applet requests access to a resource that is located in a local or remote security domain that is outside the sandbox. In block  534 , the secure service proxy facilitates access by the applet to the local or remote security domain.
　Applets that use this approach are configured to communicate with the secure service proxy. An applet may directly include code for this, or it may be linked with a library that encapsulates such functionality. For example, communication of an applet to the secure service proxy may involve making a Remote Procedure Call (RPC) over the loopback connection to the secure service proxy on the local host.
　Because the secure service proxy is a native process running on the operating system on the end-user computer, the sandbox controls do not restrict its operation. Once the applet connects to the secure service proxy, the secure service proxy may provide the applet with access to any of the services provided by the operating system on the end-user computer. The end-user can then restrict the access that the secure service proxy permits applets with as much granularity as allowed by the operating system, by carrying out appropriate configuration at block  524 .
　The secure service proxy may restrict applet access in any suitable manner. For example, the secure service proxy may maintain a database of access control lists (ACL), one for each distinct applet. The access control lists specify restrictions on access to security domains. For example, an ACL may allow an applet access to local disk, but limit the total amount of disk space usable by an applet, thereby creating a small virtual disk to which the applet has access. An ACL may also allow and restrict network access to certain IP address ranges or DNS domains, and may also restrict the bandwidth allowed to each applet.」
　
（当審仮訳：Ｈ．セキュアサービスプロキシ
　セキュアサービスプロキシ215は、システムリソースへのより拡張的かつ安全アクセスをアプリケーションに提供することが容易にする。背景で説明したように、アプレットに関連するセキュリティ問題は、信頼されていないサーバから受け取られたアプレットは、クライアントコンピュータは、不正操作を行わせようとすることである。したがって、ほとんどのウェブ・ブラウザは、限定されたセキュリティドメイン内またはアプレットが使用できるリソースを制限する「サンドボックス」でアプレットを実行する。ウェブ・ブラウザは、サンドボックスのセキュリティ制限または境界を、とても大まかにオペレータに設定することを許可することもある。セキュアサービスプロキシ215は、ウェブ・ブラウザによるサンドボックス制御を受けているアプレットに対して、より細かなセキュリティアクセス制御を可能にするメカニズムを提供する。
　・・・（中略）・・・
　
図5Aは、アプレットプログラムに強化されたセキュリティ制御を提供するシステム
　
エンドユーザコンピュータ104は、ウェブブラウザ108を実行する。アプレット502などのアプリケーションプログラムは、ブラウザ内で実行される
アプレット502は、ネットワーク接続508によって通信可能にセキュアサービスプロキシ215に接続されている。アプレット502とセキュアサービスプロキシ215との接続は、論理サンドボックス506内にあるリソースのみにアプレットがアクセスできるようなセキュリティ制御に従う
　
セキュアサービスプロキシ215は、1以上のローカルリソース504へのアクセスを有する。セキュアサービスプロキシ215は、また、サーバコンピュータ306、サーバコンピュータ514、あるいは他のネットワーク要素へネットワーク接続510、512を確立することもできるであろう
　
図5Bは、アプリケーションプログラムに強化されたセキュリティ制御を行う図5Aのシステム
　ブロック520において、1つ以上のアプレットの実行を開始する。例えば、アプレット502は、ネットワーク接続を介してエンドユーザコンピュータ102で受信され、一時的に記憶され、一時的な記憶装置からメモリにロードされ、ブラウザ206の制御下でエンド・ユーザ・コンピュータで実行される。アプレットは、ローカルホストからロードされているため、サンドボックス制御は、各アプレットにロード元のローカルホストのみネットワーク・アクセスを有することを許可する(ブロック522)。例えば、アプレットがJava(登録商標)プログラムである場合、このようなサンドボックス・コントロールは、ブラウザの一部としてアプレットの実行の制御及び管理するJava仮想マシンの固有の一部を形成する。一方、同時にまたはアプレットを実行する前に、セキュアサービスプロキシは、1つまたは複数のアクセスの制限が設定される(ブロック524)。
　以上準備段階後のある時点で、パーソナルサーバのコンテキストとしては、セキュアサービスプロキシは、アプレットがコンテキストをレンダリングするために装置内および装置外のセキュリティドメインにアクセスすることを許可するように動作する。一実施例として、ブロック530に示すように、セキュアサービスプロキシは、パーソナルサーバのコンポーネント、または独立のプロセスとして、指定されたポート番号に結合され、アプレットから入来する接続をリッスンする。ブロック532では、
アプレットは、サンドボックスの外側にある装置内、もしくな装置外のセキュリティドメインにあるリソースへのアクセスを要求する
ブロック534では、セキュアサービスプロキシは、装置内または装置外のセキュリティドメインにアプレットがアクセスすることを容易にする
　このアプローチを使用するアプレットはセキュアサービスプロキシと通信するように構成されている。アプレットは、直接このためのコードを含んでもよく、あるいは、そのような機能をカプセル化するライブラリとリンクすることができる。例えば、アプレットとセキュアサービスプロキシとの通信は、ローカルホスト上のセキュアサービスプロキシへのループバック接続を介してリモートプロシージャコール(RPC)で行ってもよい。
　セキュアサービスプロキシは、エンドユーザコンピュータ上のオペレーティングシステム上で動作するネイティブ・プロセスであるので、サンドボックスの制御はセキュアサービスプロキシの動作を制限するものではない。一旦、アプレットがセキュアサービスプロキシへの接続されると、セキュアサービスプロキシは、アプレットにエンドユーザコンピュータのオペレーティング・システムによって提供されるサービスのいずれへのアクセスも提供することができる。エンドユーザが受けるアクセスの制限は、セキュアサービスプロシキがオペレーティングシステムによって許容される精度でアプレットに許可する制限であり、ブロック524において適切な構成を実施することができる。
　
セキュアサービスプロキシはいかなる方法でもアプレットのアクセスを制限することができる。例えば、セキュアサービスプロキシは、各アプレット毎にアクセス制御リスト(ACL)のデータベースを持ってもよい
　
オ．「I. Security Manager
　
　Security manager  224  is a user interface that an end-user may use to configure the properties and settings of the naming proxy  214  and the secure service proxy  215 . The types of configuration possible for each of these two components are specified in their respective descriptions herein. In an alternative approach, naming proxy  214  and secure service proxy  215  each have an integrated user interface element, and a separate security manager  224  is not required.」
　
（当審仮訳：Ｉ．セキュリティマネージャ
　セキュリティ管理部224は、エンドユーザが命名プロキシ214とセキュアサービスプロキシ215の特性及び設定を構成するために使用することができるインターフェースである。これら2の構成要素の各々に可能なコンフィギュレーションのタイプは、明細書の対応箇所に記載されている。代替のアプローチでは、ネーミングプロキシ214とセキュリティでセキュアサービスプロキシ215は、それぞれにユーザインターフェイス要素が統合されており、別のセキュリティ管理部224は不要である。）
　
　
　上記H.、及び図5Aの記載によれば、「セキュアサービスプロキシ215」は「エンドユーザコンピュータ104」内に設けられ、「エンドユーザコンピュータ104」内の「ローカルリソース504」、及び、「エンドユーザコンピュータ10」外の「サーバコンピュータ306、サーバコンピュータ514」にアクセスできるものと認められる。
　
　以上総合すると、刊行物１には、以下の発明（以下、「引用発明」という。）が記載されているといえる。
 
〈引用発明〉
　 
「比較的小型の実行可能プログラムであるアプレットにセキュリティ制御を提供するシステムであって、
　エンドユーザコンピュータ104は、ウェブブラウザ108を実行し、アプレット502などのアプリケーションプログラムは、ブラウザ内で実行され、
　セキュアサービスプロキシ215はエンドユーザコンピュータ104内に設けられ、
　アプレット502は、ネットワーク接続508によって通信可能にセキュアサービスプロキシ215に接続され、
　アプレット502とセキュアサービスプロキシ215との接続は、論理サンドボックス506内にあるリソースのみにアプレットがアクセスできるセキュリティ制御に従い、
　セキュアサービスプロキシ215は、エンドユーザコンピュータ104内の１以上のローカルリソース504へのアクセス、及び、エンドユーザコンピュータ104外のサーバコンピュータ306、サーバコンピュータ514、あるいは他のネットワーク要素へネットワーク接続510、512を確立し、
　アプレットは、他のプロセス及びローカルストレージ等のローカル・リソースにアクセスを要求することができ、
　セキュアサービスプロキシが、アプレット毎にアクセス制御リスト(ACL)を用いてアプレットからのアクセスの要求を制限することができる、
　システム。」
　
　この点、引用発明のアプレットは、セキュアサービスプロキシとネットワーク接続によって通信可能なものではあるが、自身がネットワーク接続を介して、アクセスの要求をセキュアサービスプロキシに送るものと認められ、セキュアサービスプロキシと同一のソースからアプレット内にインストールされるものであるとも、Ｗｅｂアプリケーションからのアクセスの要求をセキュアサービスプロキシに中継するコンポーネントであるとも、いえない。
　
　
２．対比
 
　本願発明と引用発明とを対比すると、次のことがいえる。
　 
ア．引用発明の「エンドユーザコンピュータ」は、本願発明の「コンピュータ装置」に相当する。
　　 
イ．引用発明の「アプレット」は、「ブラウザ内で実行され」る比較的小型のプログラムであり、本願発明の「Ｗｅｂアプリケーション」と、「プログラム」の点で共通する。
　 
ウ．引用発明の「システム」は、「アプレット」にセキュリティ制御を提供するものであり、さらに、セキュアサービスプロキシ215が中継することで「他のプロセス」等のローカル・リソースにアクセスできるものであるから、引用発明の「システム」と、本願発明の「コンピューティング装置上で動作しているプロセスにＷｅｂアプリケーションから要求を安全に中継するためのシステム」とは、「コンピューティング装置上で動作しているプロセスにプログラムから要求を安全に中継するためのシステム」の点で共通する。
　
　
　よって、本願発明と引用発明は、以下の点で一致、ないし相違している。
　 
（一致点）
　 
「コンピューティング装置上で動作しているプロセスにプログラムから要求を安全に中継するためのシステム。」
　 
　
（相違点１）プログラムが、本願発明では、「Ｗｅｂアプリケーション」であるのに対して、引用発明では、「アプレット」である点。
　
（相違点２）本願発明では、「コンピューティング装置に対しローカルのブラウザー環境内で動作しているＷｅｂアプリケーション内にインストールされたブリッジメッセージクライアントコンポーネントであって、ブリッジサーバーコンポーネントと同一のソースから由来するものとして前記ブリッジメッセージクライアントコンポーネントが識別された場合に前記ブリッジサーバーコンポーネントが前記Ｗｅｂアプリケーションからの要求を信頼することを可能にするブリッジメッセージクライアント識別子を使用することに基づいて、ブリッジサーバーコンポーネントとの安全なローカル接続を確立し、前記ブラウザー環境の外の前記コンピューティング装置上で動作するプロセスへルーティングするため、前記Ｗｅｂアプリケーションからの要求を前記安全なローカル接続を通して前記ブリッジサーバーコンポーネントに中継する、ように構成されたブリッジメッセージクライアントコンポーネント」、を有するのに対して、引用発明は、それに相当するコンポーネントを有しない点。
　　 
　
３．判断
　
　当審は次のとおり判断する。
　
　下のア．〜ウ．に示す理由で、引用発明において上記相違点２に係る本願発明の構成を採用することは、当業者といえども容易に推考し得たこととはいえない。
　
　したがって、その他の点について判断するまでもなく、本願発明は引用発明に基づいて当業者が容易に発明することができたものとはいえない。
　
ア．引用発明を開示する刊行物１には、引用発明において上記相違点２に係る本願発明の構成を採用することについての記載も、それを示唆する記載もない。
　
イ．拒絶査定で引用された「リモートアクセスを導入するなら  簡単・安い・便利  三拍子そろったＳＳＬ  ＶＰＮ，Ｎ＋Ｉ  ＮＥＴＷＯＲＫ　第５巻  第２号，日本，ソフトバンクパブリッシング株式会社，２００５年　２月　１日，第5巻，第10-12頁」（以下、「刊行物２」という。）には、アプリケーションをＳＳＬでカプセル化するアプレットを用いて他のリソースに安全にアクセスすることは記載（特に、第１１頁、１２頁参照。）されているが、刊行物２の「アプレット」はＷｅｂアプリケーションにインストールされるものではなく、Ｗｅｂアプリケーションからの要求を安全なローカル接続を通してブリッジサーバーコンポーネントといい得るものに中継するものでもない。また、刊行物２では、ＳＳＬを用いてセキュリティを確保するものであり、「ブリッジサーバーコンポーネントと同一のソースから由来するものとして前記ブリッジメッセージクライアントコンポーネントが識別された場合に前記ブリッジサーバーコンポーネントが前記Ｗｅｂアプリケーションからの要求を信頼することを可能にする」ものではない。
　したがって、仮に引用発明における「アプレット」におけるアクセスの要求を「セキュアサービスプロキシ」に送る手段として、上記刊行物２に記載される技術を採用したとしても、上記相違点２に係る本願発明の構成は導出されない。
　　
　したがって、上記刊行物２に記載される技術の存在をもっては、引用発明において上記相違点２に係る本願発明の構成を採用することが当業者にとって容易であったとはいえない。
　
ウ．ほかに引用発明において上記相違点２に係る本願発明の構成を採用することが当業者にとって容易であったとはいえる根拠は見当たらない。
　
　本願の請求項９は、本願の請求項１に係る発明を方法として表現したものに過ぎず、また、本願の請求項１８は、本願の請求項１に係る発明をコンピュータ実行可能命令を含む記録媒体として表現したものに過ぎないことから、本願発明と同様に、当業者が引用発明に基づいて容易に発明することができたとはいえない。
　
　さらに、本願の請求項２−８、９−１７に係る発明は、本願の請求項１、８に係る発明をさらに限定したものであるから、本願発明と同様に、当業者が引用発明に基づいて容易に発明することができたとはいえない。
　
　 
第５　むすび
　以上のとおり、本願の請求項１−１８に係る発明は、いずれも、当業者が引用発明に基づいて容易に発明することができたものではないから、原査定の理由によっては、本願を拒絶することはできない。 
　
　また、他に本願を拒絶すべき理由を発見しない。 
　
　よって、結論のとおり審決する。