【事件の表示】
　特願２０１６−５４０４２８「身体的活動の取り込み済み画像データを用いたセッションの実施およびトークン検証可能なプロキシ・アップローダを使用するアップロード」拒絶査定不服審判事件〔平成２７年　３月１２日国際公開、ＷＯ２０１５／０３５１９７、平成２８年１２月　８日国内公表、特表２０１６−５３８６５５、請求項の数（７）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　
　本願は，２０１４年９月５日（パリ条約による優先権主張２０１３年９月５日（以下，「優先日」という。），米国）を国際出願日とする出願であって，平成２８年３月２日付けで特許法第１８４条の５第１項の規定による書面が提出され，平成２８年４月２７日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る。）の日本語による翻訳文が提出され，平成２９年６月９日付けで拒絶理由通知がされ，平成２９年９月２０日に意見書が提出されるとともに手続補正がされ，平成３０年２月２８日付けで拒絶査定（原査定）がされ，これに対し，平成３０年７月３日に拒絶査定不服審判の請求がされると同時に手続補正がされ，令和１年６月３日付けで当審より拒絶理由通知（以下，「当審拒絶理由通知」という。）がされ，令和１年１１月１９日に意見書が提出されるとともに誤訳訂正がされたものである。
　
　
第２　原査定の概要
　
　原査定（平成３０年２月２８日付け拒絶査定）の概要は次のとおりである。
　
（１）（進歩性）本願請求項１−３，５−１６に係る発明は，以下の引用文献１ないし４に基づいて，当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
（２）（明確性及び実施可能要件）この出願は，特許請求の範囲の請求項４の記載及び発明の詳細な説明の記載が，特許法第３６条第４項第１号及び第６項第２号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　＜引用文献等一覧＞
１．米国特許出願公開第２０１１／０２０２９８８号明細書　
２．特開２０１２−１７３８０１号公報　
３．特開２００６−１１９７６９号公報　
４．特開２００８−００９６０７号公報　
　
第３　当審拒絶理由の概要
　
　当審拒絶理由通知における拒絶理由の概要は次のとおりである。
　
１．（明確性）この出願は，特許請求の範囲の記載が，特許法第３６条第６項第２号に規定する要件を満たしていない。 
 　 
２．（実施可能要件）この出願は，発明の詳細な説明の記載が，特許法第３６条第４項第１号に規定する要件を満たしていない。 
 　 
３．（進歩性）この出願の請求項１−７に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　　　　　　　　　　＜引用文献等一覧＞
　
１．米国特許出願公開第２０１１／０２０２９８８号明細書　
２．特開２０１２−１７３８０１号公報　
３．特開２００６−１１９７６９号公報　
４．特開２００８−００９６０７号公報　
　
第４　本願発明
　
　本願請求項１ないし７に係る発明（以下，それぞれ「本願発明１」ないし「本願発明７」という。）は，令和１年１１月１９日付けの誤訳訂正で訂正された特許請求の範囲の請求項１ないし７に記載された事項により特定される発明であり，以下のとおりの発明である。
　
「　【請求項１】
　コンピュータに実装される方法であって、
　ホスト型サービス・サーバにおいて、エンド・ユーザ通信デバイスから送信された、ホスト型プロキシ・サーバへのアスリートによって行われる身体的活動に関する電子情報を含む第１のメディア・ファイルの送信を承認するべく構成された前記ホスト型サービス・サーバからのアップロード・トークンを要求するトークン要求を受信することと、
　前記ホスト型サービス・サーバに対するエンド・ユーザ信用証明書を使用する前記エンド・ユーザ通信デバイスのユーザの有効化に応答して前記エンド・ユーザ通信デバイスへ前記アップロード・トークンが送信され、さらに、前記ホスト型プロキシ・サーバによって、前記アップロード・トークンと前記第１のメディア・ファイルが受信され、前記アップロード・トークンと前記第１のメディア・ファイルが受信されたことに応答して、前記ホスト型プロキシ・サーバによって、前記トークン有効化呼び出しを前記ホスト型サービス・サーバへ送信することと、
　前記ホスト型サービス・サーバにおいて、前記ホスト型プロキシ・サーバから前記トークン有効化呼び出しを受信することと、
　前記ホスト型プロキシ・サーバから前記第１のメディア・ファイルをメディア共有サイトへ送信することを、前記ホスト型サービス・サーバの信用証明書を使用して承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信することと、
　前記ホスト型サービス・サーバから前記有効化メッセージを受信したことに応答して、前記ホスト型プロキシ・サーバによって、前記第１のメディア・ファイルと前記ホスト型サービス・サーバの前記信用証明書とが前記メディア共有サイトへ送信されることと、
　を含むコンピュータに実装される方法。
　　【請求項２】
　前記エンド・ユーザ通信デバイスの前記ユーザの前記有効化は、前記エンド・ユーザ通信デバイスが信用証明書を前記メディア共有サイトへ提供することなく実施され、前記エンド・ユーザ通信デバイスは、前記有効化の一部として前記メディア共有サイト固有の信用証明書を送信しない、請求項１に記載のコンピュータに実装される方法。
　　【請求項３】
　前記ホスト型プロキシ・サーバからの前記トークン有効化呼び出しは、前記ホスト型プロキシ・サーバの前記アップロード・トークンと、（１）前記エンド・ユーザ通信デバイスからの前記第１のメディア・ファイル、または（２）前記ホスト型プロキシ・サーバへの、前記第１のメディア・ファイルをアップロードするための前記エンド・ユーザ通信デバイスからの要求の何れかと、を受信することに応答して、前記ホスト型サービス・サーバへ送信される、請求項１に記載のコンピュータに実装される方法。
　　【請求項４】
　前記第１のメディア・ファイルは、複数の順次画像を含み、前記方法は、さらに、
　前記ホスト型プロキシ・サーバにおいて、前記複数の順次画像の少なくとも一部に対して画像解析を行ない、前記第１のメディア・ファイルのためのタグを決定する、
　請求項１に記載のコンピュータに実装される方法。
　　【請求項５】
　さらに、
　前記ホスト型サービス・サーバにおいて、前記メディア共有サイト上の前記第１のメディア・ファイルの場所を表わす一意的な識別を受信すること、
　を含む、請求項１に記載のコンピュータに実装される方法。
　　【請求項６】
　さらに、
　前記エンド・ユーザ通信デバイスにおいて、前記メディア共有サイト上の前記第１のメディア・ファイルの場所を表わす一意的な識別を受信すること、
　を含む、請求項１に記載のコンピュータに実装される方法。
　　【請求項７】
　前記エンド・ユーザ通信デバイスは、第１のエンド・ユーザ通信デバイスであり、前記方法は、さらに、
　前記第１のメディア・ファイルまたはそれの一部を前記ホスト型プロキシ・サーバ上にストアすることを含み、前記ホスト型プロキシ・サーバおよび前記メディア共有サイトにストアされる前記第１のメディア・ファイルは、前記第１のエンド・ユーザ通信デバイスによって検索可能であり、前記ホスト型プロキシ・サーバ上にストアされる前記第１のメディア・ファイルは、第２のエンド・ユーザ通信デバイスによって検索可能でない、
　請求項１に記載のコンピュータに実装される方法。」
　
　
第５　引用文献，引用発明等
　
１．引用文献１について
　
　原査定の拒絶の理由に引用され，当審拒絶理由通知にも引用された引用文献１（米国特許出願公開第２０１１／０２０２９８８号明細書）には，図面とともに次の事項が記載されている。（下線は当審により付与。以下同様。）
　　
Ａ　「［0047］　If it is determined that the second authentication context is valid, in step 405, data retrieval over the service session is initiated. Step 405 is explained in more detail in FIG.4B, according to one embodiment. In one example, the process 410 of FIG.4B for retrieving data based on a server-server authentication context (first authentication context) can be implemented as step 405 of process 400 of FIG.4A. When it is determined that the second authentication context received from, for example, the client application 111 is valid, in step 411, a connection is initiated with an application server (such as application server 107a). This connection is based, at least in part, on the first authentication context (e.g., a server-server authentication context implemented by the authentication server 105 ). In step 413, the requested data is retrieved from the application server 107, if the first authentication context (e.g., a server-server authentication context implemented by the authentication server 105) is valid. In step 415, the retrieved data is transmitted to, for example, the client application 111 that requested the data based, at least in part, on the second authentication context (e.g., a client-server authentication context established between the UE 103 and the proxy server 101). In one embodiment, the returned data can be a webpage, multimedia data (such as a video, a music file, an image), etc.」
（当審による仮訳：
「［0047］　第２認証コンテキストが有効であると判定された場合，ステップ４０５で，サービスセッションを介してデータ検索が開始される。ステップ４０５は，図４ｂにおいてより詳細に説明される，一実施形態による。一例では，サーバがサーバ認証コンテキスト（第１認証コンテキスト）に基づいてデータを検索するために図４Ｂの方法４１０は，図４Ａのプロセス４００のステップ４０５として実装することができる。例えば，クライアント・アプリケーション１１１から受信された第２認証コンテキストが有効であると判定された場合，ステップ４１１において，アプリケーションサーバ（アプリケーションサーバ１０７ａのような）で開始される。この接続は，少なくとも部分的に，第１認証コンテキスト（例えば，認証サーバ１０５により実装されたサーバのサーバ認証コンテキスト）に基づいている。ステップ４１３において，第１認証コンテキスト（例えば，認証サーバ１０５によって実装されたサーバのサーバ認証コンテキスト）が有効である場合に，要求されたデータがアプリケーションサーバ１０７から検索される。ステップ４１５では，検索されたデータは，例えば，少なくとも部分的に，第２認証コンテキスト（例えば，ユーザ端末１０３とプロキシ・サーバ１０１との間で確立されたクライアント―サーバ認証コンテキスト）に基づいてデータを要求したクライアント・アプリケーション１１１に送信される。一実施形態では，返されるデータは，ウェブページ，マルチメディアデータ（ビデオ，音楽ファイル，画像など）などとすることができる。」）
　
Ｂ　「［0048］　FIG.5 is a time sequence diagram that illustrates a 
sequence
processes for providing separation of authentication contexts for client-server and server-server communication, according to one embodiment
［0049］　
At 501, the client application 111 (of the UE 103) authenticates itself against the authentication server 105. In one embodiment, the message 501 passed from client application 111 to the authentication server 105 can include credentials of the client application 111, a user of the UE 103, etc
The authentication server 105 validates the credentials received from the client application 111 (at 503) and generates/retrieves and transmits a first authentication context (such as a token or a cookie) to the client application 111 (at 505)
［0050］　
At 507, the client application 111 contacts the proxy server 101 with a request to initiate a service session
the service session initiation request 507 can include the first authentication context (such as the token and/or the cookie generated/retrieved by the authentication server 105)
［0051］　Next, the proxy server 101 validates/verifies the received first authentication context. In one embodiment, 
the proxy server 101 generates and initiates transmission of a verification request to the authentication server 105 to verify the validity of the first authentication context (at 509). The authentication server 105 verifies the first authentication context (at 511) and communicates a verification response to the proxy server 101 (513)
At 515 , depending on the implementations or information received from the client application 111, the proxy server 101 determines a desired authentication protocol and implements a second authentication context with the client application 111. Therefore, according to one embodiment, communication between the client application 111 and the proxy server 101 can be based, at least in part, on the second authentication context.
［0052］　According to one example, 
after the first authentication context of the client application 111 is verified and validated by the proxy server 101 and the second authentication context is implemented, the client application 111 contacts the proxy server 101 with a request to retrieve data (at 517). The request 517 can be based on the second authentication context that is implemented between the client application 111 and the proxy server 101 and can include information regarding the application server 107. At 519, the proxy server 101 can validate the second authentication context and if the authentication context is valid, the proxy server 101 can initiate a communication with the application server 107 (at 521)
［0053］　According to one embodiment, the proxy server 101 can further control data retrieval request to the application server 107. For example, when the proxy server 101 receives the request 517 from the client application 111, the proxy server 101 can determine the application server 107, which the request 517 is intended for. Further, the proxy server 101 can determine the amount of data traffic for the application server 107. If the proxy server 101 determines that, for example, data traffic of the application server 107 is more than a predetermined threshold, the proxy server 101 can take actions, such as blocking the request 517, delaying the request for a later time (if it is permitted by a quality of service measure of the request 517), rerouting the request 517 to another application server, which has access to the requested data, etc. It is contemplated that any other criteria for determining load on the application server can also be implemented.
［0054］　
At 521, the proxy server 101 communicates with the application server 107 to request for the retrieval of data requested by the client application. In one embodiment, the communication 521 is based on the first authentication context. At 523, the application server 107 retrieves and transmits the requested data to the proxy server 101. At 525, the retrieved data is transmitted from the proxy server 101 to the client application 111
［0055］　The process 500 illustrates that the authentication context and/or authentication protocol used for client-server and sever-server communication is advantageously separated. For example, communication between the client application 111 and the proxy server 101 can be implemented based on a second authentication context and the communication between the proxy server 101 and the application server 107 can be implemented based on a first authentication context, as discussed before. Therefore, need for implementing same authentication scheme for both client-server and server-server communication can be eliminated.」
（当審による仮訳：
「［0048］　図５は，
クライアント−サーバ及びサーバ−サーバの通信のための認証コンテキストの分離を提供するための
手順の一実施形態を説明するためのシーケンス図である
［0049］　
５０１では，クライアント・アプリケーション１１１（１０３）は，認証サーバ１０５に対して認証を行う。一実施形態では，クライアント・アプリケーション１１１から認証サーバ１０５に渡されるメッセージ５０１は，クライアント・アプリケーション１１１の認証，端末１０３の利用者等を含むことができる
認証サーバ１０５は，クライアント・アプリケーション１１１（５０３）から受信した信用証明書の妥当性を検査し，生成／検索し，第１認証コンテキスト（トークンまたはクッキーなど）をクライアント・アプリケーション１１１に送信する（５０５）
［0050］　
５０７において，クライアント・アプリケーション１１１は，サービス・セッションを開始するための要求をプロキシ・サーバ１０１に接触する
サービスセッション開始要求５０７が第１認証コンテキスト（トークンおよび／または認証サーバ１０５で生成／検索されたクッキーなど）を含むことができる
［0051］　次に，プロキシ・サーバ１０１は，確認／受信された第１認証コンテキストを検証する。一実施形態では，
プロキシ・サーバ１０１は，認証サーバ１０５への認証要求の送信を生成して開始することで第１認証コンテキスト（５０９）の有効性を検証する。認証サーバ１０５は，第１認証コンテキストを（５１１において）検証し，プロキシ・サーバ１０１に検証応答を送る（５１３）
５１５で，クライアント・アプリケーション１１１から受信された実装情報に依存して，プロキシ・サーバ１０１では認証の目的の認証プロトコルを決定し，クライアント・アプリケーション１１１を用いて第２認証コンテキストをインプリメントする。したがって，１つの実施形態によれば，クライアント・アプリケーション１１１とプロキシ・サーバ１０１との間の通信は，少なくとも部分的に，第２認証コンテキストに基づくことができる
［0052］　一例によれば，
クライアント・アプリケーション１１１の第１認証コンテキストは，プロキシ・サーバ１０１によって検証され，検証されると，第２認証コンテキストが実行された後，クライアント・アプリケーション１１１は，データを検索する要求をプロキシ・サーバ１０１に接触する（５１７において）。要求５１７は，クライアント・アプリケーション１１１とプロキシ・サーバ１０１との間で実施される第２認証コンテキストに基づくことが可能であり，アプリケーションサーバ１０７に関する情報を含むことができる。５１９で，プロキシ・サーバ１０１は，第２認証コンテキストを検証し，認証コンテキストが有効である場合，プロキシ・サーバ１０１は，アプリケーションサーバ１０７（５２１）との通信を開始することができる
［0053］　一実施形態によれば，プロキシ・サーバ１０１は，アプリケーションサーバ１０７にデータ検索要求を制御することができる。例えば，プロキシ・サーバ１０１は，クライアント・アプリケーション１１１から要求５１７を受信すると，プロキシ・サーバ１０１は，要求５１７が意図されているアプリケーションサーバ１０７を決定することができる。さらに，プロキシ・サーバ１０１は，アプリケーションサーバ１０７のデータトラフィックの量を決定することができる。プロキシ・サーバ１０１は，たとえば，アプリケーション・サーバ１０７のデータ・トラフィックが所定の閾値以上であると判定した場合には，プロキシ・サーバ１０１は，要求されたデータへのアクセスなど，要求５１７を阻止すること，後の時間（要求５１７のサービスの品質の尺度によって許可される場合）の要求を遅延させること，他のアプリケーションサーバにリクエスト５１７を再ルーティングするなどのアクションをとることができる。なお，アプリケーションサーバの負荷を決定するための任意の他の基準も，実施することができることが企図される。
［0054］　
５２１で，プロキシ・サーバ１０１は，アプリケーションサーバ１０７と通信するクライアント・アプリケーションによって要求されたデータの検索を要求する。一実施形態では，通信５２１は，第１認証コンテキストに基づいている。ステップ５２３において，アプリケーションサーバ１０７は，要求されたデータをプロキシ・サーバ１０１に取り出しおよび送信する。５２５において，検索されたデータは，プロキシ・サーバ１０１からクライアント・アプリケーション１１１に伝送される
［0055］　プロセス５００は，クライアント−サーバおよびサーバ−サーバ通信に用いられる認証及び／又は認証プロトコルは有利には分離されることを示している。例えば，クライアント・アプリケーション１１１とプロキシ・サーバ１０１との間の通信は，第２認証コンテキストに基づいて実施することが可能であり，プロキシ・サーバ１０１およびアプリケーションサーバ１０７との間の通信は，第１認証コンテキストとに基づいて実施することができる。従って，クライアント−サーバ及びサーバ−サーバの通信の両方のために同一の認証スキームを実装する必要性をなくすことができる。」）
　
　上記Ａ及びＢの記載から，上記引用文献１には次の発明（以下，「引用発明」という。）が記載されていると認められる。
　
「クライアント−サーバ及びサーバ−サーバの通信のための認証コンテキストの分離を提供するための方法であって，
　クライアント・アプリケーションは，認証サーバに対して認証を行い，クライアント・アプリケーションから認証サーバに渡されるメッセージは，クライアント・アプリケーションの認証，端末の利用者等を含むことができ，認証サーバは，クライアント・アプリケーションから受信した信用証明書の妥当性を検査し，生成／検索し，第１認証コンテキスト（トークンまたはクッキーなど）をクライアント・アプリケーションに送信し，
　クライアント・アプリケーションは，サービス・セッションを開始するための要求をプロキシ・サーバに接触し，サービスセッション開始要求が第１認証コンテキスト（トークンおよび／または認証サーバで生成／検索されたクッキーなど）を含むことができ，
　プロキシ・サーバは，認証サーバへの認証要求の送信を生成して開始することで第１認証コンテキストの有効性を検証し，認証サーバは，第１認証コンテキストを検証し，プロキシ・サーバに検証応答を送り，
　クライアント・アプリケーションから受信された実装情報に依存して，プロキシ・サーバでは認証の目的の認証プロトコルを決定し，クライアント・アプリケーションを用いて第２認証コンテキストをインプリメントし，したがって，クライアント・アプリケーションとプロキシ・サーバとの間の通信は，少なくとも部分的に，第２認証コンテキストに基づくことができ，
　クライアント・アプリケーションの第１認証コンテキストは，プロキシ・サーバによって検証されると，第２認証コンテキストが実行された後，クライアント・アプリケーションは，データを検索する要求をプロキシ・サーバに接触し，これは，クライアント・アプリケーションとプロキシ・サーバとの間で実施される第２認証コンテキストに基づくことが可能であり，アプリケーションサーバに関する情報を含むことができ，プロキシ・サーバは，第２認証コンテキストを検証し，第２認証コンテキストが有効である場合，プロキシ・サーバは，アプリケーションサーバとの通信を開始することができ，
　プロキシ・サーバは，アプリケーションサーバと通信するクライアント・アプリケーションによって要求されたデータの検索を要求し，この通信は，第１認証コンテキストに基づいており，アプリケーションサーバは，要求されたデータをプロキシ・サーバに取り出しおよび送信し，検索されたデータは，プロキシ・サーバからクライアント・アプリケーションに伝送される，
　方法。」
　
２　引用文献２について
　
　原査定の拒絶の理由に引用文献２として引用された特開２０１２−１７３８０１号公報には，図面とともに次の事項が記載されている。
Ｃ　「【０００２】
　現在、
インターネット上のコンテンツ共有サービス
【０００３】
　一方、通信装置が外部サービスに直接アクセスするのではなく、中継装置を経由してアクセスするシステムが知られている（特許文献１参照）。これにより、外部サービス間の機能やデータ形式に関する差異や、外部サービスの追加や変更に伴う更新を中継装置によって吸収することができ、通信装置への影響を防ぐことができる。
【０００４】
　しかし、上述したシステムでは、通信装置が外部サービスにコンテンツをアップロードする場合も中継装置を経由するため、中継装置の処理負荷及び通信負荷が増大してしまうことがあった。そのため、通信装置が外部サービスにコンテンツをアップロードする際、外部サービスに直接アップロードすることが可能であるか否かを判断し、可能である場合、外部サービスに直接アップロードを行う方法が知られている（特許文献２参照）。
【０００５】
　特許文献２に開示される技術では、通信装置は、外部サービスに直接アップロードすることが可能であると判断した場合、直接アップロードを要求する要求メッセージを作成するために必要な情報（以下、必要情報と称す）を中継装置に要求する。このとき、通信装置は、アップロードの対象となる各コンテンツに関するファイル名やファイルサイズ等のパラメタデータを中継装置に送信する。中継装置は、通信装置から受信したパラメタデータと、中継装置が管理する外部サービスに対する認証トークン情報とに基づいて必要情報を作成し、通信装置に返送する。通信装置は、中継装置から受信した必要情報に基づいて要求メッセージを作成し、外部サービスにコンテンツを直接アップロードする。」
　
３　引用文献３について
　
　原査定の拒絶の理由に引用文献３として引用された特開２００６−１１９７６９号公報には，図面とともに次の事項が記載されている。
Ｄ　「【００８０】
　このように、本実施の形態では、認証サーバ２で各ユーザが属するグループのグループＩＤを記憶するユーザグループ情報２４Ｂを記憶しておき、正当性が確認されたクライアントシステム１からの接続要求に応じて
認証サーバ２でユーザグループ情報２４Ｂから取得した当該ユーザのグループＩＤを含む接続確認要求をコンテンツ提供サーバ３へ送信し
　したがって、
認証サーバ２でのグループ管理によりコンテンツ提供サーバ３に対するユーザからの匿名アクセスを実現しつつ、正当性が確認された認証サーバ２からしか接続確認要求を受け付けないようにした
　
４　引用文献４について
　
　原査定の拒絶の理由に引用文献４として引用された特開２００８−００９６０７号公報には，図面とともに次の事項が記載されている。
Ｅ　「【００５４】
　次に、図５を用いて、図１および図２に示す情報処理システムにおける処理の流れについて説明する。なお、ここでは、クライアント端末１０にＣ−ＳＳＯ１２が既にインストールされている状態からの処理の流れについて説明する。
【００５５】
　まず、ユーザがクライアント端末１０からＷｅｂブラウザ１１を用いてサービス提供サーバ４０へのアクセスを試みると（ステップＳ２０１）、Ｃ−ＳＳＯ１２は、リクエスト取得部６２において、このリクエストを横取りする。この時点でＣ−ＳＳＯ１２へのログインが済んでいなければ、ユーザ認証部６１は、ポップアップを表示するなどして、ユーザにＣ−ＳＳＯ１２へのログインを要求する（ステップＳ２０２）。
【００５６】
　ユーザは、アカウント、パスワード等のユーザ認証情報を入力し（ステップＳ２０３）、ユーザ認証の実行を指示する。ここで、認証が成功すると（ステップＳ２０４）、Ｃ−ＳＳＯ１２へのログインが行われることになる。
【００５７】
　続いてＣ−ＳＳＯ１２は、サービス提供サーバ４０への認証がまだ済んでいないことを検出すると、
ユーザに代わって各サービス提供サーバ４０へ認証代行を行う
【００５８】
　認証代行に成功すると（ステップＳ２０６）、これを受けたリクエスト取得部６２は、ステップＳ２０１におけるＷｅｂブラウザ１１からのリクエストを中継する（ステップＳ２０７）。このリクエストに対するサービス提供サーバ４０からの応答があると（ステップＳ２０８）、Ｃ−ＳＳＯ１２のリクエスト取得部６２がこれを中継して（ステップＳ２０９）、Ｗｅｂブラウザ１１へ返す。これにより、Ｗｅｂブラウザ１１の画面上には、ステップＳ２０１のリクエストに対応するＨＴＭＬコンテンツ等が表示されることになる（ステップＳ２１０）。」
　
　
第６　対比・判断
　
１．本願発明１について
（１）対比
　本願発明１と引用発明とを対比する。
　
ア　引用発明における認証サービスを行う「認証サーバ」，「クライアント・アプリケーション」を有するデバイス，「プロキシ・サーバ」，「第１認証コンテキスト（トークンまたはクッキーなど）」は，それぞれ本願発明１における「ホスト型サービス・サーバ」，「エンド・ユーザ通信デバイス」，「ホスト型プロキシ・サーバ」，「トークン」に相当し，また，引用発明の「データを検索する要求」の送信と本願発明１の「第１のメディア・ファイル」の「送信」とは，“情報の送信”である点で共通する。
　また，引用発明が，「クライアント・アプリケーション」から「アプリケーションサーバ」に対し「データの検索を要求」することは，情報の処理のリクエストを送信することともいえ，「認証サーバ」から渡される「第１認証コンテキスト（トークンまたはクッキーなど）」はその送信を承認するためのトークンといえ，当該「第１認証コンテキスト（トークンまたはクッキーなど）」を「クライアント・アプリケーション」から「認証サーバ」に要求しているといえるから，当該「認証サーバ」は，上記「クライアント・アプリケーション」から送信された，「データの検索」の「要求」を承認するための「第１認証コンテキスト（トークンまたはクッキーなど）」を要求するトークン要求を受信しているといえ，そうすると，本願発明１の「ホスト型サービス・サーバにおいて，エンド・ユーザ通信デバイスから送信された，ホスト型プロキシ・サーバへのアスリートによって行われる身体的活動に関する電子情報を含む第１のメディア・ファイルの送信を承認するべく構成された前記ホスト型サービス・サーバからのアップロード・トークンを要求するトークン要求を受信すること」と，引用発明の「認証サーバ」が「クライアント・アプリケーション」に「第１認証コンテキスト（トークンまたはクッキーなど）」を「送信」するために「第１認証コンテキスト（トークンまたはクッキーなど）」の要求を「認証サーバ」が「クライアント・アプリケーション」から受信することであり，当該「第１認証コンテキスト（トークンまたはクッキーなど）」が「クライアント・アプリケーション」から送信された「データの検索」の「要求」を承認するためのものであることとは，“ホスト型サービス・サーバにおいて，エンド・ユーザ通信デバイスから送信された，ホスト型プロキシ・サーバへの情報の送信を承認するべく構成された前記ホスト型サービス・サーバからのデータ処理のためのトークンを要求するトークン要求を受信すること”である点で共通するといえる。
　
イ　引用発明の「認証サーバ」は「クライアント・アプリケーションから受信した信用証明書の妥当性を検査」した上で，「第１認証コンテキスト（トークンまたはクッキーなど）をクライアント・アプリケーションに送信」しており，「クライアント・アプリケーションから受信した信用証明書」が「妥当」であるとはユーザが有効であることといえ，また，引用発明の「クライアント・アプリケーション」は，「サービス・セッションを開始するための要求をプロキシ・サーバに接触」するものであり，この場合の「サービス・セッションを開始するための要求」である「サービスセッション開始要求が」，「第１認証コンテキスト（トークンおよび／または認証サーバで生成／検索されたクッキーなど）を含む」ことから，要求を受ける「プロキシ・サーバ」は「第１認証コンテキスト」を受信することとなり，さらに引用発明の「プロキシ・サーバは，認証サーバへの認証要求の送信を生成して開始することで第１認証コンテキストの有効性を検証し」ているから，上記「認証サーバへの認証要求」は，「第１認証コンテキスト」（本願発明１の「トークン」に相当）の有効性があるか否かを「認証サーバ」（本願発明１の「ホスト型サービス・サーバ」に相当）に対して呼び出すものであって，本願発明１の「トークン有効化呼び出し」に相当する構成を含むといえる。
　そうすると，本願発明１の「前記ホスト型サービス・サーバに対するエンド・ユーザ信用証明書を使用する前記エンド・ユーザ通信デバイスのユーザの有効化に応答して前記エンド・ユーザ通信デバイスへ前記アップロード・トークンが送信され，さらに，前記ホスト型プロキシ・サーバによって，前記アップロード・トークンと前記第１のメディア・ファイルが受信され，前記アップロード・トークンと前記第１のメディア・ファイルが受信されたことに応答して，前記ホスト型プロキシ・サーバによって，前記トークン有効化呼び出しを前記ホスト型サービス・サーバへ送信すること」と，引用発明の「認証サーバは，クライアント・アプリケーションから受信した信用証明書の妥当性を検査し，生成／検索し，第１認証コンテキスト（トークンまたはクッキーなど）をクライアント・アプリケーションに送信し」，「クライアント・アプリケーションは，サービス・セッションを開始するための要求をプロキシ・サーバに接触し，サービスセッション開始要求が第１認証コンテキスト（トークンおよび／または認証サーバで生成／検索されたクッキーなど）を含むことができ」，「プロキシ・サーバは，認証サーバへの認証要求の送信を生成して開始することで第１認証コンテキストの有効性を検証し，認証サーバは，第１認証コンテキストを検証」することとは，“前記ホスト型サービス・サーバに対する信用証明書を使用する前記エンド・ユーザ通信デバイスのユーザの有効化に応答して前記エンド・ユーザ通信デバイスへ前記トークンが送信され，さらに，前記ホスト型プロキシ・サーバによって，前記トークンが受信され，前記トークンが受信されたことに応答して，前記ホスト型プロキシ・サーバによって，前記トークン有効化呼び出しを前記ホスト型サービス・サーバへ送信すること”である点で共通するといえる。
  
