Designed Source: Software developed under Cubicon represent executable designs that do not require interpretation or compiling. A 'distilled' design will execute directly via a CubeRun Context Engine on existing ILP processor architectures or can be synthesized into circuits for native execution on a future Context Processor. This novel machine architecture will have the programmability of a microprocessor with the concurrency of an ASIC. A native Cubicon system executing within a Semantic Processor performs task switching entirely in hardware, thus eliminating the requirement for a software operating system to perform this core function.

An executable design is captured in iconic notation via the CubeStudio Integrated Development Environment (IDE). This IDE is completely syntax-driven and semantically-bound bringing a very high degree of design automation to the system development process. A system declared in Cubicon represents a virtual design that can be targeted for either software or hardware execution as a late binding decision.

Rationale: We believe that there is a fundamental deficiency in the way that formal IP is captured in lexical source code languages.

These deficiencies greatly reduce the velocity of shared understanding and thus impede independent peer review and continuous evolutionary improvement.

Without clear and concise understanding, it is difficult to efficiently add to the formal knowledge pool. Most source code is represented in English that impedes the world's majority not proficient in this language. Cubicon's iconic syntax expresses common semantic knowledge in a language-neutral notation that is tagged with interchangeable lexical tokens. This technique greatly increases the population who can participate in the development of shared knowledge.

The wide chasm that currently exists between software and hardware development languages and tool chains increases the difficulty in efficiently developing systems to power the growing population of devices that require tight software and hardware binding.

Designed Source: CubeExchange – Cubicon components are the optimal architecture required for design reuse and robust commerce for Intellectual Property (IP) exchange and collaboration. CubeExchange enables developers to publish their designs without fear of losing their component IP rights and where revenue collection and auditing of IP are automated.

Cubicon-based components have the inherent property of 'unpremeditated compatibility.' This means that a third party component can be 'morphed' into an existing component without prior agreement between the producer and consumer and without the development of an Application Programming Interface (API). CubeExchange serves as a powerful Internet infrastructure layer that will directly support the growing worldwide Cubicon community at large. This community will be extremely productive due to the attributes of a shared system model. This superior model will displace the current 'Tower of Babel' paradigm with its many disparate languages and fractured methodologies.

Free Worldwide CubeStudio Distribution – CoreTalk is focusing its business activities at the horizontal infrastructure level, leaving all vertical application development opportunities to enterprise and individual entities. By providing the means for component producers to maintain rights, and profit from their distributed IP, the integrated system model will allow the worldwide community to build the many required facets of this new knowledge infrastructure.

CubeStudio will be freely available to any entity over the Internet for a nominal registration fee. However, Cubicon will charge developers in direct proportion to the amount of original IP they produce with cube components. This could possibly range from $25/year for a very casual developer to $500/year for a highly prolific developer. The producer maintains copyright and patent rights to their declared IP and can freely choose any means of distribution. In other words, Cubicon provides the commerce mechanism while the producer provides the commerce policy.

A policy may be based upon a free, purchase or rental model. The CubeExchange automatically tracks IP commerce transactions and distributes licensing fees where applied. We believe that the CubeExchange distribution channel will offer compelling market advantages.

Products and Services – Cubicon provides an intelligent layer on top of the Internet that enable a wide variety of new products and services to be offered by Community Repositories. There is a symbiotic relationship between the CubeDialog and the CubeExchange that enables these capabilities. Any community become an emitter of IP products and services. A producer’s community broadcasts its available products and services to a consumer's CubeStudio. A consumer can browse and transact IP through the public interface of a producer’s community.

Rationale: The open source model is limited by the weak programming language technologies that are an integral part of the current paradigm. Thus, this model must require free software distribution. This certainly works for a certain segment of software uses, but lacks an industrial basis to attract widespread capital formation to build long-term scalable system technologies. Cubicon provide the technologies that deal with the following IP aspects including effective means to execute, create, manage, store, educate, transmit, locate, protect, distribute and transact.

Designed Source: Current software is disclosed either in source (white box) or binary (black box) forms. Cubicon declared iconic designs provide a ‘color box’ model for selective disclosure. This model enables the producer to choose the abstraction level of IP disclosure appropriate to enable reuse without the wholesale giveaway of trade secret implementation details.

