• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F
審判 査定不服 2項進歩性 取り消して特許、登録 G06F
審判 査定不服 特36条4項詳細な説明の記載不備 取り消して特許、登録 G06F
管理番号 1358327
審判番号 不服2018-9130  
総通号数 242 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2020-02-28 
種別 拒絶査定不服の審決 
審判請求日 2018-07-03 
確定日 2020-01-21 
事件の表示 特願2016-540428「身体的活動の取り込み済み画像データを用いたセッションの実施およびトークン検証可能なプロキシ・アップローダを使用するアップロード」拒絶査定不服審判事件〔平成27年 3月12日国際公開、WO2015/035197、平成28年12月 8日国内公表、特表2016-538655、請求項の数(7)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯

本願は,2014年9月5日(パリ条約による優先権主張2013年9月5日(以下,「優先日」という。),米国)を国際出願日とする出願であって,平成28年3月2日付けで特許法第184条の5第1項の規定による書面が提出され,平成28年4月27日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る。)の日本語による翻訳文が提出され,平成29年6月9日付けで拒絶理由通知がされ,平成29年9月20日に意見書が提出されるとともに手続補正がされ,平成30年2月28日付けで拒絶査定(原査定)がされ,これに対し,平成30年7月3日に拒絶査定不服審判の請求がされると同時に手続補正がされ,令和1年6月3日付けで当審より拒絶理由通知(以下,「当審拒絶理由通知」という。)がされ,令和1年11月19日に意見書が提出されるとともに誤訳訂正がされたものである。


第2 原査定の概要

原査定(平成30年2月28日付け拒絶査定)の概要は次のとおりである。

(1)(進歩性)本願請求項1-3,5-16に係る発明は,以下の引用文献1ないし4に基づいて,当業者が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができない。

(2)(明確性及び実施可能要件)この出願は,特許請求の範囲の請求項4の記載及び発明の詳細な説明の記載が,特許法第36条第4項第1号及び第6項第2号に規定する要件を満たしていない。

＜引用文献等一覧＞

1.米国特許出願公開第2011/0202988号明細書
2.特開2012-173801号公報
3.特開2006-119769号公報
4.特開2008-009607号公報


第3 当審拒絶理由の概要

当審拒絶理由通知における拒絶理由の概要は次のとおりである。

1.(明確性)この出願は,特許請求の範囲の記載が,特許法第36条第6項第2号に規定する要件を満たしていない。

2.(実施可能要件)この出願は,発明の詳細な説明の記載が,特許法第36条第4項第1号に規定する要件を満たしていない。

3.(進歩性)この出願の請求項1-7に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。

＜引用文献等一覧＞

1.米国特許出願公開第2011/0202988号明細書
2.特開2012-173801号公報
3.特開2006-119769号公報
4.特開2008-009607号公報


第4 本願発明

本願請求項1ないし7に係る発明(以下,それぞれ「本願発明1」ないし「本願発明7」という。)は,令和1年11月19日付けの誤訳訂正で訂正された特許請求の範囲の請求項1ないし7に記載された事項により特定される発明であり,以下のとおりの発明である。

「 【請求項1】
コンピュータに実装される方法であって、
ホスト型サービス・サーバにおいて、エンド・ユーザ通信デバイスから送信された、ホスト型プロキシ・サーバへのアスリートによって行われる身体的活動に関する電子情報を含む第1のメディア・ファイルの送信を承認するべく構成された前記ホスト型サービス・サーバからのアップロード・トークンを要求するトークン要求を受信することと、
前記ホスト型サービス・サーバに対するエンド・ユーザ信用証明書を使用する前記エンド・ユーザ通信デバイスのユーザの有効化に応答して前記エンド・ユーザ通信デバイスへ前記アップロード・トークンが送信され、さらに、前記ホスト型プロキシ・サーバによって、前記アップロード・トークンと前記第1のメディア・ファイルが受信され、前記アップロード・トークンと前記第1のメディア・ファイルが受信されたことに応答して、前記ホスト型プロキシ・サーバによって、前記トークン有効化呼び出しを前記ホスト型サービス・サーバへ送信することと、
前記ホスト型サービス・サーバにおいて、前記ホスト型プロキシ・サーバから前記トークン有効化呼び出しを受信することと、
前記ホスト型プロキシ・サーバから前記第1のメディア・ファイルをメディア共有サイトへ送信することを、前記ホスト型サービス・サーバの信用証明書を使用して承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信することと、
前記ホスト型サービス・サーバから前記有効化メッセージを受信したことに応答して、前記ホスト型プロキシ・サーバによって、前記第1のメディア・ファイルと前記ホスト型サービス・サーバの前記信用証明書とが前記メディア共有サイトへ送信されることと、
を含むコンピュータに実装される方法。
【請求項2】
前記エンド・ユーザ通信デバイスの前記ユーザの前記有効化は、前記エンド・ユーザ通信デバイスが信用証明書を前記メディア共有サイトへ提供することなく実施され、前記エンド・ユーザ通信デバイスは、前記有効化の一部として前記メディア共有サイト固有の信用証明書を送信しない、請求項1に記載のコンピュータに実装される方法。
【請求項3】
前記ホスト型プロキシ・サーバからの前記トークン有効化呼び出しは、前記ホスト型プロキシ・サーバの前記アップロード・トークンと、(1)前記エンド・ユーザ通信デバイスからの前記第1のメディア・ファイル、または(2)前記ホスト型プロキシ・サーバへの、前記第1のメディア・ファイルをアップロードするための前記エンド・ユーザ通信デバイスからの要求の何れかと、を受信することに応答して、前記ホスト型サービス・サーバへ送信される、請求項1に記載のコンピュータに実装される方法。
【請求項4】
前記第1のメディア・ファイルは、複数の順次画像を含み、前記方法は、さらに、
前記ホスト型プロキシ・サーバにおいて、前記複数の順次画像の少なくとも一部に対して画像解析を行ない、前記第1のメディア・ファイルのためのタグを決定する、
請求項1に記載のコンピュータに実装される方法。
【請求項5】
さらに、
前記ホスト型サービス・サーバにおいて、前記メディア共有サイト上の前記第1のメディア・ファイルの場所を表わす一意的な識別を受信すること、
を含む、請求項1に記載のコンピュータに実装される方法。
【請求項6】
さらに、
前記エンド・ユーザ通信デバイスにおいて、前記メディア共有サイト上の前記第1のメディア・ファイルの場所を表わす一意的な識別を受信すること、
を含む、請求項1に記載のコンピュータに実装される方法。
【請求項7】
前記エンド・ユーザ通信デバイスは、第1のエンド・ユーザ通信デバイスであり、前記方法は、さらに、
前記第1のメディア・ファイルまたはそれの一部を前記ホスト型プロキシ・サーバ上にストアすることを含み、前記ホスト型プロキシ・サーバおよび前記メディア共有サイトにストアされる前記第1のメディア・ファイルは、前記第1のエンド・ユーザ通信デバイスによって検索可能であり、前記ホスト型プロキシ・サーバ上にストアされる前記第1のメディア・ファイルは、第2のエンド・ユーザ通信デバイスによって検索可能でない、
請求項1に記載のコンピュータに実装される方法。」