ウ　上記イの検討から，引用発明の「認証サーバ」は「トークン有効化呼び出し」に相当する構成を含む「認証要求」を受信しているといえるから，本願発明１の「前記ホスト型サービス・サーバにおいて，前記ホスト型プロキシ・サーバから前記トークン有効化呼び出しを受信すること」と，引用発明の「認証サーバは，第１認証コンテキストを検証」するために受信することとは，“前記ホスト型サービス・サーバにおいて，前記ホスト型プロキシ・サーバから前記トークン有効化呼び出しを受信すること”である点で共通するといえる。
　
エ　引用発明において，「認証サーバは，第１認証コンテキストを検証し，プロキシ・サーバに検証応答を送」っており，当該「検証」のために何らかの信用に係る証明書を用いていることは明らかである。また，引用発明の「アプリケーションサーバ」は「要求されたデータをプロキシ・サーバに取り出しおよび送信」するものであるからデータ処理サーバであるといえ，本願発明１の「メディア共有サイト」とは，“データ処理装置”である点で共通し，さらに，引用発明の「認証サーバ」が「第１認証コンテキストを検証し，プロキシ・サーバ」に送信する「検証応答」は，第１認証コンテキストの有効性の検証結果であって「アプリケーションサーバ」への「データの検索」「要求」を承認するための「有効化メッセージ」といえるから，本願発明１の「前記ホスト型プロキシ・サーバから前記第１のメディア・ファイルをメディア共有サイトへ送信することを，前記ホスト型サービス・サーバの信用証明書を使用して承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信すること」と，引用発明の「認証サーバは，第１認証コンテキストを検証し，プロキシ・サーバに検証応答を送」ることであり，それにより「アプリケーションサーバ」への「データの検索」「要求」が行えるものであることとは，“前記ホスト型プロキシ・サーバから前記情報をデータ処理装置へ送信することを，信用証明書を使用して承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信すること”である点で共通するといえる。
　
オ　本願発明１と引用発明とは，“コンピュータに実装される方法”である点で一致するといえる。
  