A Cubicon component can be downloaded via the Internet without charge for simulation and evaluation. Purchase or rental license fees only apply if a transaction is completed on encumbered components. An encumbered component can be morphed into a third-party component and redistributed. A derived component carries its multiple license burden that is automatically tracked and disclosed down through the user feeding chain.

Rationale: The very nature of source 'code' already obfuscates IP. As "a system of symbols (as letters, numbers, or words) used to represent assigned and often secret meaning" source code is itself not readily understood or clearly expressed. Human pattern matching capabilities are greatly underutilized when all IP has to be reduced to long strings of dead text that require interpretation or compiling to derive meaning by a machine. Imagine the field of architecture operating where all three-dimensional building designs were limited to lexical expression. N-dimensional software and hardware designs are much more complex and require deterministic behavior characteristics. Cubicon effectively harnesses human pattern matching capability, thus making IP expression highly understandable by both humans and machines. Thus, selective disclosure becomes vital to control not just the expression but also the underlying ideas in the declared process.

Designed Source: The concept of a monolithic 'application' program gives way to a 'framework' program in native Cubicon. A framework provides pure structure and behavior modules that drives one or more collaborating content systems. A system driven by a framework possesses four unique properties. A system remains morphable, immutable, updatable, communicable and peer review-able throughout the lifecycle of an IP asset. Technology support of these properties in a medium at first may appear to be oxymoronic in their functions. Cubicon successfully integrates these software development properties to obtain the following inherent characteristics:

Morphable – A Cubicon developer is free to adapt data structure and operation behavior of ancestor templates while the medium maintains descendent template integrity. This 'object-composed' technology effectively solves the 'fragile class problem' of object-oriented languages. Established IP rights are automatically transferred to newly declared descendent templates.

A community-declared component can be shared with another community through two mechanisms – refer or link copy. A refer share means that the component producer maintains control of modifications that are automatically updated in the consumer community. A link copy share means that the consumer community can declare specialized component versions of the original. A refer component automatically coverts to a link copy if the original community ceases to exist.

Immutable – Template design schema is separate but related to actual value structures. This means that adapting anatomies will continue to support existing operation system versions.

Updatable – Existing deployed systems can be automatically updated to the current version without human intervention. This update capability can be performed locally or through the Internet to any number of distributed systems.

Communicable – Any two Cubicon sites may communicate in an ad hoc fashion through a sophisticated context instance dialog. Cubicon anatomies may communicate within a site through a sophisticated messaging model without the development of specialized APIs.

Peer Review-able – An independent component evaluator can attach a review and rating onto a component. A reviewer can be financially compensated based directly upon the number of times their evaluation is selected. This fee is automatically subtracted from the producer’s license fee income stream.

Rationale: These inherent characteristics redefine the very basis of rapid prototyping where an existing executing system never becomes spaghetti code. Instead, sets of collaborating components morph with changing domain requirements in a relentlessly consistent manner. Software redistribution can be as open or closed as the aggregate IP stakeholders decide is in their best interests.

Designed Source: All derived work is in the form of descendent templates without patch files. Each template's reuse policy is established by the author, on one of three levels:

– A locked template can be viewed and reused but not modified in any fashion.
– A half-locked template is ancestor to one or more descendent templates.
– An unlocked template can be modified.

The original author supports both locked and half-locked components. An unlocked template is essentially freeware with no associated support.

Cubicon software is intrinsically secure. All components are sourced from a Community Repository and are composed from a finite set of structural and behavioral component. A Context Engine would reject any foreign code injection attempt.

Rationale: By eliminating patch files, all derived templates carry their indelible IP rights embedded in the components so the responsible authors are disclosed. Authors thus have a technology-based guarantee that no tampering can take place on their IP base. This guarantee is the basis for component certification and limited warranty.

Designed Source: Component disclosure can be restricted to in-house department reuse through a private CubeExchange. Alternately, selective or open disclosure can be made through the public CubeExchange. This 'open and protected' model provides a producer with a wide range of choices with which to distribute original IP.

Each entity has a home Community Repository that they can invite additional entity members to participate in shared IP ownership. An individual can be designated with an administrator, architect or language translator role. While only an architect can modify components, general members can review and attach interactive comments. Comment trails are a permanent record that provides rationale for component evolution.

