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 is a first action on the merits regarding applicants RCE filed January 7, 2025.
Claims 2, 4-9, 11-16, 18-21 are presented for examination.
Response to Arguments
Applicant's arguments filed Applicant’s arguments filed 01/07/2025 have been fully considered but they are not persuasive. Applicants arguments are directed to claims as amended. The primary reference Koushik has been remapped to teach portions of the overall invention as amended and a new reference Bokare has been introduced in a 35 USC § 103 combination to teach the remainder of the limitations.
Claim interpretation
The term platform-independent access token does not appear to have an ordinary customary meaning in the art. Examiner turns to the specification for interpretation. Paragraph [0012] states A user may work across different platform when using multiple devices, when using multiple browsers on a single device, or when an integrated application requires a separate Sign On to be accessed within a host web application or portal service.
Claim Objections
Claims 8, 15 and 21 are objected to because of the following informality: a stray recitation of the limitation “the computing system” on line 3 of said claims. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 2, 4-9, 11-16, 18-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 8, 15 and 21 recites the limitation "second client device". The prior claims do not recite a “first client device” or “a client device” per se. In fact a prior version of claim 2 and 8 recited a “client device” which was to be authenticated using the computer system. The recitation of this limitation was removed by amendment. Appropriate correction is required.
Claim 8, 15 and 21 recite the “the computing system authenticating a second client device.” However, in the previous claims the computing device appears to be established as the client in and of itself. A client does not authenticate another client to a server instead the computing system in this claim appears to be acting as another intermediary or proxy for authentication to the server rather than as an end client. The content of this claim appears to be a holdover from before applicants amendment to overcome the 35 USC 112a rejection of the office action on 4/11/2024, where the claims treated the computing system as an intermediary for authentication of the user on separate client devices. Appropriate correction is required.
Claims 2, 8, 9, 15, 16 and 21 recite limitations referring to authentication of a device however, authentication is of a user not a device, see [0027] where “browser application 210” (computer system) “is redirected to request user authentication”, and elsewhere in the specification. Appropriate correction is required. Claims 4-7, 11-14 and 18-21 are similarly rejected due to their dependence on claim 2, 9, and 16 respectively.
Claims 6, 13 and 20 recite the limitation “and associated the access token with the account of the productivity application”. This is improper grammar that renders the claim indefinite. For the purposes of further examination the limitation is treated as “and the access token is associated with the account of the productivity application.” Claim 7-8, 14-15 and 21 are similarly rejected due to their dependency claims 6, 13 and 20 respectively.
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 2, 4-9, 11-16, 18-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Koushik et al. (US 2016/0134616 A1), herein referred to as Koushik, in view of Bokare et al. (US 2017/0195429 A1), herein referred to as Bokare.
Regarding claim 2 Koushik teaches,
A method for providing single sign-on access (Koushik [0159] “the systems descried herein may support a single sign-on model”) to a productivity application integrated within a cloud-based service, the method comprising:
receiving, by a proxy token service (application delivery agent 638), a request from a computing system (desktop application management module 648) providing access to the cloud-based service (Koushik [0166] “an end-user may launch the desktop application management module, which may display the login page hosted by an external identity service (e.g., a domain controller). The end user may provide their domain credentials to login there. As a result, the desktop application management module may receive an authorization code (e.g., one that conforms to the OAuth open source standard). The desktop application management module may then call the application delivery agent, providing the authorization code, in order to get a security token.”), the request having been transmitted in response to authenticating the computing system to access the cloud-based service, the request identifying an account of the productivity application (Koushik [0101]“an active directory identifier ticket (e.g., one provided by a domain controller) may be presented to the identity broker service specifying that a principal (user) X wants access to a particular application on machine Y that is connected to domain Z.”);
searching, by the proxy token service, a secure storage based on the account identified in the request to determine whether a valid access token exists for accessing the productivity application (Koushik [0166] “The application delivery agent may store the security token (and the refresh tokens) in protected local storage (e.g., encrypted storage) for further reference, e.g., so that the desktop application management module will be able to get it later without requiring the end user to login each time.”);
in response to determining that no valid access token exists in the secure storage for the identified account, redirecting, by the proxy token service, the computing system to a directory service of the productivity application (Koushik [0166] external identity service is contacted and a login page is provided every time a security token is not present as determined by application delivery agent) to provide authentication credentials associated with the account (Koushik [0166] login page),
wherein the proxy token service performs token validation (Koushik [0166] application delivery agent checks if it has a valid token available) and authentication redirection without acting as a gateway for all service request (Koushik [0166] User is redirected to login page and there is a receipt of an authorization code between an identity service and the desktop application service that does not go through the application delivery agent); and
in response to determining that the authentication credentials associated with the account were provided to the directory service (Koushik [0166] via login page leading to receipt of authentication code which is then given to delivery agent to exchange for a token), providing the computing system with a(n) … access token to access the productivity application (Koushik [0101] access token is for accessing application), the computing system using the access token to access the productivity application integrated within the cloud-based service (Koushik [0101] access tokens are used to access the application).
Koushik does not teach, however, Bokare teaches:
Wherein an access token is a platform-independent access token (Bokare [0038] – [0043] teaches providing access to a client 208 (second device) based on the access token that was provided to the associated device 202 (computing system);).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Koushik to utilize platform-independent access tokens as taught by Bokare in order to allow multiple user devices or instances to access applications.
Regarding claim 4, Koushik in view of Bokare teaches:
The method of claim 2, wherein determining that the authentication credentials associated with the account were provided to the directory service comprises: receiving an authorization code from the computing system (Koushik [0166] the desktop application management module provides the authorization code to the application delivery agent), the authorization code having been provided to the computing system by the directory service in response to the authentication credentials associated with the account being provided to the directory service (Koushik [0166] login page).
Regarding claim 5, Koushik in view of Bokare teaches:
The method of claim 4, wherein providing the computing system with the access token to access the productivity application comprises: transmitting the authorization code to the directory service to redeem the access token (Koushik [0166] The agent may then call the identity broker service of the application fulfillment platform, passing the authorization code, along with user and device information, and may get back the security token and, in some embodiments, multiple refresh tokens.); and receiving the access token from the directory service (see previous citation).
Regarding claim 6 Koushik in view of Bokare teaches:
The method of claim 5, further comprising: storing the access token in a secure storage and associated the access token with the account of the productivity application (Koushik [0166] “The application delivery agent may store the security token (and the refresh tokens) in protected local storage (e.g., encrypted storage) for further reference, e.g., so that the desktop application management module will be able to get it later without requiring the end user to login each time.” Examiner’s note: Access token is associated with the account of the productivity application in that it used for the user of the account to gain access to the productivity application).
Regarding claim 7, Koushik in view of Bokare teaches:
The method of claim 6, further comprising: receiving a subsequent request from the computing system providing access to the cloud- based service (Koushik [0166] future request requiring token may use a stored token), the subsequent request identifying the account of the productivity application (Koushik [0101]“an active directory identifier ticket (e.g., one provided by a domain controller) may be presented to the identity broker service specifying that a principal (user) X wants access to a particular application on machine Y that is connected to domain Z.” examiners note: the information about what app user wants to use must be collected in order to determine if a token exist for it already, if it is not then this step happens.); accessing the access token by searching the secure storage based on the account of the productivity application that is identified in the subsequent request; and providing the computing system with the access token to access the productivity application (Koushik [0166] application management module gets token from agent).
Regarding claim 8, Koushik in view of Bokare teaches:
The method of claim 7, wherein the subsequent request (Bokare [0032] initial request may be from associated device to sign-on module 104; further note per [0031] sign-on module may not be part of the web server and may instead be a part of associated device, for example (see fig. 4), subsequent request may be for another device to access) was transmitted in response to the computing system (Fig. 4 102 systems of computing modules 112) authenticating a second client device (Bokare Client device 208) to access the cloud-based service (Bokare user resources 102 in fig. 4 see [0049]; Koushik where a user resource is the application in the cloud based service) the computing system and the computing system uses the access token to provide the second client device with the productivity application integrated within the cloud-based service (Bokare [0038] – [0043] teaches providing access to a client 208 (second device) based on the access token that was provided to the associated device 202 (computing system);).
The same motivation to combine for claim 2 applies to claim 8.
Regarding claim 9, Koushik teaches:
A proxy token service (Koushik fig. 6 application delivery agent 638) for providing single sign-on access to a productivity application integrated within a cloud-based service, the proxy token service comprising: one or more computer processors (Koushik [0035] application resource agent may be installed on the computing resource instance 138 which may be a physical computing device. This would be as software which would run on the one or more processors of the computing resource instance (embodied as a physical computing device, see processor 1410a in fig. 14) ;
and one or more machine readable mediums storing instructions that, when executed by the one or more computer processors, cause the proxy token service to perform operations comprising (Koushik [0035] the instruction for the application delivery agent would be stored on memory of the computer resource instance (embodied as a physical computing device, see memory 1420 in fig. 14)):
receiving, by a proxy token service (application delivery agent 638), a request from a computing system (desktop application management module 648) providing access to the cloud-based service (Koushik [0166] “an end-user may launch the desktop application management module, which may display the login page hosted by an external identity service (e.g., a domain controller). The end user may provide their domain credentials to login there. As a result, the desktop application management module may receive an authorization code (e.g., one that conforms to the OAuth open source standard). The desktop application management module may then call the application delivery agent, providing the authorization code, in order to get a security token.”), the request having been transmitted in response to authenticating the computing system to access the cloud-based service, the request identifying an account of the productivity application (Koushik [0101]“an active directory identifier ticket (e.g., one provided by a domain controller) may be presented to the identity broker service specifying that a principal (user) X wants access to a particular application on machine Y that is connected to domain Z.”);
searching, by the proxy token service, a secure storage based on the account identified in the request to determine whether a valid access token exists for accessing the productivity application (Koushik [0166] “The application delivery agent may store the security token (and the refresh tokens) in protected local storage (e.g., encrypted storage) for further reference, e.g., so that the desktop application management module will be able to get it later without requiring the end user to login each time.”);
in response to determining that no valid access token exists in the secure storage for the identified account, redirecting, by the proxy token service, the computing system to a directory service of the productivity application (Koushik [0166] external identity service is contacted and a login page is provided every time a security token is not present as determined by application delivery agent) to provide authentication credentials associated with the account (Koushik [0166] login page),
wherein the proxy token service performs token validation (Koushik [0166] application delivery agent checks if it has a valid token available) and authentication redirection without acting as a gateway for all service request (Koushik [0166] User is redirected to login page and there is a receipt of an authorization code between an identity service and the desktop application service that does not go through the application delivery agent); and
in response to determining that the authentication credentials associated with the account were provided to the directory service (Koushik [0166] via login page leading to receipt of authentication code which is then given to delivery agent to exchange for a token), providing the computing system with a(n) … access token to access the productivity application (Koushik [0101] access token is for accessing application), the computing system using the access token to access the productivity application integrated within the cloud-based service (Koushik [0101] access tokens are used to access the application).
Koushik does not teach, however, Bokare teaches:
Wherein an access token is a platform-independent access token (Bokare [0038] – [0043] teaches providing access to a client 208 (second device) based on the access token that was provided to the associated device 202 (computing system);).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Koushik to utilize platform-independent access tokens as taught by Bokare in order to allow multiple user devices or instances to access applications.
Regarding claim 11, Koushik in view of Bokare teaches:
The proxy token service of claim 9, wherein determining that the authentication credentials associated with the account were provided to the directory service comprises: receiving an authorization code from the computing system (Koushik [0166] the desktop application management module provides the authorization code to the application delivery agent), the authorization code having been provided to the computing system by the directory service in response to the authentication credentials associated with the account being provided to the directory service (Koushik [0166] login page).
Regarding claim 12, Koushik in view of Bokare teaches:
The proxy token service of claim 11, wherein providing the computing system with the access token to access the productivity application comprises: transmitting the authorization code to the directory service to redeem the access token (Koushik [0166] The agent may then call the identity broker service of the application fulfillment platform, passing the authorization code, along with user and device information, and may get back the security token and, in some embodiments, multiple refresh tokens.); and receiving the access token from the directory service (see previous citation).
Regarding claim 13 Koushik in view of Bokare teaches:
The proxy token service of claim 12, further comprising: storing the access token in a secure storage and associated the access token with the account of the productivity application (Koushik [0166] “The application delivery agent may store the security token (and the refresh tokens) in protected local storage (e.g., encrypted storage) for further reference, e.g., so that the desktop application management module will be able to get it later without requiring the end user to login each time.” Examiner’s note: Access token is associated with the account of the productivity application in that it used for the user of the account to gain access to the productivity application).
Regarding claim 14, Koushik in view of Bokare teaches:
The proxy token service of claim 13, further comprising: receiving a subsequent request from the computing system providing access to the cloud- based service (Koushik [0166] future request requiring token may use a stored token), the subsequent request identifying the account of the productivity application (Koushik [0101]“an active directory identifier ticket (e.g., one provided by a domain controller) may be presented to the identity broker service specifying that a principal (user) X wants access to a particular application on machine Y that is connected to domain Z.” examiners note: the information about what app user wants to use must be collected in order to determine if a token exist for it already, if it is not then this step happens.); accessing the access token by searching the secure storage based on the account of the productivity application that is identified in the subsequent request; and providing the computing system with the access token to access the productivity application (Koushik [0166] application management module gets token from agent).
Regarding claim 15, Koushik in view of Bokare teaches:
The proxy token service of claim 14, wherein the subsequent request (Bokare [0032] initial request may be from associated device to sign-on module 104; further note per [0031] sign-on module may not be part of the web server and may instead be a part of associated device, for example (see fig. 4), subsequent request may be for another device to access) was transmitted in response to the computing system (Fig. 4 102 systems of computing modules 112) authenticating a second client device (Bokare Client device 208) to access the cloud-based service (Bokare user resources 102 in fig. 4 see [0049]; Koushik where a user resource is the application in the cloud based service) the computing system and the computing system uses the access token to provide the second client device with the productivity application integrated within the cloud-based service (Bokare [0038] – [0043] teaches providing access to a client 208 (second device) based on the access token that was provided to the associated device 202 (computing system);).
The same motivation to combine for claim 9 applies to claim 15.
Regarding claim 16, Koushik in view of Bokare teaches:
A machine readable medium storing instructions (Koushik fig. 14 memory 1420) for providing single sign-on access to a productivity application integrated within a cloud-based service, the instructions, when executed by one or more computer processors of a proxy token service (Koushik Fig. 6 application delivery agent 638), causing the proxy token service to perform operations (Koushik [0035] application resource agent may be installed on the computing resource instance 138 which may be a physical computing device. This would be as software which would run on the one or more processors of the computing resource instance (embodied as a physical computing device, see processor 1410a in fig. 14) using the instruction stored in memory 1420) comprising:
receiving, by a proxy token service (application delivery agent 638), a request from a computing system (desktop application management module 648) providing access to the cloud-based service (Koushik [0166] “an end-user may launch the desktop application management module, which may display the login page hosted by an external identity service (e.g., a domain controller). The end user may provide their domain credentials to login there. As a result, the desktop application management module may receive an authorization code (e.g., one that conforms to the OAuth open source standard). The desktop application management module may then call the application delivery agent, providing the authorization code, in order to get a security token.”), the request having been transmitted in response to authenticating the computing system to access the cloud-based service, the request identifying an account of the productivity application (Koushik [0101]“an active directory identifier ticket (e.g., one provided by a domain controller) may be presented to the identity broker service specifying that a principal (user) X wants access to a particular application on machine Y that is connected to domain Z.”);
searching, by the proxy token service, a secure storage based on the account identified in the request to determine whether a valid access token exists for accessing the productivity application (Koushik [0166] “The application delivery agent may store the security token (and the refresh tokens) in protected local storage (e.g., encrypted storage) for further reference, e.g., so that the desktop application management module will be able to get it later without requiring the end user to login each time.”);
in response to determining that no valid access token exists in the secure storage for the identified account, redirecting, by the proxy token service, the computing system to a directory service of the productivity application (Koushik [0166] external identity service is contacted and a login page is provided every time a security token is not present as determined by application delivery agent) to provide authentication credentials associated with the account (Koushik [0166] login page),
wherein the proxy token service performs token validation (Koushik [0166] application delivery agent checks if it has a valid token available) and authentication redirection without acting as a gateway for all service request (Koushik [0166] User is redirected to login page and there is a receipt of an authorization code between an identity service and the desktop application service that does not go through the application delivery agent); and
in response to determining that the authentication credentials associated with the account were provided to the directory service (Koushik [0166] via login page leading to receipt of authentication code which is then given to delivery agent to exchange for a token), providing the computing system with a(n) … access token to access the productivity application (Koushik [0101] access token is for accessing application), the computing system using the access token to access the productivity application integrated within the cloud-based service (Koushik [0101] access tokens are used to access the application).
Koushik does not teach, however, Bokare teaches:
Wherein an access token is a platform-independent access token (Bokare [0038] – [0043] teaches providing access to a client 208 (second device) based on the access token that was provided to the associated device 202 (computing system);).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Koushik to utilize platform-independent access tokens as taught by Bokare in order to allow multiple user devices or instances to access applications.
Regarding claim 18, Koushik in view of Bokare teaches:
The machine readable medium of claim 16, wherein determining that the authentication credentials associated with the account were provided to the directory service comprises: receiving an authorization code from the computing system (Koushik [0166] the desktop application management module provides the authorization code to the application delivery agent), the authorization code having been provided to the computing system by the directory service in response to the authentication credentials associated with the account being provided to the directory service (Koushik [0166] login page).
Regarding claim 19, Koushik in view of Bokare teaches:
The machine readable medium of claim 18, wherein providing the computing system with the access token to access the productivity application comprises: transmitting the authorization code to the directory service to redeem the access token (Koushik [0166] The agent may then call the identity broker service of the application fulfillment platform, passing the authorization code, along with user and device information, and may get back the security token and, in some embodiments, multiple refresh tokens.); and receiving the access token from the directory service (see previous citation).
Regarding claim 20, Koushik in view of Bokare teaches:
The proxy token service of claim 19, further comprising:
storing the access token in a secure storage and associated the access token with the account of the productivity application (Koushik [0166] “The application delivery agent may store the security token (and the refresh tokens) in protected local storage (e.g., encrypted storage) for further reference, e.g., so that the desktop application management module will be able to get it later without requiring the end user to login each time.” Examiner’s note: Access token is associated with the account of the productivity application in that it used for the user of the account to gain access to the productivity application). receiving a subsequent request from the computing system providing access to the cloud- based service (Koushik [0166] future request requiring token may use a stored token), the subsequent request identifying the account of the productivity application (Koushik [0101] “an active directory identifier ticket (e.g., one provided by a domain controller) may be presented to the identity broker service specifying that a principal (user) X wants access to a particular application on machine Y that is connected to domain Z.” examiners note: the information about what app user wants to use must be collected in order to determine if a token exist for it already, if it is not then this step happens.); accessing the access token by searching the secure storage based on the account of the productivity application that is identified in the subsequent request; and providing the computing system with the access token to access the productivity application (Koushik [0166] application management module gets token from agent).
Regarding claim 21, Koushik in view of Bokare teaches:
The proxy token service of claim 20, wherein the subsequent request (Bokare [0032] initial request may be from associated device to sign-on module 104; father note per [0031] sign-on module may not be part of the web server and may instead be a part of associated device, for example (see fig. 4), subsequent request may be for another device to access) was transmitted in response to the computing system (Fig. 4 102 systems of computing modules 112) authenticating a second client device (Bokare Client device 208) to access the cloud-based service (Bokare user resources 102 in fig. 4 see [0049]; Koushik where a user resource is the application in the cloud based service) the computing system and the computing system uses the access token to provide the second client device with the productivity application integrated within the cloud-based service (Bokare [0038] – [0043] teaches providing access to a client 208 (second device) based on the access token that was provided to the associated device 202 (computing system);).
The same motivation to combine for claim 9 applies to claim 15.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW J GANOUS whose telephone number is (571)270-0542. The examiner can normally be reached Monday - Thursday 7:30 AM - 5:00 PM.
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, Jeffrey Nickerson can be reached at (469)295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/ANDREW J GANOUS/ Examiner, Art Unit 2432