第5 引用文献,引用発明等

1.引用文献1について

原査定の拒絶の理由に引用され,当審拒絶理由通知にも引用された引用文献1(米国特許出願公開第2011/0202988号明細書)には,図面とともに次の事項が記載されている。(下線は当審により付与。以下同様。)

A 「[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] 第2認証コンテキストが有効であると判定された場合,ステップ405で,サービスセッションを介してデータ検索が開始される。ステップ405は,図4bにおいてより詳細に説明される,一実施形態による。一例では,サーバがサーバ認証コンテキスト(第1認証コンテキスト)に基づいてデータを検索するために図4Bの方法410は,図4Aのプロセス400のステップ405として実装することができる。例えば,クライアント・アプリケーション111から受信された第2認証コンテキストが有効であると判定された場合,ステップ411において,アプリケーションサーバ(アプリケーションサーバ107aのような)で開始される。この接続は,少なくとも部分的に,第1認証コンテキスト(例えば,認証サーバ105により実装されたサーバのサーバ認証コンテキスト)に基づいている。ステップ413において,第1認証コンテキスト(例えば,認証サーバ105によって実装されたサーバのサーバ認証コンテキスト)が有効である場合に,要求されたデータがアプリケーションサーバ107から検索される。ステップ415では,検索されたデータは,例えば,少なくとも部分的に,第2認証コンテキスト(例えば,ユーザ端末103とプロキシ・サーバ101との間で確立されたクライアント?サーバ認証コンテキスト)に基づいてデータを要求したクライアント・アプリケーション111に送信される。一実施形態では,返されるデータは,ウェブページ,マルチメディアデータ(ビデオ,音楽ファイル,画像など)などとすることができる。」)

