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 .
This action is in response to the amendment and remarks filed 5/22/2025. Claims 1-20 are pending. Claims 1 (a non-transitory CRM), 11 (a method), and 20 (a machine) are independent.
Response to Arguments
Applicant's arguments filed 5/22/2025 have been fully considered but they are not persuasive.
Regarding the § 112(a) rejection, Applicant asserts that the amendment “wherein the tests interrogate for a first type-of-authentication and a second type-of-authentication” along with paragraphs 90, 91, and 98 of the specification provide written description support for the claimed subject matter.
Examiner responds by noting that the various portions of Applicant’s specification discussing the “test”, ¶¶ 47, 57, 80, 104, 95, and “interrogating”, 40, 42, 44, 45, 47, 48, 54, 68, 72, 79, 80, 89, 94-96, 98, 103, 104, do not describe how “tests” or “interrogations” are generated or administered. Rather, each paragraph above merely notes that interrogations or tests are performed and result in determining the authentication mechanism. Therefore, the tests could not “interrogate for a first type-of authentication”.
Examiner notes that every access to a website or service that requires authentication is analogous to a “test” that “interrogates” for required authentication. For example, providing www (dot) facebook (dot) com results in a cloud-based application with a login area. The input and transmission of the URL request being the test and the webpage being the response. The question is then how does Applicant’s test differ from all possible authentication flows? This question makes the content and use of the claimed “test” critical.
Note that a rejection in view of Grossbart, “What you need to know about OAuth2 and logging in with Facebook” has been added to illustrate the scope of the claims and ubiquity of the performance thereof.
On page 10 of the remarks Applicant states: “Cha states in part in paragraph 0122, The UE 800 may receive a 401 (Unauthorized) message back from the server, in which the WWW-Authenticate header may comprise the first challenge for the proposed authentication protocol...the server may send another 401 with a different WWW-Authenticate header which may comprise a challenge for the authentication protocol... Accordingly, Cha relies on his server sending tests to his client/UE, which is the opposite direction recited by Claims 1, 11, and 20.”
Examiner reiterates (see Office Action mailed 3/24/205, page 4) that the rejection of independent claims 1, 11, and 20 in view of Cha US 2013/0174241 (filed 2012) and Barton et al., US 2014/0033271 (filed 2013). Has always cited messages from the UE, Cha Figure 8, messages 804, 808, and 814. Each of said messages results in the server providing authentication method feedback to the client.
Applicant’s alleged “tests” from the server to the client are authentication challenges.
Applicant has not provided remarks with regard to why the messages of Cha 804, 808, and 814, do not constitute tests. As such, Applicant’s arguments are not persuasive.
For at least the above reasons, Applicant’s remarks are not persuasive.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claims 1, 11, and 20 require:
transmitting tests from a client device to server-side software located on a server device;
wherein the tests interrogate for a first type-of-authentication and a second type-of-authentication
…
selecting, based on results of the tests,
The most comprehensive disclosure of this feature is found in Applicant’s specification ¶ 47:
If in the metadata-checking step 118, the authentication module 20 of Fig. 1 recognizes the web service or API 26 as using a suitable authentication method (i.e., a method that can be handled by the authentication module 20), then a sub-flow initiation step 120 begins. If the response is not suitable, i.e., the authentication module 20 does not recognize the web service or API 26 as using a suitable authentication method, then the authentication module 20 continues its attempts to inquire as to the authentication method used by the web service or API 26. Repeated attempts to query or interrogate the web service or API 26 for authentication-method information may involve use of different types of request messages and may be governed by logic incorporated in the interrogation step 114. The logic may specify which tests to run (e.g., specific request messages to send) if a given test does not return suitable authentication-method information for the web service 26 of Fig. 1; when to terminate a particular test or negotiation (e.g., after all tests are exhausted); and so on.
(emphasis Examiner’s)
Applicant’s specification does not provide written description support for generating tests or making determinations based on the responses or how to administer the tests.
In other words, there is no description regarding how to test a server or what to look for in a response from the server. Further complicating the issue is that the claim is not limited to a particular authentication protocol or API; thus, the claim must provide written description support for all authentication types. However, since no mechanism for testing is disclosed within Applicant’s specification it is not evident that the testing would even be possible on all authentication types.
As to the amendment of 5/22/2025 and the first/second “type-of-authentication”; it is not evident that paragraphs 90, 91, and 98 provide written description support for the amended features, or the other features noted above. Specifically, there does not appear to be support for a “test” that “interrogate for a first type-of-authentication”. This clause appears to require that the transmitted test contemplates a particular type-of-authentication. There does not appear to be any disclosure of a test that is particularized for a type-of-authentication.
For example, Applicant’s specification ¶ 80 states: “The testing may involve the sending of messages (and analyzing the responses) to test which type of authentication method (and/or properties or parameters thereof) are employed by the web services or APIs 26 of Fig. 1.”
This does not detail how to perform a test, or how responses may be parsed. Rather, it is a high-level abstract concept of determining, in any possible way, how a web server requests authentication.
Much like any ordinary user access to a web server. See Grossbart as cited below.
Claims 2-10, 12-19 are rejected due to their dependence on claims 1 and 11, respectively.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 4-9, 11, and 14-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Grossbart, “What you need to know about OAuth2 and logging in with Facebook” (published 2017).
As to claims 1, 11, and 20, Grossbart discloses:
A non-transitory processor-readable medium including instructions executable by one or more processors, and when executed operable for: (“I use Spotify on my iPad” Grossbart p. 6)
transmitting tests from a client device to server-side software located on a server device, wherein the tests interrogate for a first type-of-authentication and a second type-of-authentication; (“I hardly ever log into Spotify, so I don’t want to create another account and have to remember another password.” Grossbart p. 7. The activity of attempting to use a service and being “challenged” with an authentication prompt is analogous to a “test”)
receiving results of the tests from the server-side software; (see Figure on Grossbart p. 8. The result of the “test” being the authentication GUI requesting user authentication; here, password-based authentication or Facebook)
selecting, based on the results of the tests, an authentication sub-flow from a plurality of authentication sub-flows enabling a client-side program on the client device to operate on cloud-based data associated with server-side software; (“I can use my Facebook account to log in. When I tap that button, Spotify sends me over to facebook.com, and I log in there.” Grossbart p. 9)
facilitating client authentication for the client-side program to operate on the cloud-based data using the selected authentication sub-flow; and (“Spotify sends me over to facebook.com, and I log in there.” Grossbart p. 9. Spotify is a distributed multi-server service and is therefore cloud based.)
operating on the cloud-based data from the client-side program using the client- authentication. (“As an example, I use Spotify on my iPad.” Grossbart p. 6)
This rejection is intended as an example to illustrate the 112(a) issue. Grossbart describes the ubiquitous login flow of choosing between username/password and a federated identity provider (Facebook). It could be argued that the claim differs from ubiquitous login flows in the administration of tests or perhaps the selection of a particular login mechanism. However, the tests and the selection are not further detailed in Applicant’s specification as originally filed.
As to claims 4 and 14, Grossbart further discloses:
wherein the tests are messages and the transmitting tests from a client device to server-side software further includes: transmitting the messages from the client device to the server-side software. (Grossbart pp. 6-8).
As to claims 5 and 15, Grossbart further discloses:
wherein the test results are responses and the receiving of the results of the tests from the server- side software further includes: receiving the responses of the messages from the server-side software. (Grossbart pp. 6-8).
As to claims 6 and 16, Grossbart further discloses:
wherein each of the plurality of authentication sub-flows are associated with a different type of authentication. (see Grossbart Figure on p. 8, Facebook or username/password)
As to claims 8 and 18, Grossbart further discloses:
determining a type of authentication used by the server-side software based on the results from the tests. (see Grossbart Figure on p. 8, Facebook or username/password)
As to claims 9 and 19, Grossbart further discloses:
(“I can use my Facebook account to log in. When I tap that button, Spotify sends me over to facebook.com, and I log in there.” Grossbart p. 9)
providing authenticated credentials; and (“Opening a new browser window for the OAuth2 provider is a crucial step. That’s what allows providers to show their own log-in forms and to ask each user for whatever login information they need.” Grossbart p. 13)
collecting authentication evidence based on the selected authentication sub-flow. (“The important part is that, when the provider is done, they will redirectback to you and give you a token.” Grossbart p. 14)
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.
Claim(s) 1-6, 8-16, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cha US 2013/0174241 (filed 2012), in view of Barton et al., US 2014/0033271 (filed 2013).
As to claims 1, 11, and 20, Cha discloses a non-transitory processor-readable medium including:
transmitting tests from a client device to server-side software located on a server device; (see Cha figure 8, messages 804, 808, 814)
receiving results of the tests from the server-side software, located on a server device (see Cha Fig. 8, messages 806, 810), wherein the tests interrogate for a first type-of-authentication and a second type-of-authentication; (see Cha Fig. 8, messages 806, 810)
selecting, based on results of the tests, an authentication sub-flow from a plurality of authentication sub-flows enabling a client-side program on the client device (“the server may send another 401 with a different WWW-Authenticate header which may comprise a challenge for the authentication protocol that matches the UE's and RP's requested authentication protocol (812).” Cha ¶ 122)
…
facilitating client authentication for the client-side program to (“the server may send another 401 with a different WWW-Authenticate header which may comprise a challenge for the authentication protocol that matches the UE's and RP's requested authentication protocol (812).” Cha ¶ 122)
Cha does not disclose a cloud, as claimed:
to operate on cloud-based data associated with server-side software;
…
operate on the cloud-based data using the selected authentication sub-flow; and
operating on the cloud-based data from the client-side program using the client-authentication.
Barton discloses:
to operate on cloud-based data associated with server-side software; (“As seen in FIG. 2, client computers 211-214 may communicate with a cloud management server 210 to access the computing resources (e.g., host servers 203, storage resources 204, and network resources 205) of the cloud system.” Barton ¶ 67)
…
operate on the cloud-based data using the selected authentication sub-flow; and
operating on the cloud-based data from the client-side program using the client-authentication. (“A variety of authentication techniques may be employed in the procedure above. For example, in some arrangements, a set of tickets (or tokens) is loaded into the mobile device during initial authentication” Barton ¶ 313. Also Barton ¶¶ 323 and 402. “Assuming the mobile device is running on a foreign network and the enterprise administrator has permitted VPN access for this application for this user, then the specialized network software initiates a secure connection to the corporate gateway device” Barton ¶ 324.)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Cha with Barton by utilizing the authentication negotiation of Cha in mobile devices authenticating to a cloud environment of Barton. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Cha with Barton in order to allow control over managed corporate software and its access to sensitive internal information in a cloud, thereby securing corporate information from unintended exposure.
As to claims 2 and 12, Cha in view of Barton discloses the CRM/method/machine of claims 1, 11, and 20 and further discloses:
further including instructions executable by the one or more processors and when executed operable for:
transmitting
receiving
selecting, based on the side software. (“As seen in FIG. 2, client computers 211-214 may communicate with a cloud management server 210 to access the computing resources (e.g., host servers 203, storage resources 204, and network resources 205) of the cloud system.” Barton ¶ 67).
Cha in view of Barton, as combined in claim 1, does not disclose:
second [authentication]
second results
second cloud-based
Barton further discloses:
second [authentication]
second results
(“it should be understood that over time, such tickets may expire. If such tickets expire prior to use, operations that required tickets instead now require that the user re-authenticate.” Barton ¶ 314, see also ¶¶ 315 and 324)
second cloud-based (“one or more policy files may define the circumstances under which one or more applications operating under the control of or in accordance with those policy files can and cannot use an SSO service to bypass an authentication or security challenge.” Barton ¶ 395)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Cha with Barton by utilizing the authentication negotiation of Cha in mobile devices authenticating to a cloud environment of Barton. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Cha with Barton in order to allow control over managed corporate software and its access to sensitive internal information in a cloud, thereby securing corporate information from unintended exposure.
As to claim 3 and 13, Cha in view of Barton discloses the CRM/method/machine of claims 2 and 12 and further discloses:
facilitating second client authentication for the second client-side program to operate on the second cloud-based data using the selected second authentication sub-flow; and (“the server may send another 401 with a different WWW-Authenticate header which may comprise a challenge for the authentication protocol that matches the UE's and RP's requested authentication protocol (812).” Cha ¶ 122)
operating on the second cloud-based data from the second client-side program using the second client authentication. (“A variety of authentication techniques may be employed in the procedure above. For example, in some arrangements, a set of tickets (or tokens) is loaded into the mobile device during initial authentication” Barton ¶ 313. Also Barton ¶ 323. “Assuming the mobile device is running on a foreign network and the enterprise administrator has permitted VPN access for this application for this user, then the specialized network software initiates a secure connection to the corporate gateway device” Barton ¶ 324).
As to claims 4 and 14, Cha in view of Barton discloses the CRM/method/machine of claims 1, 11, and 20 and further discloses:
wherein the tests are messages and the transmitting tests from a client device to server-side software further includes:
transmitting the messages from the client device to the server-side software. (see Cha figure 8, messages 804, 808, 814).
As to claim 5 and 15, Cha in view of Barton discloses the CRM/method/machine of claims 4 and 14 and further discloses:
wherein the test results are responses and the receiving of the results of the tests from the server-side software further includes: receiving the responses of the messages from the server-side software. (see Cha Fig. 8, messages 806, 810)
As to claims 6 and 16, Cha in view of Barton discloses the CRM/method/machine of claims 1, 11, and 20 and further discloses:
wherein each of the plurality of authentication sub-flows are associated with a different type of authentication. (“the server may send another 401 with a different WWW-Authenticate header which may comprise a challenge for the authentication protocol that matches the UE's and RP's requested authentication protocol (812).” Cha ¶ 122)
As to claims 8 and 18, Cha in view of Barton discloses the CRM/method/machine of claims 1, 11, and 20 and further discloses:
further including instructions executable by the one or more processors and when executed operable for: determining a type of authentication used by the server-side software based on the results from the tests. (“the server may send another 401 with a different WWW-Authenticate header which may comprise a challenge for the authentication protocol that matches the UE's and RP's requested authentication protocol (812).” Cha ¶ 122)
As to claims 9 and 19, Cha in view of Barton discloses the CRM/method/machine of claims 1, 11, and 20 and further discloses:
further including instructions executable by the one or more processors and when executed operable for:
providing authenticated credentials; and collecting authentication evidence based on the selected authentication sub-flow. (see Cha figure 8, messages 812, 814. “A variety of authentication techniques may be employed in the procedure above. For example, in some arrangements, a set of tickets (or tokens) is loaded into the mobile device during initial authentication” Barton ¶ 313. Also Barton ¶ 323. “Assuming the mobile device is running on a foreign network and the enterprise administrator has permitted VPN access for this application for this user, then the specialized network software initiates a secure connection to the corporate gateway device” Barton ¶ 324).
As to claims 10, Cha in view of Barton discloses the CRM/method/machine of claims 1, 11, and 20 and further discloses:
further including instructions executable by the one or more processors and when executed operable for:
transmitting the tests from the client device to the server-side software on a second server device; (see Cha figure 8, messages 804, 808, 814)
receiving ; (see Cha Fig. 8, messages 806, 810)
selecting, based on ; (“the server may send another 401 with a different WWW-Authenticate header which may comprise a challenge for the authentication protocol that matches the UE's and RP's requested authentication protocol (812).” Cha ¶ 122)
facilitating
operating on the enterprise administrator has permitted VPN access for this application for this user, then the specialized network software initiates a secure connection to the corporate gateway device” Barton ¶ 324.)
Cha in view of Barton, as combined in claim 1, does not disclose:
a copy of the server-side software
a second server device
second results of the tests … on a second server device … on a second server device
second cloud-based data
second client-authentication
Barton further discloses:
a copy of the server-side software (“The proxy device 2510 may comprise one or more of a server (e.g., servers 201, 206, 1701, 410), computing device, access gateway 360, gateway server 406, or any other device. The proxy device 2510 may facilitate communications between the client device 2510 and enterprise resources or other networks. For example, a user of the client device 2505 may wish to access enterprise resources that require authentication, and the proxy device 2510 may mediate access.” Barton ¶ 402. See also Barton ¶ 73)
a second server device (Barton ¶ 402. See also Barton ¶ 73)
second results of the tests (“it should be understood that over time, such tickets may expire. If such tickets expire prior to use, operations that required tickets instead now require that the user re-authenticate.” Barton ¶ 314, see also ¶¶ 315 and 324) … on a second server device … on a second server device (“The proxy device 2510 may comprise one or more of a server (e.g., servers 201, 206, 1701, 410), computing device, access gateway 360, gateway server 406, or any other device. The proxy device 2510 may facilitate communications between the client device 2510 and enterprise resources or other networks. For example, a user of the client device 2505 may wish to access enterprise resources that require authentication, and the proxy device 2510 may mediate access.” Barton ¶ 402. See also Barton ¶ 73)
second cloud-based data (“one or more policy files may define the circumstances under which one or more applications operating under the control of or in accordance with those policy files can and cannot use an SSO service to bypass an authentication or security challenge.” Barton ¶ 395)
second client-authentication (“it should be understood that over time, such tickets may expire. If such tickets expire prior to use, operations that required tickets instead now require that the user re-authenticate.” Barton ¶ 314, see also ¶¶ 315 and 324)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Cha with Barton by utilizing the authentication negotiation of Cha in mobile devices authenticating to a cloud environment of Barton. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Cha with Barton in order to allow control over managed corporate software and its access to sensitive internal information in a cloud, thereby securing corporate information from unintended exposure.
Claim(s) 7 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cha US 2013/0174241 (filed 2012), in view of Barton et al., US 2014/0033271 (filed 2013), and Vepa et al., US 2017/0329957 (published 2017-11).
As to claims 7 and 17, Cha in view of Barton discloses the CRM/method/machine of claims 1, 11, and 20 and further discloses:
wherein the types of types of authentication include
Cha in view of Barton does not disclose:
include JSON Web Token (JWT), basic access authentication (BASIC)
Vepa discloses:
include JSON Web Token (JWT) (“receiving standard identity tokens that are JavaScript Object Notation (“JSON”) Web Tokens (“JWTs”) conveying the user's authenticated identity.” Vepa ¶ 100), basic access authentication (BASIC) (“Cloud Gate 702 also acts as an HTTP Basic Auth authenticator, validating HTTP Basic Auth credentials against IDCS.” Vepa ¶ 143)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have modified Cha in view of Barton with Vepa by incorporating and supporting JSON web tokens and HTTP Basic. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Cha in view of Barton with Vepa in order to expand the supported authentication methods and thereby support a wide variety of software products and services.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly:
Kitamura, “Streamlining the sign-in flow using credential management API”, discloses a flow chart for selecting among different authentication methods.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W CHAO whose telephone number is (571)272-5165. The examiner can normally be reached M, W-F 8-5.
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, Rupal Dharia can be reached at (571) 272-3880. 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.
/MICHAEL W CHAO/ Primary Examiner, Art Unit 2492
Prosecution Insights