Source: https://patents.justia.com/patent/10250710
Timestamp: 2019-06-24 20:28:59
Document Index: 196653175

Matched Legal Cases: ['§ 119', 'Application No. 62', 'Application No. 62', '§ 119', 'Application No. 62', 'Application No. 16164719']

US Patent for Systems and methods for caching of managed content in a distributed environment using a multi-tiered architecture including off-line access to cached content Patent (Patent # 10,250,710 issued April 2, 2019) - Justia Patents Search
Justia Patents US Patent for Systems and methods for caching of managed content in a distributed environment using a multi-tiered architecture including off-line access to cached content Patent (Patent # 10,250,710)
Feb 16, 2017 - Open Text SA ULC
This application is a continuation of, and claims a benefit of priority to, U.S. patent application Ser. No. 15/094,524, filed Apr. 8, 2016, issued as U.S. Pat. No. 10,021,209, entitled “SYSTEMS AND METHODS FOR CACHING OF MANAGED CONTENT IN A DISTRIBUTED ENVIRONMENT USING A MULTI-TIERED ARCHITECTURE” by Ionescu et al., which claims the benefit of priority under 35 U.S.C. § 119 to U.S. Provisional Patent Application No. 62/146,030, filed Apr. 10, 2015, entitled “SYSTEMS AND METHODS FOR CACHING OF MANAGED CONTENT IN A DISTRIBUTED ENVIRONMENT USING A MULTI-TIERED ARCHITECTURE,” by Trufasiu et al., and U.S. Provisional Patent Application No. 62/296,329, filed Feb. 17, 2016, entitled “SYSTEMS AND METHODS FOR CACHING OF MANAGED CONTENT IN A DISTRIBUTED ENVIRONMENT USING A MULTI-TIERED ARCHITECTURE INCLUDING OFF-LINE ACCESS TO CACHED CONTENT” by Pauthner et al. This application claims the benefit of priority under 35 U.S.C. § 119 to U.S. Provisional Patent Application No. 62/296,329, filed Feb. 17, 2016, entitled “SYSTEMS AND METHODS FOR CACHING OF MANAGED CONTENT IN A DISTRIBUTED ENVIRONMENT USING A MULTI-TIERED ARCHITECTURE INCLUDING OFF-LINE ACCESS TO CACHED CONTENT” by Pauthner et al. All referenced applications are hereby fully incorporated by reference herein for all purposes.
In particular, use of these types of centralized management architectures in a distributed network environment may present certain problems, some of the most concerning of which have to do with speed of access. As detailed above, in many cases the users who access content may be distributed, and remote from, a centralized content management platform, with varying speed, bandwidth and reliability of network connections to such a content management platform. Despite these types of variations, all accesses by all users to the managed content must go through the primary content management server in order that the content being accessed may be managed in conjunction with the access. Such accesses may therefore require a number of communications between whatever application is being utilized to access the content and the primary content management server in order to, for example, reconcile permissions, version the content, download the content from the management server to the user's local device, upload changes from the user's application to the central management server, or perform other functionality involve with managing the content.
For at least these reasons then, because access to content may be distributed, and remote from, a centralized content management platform, with varying speed, bandwidth and reliability of network connections, both the availability of content and the speed of access to such content when it is available may be inconsistent. If the network connection is slow or unavailable, a user's access to desired content may be impeded.
In particular, according to certain embodiments, a remote cache server may be associated with a remote site to store local copies of documents that are managed by the primary content management platform. Periodically, a portion (which may be a single document) of remote site's cache may be synchronized with the content management platform's primary site using an extensible architecture to ensure that content at the remote cache server is current. This synchronization may provide users at the remote site dramatically faster access to current content while still adhering to the management model (e.g., permissions or access controls, versioning, etc.) of the primary content management platform.
A primary content management platform may, however, serve as a centralized access point for the content, applying permissions, versioning, etc. to the content. The use of these types of centralized management architectures may present certain problems having to do with availability of, or speed of access to, content. Because access to content may be distributed, and remote from, a centralized content management platform, with varying speed, bandwidth and reliability of network connections, the availability of content may be inconsistent. Specifically, if the network connection is slow or unavailable, a user's access to desired content may be impeded. What is desired are systems and methods which speed or otherwise serve to optimize access to this manage content in a distributed environment.
Primary content management platform 140 may, for example, be one or more computers configured with OpenText's Content Server, OpenText's Archive Server or another type of repository, content management or storage server (collectively referred to as a content management platform or server, a repository platform or server or a primary server). The content managed by primary server 140 may be stored on a data store (electronic file store (EFS)) 142 associated with the primary server 140 itself, or may, in turn, be stored and managed by another repository server 150 which itself has an EFS 152.
In cases where the content is stored or managed by another repository server 150, the primary server 140 may include metadata on the content indicating the repository server 150 on which the content is stored in addition to any other metadata maintained by primary server 140 on the content. Such a repository server 150 may, for example, be an instance of OpenText's Archive Server or Content Server.
Accordingly, in certain embodiments for remote caching as depicted herein a multi-tiered architecture may be implemented in conjunction with the remote cache servers deployed at user's sites to minimize communications between other tiers of the caching system (and between tiers of the caching system and management platforms) and to optimize those communications.
Remote cache server 220 may also include cache client interface 225, which includes one or more interfaces configured to accept requests from an application 212 for use with a particular type of repository platform which may be utilized as primary server 240. For example, one interface may be configured to accept and process requests from application 212 for use with OpenText's Enterprise Connect while another module may be configured to accept and process requests from application 212 for use with OpenText's Archive Server. For example, one of the cache client interfaces 225 may be a common gateway interface (CGI) configured to be accessed from applications 212 that are utilized in a web based environment. Thus, such a CGI interface could, for example, accept requests issued through a hypertext transfer protocol (HTTP) GET or POST with a particular universal resource locator (URL).
For example, one repository connector may be configured for use with OpenText's Content Server while another repository connector may be utilized with OpenText's Archive Server. It will be noted that in certain embodiments, such repository connectors may be instantiated or deployed for each repository platform with which the primary content transfer module 244 is to be utilized such that there may be a one to one correspondence with repository connectors and repository platforms being utilized with the primary content transfer module 244.
The cache client interface 225 can then reply to the user through the application 212 or an independent interface informing the user that the requested content is unavailable, informing the user that a version of the content is available locally and providing the user the ability to access the local version of the content (in the cache 222). The user can then be allowed to access the local version of the requested content in the cache 222. In one embodiment, the user may be granted only read access to such content to facilitate multiple users' access to the content or to ensure that synchronization or version issues are not encountered when primary server 240 once again becomes available.
In one embodiment, the metadata in DB 228 may include associated permissions for the content in cache 222. By storing such permissions, a requesting user's permission may be checked against the permissions associated with the requested content and stored in DB 228 by remote client transfer module 226 or cache client interface 225. Access to the local copy of the requested content stored in cache 222 may then be granted to the user if the user is allowed to access the requested content based on the locally stored permissions in DB 228.
In a particular embodiment, permissions may be managed utilizing a directory server such as Active Directory or OpenText Directory Services (OTDS). The directory server (not shown) may be utilized to authenticate all users of the primary server 240. At those remote sites 210, or in conjunction with remote cache server 220, a federated directory server, such as an OTDS replication server or the like will be deployed and connected to the primary directory server utilized with the primary server 240. The primary and replication directory servers may keep their data synchronized through periodic updates automatically. The primary directory server (e.g., primary OTDS) is connected to an entity's enterprise directory (e.g., Microsoft Active Directory/LDAPv3 server) and will update the replication server(s) as needed. In the event there is a temporary network interruption, the primary directory server will resume updating the replication servers as soon as the network is available again.
Remote client transfer module 325 and primary content transfer module 334 may cooperate to store content managed (including stored) by a repository platform 340 in the cache 322 at the remote cache server 320. The content stored in the cache 322 at the remote cache server 322 provide quicker access to the content managed by the repository platform 340. Remote client transfer module 325 and primary content transfer module 334 also cooperate to keep content in cache 322 synchronized with the content managed at by the repository platform 340. Accordingly, remote client transfer module 325 and primary content transfer module 334 may communicate metadata or content between themselves to accomplish this synchronization. In one embodiment, the transfer of content may occur according to a particular protocol utilized by remote client transfer module 325 and primary content transfer module 334, and implemented through protocol modules 327 and 337, to increase both the speed and reliability of the transfer of content between the remote client transfer module 325 and primary content transfer module 334.
As a result, content may be more quickly and reliably accessed by users utilizing repository platform applications 302. These repository platform applications 302 may include applications that may be deployed in a remote site or on a user's device within the remote site and be configured to be clients of a type of repository platform 340 to allow a user to access content managed by that repository platform 340. For example, content web services 302a may be an application that uses web services to allow a user to access managed content, browser application 302b may be an application or interface configured to be executed or rendered by a browser to allow a user to access content managed by a repository platform 340. Office integration application 302c may be a plug-in or other application that may be utilized with Microsoft Office Applications (e.g., Word) to allow content managed by a repository platform 340 to be accessed. Similarly, SAP integration application 302d may be an application designed to integrate with a repository platform 340 using interfaces or associated with SAP (e.g., SAP SE of Walldorf, Germany). Other application 302n (e.g., deployed differently or designed to integrate with different repository platforms 340) may be utilized.
Cache client interface providers 312 include one or more modules 312 configured to accept and respond to requests from applications 302, where each of the modules 312 may be configured for a particular type of request. For example, remote cache (RC) interface 312a may be configured for requests that correspond to a remote caching systems that an application 312 is configured to utilize. For example, one or more repository platform applications 302 may be configured to utilize a caching platform such as OpenText's cache server or the like. Thus, the remote cache interface 312a may be configured to accept requests in the format utilized by the caching platform such that these requests may be implemented in conjunction with embodiments of the distributed remote caching architecture through remote cache server 320 and primary content transfer module 334 without alteration or modification of repository platform applications 302.
ENCRYPTION_KEY_ID—id for the key in a DOC SYSTEM KEYS table used to encrypt the document key. If content is not encrypted the value is −1
Repository platforms 340, as discussed above, may be any storage or content management platform such as for example, OpenText's Content Server 340a, 340c or OpenText's Archive Server 340b. Other repository platforms 340n are also contemplated. Such repository platforms 340 may accept and respond to requests associated with managed content. The managed content may be stored locally on the repository platform 340 or may be stored on another repository platform 340.
As described above, to insure that remote caching systems as disclosed herein may be utilized with different types of repository platforms 340 being utilized as a primary content management server one or more repository connectors 332 may be utilized be primary content transfer module 334. Each repository connector 332 is configured to receive requests and issue requests associated with the requested functionality to a corresponding type of repository server 340. For example, repository connector 332a, 332c may be configured for use with OpenText's Content Server while repository connector 332b may be configured for use with OpenText's Archive Server. Repository connectors 332n configured for use with other types of repository platforms are also contemplated.
When platform application 302 issues the request it is intercepted or received at a cache module client 312 (e.g., CGI interface 312b) at a remote cache server 320 for the user's site that is associated with the repository server 340 that is the primary content management server. Alternatively, the request from the application 302 may be issued as a request to a remote cache service or server associated with a particular repository platform 340 which manages the content. In this case, the request may be intercepted by a cache module client 312 (e.g., remote cache interface 312a) associated with the remote cache service.
For example, a requested action (e.g., access) may be determined by an argument in the query string received by the CGI interface 312b. A URL (or portion thereof) received at CGI interface 312 may look like: http://nionescu-t.opentext.net/OTCS/cs.exe?func=ll&objId=8042&objAction=download&viewType=1. The “objAction” argument may specify the requested operation. Thus, if the value for such an argument is “download”, “downloadrenditionaction”, “doc.fetch”, “doc.view”, etc. CGI interface 312b may determine that an access to a document requiring retrieving or providing the document is what is being requested. Other arguments may include an identifier for a document (or component) and version, among other arguments.
Command URL String Description GET /component/{component_id}/cache Get information about the specified component. Only the metadata may returned not the content. The information may be taken from the local cache 322. POST /component/{component_id}/contents Upload a component stream. GET /component/{component_id}/contents Get the stream of a component of a document. POST /component Create a component object. GET /component/{component_id} Get information about the specified component. Only the metadata may be returned not the content.
Using the metadata obtained on the requested content from the primary content management server for that content the permissions may be checked at step 414. In particular, primary content transfer module 334 can determine if the user who issued the initial request has appropriate permission to perform the requested access on the requested content. In one embodiment, this can be done by obtaining permissions associated with the user using the identifier for the user included in the received request and the metadata on the requested content obtained from the primary content management server 340. If the requesting user does not have appropriate permissions for the requested access on the requested content at step 416 a response may be sent to remote client transfer module 325 indicating the user's request should be denied at step 418.
For example, a requested action (e.g., upload) may be determined by an argument in the query string received by the CGI interface 312b. A URL (or portion thereof) received at CGI interface 312b may look like: http://nionescu-t.opentext.net/OTCS/cs.exe?func=ll&objId=8042&objAction=doc.addversion2&viewType=1. The “objAction” argument may specify the requested operation. Thus, if the value for such an argument is “doc.addversion2”, “create”, “create2”, etc. CGI interface 312b may determine that an access to a document requiring uploading the document is what is being requested. Other arguments may include an identifier for a document (or component) and version, and the content itself, among other arguments.
1. A system for remote caching, comprising:
a primary content management server for managing content;
a remote cache system, including: a cache; an interface to a network; a data store for storing metadata corresponding to content stored in the cache, wherein the content in cache is managed by the primary content management server; and
a remote client transfer module, configured for: accessing the data store to determine if first metadata associated with designated content is stored in the data store; sending a first request to a primary content transfer module associated with the primary content management server; receiving a first response from the primary content transfer module including second metadata; if first metadata associated with the designated content is stored in the data store: comparing the first metadata to the second metadata to determine if a version of the content stored in the cache is a current version of the content; if the version of the content stored in the cache is a current version, setting a flag in the first metadata to designate the content as resident; if the version of the content stored in the cache is not the current version or if no first metadata associated with the designated content is stored in the data store: sending a second request for the current version of the content to the primary content transfer module; receiving the current version of the content; storing the current version of the content in the cache; and setting a flag in the first metadata to designate the content as resident; the primary content transfer module configured for: receiving the first request associated with the content from the remote client transfer module; sending a third request to the primary content management server for the second metadata associated with the content; returning the first response, including the second metadata to the remote client transfer module; receiving the second request for the current version of the content; obtaining the current version of the content from the content management platform; returning the current version of the content to the remote client transfer module; and wherein the remote client transfer module is further configured for: receiving a fourth request to access the content, wherein the fourth request is associated with a user; determining that the primary content transfer module is inaccessible over the network; accessing the data store to determine that the requested content is in the cache; and providing the content in the cache in response to the fourth request.
2. The remote caching system of claim 1, wherein the remote client transfer module is configured for receiving a first request to designate content as resident in the cache.
3. The remote caching system of claim 1, wherein the remote client transfer module is configured for synchronizing the designated content with the primary content server at some interval asynchronously to servicing user requests.
4. The remote caching system of claim 1, wherein heartbeat messages are sent between remote client transfer module and the primary content transfer module to determine that the primary content transfer module is inaccessible over the network.
5. The remote caching system of claim 1, wherein providing the content in the cache comprises providing a location of the content to the user.
6. The remote caching system of claim 1, wherein the fourth request is received from one of a set of cache module clients, each cache module client corresponding to a type of repository platform application.
7. A method for remote caching, comprising:
accessing, at a remote client transfer module, a data store of a remote cache system including a cache and the data store to determine if first metadata associated with designated content is stored in the data store, wherein the data store is for storing metadata corresponding to content stored in the cache and the content in the cache is managed by a primary content management server;
sending a first request to a primary content transfer module associated with the primary content management server;
receiving a first response from the primary content transfer module including second metadata; if first metadata associated with the designated content is stored in the data store: comparing the first metadata to the second metadata to determine if a version of the content stored in the cache is a current version of the content; if the version of the content stored in the cache is a current version, setting a flag in the first metadata to designate the content as resident; if the version of the content stored in the cache is not the current version or if no first metadata associated with the designated content is stored in the data store: sending a second request for the current version of the content to the primary content transfer module; receiving the current version of the content;
setting a flag in the first metadata to designate the content as resident;
receiving, at the primary content transfer module, the first request associated with the content from the remote client transfer module;
sending a third request to the primary content management server for the second metadata associated with the content;
returning the first response, including the second metadata to the remote client transfer module;
obtaining the current version of the content from the content management platform;
returning the current version of the content to the remote client transfer module; and
at the remote client transfer module:
receiving a fourth request to access the content, wherein the fourth request is associated with a user;
determining that the primary content transfer module is inaccessible over the network;
accessing the data store to determine that the requested content is in the cache; and
providing the content in the cache in response to the fourth request.
8. The method of claim 7, wherein the remote client transfer module is configured for receiving a first request to designate content as resident in the cache.
9. The method of claim 7, wherein the remote client transfer module is configured for synchronizing the designated content with the primary content server at some interval asynchronously to servicing user requests.
10. The method of claim 7, wherein heartbeat messages are sent between remote client transfer module and the primary content transfer module to determine that the primary content transfer module is inaccessible over the network.
11. The method of claim 7, wherein providing the content in the cache comprises providing a location of the content to the user.
12. The method of claim 7, wherein the fourth request is received from one of a set of cache module clients, each cache module client corresponding to a type of repository platform application.
13. A non-transitory computer readable medium, comprising instruction for implementing remote caching in a system including a primary content management server for managing content, a remote cache system including a cache and a data store for storing metadata corresponding to content stored in the cache, where the content in cache is managed by the primary content management server, the instruction translatable to implement a remote client transfer module and a primary content transfer module, and
at a remote client transfer module:
accessing the data store to determine if first metadata associated with designated content is stored in the data store;
at the primary content transfer module: receiving the first request associated with the content from the remote client transfer module;
14. The computer readable medium of claim 13, wherein the remote client transfer module is configured for receiving a first request to designate content as resident in the cache.
15. The computer readable medium of claim 13, wherein the remote client transfer module is configured for synchronizing the designated content with the primary content server at some interval asynchronously to servicing user requests.
16. The computer readable medium of claim 13, wherein heartbeat messages are sent between remote client transfer module and the primary content transfer module to determine that the primary content transfer module is inaccessible over the network.
17. The computer readable medium of claim 13, wherein providing the content in the cache comprises providing a location of the content to the user.
18. The computer readable medium of claim 13, wherein the fourth request is received from one of a set of cache module clients, each cache module client corresponding to a type of repository platform application.
10021209 July 10, 2018 Ionescu
20110225373 September 15, 2011 Ito
20130138763 May 30, 2013 Panzer
20130198313 August 1, 2013 Hayton
20160301766 October 13, 2016 Ionescu et al.
20180332133 November 15, 2018 Ionescu et al.
2 650 795 October 2013 EP
Notice of Allowance for U.S. Appl. No. 15/094,524, dated Mar. 13, 2018, 14 pages.
Extended European Search Report issued for European Patent Application No. 16164719.3, dated Jun. 3, 2016, 17 pgs.
Anonymous: “Web cache—Wikipedia, the free encyclopedia,” May 31, 2014, XPO55223230, [Retrieved on Oct. 23, 2015 from <<URL:https://web.archive.org/web/20140531225019/http://en.wikipedia.org/wiki/Web_cache>>], 3 pgs.
Anonymous: “Digest Access Authentication—Wikipedia, the Free Encyclopedia”, Mar. 9, 2015, XPO55273057, [Retrieved on May 17, 2016 from <<URL:https://en.wikipedia.org/w/index.php?title=Digest_access_authentication&oldid=65585396>>], 8 pgs.
Anonymous: “Squid (Software)—Wikipedia, the Free Encyclopedia,” Mar. 20, 2015, XPO55273110, [Retrieved on May 17, 2016 from <<URL:https://en.wikipedia.org/w/index.php?title=Squid_(software)&oldid=652760343>>], 5 pgs.
Anonymous: “URL Redirection—Wikipedia, the Free Encyclopedia,” Mar. 22, 2015 (Mar. 22, 2015), XPO55273101, [Retrieved on May 17, 2016, from <<URL:https://en.wikipedia.org/w/index.php?title=URLredirection&oldid=653028966>>], 11 pgs.
Anonymous: “Working Off the Grid with HTML5 Offline—HTML5 Rocks”, Apr. 28, 2014, XPO55273439, [Retrieved on May 18, 2016, from <<URL: https://web.archive.org/web/20140428080331/http://www.html5rocks.com/en/mobile/workingoffthegrid/?redirect_from_locale=de>>], 7 pgs.
Office Action for U.S. Appl. No. 15/094,524, dated Sep. 20, 2017, 19 pages.
Office Action for U.S. Appl. No. 16/006,317, dated Sep. 25, 2018, 15 pgs.
Patent number: 10250710
Patent Publication Number: 20170161293
Inventors: Nicolae Ionescu (Toronto), Dan-Horia Trufaisu (Newmarket), Peter Varga (Markham), Tao Zhou (Richmond Hill), Franz Pauthner (Zorneding), Yue Kuk Wong (Toronto)
Application Number: 15/434,235