B 「[0048] FIG.5 is a time sequence diagram that illustrates a sequence of messages and processes for providing separation of authentication contexts for client-server and server-server communication, according to one embodiment. A network process is represented by vertical line. A message passed from one process to another is represented by horizontal arrows. A step performed by a process is indicated by the text. The processes represented in FIG. 5 are the client application 111 (of the UE 103), the proxy server 101, the authentication server 105, and the application server 107. The example of FIG. 5 discusses the process 500 for providing separation of authentication contexts for client-server and server-server communication.
[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. In one example, the credentials can include username, password, one time password, consumer key, secret key, biometrics, 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. In one embodiment, if the authentication context of the client application 111 has not been verified/validated by the proxy server 101 (for example, the first authentication context that the client application 111 received before was expired and the client application 111 has received a new first authentication context), 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] 図5は,クライアント-サーバ及びサーバ-サーバの通信のための認証コンテキストの分離を提供するためのメッセージと手順の一実施形態を説明するためのシーケンス図である。ネットワークプロセスは,垂直線によって表される。あるプロセスから別のプロセスに送られるメッセージは,水平矢印によって表されている。プロセスによって実行されるステップは,テキストで示されている。図5に示す処理は,クライアント・アプリケーション111(103),プロキシ・サーバ101,認証サーバ105,アプリケーションサーバ107が設けられている。図5の例は,クライアント-サーバ及びサーバ-サーバの通信のための認証コンテキストの分離を提供するためのプロセス500を説明する。
[0049] 501では,クライアント・アプリケーション111(103)は,認証サーバ105に対して認証を行う。一実施形態では,クライアント・アプリケーション111から認証サーバ105に渡されるメッセージ501は,クライアント・アプリケーション111の認証,端末103の利用者等を含むことができる。一実施例では,証明書は,ユーザ名,パスワード,ワンタイムパスワード,すなわち,消費者鍵,秘密鍵,バイオメトリクスなどを含むことができる。認証サーバ105は,クライアント・アプリケーション111(503)から受信した信用証明書の妥当性を検査し,生成/検索し,第1認証コンテキスト(トークンまたはクッキーなど)をクライアント・アプリケーション111に送信する(505)。
[0050] 507において,クライアント・アプリケーション111は,サービス・セッションを開始するための要求をプロキシ・サーバ101に接触する。一実施形態では,クライアント・アプリケーション111の認証コンテキストは,プロキシ・サーバ101によって検証/確認されていない(例えば,クライアント・アプリケーション111が以前に受信した第1認証コンテキストは期限が切れ,クライアント・アプリケーション111は,新たな第1認証コンテキストを受信する)が,サービスセッション開始要求507が第1認証コンテキスト(トークンおよび/または認証サーバ105で生成/検索されたクッキーなど)を含むことができる。
[0051] 次に,プロキシ・サーバ101は,確認/受信された第1認証コンテキストを検証する。一実施形態では,プロキシ・サーバ101は,認証サーバ105への認証要求の送信を生成して開始することで第1認証コンテキスト(509)の有効性を検証する。認証サーバ105は,第1認証コンテキストを(511において)検証し,プロキシ・サーバ101に検証応答を送る(513)。515で,クライアント・アプリケーション111から受信された実装情報に依存して,プロキシ・サーバ101では認証の目的の認証プロトコルを決定し,クライアント・アプリケーション111を用いて第2認証コンテキストをインプリメントする。したがって,1つの実施形態によれば,クライアント・アプリケーション111とプロキシ・サーバ101との間の通信は,少なくとも部分的に,第2認証コンテキストに基づくことができる。
[0052] 一例によれば,クライアント・アプリケーション111の第1認証コンテキストは,プロキシ・サーバ101によって検証され,検証されると,第2認証コンテキストが実行された後,クライアント・アプリケーション111は,データを検索する要求をプロキシ・サーバ101に接触する(517において)。要求517は,クライアント・アプリケーション111とプロキシ・サーバ101との間で実施される第2認証コンテキストに基づくことが可能であり,アプリケーションサーバ107に関する情報を含むことができる。519で,プロキシ・サーバ101は,第2認証コンテキストを検証し,認証コンテキストが有効である場合,プロキシ・サーバ101は,アプリケーションサーバ107(521)との通信を開始することができる。
[0053] 一実施形態によれば,プロキシ・サーバ101は,アプリケーションサーバ107にデータ検索要求を制御することができる。例えば,プロキシ・サーバ101は,クライアント・アプリケーション111から要求517を受信すると,プロキシ・サーバ101は,要求517が意図されているアプリケーションサーバ107を決定することができる。さらに,プロキシ・サーバ101は,アプリケーションサーバ107のデータトラフィックの量を決定することができる。プロキシ・サーバ101は,たとえば,アプリケーション・サーバ107のデータ・トラフィックが所定の閾値以上であると判定した場合には,プロキシ・サーバ101は,要求されたデータへのアクセスなど,要求517を阻止すること,後の時間(要求517のサービスの品質の尺度によって許可される場合)の要求を遅延させること,他のアプリケーションサーバにリクエスト517を再ルーティングするなどのアクションをとることができる。なお,アプリケーションサーバの負荷を決定するための任意の他の基準も,実施することができることが企図される。
[0054] 521で,プロキシ・サーバ101は,アプリケーションサーバ107と通信するクライアント・アプリケーションによって要求されたデータの検索を要求する。一実施形態では,通信521は,第1認証コンテキストに基づいている。ステップ523において,アプリケーションサーバ107は,要求されたデータをプロキシ・サーバ101に取り出しおよび送信する。525において,検索されたデータは,プロキシ・サーバ101からクライアント・アプリケーション111に伝送される。
[0055] プロセス500は,クライアント-サーバおよびサーバ-サーバ通信に用いられる認証及び/又は認証プロトコルは有利には分離されることを示している。例えば,クライアント・アプリケーション111とプロキシ・サーバ101との間の通信は,第2認証コンテキストに基づいて実施することが可能であり,プロキシ・サーバ101およびアプリケーションサーバ107との間の通信は,第1認証コンテキストとに基づいて実施することができる。従って,クライアント-サーバ及びサーバ-サーバの通信の両方のために同一の認証スキームを実装する必要性をなくすことができる。」)

上記A及びBの記載から,上記引用文献1には次の発明(以下,「引用発明」という。)が記載されていると認められる。

