Method and apparatus for accessing proprietary resources in a co-browsing session

Abstract

The co-browse service implements a resource acquisition process to make proprietary resources accessible in a co-browse session. In some embodiments, the co-browse JavaScript in the guest browser converts some or all resource URLs of the DOM to point to the resource acquisition process so that the agent browser attempts to retrieve the resource referenced by the URL from the resource acquisition process rather than from the website. The resource acquisition process, in turn, acquires the resource from the website or the guest browser. Because the resource acquisition process can acquire proprietary resources on behalf of the agent and provide the proprietary resources to the agent during the co-browse session, the agent can have a consistent view with the visitor's browser during the co-browse session.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 770,493, entitled “Accessing Proprietary Resources in a Co-browsing Session,” filed on November 21, 2018, the contents of which are incorporated herein by reference. Technical Field

[0003] The field relates to communication sessions and, more particularly, to methods and apparatus for accessing proprietary resources in a co-browsing session. Background Art

[0004] The content of a first browser can be shared and reproduced in a second browser that is geographically remote. One method of achieving this is to forward a document object model (DOM) describing the content of the first browser to the second browser. The second browser uses the DOM received from the first browser to recreate the content of the first browser.

[0005] Unfortunately, in some cases, having only a DOM is not enough to reliably reproduce all of the content of the first browser at the second browser. In particular, depending on how the website is built, the content displayed in the first browser may be based on resources such as fonts, cascading style sheets (CSS), and images, which require cookies to access and are therefore only available to the first browser. Since the second browser cannot obtain the same proprietary resources from the website, the content of the second browser will not correctly reflect the content displayed in the first browser. In addition, some websites use cross-origin resource sharing (CORS) headers to prevent browsers on another domain from accessing website resources. In this case, CORS prevents the proxy viewer from accessing resources directly from the website, but can access the resource through a "resource acquisition process." Therefore, it would be advantageous to provide a system that enables the proprietary resources of the first browser to be accessed by the second browser in a co-browsing session. Summary of the invention

[0006] The Summary and Abstract sections are provided here to introduce some concepts discussed in the Detailed Description below. The Summary and Abstract sections are not comprehensive and are not intended to describe the scope of the protected subject matter, which is set forth by the claims presented below.

[0007] In some embodiments, the co-browsing service implements a resource acquisition process so that the agent browser can access proprietary resources used on the guest browser during the co-browsing session. Some or all resource URLs (Universal Resource Locators) of the guest's DOM are converted to point to the resource acquisition process so that the agent browser attempts to retrieve the resource referenced by the URL from the resource acquisition process rather than from the website. The resource acquisition process in turn acquires the resource from the website or the guest. Because the resource acquisition process can acquire proprietary resources on behalf of the agent and provide the proprietary resources to the agent during the co-browsing session, the agent can have a consistent view with the guest browser during the co-browsing session. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Various aspects of the present invention will be specifically pointed out in the appended claims. The present invention is illustrated by examples in the following drawings, in which like reference numerals indicate like elements. The following drawings disclose various embodiments of the present invention, which are for illustrative purposes only and are not intended to limit the scope of the present invention. For clarity, not all components are labeled in each drawing. In the drawings:

[0009] Figure 1 is a functional block diagram of a network of components for accessing proprietary resources in a co-browsing session, according to some embodiments.

[0010] Figure 2 is a swim lane diagram according to some embodiments, which shows Figure 1 Information transmission between several components of the co-browsing session is related to providing dedicated resources over a co-browsing session. DETAILED DESCRIPTION

[0011] The following detailed description sets forth many specific details to provide a deeper understanding of one or more embodiments of the present invention. However, it should be understood by those skilled in the art that the present invention can be implemented without these specific details. In other examples, in order not to confuse the present invention, well-known methods, processes, components, protocols, algorithms and circuits are not described in detail.

[0012] Figure 1 1 is a functional block diagram of a network 100 of components for accessing proprietary resources in a co-browsing session 132, according to some embodiments. Figure 1 As shown, in some embodiments, a web server 110 hosts a website 115. A visitor 120 accesses the website 115 using a guest browser 125 to load web pages from the web server 110. A co-browsing service 130 facilitates a co-browsing session 132 in which an agent 135 can view the content of the guest browser 125 in an agent browser 140.

[0013] In some embodiments, the web pages loaded from the web server 110 are scripted with the co-browse JavaScript 145. Alternatively, the co-browse JavaScript 145 may be loaded into the guest browser 125 as a plug-in or extension. The co-browse JavaScript 145 causes a document object model (DOM) describing the web page loaded into the guest browser 125 to be forwarded to the co-browse service 130. The co-browse service 130 forwards the DOM to the agent browser 140 in the co-browse session 132 so that the agent browser 140 has a view consistent with the content of the guest browser 125. Additional details of how an example co-browse system of this nature may be implemented are provided in U.S. Patent No. 9,736,214, entitled INTEGRATING CO-BROWSING WITH OTHERFORMS OF INFORMATION SHARING, the contents of which are incorporated herein by reference.

[0014] When the proxy browser 140 receives the DOM describing the content of the guest browser 125, the proxy browser 140 will typically request the resources described in the DOM from the website 115. However, in some cases, the proxy browser 140 will not be able to obtain the same resources from the website 115 as the guest browser 125 can obtain from the website 115. For example, depending on how the website 115 is built, the guest browser 125 may have fonts, cascading style sheets (CSS), and images that are only provided to clients that present cookies, such as the guest browser 125. Similarly, in the case where the proxy browser 140 executes a web application on a different domain than the website 115, cross-origin resource sharing (CORS) restrictions may prevent the proxy browser 140 from accessing restricted resources on the website 115. As used herein, the term "proprietary" is defined to refer to resources that are protected by cookies and / or CORS.

