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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
DETAILED ACTION
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/11/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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-9 and 11-19 are rejected under 35 U.S.C. 103 as being unpatentable over US 20150149916 to Mendez et al. (hereinafter “Mendez 2015”) in view of US 20170013073 to Mendez et al. (hereinafter “Mendez 2017”)
Claim 1
Mendez 2015 teaches a computer implemented method for granting access to a secure resource, [e.g. Mendez 2015; Para. 0025, 0028-0030, 0125-0127 – Mendez 2015 discloses an agent is a representative who supports a visitor in carrying out tasks on a website, CServer 120 is a secured server that hosts co-browse sessions (e.g. computer system holding a secure resource), co-browse webserver 110 is a webserver controlling access to co-browse sessions by visitors and agents (e.g. access control system) and the co-browse service allows custom service agents to view the web-browsing activity of visitors.] the method comprising:
receiving at a computer system holding the secure resource, a support request from a client device; [e.g. Mendez 2015; Fig. 2, Para. 0004-0006, 0125, 0129, 0130– Mendez 2015 discloses customer support is provided when a visitor is having trouble navigating or using a website, Cobrowse.js at visitor 100 (e.g. client device) sends a StartCobrowse request (e.g. support request) to the co-browse webserver 110 of the co-browse computing arrangement in which the co-browse session is held at CServer 120 (e.g. computer system holding the secure resource).]
responsive to the support request, providing, by the computer system, a credential to the client device [e.g. Mendez 2015; Para. 0130-0133 – Mendez 2015 responsive to the StartCobrowse request, Cobrowse.js at visitor 100 receives a unique session ID (e.g. credential), the session ID includes 1) the customer group id 2) a session key and 3) a random number for uniqueness and both group id and session key are required to join a session. ]
Mendez 2015 teaches the method of claim 1 and teaches providing the unique session ID to the visitor browser, but does explicitly teach providing the same session ID to a secondary system or receiving at the co-browse webserver 110 an authorization ticket providing the group ID and permitted visitor or session parameters for the protected co-browse session.
However, Mendez 2017, like Mendez 2015, teaches
a customer support co-browse system and further teaches communicating the same co-browse session ID to a visitor browser, a presence system and an agent; [e.g. Mendez 2017; Para0081-0082 – Mendez 2017 teaches when the first browser 10 (e.g. client device) starts co-browse session 18, co-browse service 20 assigns a co-browse session ID 32 (e.g. credential) to the co-browse session 18, first browser 10 posts the co-browse session ID to the presence server 34 (e.g. secondary system and presence server provides agent 14 with a visitor presence update to communicate to the agent that the co-browse session has started and to provide the agent with the co-browse session ID 32 . ]
validating whether an agent is authorized to access the selected visitors co-browse session[e.g. Mendez 2017; Para. 0080– Mendez 2017 teaches the presence server 34 will validate the agent's authorization to co-browse with the selected visitor (e.g. authorization to access the secure resource) and, if the agent is authorized, signal the first browser 10 to start a co-browse session. ]
generating and using an authorization token that provides the Group ID and permitted visitor scope [e.g. Mendez 2017; Para 0112-0120, 0123, 0124– Mendez 2017 teaches a presence access control system 1100 generates and provides authorization tokens 1105 (e.g. tickets); the presence access control system 1100 verifies the agent's credentials (authentication) and determines whether the agent has permission to access the presence system 1120 and the scope of the agent's permission (e.g. access parameters); receiving a group ID that specifies a subset of visitors to the website about whom the agent is able to obtain presence information (e.g. permitted visitors and session scope); all agent side request carry authorization token 1105 and when a request is made, the presence system 1120 will validate the authorization token presented in connection with the request.] and
presence access control system 1100 may be implemented as part of co-browse service 20. [e.g. Mendez 2017; Para. 0113 – Mendez 2017 teaches The presence access control system 1100 may be implemented as a stand-alone server, may be implemented as part of co-browse service 20, may be implemented by website 24, or by a separate process running on presence system 34.]
Therefore, it would have been obvious to before the effective filing date of the claimed invention to incorporate the features above (e.g. presence based session identification and authorization token functionality) into the co-browse computing arrangement of Mendez 2015, specifically requiring agent session access request to carry Mendez 2017 authorization token 1105 and to validate the group ID and permitted visitor and session scope provided by the authorization token 1105 before returning Mendez’s 2015 signed session ID. Mendez 2017 states in paragraph 0078 that the use of presence enables the agent to initiate co-browsing with the visitor without requiring the visitor to take additional action, in paragraph 0085 for agents responsible for handling large numbers of calls, the use of presence to automatically establish co-browse sessions can shorten calls and decrease effort and in paragraph 0112 that a presence access control system is implemented to ensure the agent has sufficient privilege to access presence information about website visitors such that different agents may be responsible for different subsets of visitors and thus the presence information available to an agent may need to be restricted.
Thus the combination enables:
responsive to the support request, providing, by the computer system, a credential to the client device and to a secondary system, the credential being associated to access parameters; [e.g. Mendez 2015; Para. 0130-0133 – Mendez 2015 responsive to the StartCobrowse request, Cobrowse.js at visitor 100 receives a unique session ID (e.g. credential), the session ID includes 1) the customer group id 2) a session key and 3) a random number for uniqueness and both group id and session key are required to join a session. ] [e.g. Mendez 2017; Para. 0082– Mendez 2017 teaches when the first browser 10 (e.g. client device) starts co-browse session 18, co-browse service 20 assigns a co-browse session ID 32 (e.g. same credential) to the co-browse session 18, first browser 10 posts the co-browse session ID to the presence server 34 (e.g. secondary system) ; Para. 0080, 0118, 0124 – Mendez 2017 teaches the presence server 34 will validate the agent's authorization to co-browse with the selected visitor (e.g. authorization to access the secure resource); group ID specifics the subset of visitors whom the agent is able to obtain information (e.g. permitted visitor and session scope) and the group ID in the request]
receiving, at an access control system for the secure resource, a ticket providing the access parameters for the secure resource; [e.g. Mendez 2017; Para. 0080, 0112-0120, 0123, 0124– Mendez 2017 teaches presence server 34 validates whether agent is authorized to co-browse with the selected visitor (e.g. access the secure resource); Mendez 2017 teaches a presence access control system 1100 generates and provides authorization tokens 1105 (e.g. tickets); the presence access control system 1100 verifies the agent's credentials (authentication) and determines whether the agent has permission to access the presence system 1120 and the scope of the agent's permission (e.g. access parameters for the secure resource) and the group ID in authorization token 1105 must match the group ID in the request and The presence access control system 1100 may be implemented as a stand-alone server, may be implemented as part of co-browse service 20 (e.g. access control system for the secure resource), may be implemented by website 24, or by a separate process running on presence system 34.]
receiving, at the access control system, an access request for the secure resource from a user of an agent computing device, the access request including the credential; [e.g. Mendez 2015; Para. 0133-0137 – Mendez 2015 teaches both group ID and session key are required to join a session; agent opens a browser window to a URL associated with the co-browse session, e.g.: https://www.cobrowse.net/cobrowse/AgenView.aspx?SessionKey=ssnkey and AgentView.aspx at co-browse webserver 110 (e.g. access control system) looks up the session in the database by agent group id and session key.] [e.g. Mendez 2017; Para. 0082 – Mendez 2017 teaches the presence server 34 provides agent 14 (e.g. user of an agent computing device) with the co-browse session ID 32 (e.g. credential). The agent then joins co-browse session 18 using co-browse session ID 32 (e.g. access request including the credential).]
confirming, by the access control system, that the access request complies with the access parameters; [e.g. Mendez 2015; Para. 0133, 0137, 0142 – Mendez 2015 teaches both group ID and session key are required to join a session; agent opens a browser window to a URL associated with the co-browse session, e.g.: https://www.cobrowse.net/cobrowse/AgenView.aspx?SessionKey=ssnkey and AgentView.aspx at co-browse webserver 110 (e.g. access control system) looks up the session in the database by agent group id and session key and co-browse webserver 110 grants the request only if the agent is authenticated at the webserver and is a member of the group with which the session is associated (e.g. confirming that the access request complies with the group ID and permitted session scope)] [e.g. Mendez 2017; Para. 0080, 0124 – Mendez 2017 teaches the presence server 34 validates the agent’s authorization to co-browse with the selected visitor, verifies the authorization token signature, verifies that the authorization token has not expired and verifies that the group ID in authorization token 1105 (e.g. access parameter) matches the group ID in the request.]and
generating, by the access control system, an access token, the access token being usable by the user for accessing the secure resource. [e.g. Mendez 2015; Para. 0142-0145 – Mendez 2015 teaches if a matching session is found, the webserver (e.g. access control system) returns the session id, signed (e.g. generates an access token) using a secret "server key" and the CServer verifies the signature on the session id and only allows the agent to join if the signature is valid (e.g. access token usable by the user for accessing the secure resource). Once the agent has joined the session, a secure (flagged for HTTPS only) session cookie is used to maintain the agent's session. The agent session cookie contains the session id signed using a secret key known only to the CServer. The CServer only accepts WebSocket connections to a given session if the request includes a valid agent session cookie value. No browsing session data is ever served by the CServer without a valid agent session cookie attached to the request]
Claim 2:
Mendez 2015 teaches the method of claim 1 and teaches co-browse computing arrangement, including CServer 120 and co-browser webserver 110 (e.g. computing system) controls access to protected co-browse sessions, but does explicitly teach wherein the secondary system is trusted by the computer system.
However, Mendez 2017 teaches presence system 34, on which presence access control system 110 may execute (e.g. secondary system, wherein the presence access control system generates and signs authorization token 1105 and the authorization token arrangement uses a shared secret between the token issuer and consumer and verifying the token signature before permitting the requested control. [e.g. Mendez 2017; Para. 0113, 0115, 0124, 0126 – Mendez 2017 teaches a presence access control system 1100 generates and provides authorization tokens 1105, the presence access control system 1100 may be implemented by a separate process running on presence system 34 (e.g. secondary system), the presence access control system 1100 uses the JSON Web Token (JWT) standard for creating, signing, and verifying authorization tokens (e.g. signed authorization information issue by the secondary system), JSON Web Tokens require a shared secret between the token issuer and the consumer(e.g. trusted relationship between the secondary system and the computer system) and the presence system 1120 verifies the token signature, that it has not expired, and that the group ID in the token matches the group ID in the request (e.g. verification and reliance on authorization information before access is granted).]
Therefore, it would have been obvious to before the effective filing date of the claimed invention to incorporate the features above (e.g. presence system as an authorization system that issues signed authorization information) into the co-browse computing arrangement(e.g. computer system) of Mendez 2015 because Mendez 2017 states in paragraph 0112 that a presence access control system is implemented to ensure the agent has sufficient privilege to access presence information about website visitors such that different agents may be responsible for different subsets of visitors and thus the presence information available to an agent may need to be restricted.
Claim 3:
Mendez 2015 as modified by Mendez 2017 teaches the method of claim 1, wherein the secondary system corresponds to a customer assistance portal. [e.g. Mendez 2017; Para. 0004, 0008-0015, 0070, 0084, 0091-0095, 0107, 0108 – Mendez 2017 teaches website assistance may be provided by a customer agent through chat or a voice telephone call, information from presence system 34 is integrated with customer relationship management client 36, CRM window 400 displays CRM records 410 and co-browse buttons 420, a case object is automatically accessed and displayed to the agent in the agent's CRM window when a call is assigned and an agent may initiate co-browse sessions via CRM/chat. (e.g. customer assistance portal).]
Claim 4:
Mendez 2015 and Mendez 2017 teaches the method of claim 1, wherein the access parameters identify a role for a user, and wherein the confirming that the access request complies with the access parameters includes checking that a role of the user matches the role in the access parameters. [e.g. Mendez 2015; Para. 0023, 0133, 0142, 0115, 0124, 0126 – Mendez 2015 teaches group ID is a unique ID assigned to each customer website and the agents group ID is determined based on the agent co-browse group membership (e.g. role for a user). Mendez 2015 further discloses co-browse 110 grants the request only if the agent is a member of the group that the session is associated with (e.g. checking that the role of the user matches the role associated with the requested session).] [e.g. Mendez 2017; Para. 0116, 0118, 0124– Mendez 2017 teaches presence access control system 1100 determines the scope of the agent’s permission and agent 110 specifies a group ID identifying the subset of visitors about whom the agent is able to obtain presence information (e.g. access parameters identifying an authorized agent group or role). Mendez 2017 further discloses presence system 1120 verifies that the group ID in authorization token (e.g. role in the access parameters) matches the group ID in the request (e.g. role of the user)]
Claim 5:
Mendez 2015 and Mendez 2017 teaches the method of claim 1, wherein the access parameters include access to only a subset of the secure resource, and wherein the access token limits access to the subset of the secure resource. [e.g. Mendez 2015; Para. 0135-0137, 0142-0145 – Mendez 2015 teaches the agent supplies session identifying information for a particular co-browse session, co-browse webserver 110 returns the corresponding signed session ID (e.g. access token) and CServer 120 allows the agent to join the identified co-browse session only in the signature is valid (e.g. access token limiting access to the identified subset of the protected co-browse session) Mendez 2015 further discloses the agent session cookie contains the signed session ID, CServer 120 accepts a connection to the given session only when the request includes a valid agent session cooking and no browsing session data is served with the valid session specific cookie.] [e.g. Mendez 2017; Para. 0112, 0118, 0124– Mendez 2017 teaches different agents may be responsible for different subsets of visitors, group ID specifies a subset of visitors about whom the agent is able to obtain presence information, and an agent may be authorized to interact with a subset of visitors associated with the group ID (e.g. access to only a subset of the protected co-browse sessions held by the co-browse computing arrangement).]
Claim 6:
Mendez 2015 teaches the method of claim 1, wherein the credential is unique for a user of the client device over a time period. [e.g. Mendez 2015; Para. 0130-0132 – Mendez 2015 teaches Cobrowse.js receives a unique session id (e.g. credential) that includes a random number for uniqueness and Cobrowse.js stores the session id in a browser session cookie for the co-browse session (e.g. credential unique for the visitor during the active co-browse session time period.)]
Claim 7:
Mendez 2015 as modified by Mendez 2017 teaches the method of claim 1, wherein the ticket is signed or encrypted by the secondary system. [e.g. Mendez 2017; Para. 0113, 0115, 0124, 0126 – Mendez 2017 teaches a presence access control system 1100 generates and provides authorization tokens 1105, the presence access control system 1100 may be implemented by a separate process running on presence system 34 (e.g. secondary system), the presence access control system 1100 uses the JSON Web Token (JWT) standard for creating, signing, and verifying authorization tokens (e.g. signed authorization information issue by the secondary system).]
Claim 8:
Mendez 2015 teaches the method of claim 1, wherein the access control system is hosted on a separate computing device from the computing system, and wherein the computing system, the separate computing device, the client device, and the agent computing device communicate over a network. [e.g. Mendez 2015; Para. 0028-0300, 147-0154, 0161, 0162 – Mendez 2015 teaches CServer 120 is a secured standalone server that hosts the co-browse sessions, (e.g. resource holding computing system), co-browse webserver is a web server controlling access to co-browse sessions (e.g. access control system), the co-browse webserver may be a separate entity on the network (e.g. access control system hosted on a separate computing device from the computing system). Mendez 2015 further discloses the communication including downloading co-browse JavaScript from co-browse webserver 110 to the visitor browser, and communications between Cobrowse.js-CServer 120, communications between CServer 120-co-browse webserver 110 and communications between the agent browser-CServer 120 are executed using HTTP and websockets (e.g. the computing system, the separate computing device, the client device, and the agent computing device communicate over a network)]
Claim 9:
Mendez 2015 teaches the method of claim 1, wherein the access control system is hosted on the computing system, and wherein the computing system, the client device, and the agent computing device communicate over a network. [e.g. Mendez 2015; Para. 0028-0300, 147-0154, 0161, 0162 – Mendez 2015 teaches the co-browse webserver (e.g. access control system) may be collocated with the Cserver (e.g. computing system) and other implementations may incorporate aspects of the functionality of the co-browse webserver 110 with the co-browse server 120. Mendez 2015 further discloses the communication including downloading co-browse JavaScript from co-browse webserver 110 to the visitor browser, and communications between Cobrowse.js-CServer 120, communications between CServer 120-co-browse webserver 110 and communications between the agent browser-CServer 120 are executed using HTTP and websockets (e.g. the computing system, the separate computing device, the client device, and the agent computing device communicate over a network)]
Regarding claims 11-19 they are system claims essentially corresponding to the above recitations, and they are rejected, at least, for the same reasons.
Claim(s) 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20150149916 to Mendez et al. (hereinafter “Mendez 2015”) in view of US 20170013073 to Mendez et al. (hereinafter “Mendez 2017”) and further in view of US 20210120002 to Fuji et al. (hereinafter “Fuji”) retrieved from IDS dated 06/11/2025
Claim 10
Mendez 2015 and Mendez 2017 teaches the method of claim 1 and teaches generating a signed session ID usable by the agent to join the protected co-browse session, but does explicitly teach that the signed session ID (e.g. access token) stops being usable after a defined period.
However, Fujii teaches issuing an access token having an expiration date and time and determining whether the access token is beyond that expiration date and time when the token is presented. [e.g. Fujii; Para. 0057, 0058, 0077-0079, 099, 0100 – Fujii discloses a request table 44 storing an access token and an expiration date and time in association, a generation unit 31 issues access token token01 (e.g. access token) that is valid until specified date and time (e.g. a defined period of time), client 2 transmits the access token to resource server 50 to obtain the resource and extraction unit 32 determines whether the access token is beyond the expiration date and time and determines that the access token is valid only when it is not beyond the expiration date and time, when it is beyond an error is returned when it is valid obtaining the permitted resource proceeds (e.g. access token stop being usable for accessing the secure resource after the defined period elapses). ]
Therefore, it would have been obvious to before the effective filing date of the claimed invention to modify the signed session ID of Mendez 2015 to include or be associated with an expiration time as taught by Fujii. As Fujii discloses in Para. 0099, 0100 rejection an access token that is no longer within its expiration and time by returning an error while permitting resource access processing when the token remains within its expiration date and time which would limit use of the signed session ID to its define validity period.
Regarding claim 20 they are system claims essentially corresponding to the above recitations, and they are rejected, at least, for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER C HARRIS whose telephone number is (571)270-7841. The examiner can normally be reached Monday through Friday between 8:00 AM to 4:00 PM CST.
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 L Nickerson can be reached on (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.
/CHRISTOPHER C HARRIS/Primary Examiner, Art Unit 2432
Prosecution Insights