「クライアント-サーバ及びサーバ-サーバの通信のための認証コンテキストの分離を提供するための方法であって,
クライアント・アプリケーションは,認証サーバに対して認証を行い,クライアント・アプリケーションから認証サーバに渡されるメッセージは,クライアント・アプリケーションの認証,端末の利用者等を含むことができ,認証サーバは,クライアント・アプリケーションから受信した信用証明書の妥当性を検査し,生成/検索し,第1認証コンテキスト(トークンまたはクッキーなど)をクライアント・アプリケーションに送信し,
クライアント・アプリケーションは,サービス・セッションを開始するための要求をプロキシ・サーバに接触し,サービスセッション開始要求が第1認証コンテキスト(トークンおよび/または認証サーバで生成/検索されたクッキーなど)を含むことができ,
プロキシ・サーバは,認証サーバへの認証要求の送信を生成して開始することで第1認証コンテキストの有効性を検証し,認証サーバは,第1認証コンテキストを検証し,プロキシ・サーバに検証応答を送り,
クライアント・アプリケーションから受信された実装情報に依存して,プロキシ・サーバでは認証の目的の認証プロトコルを決定し,クライアント・アプリケーションを用いて第2認証コンテキストをインプリメントし,したがって,クライアント・アプリケーションとプロキシ・サーバとの間の通信は,少なくとも部分的に,第2認証コンテキストに基づくことができ,
クライアント・アプリケーションの第1認証コンテキストは,プロキシ・サーバによって検証されると,第2認証コンテキストが実行された後,クライアント・アプリケーションは,データを検索する要求をプロキシ・サーバに接触し,これは,クライアント・アプリケーションとプロキシ・サーバとの間で実施される第2認証コンテキストに基づくことが可能であり,アプリケーションサーバに関する情報を含むことができ,プロキシ・サーバは,第2認証コンテキストを検証し,第2認証コンテキストが有効である場合,プロキシ・サーバは,アプリケーションサーバとの通信を開始することができ,
プロキシ・サーバは,アプリケーションサーバと通信するクライアント・アプリケーションによって要求されたデータの検索を要求し,この通信は,第1認証コンテキストに基づいており,アプリケーションサーバは,要求されたデータをプロキシ・サーバに取り出しおよび送信し,検索されたデータは,プロキシ・サーバからクライアント・アプリケーションに伝送される,
方法。」

2 引用文献2について

原査定の拒絶の理由に引用文献2として引用された特開2012-173801号公報には,図面とともに次の事項が記載されている。

C 「【0002】
現在、インターネット上のコンテンツ共有サービスやコミュニケーションサービス等の外部サービスにアクセスする機能を備えた携帯電話やデジタルカメラが存在する。ユーザは、これらの通信装置を用いることにより、撮像したコンテンツを外部サービスにアップロードしたり、メッセージを友人に送信することができる。
【0003】
一方、通信装置が外部サービスに直接アクセスするのではなく、中継装置を経由してアクセスするシステムが知られている(特許文献1参照)。これにより、外部サービス間の機能やデータ形式に関する差異や、外部サービスの追加や変更に伴う更新を中継装置によって吸収することができ、通信装置への影響を防ぐことができる。
【0004】
しかし、上述したシステムでは、通信装置が外部サービスにコンテンツをアップロードする場合も中継装置を経由するため、中継装置の処理負荷及び通信負荷が増大してしまうことがあった。そのため、通信装置が外部サービスにコンテンツをアップロードする際、外部サービスに直接アップロードすることが可能であるか否かを判断し、可能である場合、外部サービスに直接アップロードを行う方法が知られている(特許文献2参照)。
【0005】
特許文献2に開示される技術では、通信装置は、外部サービスに直接アップロードすることが可能であると判断した場合、直接アップロードを要求する要求メッセージを作成するために必要な情報(以下、必要情報と称す)を中継装置に要求する。このとき、通信装置は、アップロードの対象となる各コンテンツに関するファイル名やファイルサイズ等のパラメタデータを中継装置に送信する。中継装置は、通信装置から受信したパラメタデータと、中継装置が管理する外部サービスに対する認証トークン情報とに基づいて必要情報を作成し、通信装置に返送する。通信装置は、中継装置から受信した必要情報に基づいて要求メッセージを作成し、外部サービスにコンテンツを直接アップロードする。」

3 引用文献3について

原査定の拒絶の理由に引用文献3として引用された特開2006-119769号公報には,図面とともに次の事項が記載されている。

D 「【0080】
このように、本実施の形態では、認証サーバ2で各ユーザが属するグループのグループIDを記憶するユーザグループ情報24Bを記憶しておき、正当性が確認されたクライアントシステム1からの接続要求に応じて認証サーバ2でユーザグループ情報24Bから取得した当該ユーザのグループIDを含む接続確認要求をコンテンツ提供サーバ3へ送信し、正当性が確認された認証サーバ2からの接続確認要求に応じてコンテンツ提供サーバ3からその接続確認要求のグループIDで閲覧可能なコンテンツ情報を認証サーバ2経由でクライアントシステム1へ通知するようにしたものである。
したがって、認証サーバ2でのグループ管理によりコンテンツ提供サーバ3に対するユーザからの匿名アクセスを実現しつつ、正当性が確認された認証サーバ2からしか接続確認要求を受け付けないようにしたので、正当なユーザに対してのみコンテンツ情報を提供できる。」

4 引用文献4について

原査定の拒絶の理由に引用文献4として引用された特開2008-009607号公報には,図面とともに次の事項が記載されている。