[0015] For example, many companies have resources on their websites that cannot be accessed by the agent browser 140 in the co-browse session 132. Some typical scenarios include fonts or CSS that cannot be accessed across domains. Therefore, if the agent browser 140 is on one domain and the resource is on another domain, the CORS restrictions may prevent the agent browser 140 from accessing the resource. As another example, the resource may be an image that is unique to the guest browser 125, an account-specific image such as a bank check image, which may require a session cookie that the agent browser 140 does not have and the co-browse service 130 does not have.

[0016] According to some embodiments, the co-browse service 130 instantiates a resource acquisition process 150 for the co-browse session 132. The co-browse JavaScript 145 copies the DOM of the browser 125 and forwards the DOM to the co-browse service 130 in the co-browse session 132. The proxy browser 140 receives the forwarded DOM in the co-browse session 132 and requests at least some of the resources referenced in the DOM from the resource acquisition process 150 instead of from the website 115. The resource acquisition process 150 services resource requests by submitting requests for resources to both the website 115 and the guest browser 125. When the resource acquisition process 150 receives a resource from the guest browser or the website, it returns the requested resource to the proxy browser 140. Using the resource acquisition process 150 enables obtaining proprietary resources on behalf of the proxy browser 140 so that the proxy browser 140 can more closely replicate the content of the guest browser 125.

[0017] Figure 2 is a swim lane diagram according to some embodiments, which shows Figure 1 The information transmission between several components of the co-browsing session 132 is used to access the proprietary resources. Figure 2 As shown, at arrow 200, the guest browser 125 downloads the web page and the co-browse JavaScript 145 from the website 115. At arrows 205 and 210, the co-browse session 132 is started. There are many ways to start a co-browse session 132. For example, the guest browser 125 can start the co-browse session 132, which is then joined by the agent browser 140; the agent can trigger the guest to start a session, which is then joined by the agent; or the agent browser 140 can start the co-browse session 132, and then the guest browser 125 can join the co-browse session 132 in display mode. Regardless of how the co-browse session 132 is started, according to some embodiments, the co-browse service 130 instantiates a resource acquisition process (arrow 215) that is used by the agent browser 140 during the co-browse session 132 to access at least some of the resources specified in the shared DOM of the guest browser 125.

[0018] In some embodiments, the guest co-browse JavaScript 145 converts the URL of the DOM of the guest browser 125 to point to the resource acquisition process 150. According to some embodiments, once the resource acquisition process 150 has been instantiated for use in the co-browse session 132, the URL of the resource acquisition process 150 is forwarded to the guest browser 125 (arrow 220). Alternatively, in some embodiments, the guest co-browse JavaScript 145 can obtain the URL of the resource acquisition process 150 based on a server at the co-browse service 130 that is used to host the co-browse session 132 (e.g., [co-browse server] / proxy / resource / [session ID]). The guest browser 125 uses the URL of the resource acquisition process 150 to convert relative resource URLs and absolute resource URLs in the DOM so that these URLs point to the resource acquisition process 150 (arrow 225). Although some embodiments have the URL conversion implemented by the co-browse JavaScript 145 in the guest browser 125, in other embodiments, the URL conversion is done at another component of the network 100, such as by the proxy browser 140, the co-browse service 130, or by the resource acquisition process 150.

[0019] In embodiments where the URL conversion process is implemented at the guest browser, once the correct set of URLs referenced in the DOM are converted by the guest co-browse JavaScript 145, the modified DOM is forwarded from the guest browser 125 to the co-browse service 130 (arrow 230), and the modified DOM is forwarded from the co-browse service 130 to the proxy browser 140 (arrow 235). In embodiments where the URL conversion is done at the co-browse service 130, the guest co-browse JavaScript forwards the DOM of the guest browser 125 to the co-browse service 130 (arrow 230), the co-browse service 130 implements the URL conversion process, and forwards the modified DOM to the proxy browser 140 (arrow 235).