Rationale: Democracy does not always rule in the real world. A producer should have the choice as to the parties they want to include in their IP evolution process.

Designed Source: An encumbered Cubicon component may restrict system execution on a machine-basis depending upon the producer's license policy. A policy is enforced through automatically through CubeExchange.

Rationale: This controlled distribution model actually encourages commercial use by assuring adequate producer compensation when a component is widely replicated within a consuming enterprise. A framework can be offered on a purchase or metered basis. Metering provides the means to cost-effectively provide functionality for both occasional and extensive use while maximizing revenue returns for the publisher.

Designed Source: The Cubicon licensing model provides the means to link certain component disclosure to an electronic non-disclosure agreement.

Rationale: There are many classes of IP embedded in software components. Some of these components will contain trade secrets that a producer does not want compromised, but must share with licensees if they are to modify a component for reuse. Providing a built-in legal mechanism for this type of disclosure increases IP proliferation and collaboration where a producer has a large investment in system development and cannot risk open exposure.

Designed Source: There is nothing in the Cubicon licensing mechanism that prohibits component morphing for third-party use within the boundaries established by the producer's license policy. However, a producer has the right to profile encumbered components so volume discounts and commission structures can be considered.

Rationale: The CubeExchange is established on the Darwinism theory of natural selection. New and improved components will continually challenge established components that can easily displace an incumbent due to the recombinant natural of Cubicon IP technology. There is an imperative to improve the functional and reliability characteristics of a component, least it be replaced by a superior component. The effect of this theory will be a continuous pricing pressure on encumbered components as they become generically available and finally fold into specific core distributions in particular domains.

Designed Source: Any set of native Cubicon components may be morphed together within the boundary of the half-locked encumbrances. Cubicon provides two general methods that components can use to dynamically interact with applications written in lexical programming languages.

1 – A foreign schema can be statically parsed and dynamically processed as a Cubicon service. A service is a sophisticated nested structure that provides powerful traverse, edit, read and write operations on composite data. A CubeRun can re-serialize a modified service back into XML. The original producer would be the entity that develops and distributes a context for the service. The entity is free to establish component license policy for a particular context.

2 – A Cubicon method can call out to a foreign method by passing arguments and returning result value through a binary signature. A foreign method is wrapped within a Community Repository and thus can be optionally encumbered for reuse.

Rationale: Cubicon offers a rich set of IP commerce mechanisms, but no restrictions on licensing policy. Policy is left up to the component producer. Our strategic goal is to establish a de facto standard iconic design medium that will greatly increase the velocity of complex system development and IP reuse, on a worldwide scale.

Designed Source: Cubicon provides CubeExchange, Community Repository and CubeStudio elements that provide a robust infrastructure for component distribution, reuse and IP tracking. The basis for IP tracking is the manner in which each cube component is embedded with the authoring entity's identifier. A person that is an employee is credited with authorship, but their IP ownership rights are automatically assigned to their employer's community.

A community can declare that a particular binary system framework is unencumbered, but they lose important rights and capabilities in doing so. An unencumbered framework can be distributed without sourcing through a Community Repository. Tracking of rights would also be lost if a component set is synthesized and reduced to a silicon representation.

Rationale: This capability is provided for practical scaling purposes and specialized domain deployments.

Designed Source: Instead of disclaimers, Cubicon offers certification. We believe that Cubicon's technologies will enable software vendors to produce component products that can be backed by a Limited Warranty and thus command higher market values. This premise is based upon the following certification architecture. A Cubicon certification has four levels of conformance:

Level 1. Certified fit for purpose with no OS or foreign method calls – A pure native Cubicon system only executes well-formed modules that essentially cannot be hacked without detection. All interactions are performed through the CubeRun. Without OS or foreign method calls, the component is guaranteed to be free from malicious intent. The remaining fit for purpose certification would be provided by a third-party testing organization that has established a reputation for providing compliance.

Level 2. No OS or foreign method calls – This certification level is the same as Level 1 except without the fit for purpose certification.

Level 3. Certified with OS or foreign method calls – This certification level is more difficult to guarantee due to possible interaction with foreign code.

None. OS or foreign method calls – No certification applied, you are on your own.