E 「【0054】
次に、図5を用いて、図1および図2に示す情報処理システムにおける処理の流れについて説明する。なお、ここでは、クライアント端末10にC-SSO12が既にインストールされている状態からの処理の流れについて説明する。
【0055】
まず、ユーザがクライアント端末10からWebブラウザ11を用いてサービス提供サーバ40へのアクセスを試みると(ステップS201)、C-SSO12は、リクエスト取得部62において、このリクエストを横取りする。この時点でC-SSO12へのログインが済んでいなければ、ユーザ認証部61は、ポップアップを表示するなどして、ユーザにC-SSO12へのログインを要求する(ステップS202)。
【0056】
ユーザは、アカウント、パスワード等のユーザ認証情報を入力し(ステップS203)、ユーザ認証の実行を指示する。ここで、認証が成功すると(ステップS204)、C-SSO12へのログインが行われることになる。
【0057】
続いてC-SSO12は、サービス提供サーバ40への認証がまだ済んでいないことを検出すると、ユーザに代わって各サービス提供サーバ40へ認証代行を行う(ステップS205)。この認証は、C-SSO12の認証代行部64から、サービス提供サーバ40の認証部42へ認証代行情報64aが送られることで実行される。
【0058】
認証代行に成功すると(ステップS206)、これを受けたリクエスト取得部62は、ステップS201におけるWebブラウザ11からのリクエストを中継する(ステップS207)。このリクエストに対するサービス提供サーバ40からの応答があると(ステップS208)、C-SSO12のリクエスト取得部62がこれを中継して(ステップS209)、Webブラウザ11へ返す。これにより、Webブラウザ11の画面上には、ステップS201のリクエストに対応するHTMLコンテンツ等が表示されることになる(ステップS210)。」


第6 対比・判断

1.本願発明1について
(1)対比
本願発明1と引用発明とを対比する。

ア 引用発明における認証サービスを行う「認証サーバ」,「クライアント・アプリケーション」を有するデバイス,「プロキシ・サーバ」,「第1認証コンテキスト(トークンまたはクッキーなど)」は,それぞれ本願発明1における「ホスト型サービス・サーバ」,「エンド・ユーザ通信デバイス」,「ホスト型プロキシ・サーバ」,「トークン」に相当し,また,引用発明の「データを検索する要求」の送信と本願発明1の「第1のメディア・ファイル」の「送信」とは,“情報の送信”である点で共通する。
また,引用発明が,「クライアント・アプリケーション」から「アプリケーションサーバ」に対し「データの検索を要求」することは,情報の処理のリクエストを送信することともいえ,「認証サーバ」から渡される「第1認証コンテキスト(トークンまたはクッキーなど)」はその送信を承認するためのトークンといえ,当該「第1認証コンテキスト(トークンまたはクッキーなど)」を「クライアント・アプリケーション」から「認証サーバ」に要求しているといえるから,当該「認証サーバ」は,上記「クライアント・アプリケーション」から送信された,「データの検索」の「要求」を承認するための「第1認証コンテキスト(トークンまたはクッキーなど)」を要求するトークン要求を受信しているといえ,そうすると,本願発明1の「ホスト型サービス・サーバにおいて,エンド・ユーザ通信デバイスから送信された,ホスト型プロキシ・サーバへのアスリートによって行われる身体的活動に関する電子情報を含む第1のメディア・ファイルの送信を承認するべく構成された前記ホスト型サービス・サーバからのアップロード・トークンを要求するトークン要求を受信すること」と,引用発明の「認証サーバ」が「クライアント・アプリケーション」に「第1認証コンテキスト(トークンまたはクッキーなど)」を「送信」するために「第1認証コンテキスト(トークンまたはクッキーなど)」の要求を「認証サーバ」が「クライアント・アプリケーション」から受信することであり,当該「第1認証コンテキスト(トークンまたはクッキーなど)」が「クライアント・アプリケーション」から送信された「データの検索」の「要求」を承認するためのものであることとは,“ホスト型サービス・サーバにおいて,エンド・ユーザ通信デバイスから送信された,ホスト型プロキシ・サーバへの情報の送信を承認するべく構成された前記ホスト型サービス・サーバからのデータ処理のためのトークンを要求するトークン要求を受信すること”である点で共通するといえる。