カ　上記アないしオの検討から，本願発明１と引用発明との間には，次の一致点，相違点があるといえる。
　
（一致点）
 「コンピュータに実装される方法であって，
　ホスト型サービス・サーバにおいて，エンド・ユーザ通信デバイスから送信された，ホスト型プロキシ・サーバへの情報の送信を承認するべく構成された前記ホスト型サービス・サーバからのデータ処理のためのトークンを要求するトークン要求を受信することと，
　前記ホスト型サービス・サーバに対する信用証明書を使用する前記エンド・ユーザ通信デバイスのユーザの有効化に応答して前記エンド・ユーザ通信デバイスへ前記トークンが送信され，さらに，前記ホスト型プロキシ・サーバによって，前記トークンが受信され，前記トークンが受信されたことに応答して，前記ホスト型プロキシ・サーバによって，前記トークン有効化呼び出しを前記ホスト型サービス・サーバへ送信することと，
　前記ホスト型サービス・サーバにおいて，前記ホスト型プロキシ・サーバから前記トークン有効化呼び出しを受信することと，
　前記ホスト型プロキシ・サーバから前記情報をデータ処理装置へ送信することを，信用証明書を使用して承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信することと，
　を含むコンピュータに実装される方法。」 
  
（相違点１）
　ホスト型サービス・サーバにおいて，エンド・ユーザ通信デバイスから送信された，ホスト型プロキシ・サーバへの情報の送信を承認するべく構成された前記ホスト型サービス・サーバからのデータ処理のためのトークンを要求するトークン要求を受信することに関し，
　本願発明１は，「アスリートによって行われる身体的活動に関する電子情報を含む第１のメディア・ファイル」の送信を承認するべく構成された前記ホスト型サービス・サーバからの「アップロード・トークン」を要求するトークン要求を受信するのに対して，
　引用発明は，「第１認証コンテキスト（トークンまたはクッキーなど）」の要求の受信がそのようなものであるかは特定されていない点。 
　
（相違点２）
　ホスト型サービス・サーバに対する信用証明書を使用するエンド・ユーザ通信デバイスのユーザの有効化に応答してエンド・ユーザ通信デバイスへトークンが送信され，さらに，ホスト型プロキシ・サーバによって，トークンが受信され，トークンが受信されたことに応答して，ホスト型プロキシ・サーバによって，トークン有効化呼び出しをホスト型サービス・サーバへ送信することに関し，
　本願発明１は，「エンド・ユーザ」の信用証明書を使用してトークンが送信され，ホスト型プロキシ・サーバによって「アップロード・トークン」と「第１のメディア・ファイル」が受信され，「アップロード・トークン」と「第１のメディア・ファイル」が受信されたことに応答して，前記ホスト型プロキシ・サーバによって，前記トークン有効化呼び出しを前記ホスト型サービス・サーバへ送信するのに対して，
　引用発明は，「エンド・ユーザ」の信用証明書を使用することや，「ホスト型プロキシ・サーバ」による「アップロード・トークン」と「第１のメディア・ファイル」両方の受信及び応答については特定されていない点。
　
（相違点３）
　ホスト型プロキシ・サーバから情報をデータ処理装置へ送信することを，信用証明書を使用して承認するべく構成された有効化メッセージをホスト型サービス・サーバからホスト型プロキシ・サーバへ送信することに関し，
　本願発明１は，ホスト型プロキシ・サーバから「第１のメディア・ファイルをメディア共有サイト」へ送信することを，「ホスト型サービス・サーバ」の信用証明書を使用して承認するべく構成された有効化メッセージを送信するのに対して，
　引用発明は，「第１のメディア・ファイルをメディア共有サイト」へ送信することに係る承認であることや，「ホスト型サービス・サーバ」の信用証明書を使用することについては特定されていない点。
　
（相違点４）
　本願発明１は，「前記ホスト型サービス・サーバから前記有効化メッセージを受信したことに応答して，前記ホスト型プロキシ・サーバによって，前記第１のメディア・ファイルと前記ホスト型サービス・サーバの前記信用証明書とが前記メディア共有サイトへ送信されること」を有するのに対して，
　引用発明は，そのような構成を有しない点。
　
（２）相違点についての判断
　事案に鑑みて，上記相違点３について先に検討する。
　
　上記相違点３に係る構成である，有効化メッセージが，ホスト型プロキシ・サーバから「第１のメディア・ファイルをメディア共有サイト」へ送信することを，「ホスト型サービス・サーバ」の信用証明書を使用して承認するべく構成されている，との点については，引用文献２ないし４には記載されておらず，また，本願優先日前において周知技術であるともいえない。
　そうすると，引用発明に基づいて，相違点３に係る本願発明１の構成とすることは，当業者が容易になし得ることであるとはいえない。
　
　したがって，本願発明１は，相違点１，２，４を検討するまでもなく，当業者であっても引用発明，引用文献２ないし４に記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。
　
２．本願発明２−７について
　本願発明２ないし７は，本願発明１を更に限定したものであるので，本願発明１と同様の理由により，引用発明，引用文献２ないし４に記載された技術的事項，及び，周知技術に基づいて容易に発明できたものであるとはいえない。
　
　
第７　原査定についての判断
　
１．特許法第２９条第２項について
　
　原査定は，請求項１−３，５−１６について上記引用文献１ないし４に基づいて，当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができないというものである。しかしながら，令和１年１１月１９日付けの誤訳訂正により訂正された請求項１ないし７は，それぞれ相違点３に係る構成を有するものとなっており，
　上記第６のとおり，本願発明１ないし７は，上記引用発明，引用文献２ないし４に記載された技術的事項に基づいて，当業者が容易に発明できたものではない。したがって，原査定を維持することはできない。
　
２．特許法第３６条第６項第２号及び第４項第１号について
　原査定は，本明細書の段落［０１７８］冒頭の「有効化メッセージの受信前，受信の間，または受信後のいずれかにおいてメディア・ファイルに対する分析（中略）を行ない得る。」との記載から，分析主体が「ホスト型サービス・サーバ」を含むとは認められないから，請求項４に係る発明のうち，「ホスト型サービス・サーバ」に関する事項の内容を特定できず，詳細な説明の記載は，当該事項を当業者が実施可能な程度に記載されているとは認められない，というものである。しかしながら，令和１年１１月１９日付けの誤訳訂正において，段落【０１７７】を「特定の実装によれば、有効化メッセージを、有効化呼び出しに応答して送信できる（プロセス４３２０参照）。
有効化メッセージは、ホスト型サービス・サーバ４３０６および／またはホスト型サービス・サーバ４３０６に関連付けられたサービスの信用証明書を使用して、メディア・ファイルをメディア共有サイトへ送信することを承認するように構成され得る。
　
第８　当審拒絶理由について
　
１．特許法第３６条第６項第２号について
　
　当審拒絶理由通知では，請求項１の「前記ホスト型サービス・サーバの信用証明書を使用して，前記ホスト型プロキシ・サーバからメディア共有サイトへの前記第１のメディア・ファイルの送信を承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信すること」における「前記ホスト型サービス・サーバの信用証明書を使用して」との記載は，後続する「送信」，「承認」，「構成」のいずれに係るのか不明確であり，また，「メディア共有サイト」に送信する「メディア・ファイル」の“内容”について何ら記載しておらず，「メディア共有サイト」のための「方法」が，具体的にどのように機能するものであるのか，全体として不明確であるとの拒絶の理由を通知しているが，令和１年１１月１９日付けの誤訳訂正において，「前記ホスト型プロキシ・サーバから前記第１のメディア・ファイルをメディア共有サイトへ送信することを、前記ホスト型サービス・サーバの信用証明書を使用して承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信すること」，及び，「アスリートによって行われる身体的活動に関する電子情報を含む第１のメディア・ファイル」と訂正された結果，この拒絶の理由は解消した。請求項２ないし７についても同様である。
２．特許法第３６条第４項第１号について
　当審拒絶理由通知では，上記１．で引用する請求項１の「前記ホスト型サービス・サーバの信用証明書を使用して，前記ホスト型プロキシ・サーバからメディア共有サイトへの前記第１のメディア・ファイルの送信を承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信すること」との記載に関連し，本願明細書の発明の詳細な説明の段落【０１７７】の記載は，「ホスト型サービス・サーバ４３０６に関連付けされたサービスの信用証明書を使用して」，何を行うのかが不明確であり，当業者が実施可能な程度に記載されているとは認められないとの拒絶の理由を通知しているが，段落【０１７７】を「特定の実装によれば、有効化メッセージを、有効化呼び出しに応答して送信できる（プロセス４３２０参照）。
有効化メッセージは、ホスト型サービス・サーバ４３０６および／またはホスト型サービス・サーバ４３０６に関連付けられたサービスの信用証明書を使用して、メディア・ファイルをメディア共有サイトへ送信することを承認するように構成され得る。
　
３．特許法第２９条第２項について
　上記第６の１．（２）で検討のとおり，令和１年１１月１９日付けの誤訳訂正により，本願請求項１に係る発明は，相違点３に係る構成を有することとなり，そして，引用発明に基づいて，相違点３に係る本願請求項１に係る発明の構成とすることは，当業者が容易になし得ることであるとはいえないから，この拒絶の理由は解消した。本願請求項２ないし７に係る発明についても同様である。
　
　
第９　むすび
　
　以上のとおり，本願発明１ないし７は，当業者が引用発明に基づいて容易に発明することができたものではない。
　したがって，原査定の拒絶理由を検討してもその理由によって拒絶すべきものとすることはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。