The CP Split can utilize MultiCryption™ software security tools to provide a unique, multi-level, data security process for exceptional data protection.

MultiCryption software uses four special levels of encryption for a virtually foolproof way to secure data files as they move across the Internet. It sets a new standard for data protection -- that is even immune to brute force attacks -- with these unique security methods:

1. File Decomposition/Recomposition - Breaks a data file into several sub-files for transmission and reassembles them upon receipt using keys
2. Data Expansion/Contraction - Separates the words, punctuation and numeric data in each sub-file into individual characters for transmission and puts them back into the correct words and numbers upon receipt using keys
3. Counter-Crypto - Adds additional characters, based on a statistical distribution analysis, for transmission and removes the extra characters upon receipt using keys
4. Data Scrambling/Unscrambling - Mixes up all the characters in a random manner for transmission and rearranges them upon receipt using keys

Click this link for more: MultiCryption™ technology

As discussed in the previous posts, the nodes use the CP Split’s patented process uses template models to:

1. Create Content Configurations in a Content File Production Grid (CFP) Grid using spreadsheet and third-party applications
2. Transfer these Content Configurations into a Content File for storage and distribution
3. Transfer the Content Configurations from the Content File into a Content File Consumption (CFC) Grid where (a) formatting instructions from spreadsheet and third-party applications present reports by rendering each content element based on its location within the spreadsheet and (b) the content elements may also be sent to populate databases.

This process differentiates the CP Split from all other technologies used for the distribution and presentation of reports. Following is a discussion of these differences and the benefits of using the CP Split technology.

How Does the CP Split Differ from Database Report Writers?

The CP Split technology differs from database report writers in the following operations:

• Database report writers and the CP Split differ in the way they retrieve the content for a report:
  • With a database report writer, the end user/client (i.e., a Subscriber node) must query a database, and indicate how the returned data are to be analyzed and formatted. The user selects predefined report formats or creates new ones.
  • With the CP Split, the end user does not query a database when generating a report. Instead, a Publisher node does any required database querying, as well as any required data analyses and other non-formatting manipulations of the data returned from the queries. It then organizes the resulting content into Content Configurations in its CFP Grid. The framework (grid-based structure) for organizing the content into configurations are created when the Publisher and Subscriber/Presenter Templates are developed and assure that the Content Configurations in the Publisher's CFP Grid correspond to their Subscribers’ CFC Grids (the next post discusses best practices for building the Content Configurations). Like the database reports, the queries, analytics, and formats may be predefined for its Subscribers, or new ones may be created via instructions from Subscriber nodes.
• Once the data queries and analytics are done, the resulting content must be formatted for report presentation. Types of report formats include columnar, crosstab, form, label, and OLAP/pivot table, and their views may include graphs/charts, lists, tables, text boxes, and more. Database report writers and the CP Split differ in the way they manage and format content for presentation:
  • Database report writers render queried content through instructions that format content elements based on their fields (and possibly other attributes). Reports can be published to a variety of file formats for distribution, including XML, PDF, HTML, RTF, Word, Excel, text, and more.
  • With the CP Split, the Publisher node places the Content Configurations from the CFP Grid to Content Files for storage and transmission, and then sends the files to its Subscriber nodes. Upon receipt, each Subscriber node places the Content Configurations from the Content File into its CFC Grid and formats the content elements for presentation through formatting instructions applied to particular content elements based on their cell locations in the CFC Grid.

Compared to database report writers, the CP Split has distinct advantages when disseminating interactive reports containing numeric values and related visualizations (e.g., charts/graphs, etc.). This is because the CP Split technology keeps the numeric content "live" – i.e., the numbers are not embedded in markup tags or converted to text – so they are ready for reuse immediately. This means there is no need to re-entry the data, use screen scrapers, or do time-consuming data parsing and transformations when using the CP Split. Furthermore, the CP Split enables content to be transmitted in its most efficient form, i.e., in delimited formats (such as in CSV files) that contain no formatting instructions, markup tags, or programming code.

How Does the CP Split Differ from Spreadsheet Reports?

To understand the CP Split more fully, it is necessary to compare it to technologies beyond database report writers.

For example, it is possible to distribute entire spreadsheet workbooks filled with the content, formatting instructions and macros. This is a very inefficient approach because every time the content is updated or used by a different model, new workbooks must be distributed, which can be very large (many megabytes). This approach also makes it difficult to track changes made to the content or models over time - for auditing purposes for example - since multiple version of the workbooks must be stored, which can require complex versioning controls.

