Abstract: A system and method of dynamic search result permission checking. A system that provides end users the ability to search an index (i.e., Shinydocs Index) built from content from one or multiple source repositories, and only display results for which the user has sufficient permissions at source to view. User credentials are validated “on the fly”, such that these checks are performant across a multiple of possible back-end repositories sequentially or simultaneously. The resultant search results from the Index may be sourced from many disparate repositories, each of which have their own unique permission structure (to view individual items). A method for handling permissions in multiple repositories in a secure (yet performant) fashion in order to only display search results that the end-user is allowed to view based on source system permissions.

Abstract: A system and method of improved performant content source crawling. A content source crawling technology that is performant and focused on an initial rapid crawling of a content source to find specific file signatures so that it can determine an inventory of files that have been modified since the last full index event, thereby minimizing the time and computing resources necessary to perform a full crawl on just the select files to update to the search index. A method of Signature Flagging is disclosed and is used to selectively crawl the metadata about contained files and folders found within a content source in order to create that information in an Index within the Shinydocs Search Library.

Abstract: An example includes: a substrate having a first package surface, having a second package surface opposite the first package surface, and having a die cavity with a depth extending into the first package surface; a semiconductor die having bond pads on a first die surface and having a second die surface opposite the first die surface, the semiconductor die having a die thickness, the second die surface of the semiconductor die mounted in the die cavity; a cover over a portion of the first die surface; conductors coupling the bond pads of the semiconductor die to bond fingers on the first package surface of the substrate; and dielectric material over the conductors, the bond fingers, the bond pads, at least a portion of the first semiconductor die and at least a portion of the cover, wherein the dielectric material extends above the first package surface of the substrate.

Abstract: A local cache content management is configured to improve the speed and reliability of access of the content management system across poor or intermittent connections. Additional techniques are used to allow document use and storage when the content management system is unavailable, and to maintain synchronization between the local cache and the content management system.

Abstract: A system and method of updating Content Server metadata on order to update and re-organize documents in a content management system (i.e., Content Server). A content management system includes a tool for setting Content Server metadata attributes, based in values in the index. Content Server Category Attributes can be set, as can Content Server Classification values, as can Content Server RM Classification values.

Abstract: A local cache content management is configured to improve the speed and reliability of access of the content management system across poor or intermittent connections. Additional techniques are used to allow document use and storage when the content management system is unavailable, and to maintain synchronization between the local cache and the content management system.

Abstract: A content management system enables a central server to connect to remote nodes at client sites. Software modules on the remote node is responsible for making necessary calls to the central server in order to create an index of the relevant data (or metadata) and fetch the appropriate binary information and files for the related metadata. Remote nodes are populated with data from the content management system via crawl/synchronize methods, or alternatively a hard drive of the data is initially configured at headquarters whereby data is saved to prevent trafficking data over a potentially unreliable connection over an extended period of time. The hard drive is then installed at the remote site and synchronized with the software module running in high performance enterprise library (HPEL) mode. The HPEL enabled server is configured to crawl and synchronize all the data and pick up differences in data using differential crawls.