イ 引用発明の「認証サーバ」は「クライアント・アプリケーションから受信した信用証明書の妥当性を検査」した上で,「第1認証コンテキスト(トークンまたはクッキーなど)をクライアント・アプリケーションに送信」しており,「クライアント・アプリケーションから受信した信用証明書」が「妥当」であるとはユーザが有効であることといえ,また,引用発明の「クライアント・アプリケーション」は,「サービス・セッションを開始するための要求をプロキシ・サーバに接触」するものであり,この場合の「サービス・セッションを開始するための要求」である「サービスセッション開始要求が」,「第1認証コンテキスト(トークンおよび/または認証サーバで生成/検索されたクッキーなど)を含む」ことから,要求を受ける「プロキシ・サーバ」は「第1認証コンテキスト」を受信することとなり,さらに引用発明の「プロキシ・サーバは,認証サーバへの認証要求の送信を生成して開始することで第1認証コンテキストの有効性を検証し」ているから,上記「認証サーバへの認証要求」は,「第1認証コンテキスト」(本願発明1の「トークン」に相当)の有効性があるか否かを「認証サーバ」(本願発明1の「ホスト型サービス・サーバ」に相当)に対して呼び出すものであって,本願発明1の「トークン有効化呼び出し」に相当する構成を含むといえる。
そうすると,本願発明1の「前記ホスト型サービス・サーバに対するエンド・ユーザ信用証明書を使用する前記エンド・ユーザ通信デバイスのユーザの有効化に応答して前記エンド・ユーザ通信デバイスへ前記アップロード・トークンが送信され,さらに,前記ホスト型プロキシ・サーバによって,前記アップロード・トークンと前記第1のメディア・ファイルが受信され,前記アップロード・トークンと前記第1のメディア・ファイルが受信されたことに応答して,前記ホスト型プロキシ・サーバによって,前記トークン有効化呼び出しを前記ホスト型サービス・サーバへ送信すること」と,引用発明の「認証サーバは,クライアント・アプリケーションから受信した信用証明書の妥当性を検査し,生成/検索し,第1認証コンテキスト(トークンまたはクッキーなど)をクライアント・アプリケーションに送信し」,「クライアント・アプリケーションは,サービス・セッションを開始するための要求をプロキシ・サーバに接触し,サービスセッション開始要求が第1認証コンテキスト(トークンおよび/または認証サーバで生成/検索されたクッキーなど)を含むことができ」,「プロキシ・サーバは,認証サーバへの認証要求の送信を生成して開始することで第1認証コンテキストの有効性を検証し,認証サーバは,第1認証コンテキストを検証」することとは,“前記ホスト型サービス・サーバに対する信用証明書を使用する前記エンド・ユーザ通信デバイスのユーザの有効化に応答して前記エンド・ユーザ通信デバイスへ前記トークンが送信され,さらに,前記ホスト型プロキシ・サーバによって,前記トークンが受信され,前記トークンが受信されたことに応答して,前記ホスト型プロキシ・サーバによって,前記トークン有効化呼び出しを前記ホスト型サービス・サーバへ送信すること”である点で共通するといえる。

ウ 上記イの検討から,引用発明の「認証サーバ」は「トークン有効化呼び出し」に相当する構成を含む「認証要求」を受信しているといえるから,本願発明1の「前記ホスト型サービス・サーバにおいて,前記ホスト型プロキシ・サーバから前記トークン有効化呼び出しを受信すること」と,引用発明の「認証サーバは,第1認証コンテキストを検証」するために受信することとは,“前記ホスト型サービス・サーバにおいて,前記ホスト型プロキシ・サーバから前記トークン有効化呼び出しを受信すること”である点で共通するといえる。

エ 引用発明において,「認証サーバは,第1認証コンテキストを検証し,プロキシ・サーバに検証応答を送」っており,当該「検証」のために何らかの信用に係る証明書を用いていることは明らかである。また,引用発明の「アプリケーションサーバ」は「要求されたデータをプロキシ・サーバに取り出しおよび送信」するものであるからデータ処理サーバであるといえ,本願発明1の「メディア共有サイト」とは,“データ処理装置”である点で共通し,さらに,引用発明の「認証サーバ」が「第1認証コンテキストを検証し,プロキシ・サーバ」に送信する「検証応答」は,第1認証コンテキストの有効性の検証結果であって「アプリケーションサーバ」への「データの検索」「要求」を承認するための「有効化メッセージ」といえるから,本願発明1の「前記ホスト型プロキシ・サーバから前記第1のメディア・ファイルをメディア共有サイトへ送信することを,前記ホスト型サービス・サーバの信用証明書を使用して承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信すること」と,引用発明の「認証サーバは,第1認証コンテキストを検証し,プロキシ・サーバに検証応答を送」ることであり,それにより「アプリケーションサーバ」への「データの検索」「要求」が行えるものであることとは,“前記ホスト型プロキシ・サーバから前記情報をデータ処理装置へ送信することを,信用証明書を使用して承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信すること”である点で共通するといえる。

オ 本願発明1と引用発明とは,“コンピュータに実装される方法”である点で一致するといえる。

カ 上記アないしオの検討から,本願発明1と引用発明との間には,次の一致点,相違点があるといえる。

(一致点)
「コンピュータに実装される方法であって,
ホスト型サービス・サーバにおいて,エンド・ユーザ通信デバイスから送信された,ホスト型プロキシ・サーバへの情報の送信を承認するべく構成された前記ホスト型サービス・サーバからのデータ処理のためのトークンを要求するトークン要求を受信することと,
前記ホスト型サービス・サーバに対する信用証明書を使用する前記エンド・ユーザ通信デバイスのユーザの有効化に応答して前記エンド・ユーザ通信デバイスへ前記トークンが送信され,さらに,前記ホスト型プロキシ・サーバによって,前記トークンが受信され,前記トークンが受信されたことに応答して,前記ホスト型プロキシ・サーバによって,前記トークン有効化呼び出しを前記ホスト型サービス・サーバへ送信することと,
前記ホスト型サービス・サーバにおいて,前記ホスト型プロキシ・サーバから前記トークン有効化呼び出しを受信することと,
前記ホスト型プロキシ・サーバから前記情報をデータ処理装置へ送信することを,信用証明書を使用して承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信することと,
を含むコンピュータに実装される方法。」

