Prosecution Insights
Last updated: October 02, 2026
Application No. 18/438,804

SYSTEMS AND METHODS FOR INTEGRATION OF NETWORK BASED SERVICES, INCLUDING NETWORK BASED SECURITY SERVICES, INTO DESKTOP ENVIRONMENTS

Non-Final OA §103§112
Filed
Feb 12, 2024
Examiner
BHANDARI, SHREYAJ RAM
Art Unit
Tech Center
Assignee
Open Text Corporation
OA Round
1 (Non-Final)
100%
Grant Probability
Favorable
1-2
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 100% — above average
100%
Career Allowance Rate
1 granted / 1 resolved
+40.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
2y 6m
Avg Prosecution
18 currently pending
Career history
15
Total Applications
across all art units

Statute-Specific Performance

§101
2.4%
-37.6% vs TC avg
§103
75.0%
+35.0% vs TC avg
§102
2.4%
-37.6% vs TC avg
§112
20.2%
-19.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 1 resolved cases

Office Action

§103 §112
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 . Claims 1-21 are pending. Claim Objections Claim 2 is objected to because of the following informalities: should be "the method of claim 1 wherein" instead of "the method of claim wherein". 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 1-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 1, 8, and 15 recite the feature "the client side service access data" which lacks antecedent basis. For examination purposes, this is interpreted as "the client side service data." Claims 2-7, 9-14, and 16-21 depend on these claims, therefore they inherit this rejection. Claims 5, 12, and 19 recite the feature "the service access data generated by the library" which lacks antecedent basis. For examination purposes, this is interpreted as "the client side service data generated by the library." Claims 6, 7, 13, 14, 20, and 21 depend on these claims, therefore they inherit this rejection. 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, 4, 8, 11, 15, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mohamad (US 20190238598 A1, hereinafter referred to as Mohamad) in view of Schneider (US 20090299938 A1, hereinafter referred to as Schneider). Regarding claim 1, Mohamad discloses: A method for incorporating use of services into desktop applications, comprising: at a desktop application executing on a computing device: determining an access to an interface of the desktop application (Mohamad: Paragraph [0224] states, "the OAuth authorization endpoint re-directs the in-app browser tab 1345 to an SSO service for user authentication by passing the requested scopes. The SSO service checks if a user session already exists, and, if not, prompts the user to submit one or more user credentials, via a user interface service, based on the configured authentication/sign-on policy. The sign-on policy may be based on the user, information from the device on which the user is signing-in, information from the IP network on which the request is sent, a risk score of the user and OAuth scopes for which the client is requesting service. The policy evaluation based on the above conditions may result in a multi-factor authentication (MFA) when a client registration scope is requested."); executing a service access module, the service access module adapted for: invoking a web browser in the service access module, the web browser configured to access a Uniform Resource Locator (URL) for a service access web page associated with a first service and including a library associated with the first service (Mohamad: Paragraph [0154] states, "an application “X” may communicate with an application “Y” based on HTTP by exposing application “Y” as an HTTP Uniform Resource Locator (“URL”). In one embodiment, “Y” is an IDCS microservice that exposes a number of resources each corresponding to a capability. When “X” (e.g., another IDCS microservice) needs to call “Y”, it constructs a URL that includes “Y” and the resource/capability that needs to be invoked (e.g., https:/host/Y/resource), and makes a corresponding REST call which goes through web routing tier 912 and gets directed to “Y”." Paragraph [0078] states, "IDCS further includes infrastructure libraries that are common code packaged as shared libraries used by IDCS services and shared libraries. Infrastructure services and libraries provide supporting capabilities as required by platform services for implementing their functionality." Examiner's note: The libraries within the IDCS are implementing the functionality performed by the specific services.); receiving the service access web page including the library (Mohamad: Paragraph [0154] states, "an application “X” may communicate with an application “Y” based on HTTP by exposing application “Y” as an HTTP Uniform Resource Locator (“URL”). In one embodiment, “Y” is an IDCS microservice that exposes a number of resources each corresponding to a capability. When “X” (e.g., another IDCS microservice) needs to call “Y”, it constructs a URL that includes “Y” and the resource/capability that needs to be invoked (e.g., https:/host/Y/resource), and makes a corresponding REST call which goes through web routing tier 912 and gets directed to “Y”." Examiner's note: Since the Y resource is being accessed through a url, it is interpreted that a web page is being received, and the libraries are also being received since the libraries are within the IDCS service.); utilizing the service access web page, calling the library associated with the first service (Mohamad: Paragraph [0154] states, "When “X” (e.g., another IDCS microservice) needs to call “Y”, it constructs a URL that includes “Y” and the resource/capability that needs to be invoked (e.g., https:/host/Y/resource), and makes a corresponding REST call which goes through web routing tier 912 and gets directed to “Y”." Paragraph [0078] states, "IDCS further includes infrastructure libraries that are common code packaged as shared libraries used by IDCS services and shared libraries. Infrastructure services and libraries provide supporting capabilities as required by platform services for implementing their functionality." Examiner's note: Calling the service Y by using a URL is interpreted as calling a library associated with the first service using a web page.), but fails to explicitly disclose: utilizing the…web page…to generate, at the computing device, client side service data associated with the first service. However, in the same field of endeavor, Schneider discloses: utilizing the…web page…to generate, at the computing device, client side service data associated with the first service (Schneider: Paragraph [0028] states, "Based on the contents of the service request, application server 105 may determine that web application 125 should perform one or more actions, after which application server 105 may return a service response to the client 120 or proxy server 110." Paragraph [0042] states, "The rules engine 130 may use rules 165 to determine whether to initiate specified aspect services 115 whenever an incoming message (e.g., a service request) or outgoing message (e.g., a service response) is received. Such decisions may be made based on message contents (e.g., message header, message context, message body, URLs, portions of a web page being transmitted, etc.)." Paragraph [0049] states, "The message may be a service request that has been generated by a client and that is addressed to a web application." Examiner's note: the service request is mapped to the client side service data.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teaching of Mohamad and include the above limitation with the teaching of Schneider in order to "simplify coding, upgrading, maintenance, etc." (Schneider: Paragraph [0029]). This motivation applies to the remainder of the claim. Schneider further discloses: sending, from the service access module at the computing device, a first request including the client side service data to an intermediary server, wherein the first request is for a second service from provided by the intermediary server (Schneider: Paragraph [0028] states, "Based on the contents of the service request, application server 105 may determine that web application 125 should perform one or more actions, after which application server 105 may return a service response to the client 120 or proxy server 110." Paragraph [0069] states, "client 405 sends a service request to proxy server 410."), wherein: the first request causes a second request to be sent from the intermediary server to a service provider of the first service, the second request including the client side service access data (Schneider: Paragraph [0037] states, "proxy server 110 generates aspect requests upon receiving service requests and or upon receiving service responses. The aspect requests may then be sent to aspect server 115. In one embodiment, aspect requests include the service request or service response), a first response to the second request is received from the service provider at the intermediary server (Schneider: Paragraph [0037] states, "After sending an aspect request to aspect server 115, proxy server 110 may wait for a response), wherein the first response including service data determined by the service provider, a second response to the first request is determined at the intermediary server based on the service data from the from the first response, and the second response is returned to the service access module at the computing device (Schneider: Paragraph [0037] states, "If an aspect response is received, proxy server 110 forwards the aspect response to the client 120 and/or application server 105. In one embodiment, if the aspect response is a null response, proxy server 110 forwards the service request to application server 105." Examiner's note: the service request sent by the client device is mapped to the first request and the content within the service request that determines the responses is mapped to the client side service data. The proxy server is mapped to the intermediary server and the proxy server generates the aspect request which is mapped to the second request that is generated in response to receiving the service request. The aspect request is sent to the aspect server which then sends an aspect response, the first response, back to the proxy server, which then depending on if the response is null or not, sends the response back to the client device.); and updating, by the service access module, the desktop application based on the second response (Schneider: Paragraph [0059] states, "an aspect service may enable commentary or forum participation on a web page or application that originally did not include such functionality. The aspect response may therefore include a request for new comments or forum posts." Examiner's note: the aspect response depends on the service request content which means the web application, mapped to the desktop application, is being updated in response to the aspect response, which is the second response that was sent to the client.). Regarding claim 4, Mohamad discloses: The method of claim 1, wherein the interface is a login interface of the desktop application (Mohamad: Paragraph [0174] states, "Login application service 1114 provides a login page in browser 1102."). Claims 8 and 15 recite features similar to those recited in claim 1, therefore they are rejected in a similar manner. Claims 11 and 18 recite features similar to those recited in claim 4, therefore they are rejected in a similar manner. Claim(s) 2, 3, 9, 10, 16, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mohamad (US 20190238598 A1, hereinafter referred to as Mohamad) in view of Schneider (US 20090299938 A1, hereinafter referred to as Schneider) in further view of Li (US 20140115702 A1, hereinafter referred to as Li). Regarding claim 2, the combination of Mohamad as modified by Schneider discloses: The method of claim, but fails to explicitly disclose: wherein the web browser is executing in a process space of the service access module. However, in the same field of endeavor, Li discloses: wherein the web browser is executing in a process space of the service access module (Li: Paragraph [0087] states, "an extraction module injects DLL into a process space of the application (e.g. web browser)."). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teaching of Mohamad as modified by Schneider and include the above limitation with the teaching of Li in order to "effectively protect and maintain stable computers and systems" (Li: Paragraph [0002]). Regarding claim 3, Mohamad discloses: The method of claim 2, wherein the web browser is confined to accessing only the configured URL (Mohamad: Paragraph [0075] states, "Applications can retrieve discovery documents by being configured with a single IDCS URL." Paragraph [0154] states, "When “X” (e.g., another IDCS microservice) needs to call “Y”, it constructs a URL that includes “Y” and the resource/capability that needs to be invoked (e.g., https:/host/Y/resource), and makes a corresponding REST call which goes through web routing tier 912 and gets directed to “Y”."). Claims 9 and 16 recite features similar to those recited in claim 2, therefore they are rejected in a similar manner. Claims 10 and 17 recite features similar to those recited in claim 3, therefore they are rejected in a similar manner. Claim(s) 5-7, 12-14, and 19-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mohamad (US 20190238598 A1, hereinafter referred to as Mohamad) in view of Schneider (US 20090299938 A1, hereinafter referred to as Schneider) in further view of Thakkar (US 20180083941 A1, hereinafter referred to as Thakkar). Regarding claim 5, the combination of Mohamad as modified by Schneider discloses: The method of claim 4. Schneider further discloses: wherein the service access data generated [by the library] is a request [token] associated with the computing device (Schneider: Paragraph [0028] states, "Based on the contents of the service request, application server 105 may determine that web application 125 should perform one or more actions, after which application server 105 may return a service response to the client 120 or proxy server 110." Paragraph [0042] states, "The rules engine 130 may use rules 165 to determine whether to initiate specified aspect services 115 whenever an incoming message (e.g., a service request) or outgoing message (e.g., a service response) is received. Such decisions may be made based on message contents (e.g., message header, message context, message body, URLs, portions of a web page being transmitted, etc.)." Paragraph [0049] states, "The message may be a service request that has been generated by a client and that is addressed to a web application." Examiner's note: the service request is mapped to the client side service data.). The same motivation to modify with Schneider, as in claim 1, applies. Schneider fails to explicitly disclose: data generated by the library is a request token. However, in the same field of endeavor, Thakkar discloses: data generated by the library is a [request] token (Thakkar: Paragraph [0097] states, "the first client 16 triggers generation of a token by the shared library 34."). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teaching of Mohamad as modified by Schneider and include the above limitation with the teaching of Thakkar in order for "efficient integration and secure communications between computing environment resources" (Thakkar: Paragraph [0005]). Thakkar fails to explicitly disclose: request token. However, Mohamad further discloses: request token (Mohamad: Paragraph [0174] states, "the SSO microservice 1112 redirects browser 1102 to a login application service 1114 implemented in JavaScript. Login application service 1114 provides a login page in browser 1102. Browser 1102 sends a REST POST to the SSO microservice 1112 including login credentials. The SSO microservice 1112 generates an access token and sends it to Cloud Gate 1104 in a REST POST. Cloud Gate 1104 sends the authentication information to Admin SCIM microservice 1116 to validate the user's password."). Regarding claim 6, Mohamad discloses: The method of claim 5, wherein the service data includes a risk access score associated with the request token (Mohamad: Paragraph [0224] states, "The sign-on policy may be based on the user, information from the device on which the user is signing-in, information from the IP network on which the request is sent, a risk score of the user and OAuth scopes for which the client is requesting service."). Regarding claim 7, Mohamad discloses: The method of claim 6, wherein the first request includes a username and password provided through the login interface and the request token generated [by the library] (Mohamad: Paragraph [0174] states, "the SSO microservice 1112 redirects browser 1102 to a login application service 1114 implemented in JavaScript. Login application service 1114 provides a login page in browser 1102. Browser 1102 sends a REST POST to the SSO microservice 1112 including login credentials. The SSO microservice 1112 generates an access token and sends it to Cloud Gate 1104 in a REST POST. Cloud Gate 1104 sends the authentication information to Admin SCIM microservice 1116 to validate the user's password."), but fails to explicitly disclose: token generated by the library. However, Thakkar further discloses: token generated by the library (Thakkar: Paragraph [0097] states, "the first client 16 triggers generation of a token by the shared library 34."). The same motivation to modify with Thakkar, as in claim 5, applies. Claims 12 and 19 recite features similar to those recited in claim 5, therefore they are rejected in a similar manner. Claims 13 and 20 recite features similar to those recited in claim 6, therefore they are rejected in a similar manner. Claims 14 and 21 recite features similar to those recited in claim 7, therefore they are rejected in a similar manner. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure includes: Lalonde (US 20050198618 A1) discusses a distributed fabrication system supported by an applicative framework system supplying a generic dynamically adaptable N-Tier client-server object-oriented applicative infrastructure constructed on top of a third party software system infrastructure to support a business application compatible with XInternet technologies via a communication network, the third party software system infrastructure being complemented by database management system components. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHREYAJ RAM BHANDARI whose telephone number is (571)272-0727. The examiner can normally be reached 7:30-5:00. 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, Ali Shayanfar can be reached at (571) 270-1050. 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. /SHREYAJ RAM BHANDARI/ Examiner, Art Unit 2434 /NOURA ZOUBAIR/ Primary Examiner, Art Unit 2434
Read full office action

Prosecution Timeline

Feb 12, 2024
Application Filed
Sep 24, 2026
Non-Final Rejection mailed — §103, §112 (current)

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
100%
Grant Probability
99%
With Interview (+0.0%)
2y 6m (~0m remaining)
Median Time to Grant
Low
PTA Risk
Based on 1 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month