Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Detailed Action
This office action is in response to the claims filed on January 27, 2025. Claims 1-20 are currently pending.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-19 of U.S. Patent No. 12,238,216. Although the claims at issue are not identical, they are not patentably distinct from each other because both sets of claims are substantially similar in their claimed approach to providing secure streaming across distributed platforms. These similarities are illustrated in the table below, comparing an independent claim of the present application against one from the patent.
Present Application
Claim 1
Patent 12,238,216
Claim 1
A computer-implemented method for secure stream distribution, the computer-implemented method comprising: receiving a first request for retrieving data from a client device at a first network node;
A computer-implemented method for secure stream distribution, the computer-implemented method comprising: receiving a first request from a client device at a first network node, wherein the first request comprises a first link for a particular stream of a streaming service that is accessed from a first domain associated with the first network node;
generating a first token, wherein generating the first token comprises encoding unique identifying information of the client device;
generating a first token in response to performing the first verification, wherein generating the first token comprises encoding unique identifying information of the client device and a signature as part of the first token;
providing, to the client device, the first token with a link associated with a second network node that manages the data; verifying, at the second network node, the first token that is provided with a second request from the client device;
providing the first token with a second link to the client device in response to the first request and performing the first verification, wherein the second link is directed to a second domain associated with a second network node that distributes the particular stream on behalf of the streaming service;
and providing access to the data for the client device via the second network node in response to verifying the first token.
and streaming the specific data from the second network node to the client device in response to performing a second verification of the client device at the second network node based on one or more requests for the specific data comprising the second token and the two or more identifiers encoded as part of the second token.
While the patented claim explicitly cites the access provided is to data streaming, the present application’s claims do not recite such a feature. However, the present application does state access is provided to data, upon verification. It is well known to those skilled in the art, before the effective filing date, that streaming content is a form of data access. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have provided a verified user access to streaming as an acceptable form of data access.
Claims 2-20 are similarly rejected as being substantially similar to patented claims 2-19.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kaplan et al (US PGPub No: 2016/0147544) in view of Grajek et al (US PGPub No: 2014/0082715), hereafter referred to as Kaplan and Grajek, respectively.
With regard to claims 1, 10, and 20, Kaplan teaches through Grajek, a computer-implemented method for secure stream distribution, the computer-implemented method comprising: receiving a first request for retrieving data from a client device at a first network node (Kaplan teaches an accessibility request for content from a client application within a computing device (i.e. client application + client device combined are equivalent to the claimed client device) to a content management system (CMS) (i.e. first network node); see paragraph 27 and Figure 3, Kaplan);
generating a first token, wherein generating the first token comprises encoding unique identifying information of the client device (Kaplan explains how the CMS generates a token encoded into a URL; see paragraph 27, Kaplan. The token is generated for the unique identifier of client application within the client device thereby enabling the CMS to determine the client device’s identity; see paragraph 28, Kaplan);
providing, to the client device, the first token with a link (Kaplan explains sending the URL+token to the client application within the client device; see paragraph 27 and Figure 3, Kaplan) associated with a second network node that manages the data (see below for the link being associated with a second network node);
verifying, at the second network node, the first token that is provided with a second request from the client device; and providing access to the data for the client device via the second network node in response to verifying the first token (see below).
While Kaplan teaches the use of tokens and URL links and a CMS/server, Kaplan does not explicitly cite a URL/link being associated with a second server/network node nor does Kaplan teach granting access to the second server/network node in response to verifying the first token. In the same field of endeavor, Grajek also teaches a network supporting the use of URLs and tokens; see paragraph 26 and 28, Grajek. In particular, Grajek explains how a user’s browser (within the user mobile device) can be directed to a URL of a web authentication server called an authentication appliance; see paragraph 26, Grajek. Once authenticated, the user’s mobile device (client device) is sent a token (i.e. first token); see paragraph 27, Grajek. When a second URL for a second app is accessed by the mobile device, the same token can be used (i.e. provide first token within a link associated with a second network node) for authentication (i.e. verifying, at the second network node, the first token that is provided with a second request from the client device; and providing access to the data for the client device via the second network node in response to verifying the first token); see paragraphs 7, and 34, Grajek.
By using the same token at two URLs/sites, a user need only authenticate once without additional intervention (see paragraph 28, Grajek), simplifying the user experience. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Grajek with those of Kaplan provide authentication with a simplified user experience.
With regard to claims 2 and 11, Kaplan teaches through Grajek, the computer-implemented method further comprising: performing a first verification of the client device at the first network node prior to generating the first token; and providing a second token and a link to the data from the second network node to the client device in response to the second request and determining that the first network node performed the first verification
Grajek teaches issuing a session token (second token) after issuance of the persistent token, the session token being affiliated with the persistent token; see paragraphs 57 and 70, Grajek. The session token can be used only for a current session (i.e. a second request, the first session being the initial request resulting in the authentication and generation of the initial persistent token).
By using the tokens, a user need only authenticate once without additional intervention (see paragraph 28, Grajek), simplifying the user experience. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Grajek with those of Kaplan provide authentication with a simplified user experience.
With regard to claims 3 and 12, Kaplan teaches through Grajek, the computer-implemented method wherein performing the first verification comprises: receiving a particular identifier that the client device uses to join a conference or webinar; obtaining an invitee list defined for the conference or webinar; and verifying the client device in response to the particular identifier matching an identifier in the invitee list
Grajek teaches determining, using an identity database (i.e. invitee list), if a user is a member of a specific authorized group (i.e. invitee of a conference) in an enterprise environment using tokens; see paragraph 66, Grajek. If they are authorized, the user is able to use the enterprise service server (i.e. allowed to join enterprise service such as a conference); see paragraph 66, Grajek.
By using the tokens, a user need only authenticate once without additional intervention (see paragraph 28, Grajek), simplifying the user experience. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Grajek with those of Kaplan provide authentication with a simplified user experience.
With regard to claims 4 and 13, Kaplan teaches through Grajek, the computer-implemented method wherein encoding the unique identifying information of the client device comprises: retrieving, at the first network node, a private key that is selected for said generating of the first token and that is stored on the first network node; and generating, at the first network node, a hash value of the unique identifying information of the client device using the private key
Grajek teaches a network supporting the use of URLs and tokens; see paragraph 26 and 28, Grajek. The use of tokens allows for an authenticated session and access to content. The system further utilizes hashing and private keys to enable the token-based access; see paragraphs 54, 65, and 125, Grajek.
By using the tokens, a user need only authenticate once without additional intervention (see paragraph 28, Grajek), simplifying the user experience. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Grajek with those of Kaplan provide authentication with a simplified user experience.
With regard to claims 5 and 14, Kaplan teaches through Grajek, the computer-implemented method wherein verifying the first token comprises: retrieving, at the second network node, a public key for the private key that was selected for said generating of the first token at the first network node; decoding, at the second network node, the unique identifying information of the client device from the first token using the public key; verifying a signature in the first token using the public key; and authenticating, at the second network node, the client device based on the unique identifying information that is decoded from the first token matching client identifying information in the second request and said verifying the signature
Grajek teaches a network supporting the use of URLs and tokens; see paragraph 26 and 28, Grajek. The use of tokens allows for an authenticated session and access to content. The system further utilizes hashing along with public and private keys to enable the token-based access; see paragraphs 54, 65, and 125, Grajek. Furthermore Grajek explains how signature are utilized in verification/validation of tokens; see paragraph 29, 47, 79, 86, and 89, Grajek.
By using the tokens, a user need only authenticate once without additional intervention (see paragraph 28, Grajek), simplifying the user experience. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Grajek with those of Kaplan provide authentication with a simplified user experience.
With regard to claims 6 and 15, Kaplan teaches through Grajek, the computer-implemented method further comprising: rejecting, at the second network node, a request from the client device that omits the first token or comprises a token that differs from the first token
Grajek teaches a network supporting the use of URLs and tokens; see paragraph 26 and 28, Grajek. The use of tokens allows for an authenticated session and access to content. The system further supports rejection of tokens for not being able to validate them, being old, or other reasons; see paragraph 97, Grajek.
By using the tokens, a user need only authenticate once without additional intervention (see paragraph 28, Grajek), simplifying the user experience. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Grajek with those of Kaplan provide authentication with a simplified user experience.
With regard to claims 7 and 16, Kaplan teaches through Grajek, the computer-implemented method further comprising: rejecting, at the first network node, a request from the client device that omits one or more credentials or contains credentials that do not match credentials that are stored for the client device at the first network node
Grajek teaches a network supporting the use of URLs and tokens; see paragraph 26 and 28, Grajek. The use of tokens allows for an authenticated session and access to content. If a token is not found or if identity information is not found to be usable (credential does not match), a repeat of authentication may need to be performed; see paragraph 60, Grajek.
By using the tokens, a user need only authenticate once without additional intervention (see paragraph 28, Grajek), simplifying the user experience. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Grajek with those of Kaplan provide authentication with a simplified user experience.
With regard to claims 8 and 18, Kaplan teaches through Grajek, the computer-implemented method wherein providing access to the data comprises: generating a second token at the second network node that encodes one or more links for accessing the data
Grajek teaches issuing a session token (second token) after issuance of the persistent token, the session token being affiliated with the persistent token; see paragraphs 57 and 70, Grajek. The session token can be used only for a current session.
By using the tokens, a user need only authenticate once without additional intervention (see paragraph 28, Grajek), simplifying the user experience. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Grajek with those of Kaplan provide authentication with a simplified user experience.
With regard to claims 9 and 19, Kaplan teaches through Grajek, the computer-implemented method further comprising: receiving a third request that is directed to a particular link and that includes the second token; and streaming the data to the client device in response to the particular link of the third request matching one of the one or more links encoded in the second token
Grajek teaches issuing a session token (second token) after issuance of the persistent token, the session token being affiliated with the persistent token; see paragraphs 57 and 70, Grajek. The session token can be used only for a current session (i.e. a third or another subsequent request). Once a token such as a session token (second token) is stored, various other website accesses (third and subsequent requests) can be performed without additional authentication; see paragraph 80, Grajek.
By using the tokens, a user need only authenticate once without additional intervention (see paragraph 28, Grajek), simplifying the user experience. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Grajek with those of Kaplan provide authentication with a simplified user experience.
With regards to claim 17, Kaplan teaches through Grajek, the secure streaming system wherein the one or more hardware processors of the second network node are further configured to: reject a fourth request from the client device that is directed to the specific data and that omits the second token or comprises a token that differs from the second token.
Grajek teaches a network supporting the use of URLs and tokens; see paragraph 26 and 28, Grajek. The use of tokens allows for an authenticated session and access to content. The system further supports rejection of tokens for not being able to validate them, being old, or other reasons; see paragraph 97, Grajek.
By using the tokens, a user need only authenticate once without additional intervention (see paragraph 28, Grajek), simplifying the user experience. Therefore, it would have been obvious to one skilled in the art, before the effective filing date, to have combined the teachings of Grajek with those of Kaplan provide authentication with a simplified user experience.
The obviousness motivation applied to independent claims 1, 10, and 20 are applicable to their respective dependent claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AZIZUL Q CHOUDHURY whose telephone number is (571)272-3909. The examiner can normally be reached M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, EMMANUEL MOISE can be reached at (571) 272-3865. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AZIZUL CHOUDHURY/Primary Examiner, Art Unit 2455
Prosecution Insights