A more sensible and elegant method for delivering report updates is to use the CP Split to distribute the content, and only the content, in delimited text Content Files. These files are a tiny fraction of the size of entire workbooks because they do not contain formatting instructions, code, or markup tags. In addition, they provide easy auditing (through change management methods) and file management (by using ID numbers to maintain the proper association between Content Files and the template files that produce and consume them). The workbooks containing the models are only redistributed if the models represented in the templates changes, which may me necessary, for example, if the schema of the source data changes.

Benefits of the CP Split Technology

The benefits of this unique approach are realized when content is shared between nodes using different template models to generate different reports, or between different nodes with the same template model to generate the same report.

The CP Split technology, therefore, offers this unique set of benefits:

• Content from diverse sources can be integrated and stored in a uniform structure for use across multiple platforms and applications, which provides a simple, transparent (human readable), and auditable interoperable architecture


• Different audiences can receive different portions of the content and have it rendered in particular ways based on what they need for personalized reports


• Content can be integrated from different sources easily for distributing composite reports


• Portions of a Content File can be sent to different sources (e.g., to populate a data warehouse)


• Content can be manipulated (e.g., analyzed, adjusted, transformed) without costly conversion from appearance-based text representations


• Content can be repurposed quickly and easily for different presentation media


• Content is transported in smaller files that consume less bandwidth because they do not contain formatting instructions, markup tags, or code


• Exceptional speed and efficiency is achieved when dealing with numbers and computations, and when generating charts and graphs, because the Content Configurations can be distributed in their proper "serialized" order, which enables rendering engines to generate charts and graphs more quickly and easily


• Different models with different formulas can be used to calculate the same set of data from a Content File, and sets of data from Content Files can be modified on-the-fly to accommodate different computational models (e.g., when doing real-time "what-if" scenarios, when slicing & dicing aggregated data) -- all without complex or time-consuming pre-processing, e.g., there is no need for database queries, for XML parsing and XSLT transformations, and for online analytic processing (OLAP) by the client (see RocketOLAP™)


• Changes can be made to the data in a model and those changes distributed as necessary, which is important when (a) editing out mistakes or updating sets of data, (b) creating and analyzing what-if scenarios, and (c) computing the same set of data using several analytic models because these activities may require somewhat different data.


• Data can be added to a model and those additions distributed when necessary, which is important in collaborative situations when (a) different people must input data to complete a data set, (b) automated (unmanned) nodes supply data, and (c) several analytic models are used to compute the same set of data, and certain models require additional data


• Portions of a data set can be restricted from being accessed by particular models, which is important when different users with different roles require only a portion of a data set; it helps assure people get to see only the data they need to minimize information overload and protect data from being viewed by unauthorized persons


• Content can be "scrambled" for a unique form of security that is forever immune to brute force attacks (see MultiCryption™).

Up to this point, I described how the nodes' asynchronous publish-subscribe process works, and discussed the use of spreadsheet templates for producing and consuming content files. This describes the inner workings of the CP Split technology.

Start by clicking this link for a PowerPoint presentation of the CP Split inner workings. Additional information follows.

The Publisher Template

If a node has publisher functionality, its Publisher Template must be pre-configured to execute the operations required for Content File creation and transmission. During this process, a reference tuple is created. Once CP Split is configured, the reference tuple is used in the process to ensure continuous referential integrity and entity integrity. Hence, this reference tuple promotes versioning.

One type of pre-configuration involves database queries. That is, if a Content File will contain data from one or more databases, the proper SQL/ODBC query code (macro/script) must be written in its template’s grid code layer. In an MS Windows operating system using Excel as the node’s underlying application, for example, the query for each database must be configured with the correct login ID & password, and it must use the correct ODBC drivers. In addition, the proper fields and records must be identified, as well as the particular spreadsheet cells into which the queried data are to be sent.

Using a Publisher Template’s macros to execute the queries enables them to be initiated automatically via remote request by having the Publisher node execute the correct queries for each of its Subscriber nodes based on ad hoc and pre-scheduled requests from its Subscriber(s). The following key processes occur automatically:

• Prior to creating a Content File for a Subscribing node, a subscription manager in the Publisher Template must store the IP addresses and authorization information for all Subscriber nodes authorized to communicate with it. This can be done, for example, by distributing to each node a list of authorized nodes, by using a centralized directory, or by having information requests and responses go to intermediate nodes that do the authorization before allowing them to be sent.