(相違点1)
ホスト型サービス・サーバにおいて,エンド・ユーザ通信デバイスから送信された,ホスト型プロキシ・サーバへの情報の送信を承認するべく構成された前記ホスト型サービス・サーバからのデータ処理のためのトークンを要求するトークン要求を受信することに関し,
本願発明1は,「アスリートによって行われる身体的活動に関する電子情報を含む第1のメディア・ファイル」の送信を承認するべく構成された前記ホスト型サービス・サーバからの「アップロード・トークン」を要求するトークン要求を受信するのに対して,
引用発明は,「第1認証コンテキスト(トークンまたはクッキーなど)」の要求の受信がそのようなものであるかは特定されていない点。

(相違点2)
ホスト型サービス・サーバに対する信用証明書を使用するエンド・ユーザ通信デバイスのユーザの有効化に応答してエンド・ユーザ通信デバイスへトークンが送信され,さらに,ホスト型プロキシ・サーバによって,トークンが受信され,トークンが受信されたことに応答して,ホスト型プロキシ・サーバによって,トークン有効化呼び出しをホスト型サービス・サーバへ送信することに関し,
本願発明1は,「エンド・ユーザ」の信用証明書を使用してトークンが送信され,ホスト型プロキシ・サーバによって「アップロード・トークン」と「第1のメディア・ファイル」が受信され,「アップロード・トークン」と「第1のメディア・ファイル」が受信されたことに応答して,前記ホスト型プロキシ・サーバによって,前記トークン有効化呼び出しを前記ホスト型サービス・サーバへ送信するのに対して,
引用発明は,「エンド・ユーザ」の信用証明書を使用することや,「ホスト型プロキシ・サーバ」による「アップロード・トークン」と「第1のメディア・ファイル」両方の受信及び応答については特定されていない点。

(相違点3)
ホスト型プロキシ・サーバから情報をデータ処理装置へ送信することを,信用証明書を使用して承認するべく構成された有効化メッセージをホスト型サービス・サーバからホスト型プロキシ・サーバへ送信することに関し,
本願発明1は,ホスト型プロキシ・サーバから「第1のメディア・ファイルをメディア共有サイト」へ送信することを,「ホスト型サービス・サーバ」の信用証明書を使用して承認するべく構成された有効化メッセージを送信するのに対して,
引用発明は,「第1のメディア・ファイルをメディア共有サイト」へ送信することに係る承認であることや,「ホスト型サービス・サーバ」の信用証明書を使用することについては特定されていない点。

(相違点4)
本願発明1は,「前記ホスト型サービス・サーバから前記有効化メッセージを受信したことに応答して,前記ホスト型プロキシ・サーバによって,前記第1のメディア・ファイルと前記ホスト型サービス・サーバの前記信用証明書とが前記メディア共有サイトへ送信されること」を有するのに対して,
引用発明は,そのような構成を有しない点。

(2)相違点についての判断
事案に鑑みて,上記相違点3について先に検討する。

上記相違点3に係る構成である,有効化メッセージが,ホスト型プロキシ・サーバから「第1のメディア・ファイルをメディア共有サイト」へ送信することを,「ホスト型サービス・サーバ」の信用証明書を使用して承認するべく構成されている,との点については,引用文献2ないし4には記載されておらず,また,本願優先日前において周知技術であるともいえない。
そうすると,引用発明に基づいて,相違点3に係る本願発明1の構成とすることは,当業者が容易になし得ることであるとはいえない。

したがって,本願発明1は,相違点1,2,4を検討するまでもなく,当業者であっても引用発明,引用文献2ないし4に記載された技術的事項,及び,周知技術に基づいて容易に発明できたものであるとはいえない。

2.本願発明2-7について

本願発明2ないし7は,本願発明1を更に限定したものであるので,本願発明1と同様の理由により,引用発明,引用文献2ないし4に記載された技術的事項,及び,周知技術に基づいて容易に発明できたものであるとはいえない。


第7 原査定についての判断

1.特許法第29条第2項について

原査定は,請求項1-3,5-16について上記引用文献1ないし4に基づいて,当業者が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができないというものである。しかしながら,令和1年11月19日付けの誤訳訂正により訂正された請求項1ないし7は,それぞれ相違点3に係る構成を有するものとなっており,
上記第6のとおり,本願発明1ないし7は,上記引用発明,引用文献2ないし4に記載された技術的事項に基づいて,当業者が容易に発明できたものではない。したがって,原査定を維持することはできない。

2.特許法第36条第6項第2号及び第4項第1号について