[0020] In embodiments where the URL conversion process is implemented at the agent browser 140, the co-browse service 130 forwards the URL of the resource acquisition process 150 to the guest browser 125 (arrow 220'). Alternatively, in some embodiments, the agent browser 140 may obtain the URL of the resource acquisition process 150 based on a server at the co-browse service 130 that is used to host the co-browse session 132 (e.g., [co-browse server] / agent / resource / [session ID]). Once the agent browser 140 has the URL of the resource acquisition process 150, the agent browser 140 may implement the URL conversion process to cause at least a subset of the URLs referenced in the DOM to point to the resource acquisition process 150.

[0021] Regardless of where the URL conversion process is implemented, after URL conversion, some or all URLs of the modified DOM loaded into the proxy browser 140 will point to the resource acquisition process 150. Therefore, when the proxy browser 140 attempts to load the web page described by the DOM, the proxy browser 140 will issue some or all resource requests to the resource acquisition process 150 (arrow 240).

[0022] In some embodiments, all URLs of the DOM are converted to point to resource acquisition process 150. In these embodiments, proxy browser 140 requests all resources referenced in the DOM from resource acquisition process 150 (arrow 240).

[0023] In other embodiments, a first subset of the URLs of the DOM are converted to point to resource acquisition process 150. In these embodiments, proxy browser 140 requests the first subset of resources from resource acquisition process 150 (arrow 240), and proxy browser 140 requests other resources from website 115 (arrow 242). Therefore, when only some of the URLs of the modified DOM point to resource acquisition process 150, when proxy browser 140 attempts to load a web page described by the DOM, proxy browser 140 will issue resource requests associated with the converted URLs to resource acquisition process 150 (arrow 240), and will issue resource requests for unconverted URLs to website 115 in a normal manner (arrow 242).

[0024] When the resource acquisition process 150 receives a resource request (arrow 240), if the resource acquisition process 150 has cached the requested resource, the resource acquisition process 150 forwards the requested resource to the proxy browser 140 (arrow 245). If the resource acquisition process 150 has not previously obtained and cached the requested resource, the resource acquisition process 150 requests the resource from the website 115 (arrow 250), requests the resource from the guest browser 125 (arrow 255), or requests the resource from both the website 115 and the guest browser 125 (arrows 250, 255).

[0025] In some embodiments, the resource acquisition process 150 requests resources from both the website 115 and the guest browser 125 without first waiting for a response from one or the other. For example, in some embodiments, the resource acquisition process 150 requests a resource from the guest browser 125 (arrow 255) and also sends a request for the same resource to the website 115 (arrow 250) before receiving a response from the guest browser 125 (arrow 270). Similarly, in some embodiments, the resource acquisition process 150 requests a resource from the website 115 (arrow 250) and also sends a request for the same resource to the guest browser 125 (arrow 255) before receiving a response from the website 115 (arrow 260).

[0026] In some cases, the resource acquisition process 150 may obtain the requested resource from the website 115. If the requested resource is available from the website 115, the website 115 forwards the requested resource to the resource acquisition process 150 (arrow 260), and the resource acquisition process 150 satisfies the resource request by forwarding the requested resource to the proxy browser 140 (arrow 265). In some cases, the resource acquisition process 150 may obtain the requested resource from the guest browser 125. If the requested resource is available from the guest browser 125, the guest browser 125 forwards the requested resource to the resource acquisition process 150 (arrow 270), and the resource acquisition process 150 satisfies the resource request by forwarding the requested resource to the proxy browser 140 (arrow 275).

[0027] In some cases, although the guest browser 125 will already have the requested resources in its cache, the JavaScript in the browser cannot access these resources as flat files. For example, the browser may have a font loaded, and the CSS may reference the font, but the JavaScript does not have a handle to the font file. In this case, the guest browser 125 makes an XMLHttpRequest (XHR request) to the website 115 for the file (arrow 280). The guest browser 125 can actually extract the actual file from the cache, or, if the resource is from a website 115 on a different domain, the guest browser 125 may have to reissue the request to the website 115 using a CORS header. When the requested resource is obtained (arrow 285), it is then forwarded to the resource acquisition process 150 (arrow 270) and then forwarded to the proxy browser 140 (arrow 275).

[0028] In some cases, the resource acquisition process 150 will obtain the requested resource from both the website 115 and the guest browser 125. In some embodiments, when the resource acquisition process 150 receives a first response from the website 115 (arrow 260), or receives a first response from the guest browser 125 (arrow 270), the resource acquisition process 150 forwards the response to the proxy browser 140 (arrow 265 or 275) to satisfy the resource request. Optionally, once a resource is received from one source, the request to the other source can be cancelled.

[0029] In some cases, the resource acquisition process 150 will receive responses from both the website 115 (arrow 260) and the visitor browser 125 (arrow 270). In some embodiments, if both responses return a hypertext transfer protocol (http) status of 200 (ok), the two responses are generally equivalent, and the resource acquisition process 150 can select any one of the two responses to satisfy the resource request of the proxy browser 140. An exception is if one of the responses returns a content type of text / hypertext markup language (text / html) instead of the expected image, font, or CSS content type. Typically, this means that the network server 110 returns an error page instead of the resource itself. In some embodiments, if the visitor browser 125 or website 115 returns an error, and the other returns an http status of 200 (ok), the reply with status 200 is used. If both return an http error status code, one of the responses, such as the one with a lower error code, can be selected, but how to select a response in this case may vary depending on the implementation.

[0030] In some embodiments, resource acquisition process 150 caches resources of website 115 and provides the website resources to proxy browser 140 (arrow 245).

[0031] In some embodiments, when the HTML is uploaded to the co-browsing service 130, the guest co-browsing JavaScript 145 adjusts <base> The guest co-browsing JavaScript 145 also converts all absolute hypertext reference (href) and source (src) attributes to relative attributes so that when used with <base> When the tag is combined, the href or src URL will point to the URL on the resource acquisition process 150.

[0032] When the resource acquisition process 150 receives a request for a website resource from the proxy browser 140, the resource acquisition process 150 provides the website resource from its local cache (arrow 245). If the resource acquisition process 150 does not already have the resource, it requests the resource from the guest browser 125 by sending a message over the sockjs connection of the guest computer 120 (arrow 255). If the guest browser 125 is not currently connected to the co-browse session 132, for example because the guest is navigating to a new page, the resource acquisition process 150 adds the request to the session state to be processed by the guest co-browse JavaScript 145 the next time the guest browser 125 is connected. The resource acquisition process 150 also requests resources directly from the web server 110 (arrow 250).

[0033] The guest browser 125 uploads the resource to the resource acquisition process 150 (arrow 270) and / or the web server 110 responds to the resource acquisition process 150 with the resource (arrow 260). The resource acquisition process 150 stores the resource in a session-specific area. The resource acquisition process 150 scans any CSS files uploaded by the guest browser 125 or returned by the web server 110 for URLs of images, fonts, or other CSS files, and converts absolute URLs in the CSS files to relative URLs.

[0034] In some embodiments, the cache is used to store resources that are specific to a single visitor 120. In some embodiments, the resource acquisition process 150 removes all cached resources at the end of the co-browsing session 132. In other embodiments, a common cache is used to store commonly requested resources so that those commonly requested resources can be obtained from the cache of co-browsing sessions 132 with multiple visitors 120. In this case, the cached resources may not be removed at the end of the co-browsing session 132.

[0035] Base Tag

[0036] In conjunction with converting the URL of the web page, in some embodiments, the guest co-browsing JavaScript 145 adds the following base tag so that all relative URLs on the page point to the server at the co-browsing service 130 hosting the resource acquisition process 150:

[0037] <base href＝" agent resource sessionid path-to-visitor-page"> .

[0038] If the page already has a base tag with an href, the guest co-browse JavaScript 145 modifies it to point to the server at the co-browse service 130 that hosts the resource fetching process 150. For example:

[0039] Will <base href＝"https: otherserver.abc.com a b c">

[0040] Modified to

[0041] <base href＝" agent resource sessionid https-otherserver.abc.com a b c"> .

[0042] Note that absolute URLs are mapped to URL path items by making some substitutions:

[0043] : / / or / / maps to- /

[0044] This allows these URLs to look like relative URLs to the proxy browser 140, while the resource fetching process 150 can still map them back to the original URL. In some implementations, this mapping is done on the guest side in a JavaScript function in the guest co-browsing JavaScript 145. For iframes, the "frame path" will also be inserted into the base tag. See the section on iframes below.

[0045] Absolute URLs in the DOM

[0046] In some embodiments, and <link> The absolute URLs in the tags are converted to relative URLs so that the proxy browser 140 sends requests for those resources to the resource acquisition process 150. For example:

[0047] Will <link href＝"https: otherserver.abc.com a b c style.CSS">

[0048] Modified to:

[0049] <link href＝"https-otherserver.abc.com a b c style.CSS"> .

[0050] In some embodiments, similarly modify The src and srcset attributes.

[0051] In some embodiments, the co-browse JavaScript 145 only transforms URLs for certain types of files so that the proxy browser 140 will fetch the untransformed resources directly from the website 115. For example, in some embodiments, the guest co-browse JavaScript 145 transforms URLs associated with CSS, img, and font resources, but does not transform URLs associated with aspects of the website 115 that are publicly available and not proprietary to the guest browser 125. In this way, the co-browse service 130 is not burdened with fetching resources for the proxy browser 140 that are normally available directly from the website 115.

[0052] Absolute URLs in CSS files

[0053] When the visitor co-browsing JavaScript 145 uploads CSS files, the resource acquisition process 150 scans these files for absolute URLs. Following the same convention, absolute URLs are converted to URLs in the resource acquisition process 150.

[0054] Calling Resource Mapping

[0055] In some embodiments, the resource acquisition process 150 tracks all pending and completed resource requests for the visitor 120 in a call resource map. The call resource map is a map of:

[0056] resourceURL=>{Future}

[0057] Unless there is no protocol, the resourceURL in the resource mapping call is an absolute URL. Whether the path specified in the page is relative or absolute, using an absolute URL allows the resource to be reused. In this article, "Future" represents a computational task that may have been completed or is to be completed at some time in the future.

[0058] Resource requests to the server at the co-browse service that hosts the resource acquisition process

[0059] In some embodiments, the resource request to the resource acquisition process 150 has a convention for specifying a URL of the original location of the resource on the website. An example of a resource request URL may be:

[0060] / agent / resource / sessionid / [resource path].

[0061] For example, the URL:

[0062] / agent / resource / sessionid / https-otherserver.abc.com / a / b / c / style.CSS

[0063] Will be used to request a resource at an absolute URL:

[0064] https: / / otherwserver.abc.com / a / b / c / style.CSS

[0065] or:

[0066] / resource / sessionid / a / b / c / style.CSS

[0067] Will be used to request a resource at a relative URL:

[0068] a / b / c / style.CSS

[0069] Among them, the URL is interpreted by the resource acquisition process 150 as a current page relative to the visitor's browser 125.

[0070] In some embodiments, if the proxy browser 140 does not present valid credentials for the co-browse session 132 specified by the co-browse session ID in the request, the resource request is rejected with http status 401 (unauthorized).

[0071] In some embodiments, the resource acquisition process 150 maps the resource path to the file name as follows:

[0072] cacheroot / sessionid / [resource path]

[0073] Wherein, cacherroot is the configuration setting of resource acquisition process, and it indicates the root directory of cache file.In certain embodiments, some characters in file URL will be replaced with underscore, to generate effective path name.

[0074] When a resource request is received from the proxy browser 140, if the resource is not found in the file cache, the resource acquisition process 150 looks for the resource in the call resource mapping. In some embodiments, files retrieved by the resource acquisition process in the context of one session can be cached and used by the resource acquisition process in conjunction with other sessions. Therefore, in some embodiments, the resource acquisition process first determines whether the resource is cached before looking in the URL-future mapping. If the resource acquisition process 150 has never requested the resource, the resource acquisition process 150 forwards these requests to the guest browser 125 as follows:

[0075] Message type: resreq

[0076] Message payload: {URL: [absolute URL / relative URL determined by resource path]}

[0077] The resource acquisition process 150 also adds an entry for the resource to the calling resource map.

[0078] If the resource was previously requested by resource acquisition process 150, but the resource request has not been satisfied, then resource acquisition process 150 waits for the resource.

[0079] If the resource request has been completed (or when it is completed), the resource acquisition process 150 responds to the request by sending the file (if the file was successfully retrieved). In some embodiments, the cache headers included in the reply to the proxy are set to cache the file indefinitely, since the file will only be valid for the length of the co-browse session 132 anyway. The content type header of the resource is set to the content type originally returned by the web server 110 when providing the resource to the guest browser 125 or to the resource acquisition process (see "Guest Handling of Resource Requests"). Whatever http status code the guest browser 125 or resource acquisition process receives when retrieving the resource is returned to the proxy browser 140.

[0080] In some embodiments, to prevent malicious JavaScript from running on the proxy browser 140, a Content Security Policy (CSP) header is used, and the co-browsing service includes the CSP header on all pages served to the proxy browser 140. The CSP header restricts the domains from which JavaScript files can be retrieved (e.g., to the co-browsing service 130), and also prevents inline JavaScript in the page from running. Therefore, a CSP-compliant browser will only execute scripts loaded from source files received from the list of allowed domains, ignoring all other scripts. Therefore, even if a visitor 120 sends a malicious script in an attempt to attack the proxy's browser 140, or if a malicious script is somehow downloaded from the website 115, the malicious script will not be executed on the proxy browser 140. In addition, the resource acquisition process will return a 401 error for any JavaScript resource request.

[0081] Guest processing of resource requests

[0082] The guest browser 125 processes the resource request by issuing an XMLHttpRequest (XHR) request for the specified resource to the website 115 (arrow 280), and upon receiving the response (arrow 285), uploads the requested resource to the resource acquisition process 150 (arrow 270) using a POST request to the co-browse service at / guest / UR. In some embodiments, the guest browser 125 sends an http status code and content type with the POST, and the resource acquisition process 150 tracks this information.

[0083] CORS and certificates

[0084] In some embodiments, where the web server 110 requires a certificate to access a resource, the initial XMLHttpRequest (XHR) request for the resource from the guest browser 125 to the web server 110 (arrow 280) includes the certificate. In some cases, the web server 110 does not require a certificate and does not allow cross-domain requests that include certificates. In this case, the guest browser 125 can report an error to the console rather than to the JavaScript engine. As a result, the XHR request will simply appear to fail, as if, for example, the network connection was disconnected. Therefore, whenever an XHR request for a resource fails without an http response, the guest browser 125 will retry the request on the web server 110 without a certificate (re-sending the request on arrow 280).

[0085] Resource acquisition process upload resource request handler

[0086] In some embodiments, the resource acquisition process 150 has an upload resource (UR) request handler. The guest browser issues a POST request to the upload resource handler on the url of the co-browsing service: / visitor / UR / ssnid=[session id&]url=[resource url]&httpstatus=[http status code], where resource url is the url of the resource and http status code is the status code returned by the website in response to the visitor's request for the resource. The body of the POST contains the resource file content. The guest browser sets the content type header of the request based on the content type header in the response to the visitor's resource request. If the guest browser 125 successfully uploads the resource, the UR request handler uses the above-mentioned resource path to file path mapping to save the body of the POST to a file.

[0087] The UR request handler looks up the resource in the call resource map and resolves the Future by setting its result to the resource content type (extracted from the content-type header on the UR request) and the http status (from the httpstatus query string parameter). The resource acquisition process 150 requires the content type and http status in order to respond to a resource request.

[0088] If the guest browser 125 cannot retrieve the resource, possibly due to a CORS error (indicated by httpstatus 0), the resource acquisition process 150 attempts to retrieve the resource itself. In some embodiments, the resource acquisition process 150 attempts to retrieve the resource from both the network server 110 and the guest browser 125 without first waiting for the request on the guest browser 125 to fail.

[0089] time out

[0090] The guest browser 125 should generally respond to a resource request by posting to the UR request handler, even if it is accompanied by a failure status. However, if: (1) a JavaScript error or network problem occurs and prevents the process from completing as expected, or (2) the guest browser 125 jumps before retrieving and uploading the resource, the resource acquisition process 150 should not let the proxy browser 140 hang indefinitely waiting for a response. For example, Chrome and possibly other browsers will not render a page until the web server 110 provides some response to the resource request. Therefore, if the guest browser 125 does not respond to the resource request within a certain period of time, and the web server 110 does not respond to the resource within the timeout period, the resource acquisition process 150 returns http status 504 (gateway timeout) to the proxy browser 140. If the guest browser 125 jumps, all outstanding resource request Futures are canceled.

[0091] Iframe

[0092] Requests for resources referenced in an iframe are handled by the "framecall" (i.e., subsession) associated with that frame. However, there is only one call resource mapping on the top-level call to take advantage of the fact that resources can be shared between iframes.

[0093] Frame URL

[0094] In order to provide iframe resources, in some embodiments, a frame resource acquisition process URL (frame path) is defined. Each frame resource acquisition process URL is uniquely mapped to an iframe. In some embodiments, the frame resource acquisition process URL is obtained from the iframe href, so when the iframe is re-instantiated on the visitor 120 side, the frame resource acquisition process URL will not change. The invariance of the frame resource acquisition process URL allows both the proxy browser 140 and the resource acquisition process 150 to reuse the cached resources referenced in the iframe.

[0095] The frame resource fetching process URL can be anything as long as it uniquely maps to the iframe href. The guest co-browsing JavaScript 145 selects the frame resource fetching process URL and sends it to the resource fetching process 150 when the frame first uploads its DOM.

[0096] When the visitor's browser sets 125 <base>When the guest co-browsing JavaScript 145 is running in an iframe, the guest browser 125 appends / cobrowse-[frame_resource_fetch_process_URL] to the base tag sent to the proxy. All resource requests from the proxy browser 140 for resources within the iframe will contain the frame resource fetch process URL.

[0097] Handling requests for framework resources

[0098] Note that only the iframe that references the resource can handle the resource request, because the iframe may not be on the same domain as the parent. If the parent requests the resource, it will be a "cross-domain" request and may fail.

[0099] When the resource acquisition process 150 receives a resource request, if the URL contains a frame resource acquisition process URL, the resource acquisition process 150 uses the frame resource acquisition process URL to identify the frame call. Then, the resource acquisition process 150 sends a resource request to the corresponding iframe on the visitor browser 125. If it is a relative URL relative to the location.href of the iframe, the visitor browser 125 can request the resource. When the visitor browser 125 receives the resource and uploads the resource to the resource acquisition process 150, the visitor browser 125 includes the frame_resource_acquisition_process_url on the / visitor / UR URL as an additional frameid query string parameter, so the resource acquisition process 150 can identify the frame to which the resource belongs. In some embodiments, the resource acquisition process 150 processes the iframe resources that are the same as the top-level resources because the resource acquisition process 150 requests them from the website 115 and the visitor browser 125 at the same time.

[0100] Relative URLs in frame stylesheets

[0101] If the style sheet in the iframe includes a relative URL, the relative resource request from the proxy browser 140 to the resource acquisition process 150 will be:

[0102] / agent / resource / ssnid / frame_resource_acquisition_process_url / path-to-stylesheet / relative-url-for-resource

[0103] The resources in the iframe are stored in the file cache under the directory ssnid / frame_resource_acquisition_process_url.

[0104] Visitor jump

[0105] In some embodiments, if the guest browser 125 jumps to a new page before satisfying outstanding resource requests, the co-browsing JavaScript on the new page must undertake the work of downloading those resources from the website 115 and uploading them to the resource acquisition process 150. For ease of implementation, the resource acquisition process 150 adds any outstanding resource requests to the session state and removes them when they are satisfied. The guest co-browsing JavaScript 145 satisfies all outstanding resource requests when the page loads. In other embodiments, if the guest browser 125 jumps to a new page before satisfying outstanding resource requests, the resource acquisition process 150 cancels the outstanding requests. After the jump, if the new page is scripted with the co-browsing JavaScript or if the guest co-browsing JavaScript 145 is persistent (cookies, extensions), the entire process will start over for the resources on the new page.

[0106] Multiple Agents

[0107] If there are multiple agents 135 in the co-browse session 132, each agent browser 140 of the multiple agents 135 will issue multiple requests for the same resource to the resource acquisition process 150. The resource acquisition process 150 should ensure that only one request (arrow 255) is forwarded to the guest browser 125. Therefore, the resource acquisition process 150 will check the co-browse session 132 status for existing outstanding requests for a resource before issuing a new request to the guest browser 125 for the same resource.

[0108] Binary Files

[0109] Some browsers may not support downloading or uploading binary files using XMLHttpRequest (XHR) requests. XHR requests are object-based APIs that transfer data between a web browser and a web server. Therefore, if one of these browsers is used to implement the guest browser 125, a possible solution is to download the binary file into a string with a custom encoding. This string is then decoded back into binary at the resource acquisition process 150.

[0110] Pre-caching

[0111] Because it may take some time to obtain resources from the guest browser 125, in some embodiments, the guest browser 125 scans the page for CSS files and preloads them when the co-browsing session 132 first begins, rather than waiting for the agent browser 140 to issue a request for these resources through the resource acquisition process 150. CSS files are critical to accurately rendering a page (compared to fonts and images) because the CSS files affect the layout of the entire page. By pre-caching CSS files at the resource acquisition process 150, the resource acquisition process 150 can provide these resources to the agent browser 140 more quickly when these resources are requested in the co-browsing session 132.

[0112] The methods described herein may be implemented as software configured to be executed by control logic, for example, contained in a CPU of an electronic device such as a computer. The functions described herein may be implemented as a set of program instructions stored in a non-temporary tangible computer-readable medium. When implemented in this manner, the computer program includes a set of instructions that, when the set of instructions is run by a computer, enables the computer to perform a method that implements the above functions. The programmable logic may be temporarily or permanently fixed in a non-temporary tangible computer-readable medium, such as a read-only memory chip, a computer memory, a disk, or other storage medium. In addition to being implemented in software, the logic described herein may be embodied using discrete components, integrated circuits, programmable logic used in combination with a programmable logic device (such as a field programmable gate array (FPGA) or a microprocessor), or any other device including any combination thereof. All such embodiments are intended to fall within the scope of the present invention.

[0113] Various changes and modifications to the embodiments described in this specification and shown in the accompanying drawings can be made within the spirit and scope of the present invention. Therefore, it is intended to point out that all contents contained in the above description and shown in the accompanying drawings should be interpreted in an illustrative rather than a restrictive sense.

Claims

1. A co-browsing system for providing exclusive resources in a co-browsing session, comprising: A guest computer, an agent computer, and a co-browsing service between the guest computer and the agent computer; The visitor computer has an instantiated first browser, the first browser having a DOM describing the content of the first browser, the DOM including objects whose URLs point to the first website, at least some of the objects being the proprietary resources, the first browser further having a co-browsing script loaded therein, the co-browsing script being configured to copy the DOM of the first browser and forward the DOM of the first browser to the agent computer via the co-browsing service in the co-browsing session; The co-browsing service has a resource acquisition process instantiated thereon, wherein the resource acquisition process is configured to acquire the exclusive resource in the co-browsing session; as well as The agent computer has a second browser instantiated thereon, the second browser being configured to load the DOM of the first browser received in the co-browsing session and request the proprietary resource referenced in the DOM from the resource acquisition process; The proprietary resources are fonts and cascading style sheets (CSS) resources protected by cross-origin resource sharing (CORS) or protected by both cookies and CORS, and the resource acquisition process is configured to simultaneously request the proprietary resources requested by the proxy computer from both the guest computer and the first website.

2. The collaborative browsing system according to claim 1, wherein: The proprietary resources further include images that are protected by CORS or are protected by both cookies and CORS.

3. A co-browsing system for providing exclusive resources in a co-browsing session, comprising: a co-browsing service between a guest computer and an agent computer, the co-browsing service being configured to implement a co-browsing session between the guest computer and the agent computer, and a resource acquisition process being instantiated on the co-browsing service, the resource acquisition process being configured to acquire the exclusive resource in the co-browsing session; The visitor computer has an instantiated first browser, the first browser having a DOM describing the content of the first browser, the DOM including objects whose URLs point to the first website, at least some of the objects being the proprietary resources, the first browser further having a co-browsing script loaded therein, the co-browsing script being configured to copy the DOM of the first browser and forward the DOM of the first browser to the agent computer via the co-browsing service in the co-browsing session; The agent computer has a second browser instantiated thereon, the second browser being configured to load the DOM of the first browser received in the co-browsing session and request the proprietary resource referenced in the DOM from the resource acquisition process; The proprietary resources are fonts and cascading style sheets (CSS) resources protected by cross-origin resource sharing (CORS) or protected by both cookies and CORS, and the resource acquisition process is configured to simultaneously request the proprietary resources requested by the proxy computer from both the guest computer and the first website.

4. A co-browsing system for providing exclusive resources in a co-browsing session, comprising: One or more processors and one or more memories, when the instructions stored in the one or more memories are executed by the one or more processors, the one or more processors perform the following operations: Instantiating a co-browsing service between a guest computer and an agent computer, the co-browsing service being configured to implement a co-browsing session between the guest computer and the agent computer, and instantiating a resource acquisition process on the co-browsing service, the resource acquisition process being configured to acquire the proprietary resource in the co-browsing session; The visitor computer has an instantiated first browser, the first browser having a DOM describing the content of the first browser, the DOM including objects whose URLs point to the first website, at least some of the objects being the proprietary resources, the first browser further having a co-browsing script loaded therein, the co-browsing script being configured to copy the DOM of the first browser and forward the DOM of the first browser to the agent computer via the co-browsing service in the co-browsing session; The agent computer has a second browser instantiated thereon, the second browser being configured to load the DOM of the first browser received in the co-browsing session and request the proprietary resource referenced in the DOM from the resource acquisition process; The proprietary resources are fonts and cascading style sheets (CSS) resources protected by cross-origin resource sharing (CORS) or protected by both cookies and CORS, and the resource acquisition process is configured to simultaneously request the proprietary resources requested by the proxy computer from both the guest computer and the first website.

5. The collaborative browsing system according to claim 1, 3 or 4, wherein: The co-browse script at the guest browser is configured to transform a first subset of URLs of the first browser's DOM prior to transmitting the DOM to the co-browse service in the co-browse session so that the first subset of URLs points to the resource acquisition process instead of to the first website.

6. The collaborative browsing system according to claim 5, wherein: The first subset of URLs are URLs related to images, fonts and Cascading Style Sheets (CSS), and wherein the proprietary resources also include images.

7. The collaborative browsing system according to claim 5, wherein: The URL of the resource acquisition process is provided by the co-browse service to the co-browse script in the co-browse session, and wherein the co-browse script is configured to convert the first subset of URLs to URLs pointing to the resource acquisition process.

8. The collaborative browsing system according to claim 5, wherein: The URL of the resource acquisition process is created by the co-browse service based on a co-browse server identity identified by the co-browse service hosting the co-browse session, and wherein the co-browse script is configured to convert the first subset of URLs to URLs pointing to the resource acquisition process.

9. The collaborative browsing system according to claim 5, wherein: The co-browse script is further configured to receive a request for resources associated with the first subset of URLs from the resource acquisition process and to respond to the request for resources by providing the requested resources to the resource acquisition process.

10. The collaborative browsing system according to claim 9, wherein: The co-browse script is further configured to process the request for a resource by requiring the resource from the website.

11. The collaborative browsing system of claim 1, 3 or 4, wherein: The process instantiated on the co-browse service is configured to convert a first subset of URLs of the first browser's DOM so that the first subset of URLs points to the resource acquisition process instead of to the first website in connection with transferring the DOM from the first browser to the agent computer.

12. The collaborative browsing system of claim 1, 3 or 4, wherein: The process instantiated on the proxy computer is configured to transform a first subset of URLs of the DOM of the first browser so that the first subset of URLs points to the resource acquisition process instead of to the first website.

13. The collaborative browsing system of claim 1, 3 or 4, wherein: The resource acquisition process is configured as follows: receiving a first resource request from the second browser, the first resource request having a URL identifying the resource acquisition process and further specifying a network address that can be resolved to a first proprietary resource associated with the first website; Through the resource acquisition process, simultaneously sending a second resource request for the first proprietary resource to the first browser and sending a third resource request for the first proprietary resource to the first website; and When the first proprietary resource is received from the first browser or from the first website, the first resource request is responded to with the first proprietary resource through the resource acquisition process.

14. A method for accessing a private resource in a co-browsing session, comprising: a first browser instantiated on a visitor computer, the first browser having a DOM describing the content of the first browser, the DOM including objects with URLs pointing to the first website, at least some of the objects being the proprietary resources, the first browser further having a co-browsing script loaded therein, the co-browsing script being configured to copy the DOM of the first browser and forward the DOM of the first browser to an agent computer via a co-browsing service in the co-browsing session; Instantiating a resource acquisition process on the co-browsing service, the resource acquisition process being configured to acquire the exclusive resource in the co-browsing session; as well as instantiating a second browser on the agent computer, the second browser configured to load the DOM of the first browser received in the co-browsing session and request the proprietary resource referenced in the DOM from the resource acquisition process; The proprietary resources are fonts and cascading style sheets (CSS) resources protected by cross-origin resource sharing (CORS) or protected by both cookies and CORS, and the resource acquisition process is configured to simultaneously request the proprietary resources requested by the proxy computer from both the guest computer and the first website.

15. The method according to claim 14, wherein: The proprietary resources further include images that are protected by CORS or are protected by both cookies and CORS.

16. A method for providing a private resource in a co-browsing session, comprising: Instantiating a co-browsing service between a guest computer and an agent computer, wherein the co-browsing service is configured to implement a co-browsing session between the guest computer and the agent computer, and instantiating a resource acquisition process on the co-browsing service, wherein the resource acquisition process is configured to acquire the exclusive resource in the co-browsing session; The visitor computer has an instantiated first browser, the first browser having a DOM describing the content of the first browser, the DOM including objects whose URLs point to the first website, at least some of the objects being the proprietary resources, the first browser further having a co-browsing script loaded therein, the co-browsing script being configured to copy the DOM of the first browser and forward the DOM of the first browser to the agent computer via the co-browsing service in the co-browsing session; The agent computer has a second browser instantiated thereon, the second browser being configured to load the DOM of the first browser received in the co-browsing session and request the proprietary resource referenced in the DOM from the resource acquisition process; The proprietary resources are fonts and cascading style sheets (CSS) resources protected by cross-origin resource sharing (CORS) or protected by both cookies and CORS, and the resource acquisition process is configured to simultaneously request the proprietary resources requested by the proxy computer from both the guest computer and the first website.

17. The method according to claim 14 or 16, wherein: The co-browse script at the guest browser is configured to transform a first subset of URLs of the first browser's DOM prior to transmitting the DOM to the co-browse service in the co-browse session so that the first subset of URLs points to the resource acquisition process instead of to the first website.

18. The method according to claim 17, wherein: The first subset of URLs are URLs related to images, fonts and Cascading Style Sheets (CSS), and wherein the proprietary resources also include images.

19. The method according to claim 17, further comprising: The URL of the resource acquisition process is provided by the co-browse service to the co-browse script in the co-browse session, and wherein the co-browse script is configured to convert the first subset of URLs to URLs pointing to the resource acquisition process.

20. The method of claim 17, further comprising: The URLs of the resource acquisition process are created by the co-browse service based on a co-browse server identity identified by the co-browse service hosting the co-browse session, and wherein the co-browse script is configured to convert the first subset of URLs to URLs pointing to the resource acquisition process.

21. The method according to claim 17, wherein: The co-browse script is further configured to receive a request for resources associated with the first subset of URLs from the resource acquisition process and to respond to the request for resources by providing the requested resources to the resource acquisition process.

22. The method according to claim 21, wherein: The co-browse script is further configured to process the request for a resource by requiring the resource from the website.

23. The method of claim 16, further comprising: Translating, by the co-browse service, a first subset of URLs of the DOM of the first browser so that the first subset of URLs points to the resource acquisition process instead of to the first website, in connection with the co-browse service transmitting the DOM from the first browser to the agent computer.

24. The method according to claim 14 or 16, wherein: The process instantiated on the proxy computer is configured to transform a first subset of URLs of the DOM of the first browser so that the first subset of URLs points to the resource acquisition process instead of to the first website.

25. The method according to claim 14 or 16, further comprising: receiving a first resource request from the second browser via a resource acquisition process, the first resource request having a URL identifying the resource acquisition process and further specifying a network address that is resolvable to a first proprietary resource associated with the first website; Through the resource acquisition process, simultaneously sending a second resource request for the first proprietary resource to the first browser and sending a third resource request for the first proprietary resource to the first website; and When the first proprietary resource is received from the first browser or from the first website, the first resource request is responded to with the first proprietary resource through the resource acquisition process.

Images