• The Publisher node must also be pre-configured to establish communication standards with each Subscriber, i.e., a “hand-shake” that ensures the nodes communicating with one another (a) are allowed to connect (i.e., their connections are authenticated) and (b) agree on how the transmission will proceed by defining how information requests from each Subscribing node must be structured and how the Content File is to be organized by the Publisher node to enable the Subscriber node’s template to read and present it as a report. For example, during the establishment of the node network, each node’s Template File would be set up with the forms, code, and metadata needed to send information requests and Content Files to each other in a way that enables each node to understand the specific data in specific cells by virtue of their cell locations in a spreadsheet.


• For ad hoc requests – such as a doctor (Subscriber) requesting the data of one or more patients from other healthcare providers (Publishers) with a different EHR systems who treat the same patients – each Publisher node’s Template File bases its queries on the requested information sent by an authorized Subscriber’s node, including patient identifiers and requested data sets. It’s macros use this information to define the correct table, records and fields to query via metadata in the models (e.g., database schema maps) and subscription rules (e.g., rules defining allowable fields to be queried based on each Subscriber’s healthcare specialty).


• For pre-scheduled requests, a node’s Publisher Template executes rules for performing such functions as sending certain Subscribers particular patient data automatically whenever the Publisher updates those data. These rules determine the queries to be executed and the spreadsheet cells into which the queried data are sent.


• Whether ad hoc or scheduled, once the required data sets are queried and stored in the appropriate spreadsheet(s), these data are then processed by cell formulas (which may be in other spreadsheets) and macro functions as defined by the Publisher Template’s models. This functionality may be integrated into third-party products such as statistical/data mining applications, inferential logic engines, etc. This processing performs any required data analytics and transformations. It then organizes the resulting data value and text strings into pre-defined cellular configurations (i.e., “Content Configurations”) in a spreadsheet (i.e., the “Content File Production Grid” or “CFP Grid”), the cell positions of which are known by the Subscriber/Presenter Template as discussed below.


• When this processing is done, the Publisher Template then saves the arrays of values and strings, without any formatting instructions and code, in a delimited text file (such as CSV format) for maximum efficiency, or in other less efficient file formats (such as spreadsheets, XML, etc.). This file is the Content File.


• Once the Content File is created, other Publisher Template functions send it to the appropriate Subscriber nodes as an e-mail attachment or via other means (e.g., FTP).

The Subscriber/Presenter Template

If a node has subscriber and report presentation functionality, its Subscriber/Presenter Template must be pre-configured to execute the operations required for consuming and rendering particular Content Files. Using its template’s spreadsheets and macros to consume and render a Content File enables a node to composite and generate reports without ever having to query a database or connect to other data sources. Following are key processes:

• Prior to receiving a Content File from a Publisher node, the Subscriber node’s Subscriber/Presenter Template must be pre-configured to establish a certain communication standards with the Publisher, as discussed above.


• Once a Subscriber node receives a Content File from an authenticated Publisher node, it uses the pre-configured models that have been assigned to that Publisher node to consume the Content File. This process involves using a macro to take the data and information contained in the Content File and parsing them into specific, pre-determined cells in a spreadsheet (the “Content File Consumption Grid” or “CFC Grid”). There is a semantic correspondence between the cellular locations of the content in the CFP Grid and the CFC Grid, which enables both the Publisher and Subscriber to “know” the particular content elements stored in each cell.


• Once the Content File’s contents are in the CFC Grid, Excel macros and cell functions format the contents of single cells or cell ranges and present them in reports as populated user forms, charts/graphs, grids, lists, text blocks, hyperlinks, etc. as specified by the template’s models. The models may limit reports to single views or provide user interactivity that enables different views of the data (e.g., data slicing/dicing/drill-down, “what-if” scenarios, choice of graphs, etc.). And if a composite report is to be generated, the Subscriber node takes multiple Content Files from one or more Publisher nodes and parses each on to pre-defined portions of the CFC Grid. It then combines parts of this content as defined by its models and renders it accordingly.


• In addition to (or instead of) presenting reports through the Excel workbook, the Subscriber/Presenter Template could enable third-party report writers to access the CFC Grid and generate the reports. Or it can send the data from the Content File to a database the third-party report writers can access.


• If a Subscriber/Presenter Template is configured to populate databases with the data from Content Files for report generation or other purposes, it must have the proper SQL/ODBC query code (macro/script) including the correct login ID & password and ODBC drivers. In addition, the proper fields and records must be identified, as well as the particular spreadsheet cells from which the data are to be obtained.

This post depicts how the publisher-subscriber functions of the node network and the CP Split technology are used to transmit information between the nodes in a peer-to-peer (P2P) architecture.