原査定は,本明細書の段落[0178]冒頭の「有効化メッセージの受信前,受信の間,または受信後のいずれかにおいてメディア・ファイルに対する分析(中略)を行ない得る。」との記載から,分析主体が「ホスト型サービス・サーバ」を含むとは認められないから,請求項4に係る発明のうち,「ホスト型サービス・サーバ」に関する事項の内容を特定できず,詳細な説明の記載は,当該事項を当業者が実施可能な程度に記載されているとは認められない,というものである。しかしながら,令和1年11月19日付けの誤訳訂正において,段落【0177】を「特定の実装によれば、有効化メッセージを、有効化呼び出しに応答して送信できる(プロセス4320参照)。有効化メッセージは、ホスト型サービス・サーバ4306および/またはホスト型サービス・サーバ4306に関連付けられたサービスの信用証明書を使用して、メディア・ファイルをメディア共有サイトへ送信することを承認するように構成され得る。別の実施態様においては、信用証明書が、エンド・ユーザ通信デバイス4304のユーザでない個人またはエンティティと関連付けできる。特定の実施態様においては、信用証明書がエンド・ユーザ・デバイス4304のユーザに未知であり、利用可能でない。有効化メッセージは、ホスト型サービス・サーバ4306からホスト型プロキシ・サーバ4308へのメディア・ファイルの転送またはコピーを承認できる(および/または、送信を開始できる)。」(下線は訂正箇所。)と訂正された結果,この拒絶の理由は解消した。


第8 当審拒絶理由について

1.特許法第36条第6項第2号について

当審拒絶理由通知では,請求項1の「前記ホスト型サービス・サーバの信用証明書を使用して,前記ホスト型プロキシ・サーバからメディア共有サイトへの前記第1のメディア・ファイルの送信を承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信すること」における「前記ホスト型サービス・サーバの信用証明書を使用して」との記載は,後続する「送信」,「承認」,「構成」のいずれに係るのか不明確であり,また,「メディア共有サイト」に送信する「メディア・ファイル」の“内容”について何ら記載しておらず,「メディア共有サイト」のための「方法」が,具体的にどのように機能するものであるのか,全体として不明確であるとの拒絶の理由を通知しているが,令和1年11月19日付けの誤訳訂正において,「前記ホスト型プロキシ・サーバから前記第1のメディア・ファイルをメディア共有サイトへ送信することを、前記ホスト型サービス・サーバの信用証明書を使用して承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信すること」,及び,「アスリートによって行われる身体的活動に関する電子情報を含む第1のメディア・ファイル」と訂正された結果,この拒絶の理由は解消した。請求項2ないし7についても同様である。

2.特許法第36条第4項第1号について

当審拒絶理由通知では,上記1.で引用する請求項1の「前記ホスト型サービス・サーバの信用証明書を使用して,前記ホスト型プロキシ・サーバからメディア共有サイトへの前記第1のメディア・ファイルの送信を承認するべく構成された有効化メッセージを前記ホスト型サービス・サーバから前記ホスト型プロキシ・サーバへ送信すること」との記載に関連し,本願明細書の発明の詳細な説明の段落【0177】の記載は,「ホスト型サービス・サーバ4306に関連付けされたサービスの信用証明書を使用して」,何を行うのかが不明確であり,当業者が実施可能な程度に記載されているとは認められないとの拒絶の理由を通知しているが,段落【0177】を「特定の実装によれば、有効化メッセージを、有効化呼び出しに応答して送信できる(プロセス4320参照)。有効化メッセージは、ホスト型サービス・サーバ4306および/またはホスト型サービス・サーバ4306に関連付けられたサービスの信用証明書を使用して、メディア・ファイルをメディア共有サイトへ送信することを承認するように構成され得る。別の実施態様においては、信用証明書が、エンド・ユーザ通信デバイス4304のユーザでない個人またはエンティティと関連付けできる。特定の実施態様においては、信用証明書がエンド・ユーザ・デバイス4304のユーザに未知であり、利用可能でない。有効化メッセージは、ホスト型サービス・サーバ4306からホスト型プロキシ・サーバ4308へのメディア・ファイルの転送またはコピーを承認できる(および/または、送信を開始できる)。」と訂正された結果,この拒絶の理由は解消した。請求項2ないし7に関しても同様である。

3.特許法第29条第2項について

上記第6の1.(2)で検討のとおり,令和1年11月19日付けの誤訳訂正により,本願請求項1に係る発明は,相違点3に係る構成を有することとなり,そして,引用発明に基づいて,相違点3に係る本願請求項1に係る発明の構成とすることは,当業者が容易になし得ることであるとはいえないから,この拒絶の理由は解消した。本願請求項2ないし7に係る発明についても同様である。


第9 むすび

以上のとおり,本願発明1ないし7は,当業者が引用発明に基づいて容易に発明することができたものではない。
したがって,原査定の拒絶理由を検討してもその理由によって拒絶すべきものとすることはできない。
また,他に本願を拒絶すべき理由を発見しない。
よって,結論のとおり審決する。
 
審決日 2020-01-09 
出願番号 特願2016-540428(P2016-540428)
審決分類 P 1 8・ 537- WY (G06F)
P 1 8・ 121- WY (G06F)
P 1 8・ 536- WY (G06F)
最終処分 成立  
前審関与審査官 脇岡 剛、圓道 浩史  
特許庁審判長 田中 秀人
特許庁審判官 仲間 晃
松平 英
発明の名称 身体的活動の取り込み済み画像データを用いたセッションの実施およびトークン検証可能なプロキシ・アップローダを使用するアップロード  
代理人 特許業務法人 信栄特許事務所  

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