The image above describes the basic components and processes. The two arrows coming out of the Template Models box depict both publisher and subscriber/presenter grid-based template-models (spreadsheet workbooks) used by the nodes.

The Node as Publisher box depicts a node using one or more of its publisher template-models to:

• Acquire content from the sources specified by its models -- as depicted by the arrow from Data Input to Data/Information Sources -- and place each content element in the cells of software grids (spreadsheet worksheets).


• Manipulate the content in the cells as necessary using mathematical, statistical, financial, logical, inferential, date & time, and/or text functions as defined by the algorithms in its template-models.


• Package the resulting content in encrypted, delimited (e.g., comma separated value) Content Files and transmit them to its subscribers via e-mail or any other methods as depicted by the Content File box. Note that these files contain the actual content to be reported, including (a) ranges of calculated and raw numeric values and (b) text (e.g., strings and blocks of alphanumeric text, hyperlinks to documents and graphic files, web site URLs, etc). They do not, however, contain any formatting instructions or metadata, which make the files very small.

The Node as Subscriber box depicts a node’s subscriber/presenter template-model taking the contents of the Content File it receives and placing each content element in pre-defined cells in its own template-model grid having a structure mirroring the template-model used by the publisher to create the Content File. In this way, the subscriber/presenter template-model “knows” what content elements are located in each cell by virtue the cell’s location in the grid. The subscriber/presenter template model then does two things:

• It immediately formats its contents obtained from the content-file and displays it in interactive reports responsive to user requests, as depicted by the arrow to Report Display.


• It allows the user to query or input new data into its user interface or to modify existing data, which is then sent to a database for storage, as depicted by the arrow from Data Input to Data/Information Sources.

Note that a single node can have both publisher and subscriber functionalities and a single node can publish to any number of subscribers. Also note that a node can interface with just about any software application via APIs.

The image above depicts a node with both publisher and subscriber/presenter functionality. In this image, a node's:

• Publisher functions involve managing subscriptions and transmitting Content Files to its subscribers as defined by its Publisher Template-Model.

• Subscriber/Presenter functions, which are defined by a node's Subscriber/Presenter Template-Model, includes:
  • Subscriber functions involve retrieving Content Files sent from publisher nodes
  • Presenter functions involve formatting/rendering the Content File's contents and presenting it as interactive reports.

• Node Processing functions, which are also defined by a node's Template-Models, include the processes that:
  • A publishing node uses for obtaining and manipulating the content
  • A subscribing/presenting node uses to (a) convert (format/render) a Content File into user-interactive reports, (b) enable manual data input, (c) modify existing data in reports, (d) query external data sources for additional content and adding it to the report
  • Enable a node to interface with external software applications through APIs.

The graphic above depicts how network of nodes operate to exchange information:

Step 1: The solid black line depicts the node at the top retrieving and processing content to create a Content File using node functions defined in its Publisher Template-Model.

Step 2: The solid blue arrows show the node at the top using the publisher functions defined in its Publisher Template-Model to send Content Files via encrypted e-mail attachments to the node at the upper right, the nodes on the left, and the node at the bottom.

Step 3: This dashed arrow shows the top node, after sending Content Files to the node on it left, subsequently receives Content Files from that same node via the subscriber functionality of its Subscriber/Presenter Template-Model. This means both these nodes invoke their publisher and subscriber functionality.

Step 4: These two nodes only receive Content Files; their publisher functionality is not invoked.

Step 5: These dotted arrows show Content Files being passed sequentially from one node to the next, with each node adding new information and/or modifying the files it receives, before sending extended Content Files to the next node.

Step 6: The bottom node receives Content Files from two other nodes. After forming a composite Content File from the accumulated content as defined by its Publisher Template-Models, it sends the composite Content File back to the node at the top.

This post contains links to technical information about how the CP Split™ technology works.

• The upper image describes the CP Split's publisher-subscriber/presenter functionality; click it for an interactive view.
• The lower image is a flowchart of the CP Split's basic functions.

Note that in these diagrams and in subsequent posts, I use the term "template" to refer to grid software (spreadsheet applications) upon which nodes are built. These templates reflect different models by predesigning its formulas, labels, macros, and other essential elements based on those models. A node may use a Publisher Template, a Subscriber/Presenter Template, or both; these templates enable the node to execute the functions defined by the model it deploys.

In the next post, I will show how the CP Split works within node networks.

Please post your questions and comments.

Click image above to enlarge

Note: Nodes have other processing functions that work in conjunctions with the Publisher and Subscriber-Presenter functions, which I discuss in the next post.