WO2005114921A2 - Architectural frameworks, functions and interfaces for relationship management (affirm) - Google Patents

Abstract

There is a process and/or mechanism that allows individuals to keep their own dictionaries of words they use and the meanings while contributing to socially building an ontology of words and their conceptual meanings within one or more different networks or social contexts in which they are involved. This enables individuals who use different words or languages to refer to the same concepts or objects to better communicate and understand each other. The conceptual meaning an individual subject user refers to when utilizing a word in a particular context that can be inferred bases on the logical architecture of the invention's data structure, effects the conceptual meaning attributed to the words or other symbols in the ontology of domains that share and represent a use context, e.g. field of study, with the individual subject.

Description

TITLE OF THE INVENTION

ARCHITECTURAL FRAMEWORKS, FUNCTIONS AND INTERFACES FOR RELATIONSHIP MANAGEMENT (AFFIRM)

BACKGROUND OF THE INVENTION

As society becomes more networked, it is easy to imagine many new opportunities as well as many new threats that might result. For example, people often assume that increased interconnectedness through computer and information networks will automatically bring amazing new benefits for humans. This is simply not true unless there is an understanding being transferred between the entities interconnected on a network. Also, as one can readily imagine after experiencing contemporary science fiction, there are also potential threats from intelligent machines getting out of control. Although it is now obvious that both of these extremes are exaggerated in the short run, the opportunities and threats are both still possible in the long run. It will help the reader of this document to more easily understand and appreciate the uniqueness and utility of the disclosed invention to have: 1) a realistic outlook on the opportunities and threats of technology, and 2) an understanding of the current abilities and limitations of communication and information technology.

1. Field of the Invention

The disclosed invention is in the field of using communication and information technology (CIT) to assist individual devices, people, groups and/or organizations in management of interaction through networks. Although impacting other levels of CIT, the invention is focused on improving the application layer of computerized networking. (See standard OSI or TCP/IP networking models) It is specifically focused on application software that is used to enable a human to interact with a computer and to use the computer with this application software to manage socioeconomic activities. Like other "application software" the preferred embodiment of this invention in a standard computer works in conjunction with and/or through an operating system (OS) to control a given computing device.

The invention is applied to improve CIT "applications" that benefit from improved handling of structured data and enhanced interaction between humans and other entities (humans, machines or other physical entities) in the environment.

2. Background Art

It is often assumed that application software is as advanced and well organized as the networking hardware technology. For example, people assume that as we make strides toward more interconnectedness on the hardware and basic data transport levels that we also make comparable strides on the application level. This is not true. In fact it was this kind of naive thinking that was a cause of the infamous "Internet Bubble". The main reason why this is not true should have been obvious. Merely being interconnected by a communication medium does not necessarily mean that the interconnected entities will be able to communicate understanding and therefore benefit human enterprise.

The reason the Internet bubble eventually burst was because we did not actually have the ability to efficiently and effectively organize and communicate information in such a way that it would dramatically enhance the common individual's ability to negotiate and manage their unscripted lives. There is a need for real-time information organization and communication tools and methods that will help common individuals to more productively negotiate and manage their lives and relationships. This is the main reason why AFFIRM was invented, so that common individuals could better benefit from the increased interconnectedness of our society. It turns out that the AFFIRM invention will also be beneficial in many other areas than directly helping people manage their socioeconomic networks. Any network or part of a network that could benefit from better simulation, negotiation, coordination, and control through improved organization and communication of information stands to benefit from the AFFIRM invention.

To create new a new breed of valuable services socioeconomic entities need to be able to:

•Evaluate future options and past performance

•Communicate efficiently and effectively

•Negotiate appropriate win/win agreements

•Transact or interact in a safe and efficient way

•Integrate or synthesize merged organizations, applications and knowledge

•Coordinate efforts of multiple distinct individuals or entities

Personal Organizational Development Needs Co ordinatio n Evaluation

__________^ f Nurture Synergistic ^ ^ integration ! Relationships and [Communication _^ Knowledge

Transaction | ^™^™^^-^™¹^" | Neg otiation |

PRESERVE VALUE: Securely Share Intellectual Property AN D CREATE VALUE: Innovate and Collaborate

Current technology does not achieve either of these two primary business objectives, securing existing value and creating new value. Enabling both of these essential yet seemingly juxtaposed benefits for demanding customers and collaborating partners will prove to be a significant value proposition

Previous attempts to satisfy these needs electronically have been unsuccessful because of security limitations and the need to do impractical and costly integration of systems from the following categories:

Analytical Applications- data warehousing, decision support, performance management applications often categorized and on-line analytical processing (OLAP).

Collaboration Tools- Office, email, instant messaging, whiteboards, team sites, etc.

Transactional Applications- ERP, accounting, inventory management, purchasing, sales, etc., often referred to as on-line transactional processing(OLTP).

Given present limits, these systems are unable to provide the above mentioned value creation capabilities in a practical way. (See Exhibit of Competitive Landscape)

The present invention both integrates the other systems mentioned in a more practical way with a common uniform intermediary data store, but also provides some of the benefits of these other applications and more, in and of itself.

Most of today's Web servers are merely haphazard additions to a company's information technology infrastructure. Therefore, most Internet information remains separate from the many other systems within a company. In fact, this absence of integration is also true of most company's internal transactional, decision support or data warehouse systems. Frankly it is an embarrassing situation for the designers of today's systems. The analytical systems are separate from the Transactional (Enterprise Resource Planning) systems that manage the internal resources of most companies today. This prevailing situation was acceptable when online business was in its early stages and business were not required to be proactive, but now, as e- business is advancing into a more collaborative knowledge-based commerce stage, this integration problem is a major detriment to further growth and development. Therefore, the status quo will become unacceptable, and the companies that break away from these severe limitations will enjoy huge gains in competitive position.

Collaborative applications are comprised of several different point solutions that are not even normally considered to be part of the transactional and analytical application landscape. It is as if the users of these applications are expected to always be operating in isolation, not needing to communicate, participate in negotiations, or other value creation activities. But the days of the lone analyst in the ivory tower are over. Today's managers in broad and deep positions in learning organizations need to be able to do it all. They need web access to integrated tools that can analyze, collaborate, transact and then analyze again all in one reoccurring seamlessly integrated learning cycle.

Managers need to be able to bring all the different existing point solutions together and to share data between them from one central data repository when appropriate. (See Personal Domain and Value Web Development PlatformTo have understanding one needs to be networked into the fluid flow of information on the "business application" level between transactional systems, analytical systems and communication systems. At this time satisfactory solutions do not exist for this challenging problem. Basically experiential (transactional) data from multiple disparate and distributed sources needs to fluidly inform analysis, which then needs to fluidly inform all related future planning and implementation decision-making (transactions) in real-time. Present limitations of the different (usually separate) CIT business application systems operating in this organizational learning cycle are explained below. How the present invention overcomes these limitations is inferred below, and further explained in the following Description of the Invention section.

Today's "computerized application programs" (define this-as below) do not efficiently and effectively structure data about an individual's behavior and ever-changing status vis-a-vis their environment. (See chart on You/Me/We) In most cases where individuals are represented in today's "computerized application programs", they are represented within large business application programs as one of many individuals in a common database "Table" or file. Some structured database application programs, such as accounting systems, enable "individual entities" to represent some aspect of themselves, e.g. their financial situation. But unfortunately these programs record data of specific types in specific pre-defined database "Tables". Therefore, these programs are not good at handling an end-user's evolving data type requirements for previously unspecified processes or situations.

Also, since database application programs, e.g. accounting systems, are structured to handle only specific numbers and/or types of data "Tables" and/or "Fields", they are not able to productively communicate with other application programs designed to handle different types of data. Therefore, different systems handling different types of data do not effectively and/or directly interact with each other and the single company or industry wide hub is still the standard method for handling exchange.

Evolution of Communication Networks

H u b and

Because of the difficulty in current disparate systems interacting, most business expenditures in information technology are for training and/or integration of different systems, rather than for the acquisition of new systems. This is also why there is great effort being applied by industry groups to try to negotiate agreement on how to define the different specific types of data that will be handled in different types of application programs. The hope is that these efforts will enable the adoption of common standard datatype definitions so disparate systems relying on structured data will then be able to communicate with each other. (See other information on XML and the many industry consortiums that are working to agree on their specific schema or data type definitions not covered in this document.) The problem with this is that industry groups can't agree on standard or common XML extensions that define everyone's data types, and it is even harder to get organizations in multiple industries to agree on a standard. Therefore, communicating structured data between organizations and their servers continues to be a major problem.

Another different problem is that it is difficult to manage the security of structured data in today's application programs or services. It is very difficult to keep information private once it is placed on a networked system. When a database, e.g. a medical records database, has private information about a particular individual, e.g. a patient, in today's systems, the information is usually commingled with information about other individuals of the same type, e.g. other patients. As a result, an individual's private data is inherently accessible by multiple users of these systems. "Third parties" with security rights to access that "level" or "Table" of data, are going to be able to access private records, whether they have any reason to interact with that particular individual's private information or not. This is a major security hole that many organizations are required to plug, e.g. because of new HIPPA laws, but are currently still looking for ways to do so. (See Highly Insecure Security) Highly Insecure Security Fact: A well encrypted database still has good chance of a security breach as a result of users letting their passwords out. If P = probability of a user letting their password out and U = number of authorized users P rob ability of Breach = P x U

rs, is

If one of today's systems is set-up to only allow certain individuals to access certain specific information on a network, then there needs to be one or more other designated "third party" security agents generally authorized and spending significant time and effort to specify and maintain specific individual access rights. In large networks this can be a huge expense. Just the fact that private information for more that one individual is store in a common place makes the information vulnerable to access by unintended parties.

As a result of these limitations and difficulties with current information technology, an individual (i.e. individual person, group, organization or other entity) still does not have access to cost effective and secure computerized services that effectively guide, coordinate and assist in the management of common yet ever changing processes. Individuals would benefit greatly from individualized and secure computerized services that help manage their unscripted relationships and processes without requiring: • Private information of multiple individuals to be combined in one place • "Third party" data security providers and/or users to access private information • Different data structures and/or programs for different applications • Agreement on a common data dictionary or type definition by interacting parties • "Application programs" to be reprogrammed when data type definitions change

This would enable collaborating individuals to work more fluidly together and to be able to be more innovative without fear of "breaking or requiring a rewrite of the system".

In addition to having too many of these above mentioned unnecessary and costly requirements with today's systems there are also some potentially valuable things that current systems, no matter how expensive they are, cannot do. Social scientists have shown that each "individual entity" (whether a individual person, group or larger organization) has a different perspective on shared knowledge and relationships. But most information systems today require those that communicate shared knowledge and information to agree to one way of describing their knowledge. Unfortunately this is not possible when different groups in different domains are used to naturally building their own vocabularies. This makes it difficult for different groups using different vocabularies to communicate or collaborate, e.g. nano, bio, info and cogno scientists all have different words for what they call the connections between the components of their structures. As the examiner of this patent application, you are involved in a perfect example of this. It must be very difficult to thoroughly research all the different patents that might be related to a new patent application, given this common tendency of different individuals from different or even related domains using different words to describe the same thing.

One who is practiced in the art of computer programming and is familiar with existing methods knows that both procedural and object oriented programming methods normally dictates that business process application programs be designed to use and only work with specific types of data or objects. Current art in the computer science field prescribes that the "programmer", in the traditional sense of a person who writes instruction code in a "programming language" to be compiled or interpreted at runtime, must define the specific type of "objects" that an "application program" is able to process. This can be seen in how data modelers define database "Tables" with specific record fields and/or similarly how business process modelers define "Classes" for a particular type of "Object". The current programming paradigm, taught in contemporary computer science classes, suggest that "Tables or "Classes" for a database and/or program be defined to directly correlate with "real object in the real world", (e.g. for example in a healthcare application you would have a record for each patient in a database table specifically structured to hold specific information fields that needs to be kept on patients) Please refer to computer software programming literature for more on contemporary programming methods. Again, like database "Tables", each application program designed to handle structured data is written by a "programmer" or "program generator" to handle certain types of data or objects for specific types of situations.

As a result of this standard programming paradigm, specific "Tables or "Classes" only handling specific types of data or objects, if an end-user wants an existing application to handle a new and different type of data or object, they will find that it won't work. They are stuck or rendered helpless unless they find a different program to handle their new type of data or object or they need to expend effort "programming" their own application program that will most likely not interoperate with the other existing programs. Wouldn't it be nice if one program was available that could handle any type of data or object?

Since this doesn't exist today, the coordinated development of "business process applications" that support collaborative interaction and evolve in real-time cannot be created and/or are not able to be programmed by normal businesspeople or "end-users".

In addition to the application development issues and other limitations with current information technology and architectures mentioned above there are other problems that the present invention is designed to resolve. There have traditionally been two separate branches of structured database business computing applications. Both were inherited from the mainframe world of computing, online analytical processing (OLAP) and online transaction processing (OLTP). Because of their drastically different requirements, they usually must be run using separate systems. This causes problems trying to get data from the transactional systems, usually the source applications, to analytical systems. Because of the extraction, transformation and load (ETL) procedures that are usually necessary before data gets to analytical systems, there is normally a time delay that prevents real-time data analysis. Another problem resulting from the fact that OLTP and OLAP systems are usually separate "islands" that don't integrate very well is that this makes it difficult for an organizations learning loop to be a complete and fluid circuit. Ideally analysis would immediately effect transactions, which would immediately impact analysis, which would then again impact transactions and so on in a continuous real-time loop. Unfortunately, because of the disjointedness of these two types of systems, they do not effectively support organizational learning.

OLTP and OLAP have some other problems in common and some that are unique to each. Both usually attempt to support seemingly unlimited multi-user demand from limited centralized servers. As a result, users of both types of systems can suffer from slow response times. Therefore we need better ways to distribute data and processing across multiple computers. But unfortunately current OLTP technology used for managing inventory, financial accounts and other important resources are not good at coordinating interaction between multiple parties and resources without bringing the data for these together in one common central location. Again this causes information systems to have inherent security and performance problems.

OLTP systems that involve more multi-user writing of data than OLAP systems also suffer from other difficulties. Since multi-user transactional database application programs normally enable editing of common structured data, they need sophisticated ways of locking a specific piece of information while someone is editing it. Locking is required while one user is editing something, so that someone else won't edit the same thing at the same time and overwrite the other user's changes.

Also, when computer servers are connected directly or indirectly to a network and allow access by the public or unknown users, e.g. email and web servers, they are subject to the possibility that these unknown users will purposely or un-purposely use too many resources from the server. In extreme cases, this causes is what is commonly called a denial of service attack. It would be better if these servers could not be accessed by unknown parties, but given the way email and other servers work, this is unpractical.

There are several things that an operating system is not intended to do. An operating system is software focused on assisting application software in operating the hardware ofa single computer.

Any software running on a different computer is always thought to be a separate instance of software requiring a separate license for use. Therefore, by definition, software that provides any sort of access or assists in control of another computer, e.g. a "client user interface to another server or computer", should not be considered or be allowed to be part of an operating system. Otherwise as a result of the pervasiveness of the Internet, the software on all computers would all be part of one massive operating system. This would provide the potential for the abuse of power resulting from having the ability to control the whole network. To prevent the possibility of any of these nightmares from happening this invention distributes control to each individual.

A separate instance of an operating system running on a separate distinct computer used to provide control of that separate computer is normally considered to be a separate instance of the operating system running another computer. Therefore again any software that accesses or controls another server or peer computer is always considered to be an application as opposed to an operating system. For security reasons operating systems are not supposed to allow their users to work with file systems on other computers on a network from a web browser, so someone cannot use an operating system to for example, organize a knowledge base in different files. This is what would normally be considered a business "application". These types of functions and most of the other things that this invention does that are unique would not normally be considered to be part of an operating system. The aspects of the present invention are normally part of what would be considered business management application software. This category of software includes all types of business application software such as inventory management, accounting, scheduling, desktop productivity, email, instant messaging, group collaboration, data warehousing or business analytics, contact management and much more. All of these types of "application" software run on top of the operating system of a computer.

It is imperative for the vibrancy and continued innovation of this industry that the operating system layers and the business management systems layers of the software industry be kept separate. It would be particularly stunting of progress toward systems that enable computers to improve the quality of life and productivity of humans, if there was only one company that could compete in the market for business applications. Unless of course you believe that an operating system should be able to include anything and everything and that it doesn't matter if one software company controls the whole industry, you need to understand that operating systems are supposed to control ONE computer's hardware and must keep track of state information about that one computer and the application software in the process of using it. Any software that can assist in the control more than one computer and keep track of the state of more than the one computer being "operated", should not be considered part of the operating system. These functions should be part of an application that is designed to work on or through many different operating systems.

Networked Directory systems and XML systems are like databases in that they require third party control of security and upfront agreement on the type of data being structured.

Email systems use a more highly evolved style of network communication called all channel. This enables the member of a network to increase their satisfaction over the traditional chain of command type networks and Hub and Spoke networks. But unfortunately "all channel networks make it difficult for leaders to emerge and current all channel communication technologies do not enable the storage and communication of structured data needed to support analysis, transactions and synthesis between entities. (See Evolution of Communication Networks- All Channel) Evolution of Communication Networks

Email systems are also prone to viruses and other attacks. Another all channel communication technology called instant messaging is designed for users to be synchronously (at the same time) connected, and is also not designed for storing and communicating structured data. Again, current all channel systems are either requiring fixed formats or data type definitions, like EDI, or are like email and instant messaging and are not designed to handle structured data. Current databases and spreadsheets handle structured data, but do not handle the ability to flexibly coordinate the integration or synthesis of the structured data between disparate hubs.

Application servers require "programmers" to code business logic using standard languages and require, with the OS, non-persistent session and state management information to manage multiuser activity.

File sharing programs are currently (often illegally) used to distribute digital content. These distribution systems, especially the peer-to-peer type, are not able to efficiently and effectively prevent unauthorized copying and distribution of this digitally recorded content. Content streaming and centralized document management can alleviate these abuses in a centralized company, but not in a situation where peers are cooperating in the process of sharing information about documents and content. Since peer-to-peer sharing of information among fans and other interested parties in only natural, we need peer-to-peer systems that prevent these abuses of copyright law.

All together these above problems and limitations of current CIT enable thieves to steal ones identity and real assets in cyberspace and cause major problems for the individual victim. It is one of the fastest growing crimes, and needs to be stopped. The present invention will prevent this crime.

Also, normal humans somehow have the ability to use good judgment, especially those that are involved in a particular business process on a daily basis. Computers on the other hand, and their "programmers" that are not usually experienced or trained as business persons, are not usually as good at judging what would be the right thing to do at a particular time. Therefore, there must usually be a two-step development process where a businessperson specifies a "business process application program" and a programmer programs it. Unfortunately, there almost always seems to be something lost in translation. Computers just do what they are specifically told to do, and at this point in time it is still too difficult to tell computers what to do!

Therefore, we need simple ways for end-users to be able to tell their computers what to do. Most efforts at this time are being placed on allowing business people or "power users" to be able to graphically layout a specific user interface and/or business process and then have a code generator actually "write" the instruction codes that are then compiled or interpreted to run as an "application program". Even this newer method requires a two-step process where "business application programs" (data structures and/or processing programs, e.g. "Tables and/or "Objects") need to be defined and written for specific business processes and object types. This does not ideally support situations where business users need real-time transactional and analytical processing systems that can easily share structured data with systems used by others with different data type definitions.

Also, for some time now, we have dreamed of computers that would be able to reason like humans with constantly changing information about the environment and able to make judgments based on that data. One reason we don't have computers that are able to do these things very well is because computers are not currently capable of being conscious or understanding of the intimate details about relationships between entities.

Have you seen a machine or computer program capable of effectively learning and managing all the different aspects of a relationship? Have you seen CIT able to keep track of and communicate information about a relationship from the different perspectives of you, me and we? Up to this point it hasn't been done very well. And this is one reason why CIT systems are not as good at assisting in the management of relationships as they could be. If computers were good at this sort of thing they could be used to more readily manage more aspects of our lives and our relationships. Just imagine what kinds of services a computer could provide if it were able to more intimately know about you, about all your potential partners, and about the value of things you might do together with these potential partners. For example, would we be able to negotiate our future plans and then have the computer know enough to then manage those plans in a semiautomatic way? Are current computers aware of what you and your partners have to contribute to achieve future plans? Are they able to recommend plans that make the most sense given your strengths, weaknesses, opportunities and threats? If computers could do this, they could be relied on to serve people in much more productive ways.

If all of the above problems were solved and possibilities achieved, we would have secure and reliable individualized services continuously available that provide: • Automatic budgeting and record keeping • Automatic intelligent order giving and taking • Automatic Research and Development • Coordinated interaction that manages optimum value creation • Continually reprioritized and automatically rescheduled To Do lists • Automated opportunity recognition and recommendations for each individual • Identification of potential partners for an individual • Etc.

Description of Invention

The technical challenges solved in the present invention to overcome the above mentioned limitations with prior art and provide other unique and useful functions that are significant. The invention should be considered both in whole and in part. Each benefit or utility and the part(s) of the invention that facilitates that utility should be considered as distinctly separate claims or inventions. It is also true that the invention as a whole provides utility and therefore should be considered an invention in whole as well. Several valuable economic benefits will accrue to socioeconomic entities that use the present invention to organize themselves and their participation in collaboration networks. These benefits are a direct result of the innovations present in this invention. The benefits primarily result from the way the invention can facilitate the secure management of the economic/business affairs of unlimited numbers of independently distributed and located economic entities, the ability to converge them into common collaborative organizational structures on demand. The technology enables users to propose and visualize collaborative alternatives, manage collaborative relationships, keep track of the value created by each collaborating entity, and even equitably share gains with participating parties.

These valuable business functions are feasible because of the technology's innovative architecture and processing methods that facilitate both analysis and transactions in a closed feedback loop. The methods that make it possible to do this are unique and unprecedented. Some technical areas the innovations impact include: Peer-to-Peer Network Computing Architecture, Authorization and Access Control, Performance Management, Information Personalization, Distributed Data Management, Partitioning & Processing, Graphical User Interfaces & Applications, Application Generation, Knowledge and Ontology representation, Knowledge Delivery & Syndication Protocols, Enterprise Application Integration, Internet & Mobile Device Services, and Privacy & Security.

Peer-to-Peer Distributed Network Computing Architecture - The advanced functionality of the technology is achieved with highly sophisticated yet efficient procedures made possible by a uniform object oriented architecture that enables distributed processing of data objects on a peer- to-peer basis. This architecture also provides a uniform yet flexible way to both distribute and integrate the data that makes up all the different knowledge bases on demand. In peer-to-peer file sharing of music and other digital content it is particularly difficulty to manage distribution rights, so it is currently difficult to directly invoice for consumption of digital content in a proactive way. An ability to do this would help this situation. This is something the present invention does, and also, when content will be shared between individuals using software based on the invention, it will not be the actual content files being sent. Rather it is categorized links to content on other content servers that are passed between users. Therefore, this will be an efficient and effective way of sharing "playlists" and other information, without automatically empowering or requiring the user to have the content. Then it is up to the authorized content server (most likely the content producer or provider themselves) to manage the streaming (or downloading) of the file direct to the end consumer. This will have the added ability to control licensing fees, etc. The authorized content provider or server also then has a better opportunity to build a relationship with the end consumer.

Authorization and Access Control - Whenever it is important to identify users before access is provided to digital systems, or content, identification systems, like bioID, etc., become important. To work well these systems need to work with systems and content that can efficiently and effectively partition content and system resources by user, and the present invention again solves this problem better than current technology.

Real-time Performance Management - The architecture also makes it possible to measure and manage the performance of an enterprise or collaborative effort in real-time. Unlike most analytical applications, this is achieved using the same data architecture as that used for transactions. Thus, real-time analysis is possible without the normally required data export, transformation and loading (ETL) from transactional systems to analytical ones.

Information Personalization - Configuration of appropriate information for a given user is converged for each individual situation based on what is shared by content providers or partner users. This creates different personalized or customized information for each user.

Distributed Data Management, Partitioning & Processing - Through applying the proprietary architecture, the technology can partition and process data in infinite separate locations and still bring data together when appropriate on demand. In this way the technology supports scaling to unlimited numbers of individual users, enterprises and industry segments. Also, the data can be organized according to user defined schemas and still be able to be merged.

Graphical User Interfaces & Applications - The technology's graphical user interface (GUI) enhancement can coexist with any Internet content delivery system to improve the organization and access of context specific knowledge. All applications are accessible through the same standard interface, thus giving users familiar with one application, the ability to operate any application without any relearning. The GUI can morph to any size, depending on the screen size available.

Application Generation - Specialized or industry specific applications can be developed or "programmed" by those that poses the specialized knowledge without the need for a separate technical person or step requiring knowledge of a computer coding language.

Language Processing, Knowledge & Ontology Representation - Comprehensive studies of language (semiotics) distinguish pragmatics as an important complement to syntactics and semantics. Syntactics is about rules of expression. Semantics is about defining conceptual meaning. Pragmatics is about shaping language through use. Modern digital communication networks (and computer programming methods) now address the first two (with the semantic web still under development) Pragmatics is not well handled in with current art and therefore we provide a much needed practical value by enabling what we call the "Pragmatic Web".

Knowledge Delivery & Syndication Protocols - The technology has one standard way of communicating packets of any type of knowledge. This enables databases to evolve and integrate easier and improves the performance and fault tolerance of the messaging system without limiting the type of knowledge that can be shared between collaborators.

Enterprise Application Integration - By providing a uniform data structure that can store virtually any type of structured data and maintain its integrity, we provide a common format that different types of structured data can be converted to as an interim stage in the transformation of data between applications needing structured data in different forms to pass between them. By providing a uniform interface we enable an individual entity such as a user or other functional device to easily control or integrate with other disparate parts of a greater system connected through a communication medium. (For an example, see Personal Domains and Value Web Personal Domain and Value Web Development Platform (User Centric Data Drives Change and System Integration)

Platform)

Internet & Mobile Device Services - The technology's knowledge protocol and GUI features make our infrastructure technology ideal for portable devices asynchronously connected through packet switched IP protocols with limited screen sizes and processing power. The combination of these devices with our infrastructure will enable the application of the right knowledge, to the right place, at the right time, no matter where that may be.

Security& Privacy- By combining the inventions data partitioning features with standard cryptographic and public private key methods a highly secure infrastructure for collaboration and exchange has been created. It provides protection while enabling the simplest implementation and maintenance requirements. Three Primary Utilities of the Invention

Utility

Enhanced Ability to Manage and Coordinate Change -resulting from how advanced technology enables structured data to be logically distributed within and across domains by state of change as well as levels of relatedness and aggregation.

Means

-New Data Record Structure

-New Data Communication Network

-New Data Partitioning

-New Data Dictionary

Utility

Enhanced Ability to Leverage Resources, Knowledge and Relationships results from advanced technology enabling structured data to be efficiently and effectively distributed across domains in mutually meaningful, efficient as well as effective ways.

Means

-New Data Record Structure

-New Data Communication Network

-New Data Partitioning

-New Data Dictionary

Utility

Enhanced Ability to Secure Intellectual Property and other Private Information - resulting from advanced technology enabling structured data to be secured within domains while coordinating its use across domains.

-New Data Record Structure

-New Data Communication Network

-New Data Partitioning

-New Data Dictionary

Summary Description of the Invention

Uniform data structure adopted by computing devices for storage, distribution and processing in a variety of applications. Uniform data structure comprised of multiple complementary subparts that together and independently facilitate communication of inputs and outputs through one or more defined interfaces that facilitate coordination between individual subjects and/or other physical entities. Methods are also disclosed that work in tandem with the data structure and interface components to enable and require a single human user or other individual subject to maintain exclusive self-control over at least one virtual domain or value web hub that represents themselves (and their relationships). A Unique Individual's Personal Value Web Hub

These exclusive virtual domains organized according to the disclosed data structure act as an interface through which individual subject owners regulate their actions that impact or interact with other's actions and effect their environments. By virtue of having exclusive control ofa domain using the disclosed structures, interfaces and methods, an individual subject is able to regulate their interaction with the environment. Individual subjects control and/or manipulate their environment by providing command inputs (proposals) to their domain(s) that represent potential commitments to future action or change.

The domain structure and change (interaction) protocol require that any action that effects or is affected by other independent subjects (with their own exclusive domains) be explicitly or implicitly agreed to by all the interacting entities. Therefore, the proposed changes are then sent out from the initiating or proposing domain to potential interacting entities. These interacting entities may include any other domains using the disclosed structure and change protocols whose controllers have agreed to partner with the initiating entity.

These domains may include group domains made up of multiple individual members, but each individual must have at least one exclusive domain from which this individual as the domain subject manages its interactions with others. (See Chart on You/Me/We) In this way, different levels and structures of organization and interaction can be achieved and/or evolved in a flexibly evolving communication network. These group domains act as collaborative process domains with either shared control instigated from each individual members individual home domain or controlled by another distinct authorized and responsible individual. In either case all data is accessed and change is controlled and/or consented to from an individual's exclusive and separate database or domain that is distinct from the domains or databases of other involved entities. Data is only shared by data owners with other individual entities domain's on an as desired or as needed basis. This enables the data owner to have control over who has what specific data of theirs in a different domain. By controlling the dissemination of data to others a data owner has control over who all sees the data. This obfuscates the need for third party security personnel and provides an audit trail of who has had access to what information. Also, by not putting all of an organizations data in one database, it limits the amount of people accessing a given database from many to one. Not only does this minimize the need for write locks on data, but also minimizes the risk of data security breaches. Individual Responsibility,

Fact: A werlli etnycryp atend ddatab Saseec wiuthr onitey conscientious authoriz d user that doesn't let th ir password out is virtually im possible to breach. If P = probability of a user letting their password out and U = number of authorized users Proba ility of Breach = P x U

In the case of a hospital patient, an individual patient would only share their personal private information with others on an as needed and trusted basis. It is a basic requirement of the Health Insurance Portability and Accountability Act (HIPAA) that a patient be able to be in control of their medical records like this, but other systems are not able offer this type of control to individual patients. Therefore, most healthcare providers require patients to give up their HIPAA rights before they will treat a patient. Expanding Universe of Trust & Application e.g. Medical Records (HIPAA Laws)

Also, with the ability to have each individual have their own individualized databases or domains comes the ability to have more that one domain per individual. An individual subject's AFFIRM data can be broken into multiple domains according to various organizational schemes. For example data can be partitioned in separate domains based on different levels of aggregation (specificity) and/or different amounts of relatedness. For example, medical information for a given individual could be in one separate domain, or medical procedure information at the total cost level of aggregation could be in one separate domain. In any case, as the number and variety of domains an individual uses increases, the security of each piece of their whole set of AFFIRM data increases. This is because each domain of data will be separately protected with separate passwords or bioID type authentication.

New Paradigm in Security An Individual Subject can Distribute Data to Multiple Separate Personal Domains

When all individual subjects interacting in a particular potential change have either proposed or affirmed a change for an agreed time this change is then scheduled to happen in all interacting domains. Then at the scheduled time, which may be immediately, the domains of all individual subjects involved in a planned change simultaneously cause their respective acts in the change or interaction to really happen. Through this mechanism real (physical) change must be enacted twice, first as an asynchronously negotiated plan, and then as a real synchronous implementation. Quantitative (and qualitative) feedback measures of planned and real actions are triggered between interacting individual subjects' domains (from the domain or location of the real effect to the domain or location of the source(s) of the affect). (See Interaction of Three aspects of AFFIRM Data, Interface and Function)

Real-Time Interaction through the External Messaging Aspect of AFFIRM between Multiple AFFIRM Systems, from One Single AFFIRM Instance or Implementation, with its Three Main Aspects of AFFIRM for the Exclusive Home Subject Entity, to the Data Stores of Many Other External Object Entities, Each Exclusively Managed as an AFFIRM instance by and for their respective Home Subject Entity.

(The same type of relationships from one subject entity to many object entities exist for all external AFFIRM Object Entities as Subjects in Relation to this and other Entities. In fact every instance of a relationship, initiated by creating and sending a proposal message (Data Object Instance) by one subject entity, has the potential to have a reciprocal affirmation message (Data Object Instance) in an object entity. Once a proposal gets its matching affirmation, the relationship is consummated, and the mutually agreed action/event (e.g. the creation of a partnership) is set to take place at the prearranged time. Once a partnership is created between domains, there are reciprocal links between the two domains. The fact that there must be these reciprocal links between two related domains for any established link to exist enables AFFIRM to prevent "lost links". Link destination can be removed by their owners, but since they always have a link back, it is possible to always inform the other of a move or changed link location before or as a link is being changed. Also, if one removes a link the other must remove the reciprocal link as well. This is unlike the Web where links can go one way and therefore often get lost.

Real-Time Interaction through the External Messaging Aspect of AFFIRM between Multiple AFFIRM Systems, from One Single AFFIRM Instance or Implementation

Overall Structural Aspect of AFFIRM

The data structure can be represented as sets of objects that are logically organized according to modified hierarchy of objects represented on various levels or dimensions. The Basic Elements of AFFIRM The Basic Elements of AFFIRM make up a proactive annd dynamic distnbuted cache that can be used to manage and persist data in the multiple aspects of AFFIRM as well as at multiple tiers or levels of a system

The AFFIRM invention has four independent basic elements These basic elements applied to a computer readable medium make a computing device able to efficiently manage data about an entity and its relationships in real time The four basic independent elements are the AFFIRM Uniform Basic Data Unιt(UBDU), Uniform Basic Data Set(UBDS), the Uniform Classification Structure(UCS), and the Uniform Domain Structure(UDS) These basic AFFIRM elements are either interdependently or independently used repeatedly (primarily to structure, store, or cache data) in the various Aspects of an AFFIRM system This AFFIRM Cache is made up of one or more UBDU instances within one or more UBDS instances within one or more UCS instances within one or more UDS instances UBDU instances or UBDUs are redundantly located or incorporated in appropriate higher structure instances (UBDSs, UCSs, or UDSs), but the the location of a particular UBDU in a unique combination of instaces of these higher structure instances makes each UBDU instance unique, identifiable, and locatable within a subject entity Each complete UBDU instance points to an object entity The object entity domain each UBDU instance points to is either a virtual (external) object domain (actually represented inside the exclusive subject entity data store at an internal address that is derived, relative to the subject, from the actual address where the object is represented as a subject) or an actual (external) object domain where the UBDS Instance the UBDU instance belongs to is an Active Primary Processing Method (APPM) (and data class) that can(ιs authorized to) initiate or commit real change by sending messages or Data Object Instances (DOIs) to either actual inside or actual outside objects

Basic Data Unit Basic Data Set Classification ofa Data Set Domain Location of a Data Set (according to UD

The three basic elements of the AFFIRM data structure are the UBDU which elsewhere in this document is called an IOO, the UBDS which are named and located according to what is elsewhere called a CID, and the Domain.

An AFFIRM interface (e.g. a graphical user interface or GUI) reflects this data structure. Below is an example of how the data is organized in a GUI. Seeing a GUI representation also helps to understand the data structure. For example you can see the Domain Chain embedded in the organization of the GUI.

Example Domain Chain(DC) and CID Used to

Access a Record (IOO) in a Domain and a Button in (the end column of) the GUI The button has a 0 as its LID (button label). This record or button (IOO or UBDU) has the following LIDs and CIDs: CID is 11111_11111 DC is 02468 3579

LIDs usually appear to be random codes, but In this example the LIDs are single digit numbers representing the sequential alternating order of Items and Options that need to be be navigated through in the GUI or Domain in order to access the IOO.

Each of the single digit numbered buttons above represent a IOO (record or 11111 11111 UBDU) selection from a set of one or more choices available in a UBDS ^"fc (file). These selections can be made by a user on the GUI or the AFFIRM software in different proceedures. The odd numbered buttons accross the top are Option buttons that represent Concepts or Uses (class) selections and the even numbered buttons going diagonal are Item buttons that represent Types or Entities. In the knowledge navigator part of the GUI from the prefered implementation, which is roughly represented above, when the buttons are Concepts or Uses they are Column header Option buttons like n the odd numbers above. When the are Types they are diagonal header buttons like the double digit buttons above. The LID of the these type of buttons and therefor the location where the files and records these buttons represent are foung are a concatination of the Item chosen in the previous collumn and the option chosen in the column header. When they are Entities they are Item buttons like the diagonal one above. The Jagged line with dots and arrows is the Domain Chain. Any element within an instance of the data structure or a representation of the data structure (e.g. in an interface like the GUI) can be accessed by knowing what is called the Domain Chain which is a string of object IDs called a Link ID (LID) including the one that identifies the final element UBDS (e.g. file) or UBDU (e.g. record) and the CID (file or UBDS name) which represents the state of the data objects and the name of the data set in the UBDS. The Link ID need only be unique within the particular CID named UBDS instance in which it the object is found. In fact, this same LID if used to represent the same object in other data sets with either different (complementary) CIDs or different locations based on the Domain Chain LIDs. (See the Domain Chain in the chart above)

It is also possible to access records or UBDUs within a UBDS based on the current Rank of the data object. From the Rank the line number of a record in a sequential file can be determined to enable the "cursor" to go directly to the record (elsewhere called a UBDU or IOO depending on the context) for quick access without doing a compare on each line to find a particular unique but random or non-sequential ID. This improves the speed of access to a specific UBDU element and enables AFFIRM to efficiently and practically save changes to a UBDS or an individual UBDU or record on an incremental and real-time basis no matter how distributed the records are throughout cyberspace. See CID of the end IOO of the Domain Chain in the chart above) In addition to a 0, 1, or X digit in the CID for each of two properties per dimension there is also a correlate LID segment of the Domain Chain. (See how they line up in the chart above)

Among other things this data structure enables entities, processes, and their properties to be organized according to a method that facilitates language processing.

AFFIRM enables the use of language (real-time dynamic communication process between one or more individuals with inherent or agreed structure) By enabling users to create and negotiate shared concept meaning ("what we mean"), apply concepts to specific contexts and objects ("by what we say"), exchange digitized words or symbols and the real objects they represent through different mediums and media. ( "when we talk about what we do " ) The way our data structure enables structures data to fluidly move (as messages) between the three main aspects of AFFIRM mentioned above plays a large role in enabling this language processing. This structure enables a processing logic to be inherent in the way data is organized.

The following diagram pictures one way that the data structure is applied to create a Data Dictionary in such a way that it embeds process and intelligence. As a result reasoned action recommendations or decisions can be made or followed by the system at the discretion and on behalf of the home subject in control of the domain that represents the data.

Legend Some Shared Objects (virtually any shared relations is possib.e) X, a and b objects can be singular or plural, general or specific (concept or instance), potential or actual, and proposed or affirmed Objects can be shared and held in common by any other object that is concievably related Instances can belong to multiple concepts Through this data structure, mterelationships between objects can be monitored and managed

Copyright Ronald Scott Visscher, 1995

The above multi-layered cards represent one way that data about relationships between object and their properties can be represented in our data structure, (e.g. an a by b correlation matrix for each X). If also shows the multi-dimensional aspect of the data structure. Surrounding boxes represent generic Concepts or Types of object classes to which specific Usages or Entities belong. (See Further Explanation below for definitions of these terms) An X is a role or process in which an Independent Subject or language user is involved. Specific X, a and b objects can be singular or plural, general (Concept and Type) or specific (Use and Entity), potential or actual, and proposed or affirmed at each dimension level where they reside. Objects can be held in common or shared and abide in multiple domains or sub-domains wherever conceivably related or relevant when authorized by the author of the object. Specific Uses or Entities can belong to multiple generic Concept or Type classes, respectively, as either the same identical instance or as a separate clone or copy of another instance. In the later case the object is considered a separate instance and has both common and unique parts to its object ID that act as a sort of model and serial number. By affecting data in this data structure (either through a HS directly creating or modifying the data or indirectly as a result of the actual and potential actions (monitoring, coordination and management functions) relegated to or implemented through a Domain by an IS. Through their Domains a user or IS maintains dominion and control over the interrelationships and interactions between its Domain and other objects.

As a result, each independent individual subject can determine anticipated (planned) effects of any change they are involved in and whether the real implementation happened according to plan and had its intended effect(s). In this way experience can be used to guide future action. So just by using the invention to participate in the change process each independent individual subject is able to receive information that enables them to anticipate potential changes and effects and compare these with actual. Another mechanism stores this experiential information and uses it to guide future action. Also by facilitating commensurate compensations of correlatives within and between interacting domains the system maintains accounting books also learns.

The disclosed invention acts as an efficient and effective universally applicable protocol for planning, regulating and improving interaction between entities. Synchronous coordination is achieved among real individual subjects using the invention and between one or more of them and their environment through asynchronously using this protocol to negotiate change.

Prior to this invention when individuals would work in collaboration with other individuals that have different ideas about how data should be typed and structured the potential for communication problems was great. Individuals in different locations using different words to describe the same "concept" would not be able to communicate about that "concept" using computers because those two words would be handled as if they were two separate "concepts". Now with this protocol for interaction, that is flexible enough to allow each user to describe and control their work and still be on the "same wavelength with other collaborators using different vocabulary, interaction can be more effectively planned, communicated and coordinated between independent entities and their hubs. (See Evolution of Communication Networks and the new hybrid possibilities enabled with the present invention inter-hub communication of structured data that can still be specified differently by each independent entity is now possible down to the level of the individual.)

Evolution of Communication Networks Hybrid: All Channel with Unique Individual Hubs

Historically computers have not been able to securely and indisputably distinguish between you, me, we or some other entity in a flexible way that would enable the recombinant synthesis of organizations made up of multiple other individuals without program code being specifically written to handle each of the details. Now AFFIRM has been created to enable each and every individual subject to be separately identified, independently represented in stored data, and self- managed through a secure and coordinated interaction process in a coordinated system. The present invention does this and as a result alleviates unauthorized data access, "identity theft" or impersonation of ones identity that is not your own, and unauthorized control of an non- consenting individual.

Again, a common person lacking sophisticated computer programming skills is not able to do this with current tools, but is empowered to do this with AFFIRM based systems. For a computerized service to effectively be responsible for performing these regulating functions it needs to have to "think" as if it were an individual from that one individuals perspective, with all data about the world organized from that one individuals perspective, and with the ability to understand and communicate with other individuals from that one individuals perspective. A basic reason why everyday computers are incapable of doing this today is because they do not distinguish between the subject and the object(s) involved in an action. Therefore, this is a very important aspect of the present invention. (Please see the value web hub chart showing domains for You/Me/We). These charts demonstrate how users are virtually made up of their relationships with other entities as the other entities and their shared or exchanged objects are represented in each related or relevant domain from the individual domain owner's subjective perspective.)

C Multip D) Int

It is useful to be able to maintain (persist) data (about past, present and future interactions) from each individual's perspective in each individual's exclusive data store or domain. This enables each individual to have exclusive control over data in their data store that is about their future actions, to provide a transparent audit trail about their decisions and actions, and to possess data about their past experience from which to learn and improve. An individual using this type of system will be the only one that can change their data. In this way, even though data is kept about all "Objects" related to an individual and interaction would still be coordinated between multiple individuals, from each individual's perspective, only one individual would be able to change a particular piece of data. Again, there are at least two basic advantages of this technique. First, each individual is able to have complete control of and responsibility for its own actions, and second the data management problem of needing write locks on data that can potentially be changed by more than one individual is alleviated.

This enables the system to provide access to data and allow change or variation of data according to the behavior of the individual (subject) within relationships in a way that is not only empowering to the individual, but also facilitates the evolution of a knowledge base that is able to support real-time reasoning and learning from the individual's perspective and in the process transform the individual and its partners in a positive way. The following chart shows examples of stages of transformational exchange or interaction that take place between entities. The invention recognizes the importance of and enables the control of the ability to intelligently determine at each stage whether a particular partner should continue to interact with the other partner(s) on a particular endeavor. At each decision point the anticipated value change resulting for the partner is checked to be anticipated to be a positive gain before making commitments to move on to further stages. (See the Partner Inspiration Matrix below)

Seven IN s of Collaborative Innovation as Stages of Opportunity/Relationship Development

The best analogy I have seen for explaining this is to think of relationships between individual entities like a grapevine. For example one might think of parents to children as one thinks of a grapevine to its branches. The branches must be connected to the vine for it to flourish. By describing a relationship in this way, it becomes obvious how one partner cannot thrive without being intimately interconnected with the other. The grafting ofa branch to a grapevine is an effective analogy that helps describe the type of intimate relationships that are most fruitful or transformational. But how do we represent these types of transformational relationship in a data structure such that a man made device can use it to regulate a human's or other real entity's interaction with other real entities in their environment and manage the value created by that interaction? (See the Partner Inspiration Matrix) Transformation or Value-Add Resulting from Interaction of Multiple Real Entities at an one or more levels of A re ation

This invention has made it possible for a common person to set up a programmed computer to delegate the actual implementation of interaction and manage value creation in any context. A common person can now set up a computerized service or system to do this. For example a web or Internet service, by instructing a computer to automatically model their relationships based on data about the outside objects they relate with and the state of those relationships. The states or status of the relationships change as exchanges or interaction happen between the related parties. To facilitate this, the present invention first provides mechanisms or services that monitor and stage data about past performance of exchanges or interaction between related parties. This information is also able to be input from a human user or other physical entity monitoring and input process. The present invention also is capable of allowing humans to further control their future interaction and transformational impact by first manipulating data about proposed change from their perspective. The present invention then uses these interaction plans to regulate the real implementation of the change or entity interaction on an as mutually agreed basis. The present invention automatically exchanges real objects and changes the state of the relationship between the parties based on mutually agreed or planned "interaction events". By defining a universal "interaction protocol" that classifies data about "Objects" based on the state of the relationship between those objects and each individual subject involved, this invention is able to manage real interaction or transformational change processes between real entities.

Notice that, unlike other application "programs" (compiled or interpreted computer instruction codes), an AFFIRM based application "program", using this "interaction protocol" and other aspects of the AFFIRM invention, is not designed to only handle a specific type of "Object". Therefore, an end-user that uses a specific domain or application program based on the AFFIRM invention to handle the processing of one type of "Object" can use the same domain or program to handle any other type of "Object". This flexibility provides large benefits over existing application "programs".

Below is a further description of how AFFIRM works, and is brought to fruition in software.

Other Terms Used to Describe the Invention or Software Objects Used to Implement the Invention

Subject- (used in the philosophical and logical sense meaning) an entity apart from its attributes or characteristics (and in the literary sense meaning) that about which something is said.

Individual Subject (IS)- a unique individual independent entity with the authority and responsibility to control itself and its interaction with others.

Domain- a separate data store used to represent a Subject in the structure prescribed in this disclosure.

Personal Domain(PD)- a partition of data at a location on a computer or network that is under the exclusive control of an Independent Subject (IS).

Home Subject (HS)- owner and controller of a given Personal Domain (PD) under discussion.

A Home Domain (ΗPD is a Domain under the control of a given Home Subject (HS) under discussion.

An Input / Output Object (IOO) is a record representing an object or an action involving that object (potential or actual). This is also referred to as a UBDU.

Prospective Interaction Partner (PIP) is another IS that is pending approval or affirmation of partnership with the IS under discussion. A PIP can be initiated by either the IS under discussion or the PIP or an IS that both sides of the prospective partnership know. Usually the PIP has either sent a proposal for partnership to or has received a proposal from the IS under discussion.

Input Output Definition Object (IODO) is a record representing a Concept.

Concept is any meaningful description of a class of reality.

Concept Domain (CD) is a Domain or data location used to persistently store information, such as words or symbols and other associated data found in an IOO, about or related to a particular

Concept. There is an IOTO (see below) or set of records for every Concept usage context. This usage context is established in a CD as users use a Concept in their PDs. A CD is created when the Concept is conceived of or registered for the first time in an AFFIRM network, and a CD gets linked to and used whenever another Domain uses the Concept.

Type is any meaningful representation of a part of reality.

Type Domain (TD) is a Domain or PD or data location used to persistently store information or data found in an IOO, about or related to a particular (Type of) object. There is an IOTO (see below) or set of records for every Type interaction context. This interaction context is established in a TD as users interact with a Type such as another IS in their PDs. A TD is created when the Type is conceived or registered for the first time in an AFFIRM network, and a TD gets linked to and used whenever another Domain partners with or uses the Type.

Whole Entity (W or WE) is an IS's PD that represents a them as a whole person. Symbol List (SL is a list kept by every domain of the words and other symbols used to refer to different concepts. There is a record for every word/concept combination. (In the preferred implementation the Symbol List is called the Item list.)

Concept List (CL) is a list kept by every domain of the concepts authored and/or used in the domain. There is a record for every concept. (In the preferred implementation this is called the

Option list.)

Type List (TL) is a list of all Types uses in a domain or network.

Community is a shared ecosystem or network in which a plurality of IS s belong, communicate, interact and build an ontology.

Uniform Interface (UI) is a device, structure or process through which data (transformed to or from the prescribed uniform domain structure) can be read, viewed or communicated.

Input/Output Object Template (IOOT) is a metadata wrapper that complies with the uniform domain data structure that acts as a purveyor of context within and between Domains. An incomplete IOOT holds one or more unspecified Input Output (Definition) Objects (IODO). An

IOOT provides all the data and structure necessary to enable multiple IS Domains to be able to communicate about one or more Concepts, Usages, Types or Entities (represented by IODOs).

An IOOT provides definition, enabling pieces of ontology to have meaning and to be shared between IS Domains. These IOOTs are shared to prepare IS s for asynchronously envisioning and negotiating a particular exchange and eventually recording and tracking actual change and

Usage of Concepts as CIOOTs. The IOOT is determined by the DC, its DCAL, its DCBAL and its DCAAL. Other properties such as the CID of the AIOO also determine the extent of what is included in an IOOT.

Complete IOOT (CIOOT) is a grouping of IOO s that represents a change in its entirety such that a given change is fully represented or defined within a CIOOT. A CIOOT must have all the elements or IOO s of a change completely specified, (e.g. all 0 or 1 s in the CID) An IOO ofa change, including future prospective change, is completely specified when each state and Value of each object involved in a change is known by all parties involved.

Link ID (LID) is like an object ID that uniquely identifies an object and is used to link or path to a (the next) node of data in a domain. It is a field or part of the uniform structure of each data object or record.

Option (Concept or Usage) ID (OID) is a LID used to identify a generic option, class or Concept or a specific option or Usage.

Item (Type or Entity) ID (IIP) is a LID used to identify a generic item, class or Type or a specific item or Entity. An Item Type is a subtype of one or more Options and an Item Entity is a subtype or specific instance of a Usage.

Object Class ID (CID) is an identifier of the state of an object in particular dimensions, in relation to the IS. It is the name of the files in which data is stored. Therefore, the CID specifies how data in an IS' s Domain is partitioned or stored. Embedded in the CID is all sorts of state information about the object including whether the object is a Option or Item, singular or plural, general (Concept and Type) or specific (Use and Entity), potential or actual, and proposed or affirmed, as well as the active or residing dimension for the object. It is a field or part of the uniform structure of each data object or record.

Object Label (OL) is a word used to describe a Concept or Usage or a name used to describe a

Type or Entity. It is a field or part of the uniform structure of each data object or record.

Object Description (OD) is a description, definition or other information about an object. It is a field or part of the uniform structure of each data object or record. Object Universal Resource Locator (URL) is a relative or absolute address used to locate and access the media or other physical object that the data object represents. It is a field or part of the uniform structure of each data object or record.

Object Rank (OR) is what determines the relative order of the storage or presentation of a data object or record. OR is dynamically recalculated when a data event might change relative OR within a data file or other storage location. It is a field or part of the uniform structure of each data object or record.

Object Value (OV or Value) is a value in a data object or record representing an IOO. The value is a quantitative measure or property of the real object the data object represents. It may be the mass, unit quantity or other measure of a physical object. In may also be a Total, Count,

Average, Correlation (or Regression) Coefficient, Visualization, etc. depending on ONT specification, or if not specified in ONT then determined by default depending on dimension.

Value type is determined by an Object's Number Type. Value is used when determine the OR. It is a field or part of the uniform structure of each data object or record.

Object Media Type (OMT) is what defines the type of physical or digital media the object represents and the type of player/recorder or other interface that should be used to access, activate, control, manipulate or transform the real object that the data object represents. It is a field or part of the uniform structure of each data object or record.

Object Number Type (ONT) is what defines the type of number the OV represents about the object, how that Value is measured, how that Value should be handled in functions, and how that

Value should be presented in output. It is a field or part of the uniform structure of each data object or record.

BID is an interactive code that is derived to or from an AIOO's CID and OR to dynamically determine where the real object is physically located in real multidimensional space and/or where the data object is represented in a data Domain.

Domain Chain (DC) is a string of one or more LID s that makeup a path through the data structure of a domain. A domains structure can be thought of as a type of hierarchical structure only somewhat modified and more complex. As you can traverse through a hierarchical file system by following a path, you can also traverse through an AFFIRM Domain structure using a

DC or path. IOOTs including CIOOTs are identified, located, read, handled and written in accordance with their DC.

Active Input Output Object (AIOO) is the activation or anchor point of an IOOT. It determines the Active Link of the DC. The AIOO is designated by the user, record or interface to control dynamic Domain and Object (data and real) manipulation functions, particularly function such as send and receive that involve handling of IOOTs and physical transformations that involve interpreting, enacting and/or recording CIOOT instructions.

DC Active Link (DCAL) is the active link of the DC that is determined by the AIOO. It is used to determine what is included in an IOOT.

DC Before AL (DCBAL) is the part of the DC that specifies the limited part of the domain made up of just the parents of the DCAL that will be included in an IOOT.

DC After AL (DCAAL) is the part of the DC that comes after the DCAL. The DCAAL represents or specifies the inclusion of subsections of a Domain in an IOOT. The IOOT includes all or multiple children or sub-items on down from the DCAL location and potentially all or multiple sub-options on down from the DCAL in the hierarchy of a Domain. Other properties such as the CID of the AIOO also determine the extent of what is included in a IOOT. Further Detailed Description of the Invention

We start out providing each new Individual Subject (IS) (a user, person, field, concept, type or other main object) (e.g. YOU), with a Domain. In the case of a person, a private or Personal Domain (PD) on a network (e.g. the Internet) is created and made accessible for the person. A PD stores and provides access to data that represents the private or semi-private network of a given exclusive Person or Individual Subject (IS) (e.g. YOU). The Home Subject (HS) is in complete control of its Domain or PD. A PD is owned or possessed by the HS person (e.g. YOUR PD belongs exclusively to YOU)

The HS is represented in the Domain or PD as the Subject. This Subject can be a Whole Entity (WE or see W below) or a part of a WE. This is one aspect of how AFFIRM enables levels of relatedness or aggregation. A part of one given Domain can incorporate a part of or all of another Domain, and the given Domain can represent part or all of a given object. In any case each Domain has a HS (Characterized as the OD W with an X spin in our preferred implementation). Other objects related to the HS in some way and the status of the relationship between these objects and the HS are reflected in an HS 's Domain. These objects can include other IS s and their potential or actual objects of exchange with the HS, as well as Concepts and Types (see below) that describe properties of the related objects. Among other things, these objects may include parts of public or semi-private shared vocabularies or ontology and qualitative and quantitative knowledge about these objects.

This knowledge is represented in the structure, state and values of the objects. See the below diagram showing the way knowledge objects are logically structured and represented in a PD. In this case we describe multiple dimensions of a PD using the letters W, X, a and b. And by directly or indirectly labeling and valuing IODOs (Concepts or Types) and IOOs (Uses or Entities of Concepts or Types) in these W, X, a and b dimensions of a domain, a user can give meaning to these objects. For example, knowledge may be incorporated in a Domain as correlation or regression coefficients describing the likelihood of coexistence or causal relationship between different concepts or instances and other concepts or instances. For example, correlation values would be found within the a by b matrix for a given X in a W and would be interpreted as within "W" in the context of "X" given "a" what would be the likelihood of "b". Various inductive and deductive reasoning methods use this knowledge to make logical insertions, recommendations and actions.

Generic Type of Individual Subject or Concept (e.g. Industry or Class)

W- An Individual Subject and their Roles (e g. You, Me or We)

X- Consumption X- Application (e.g. project) (e.g. expertise) a-attributes a- feature b- benefits b- benefit

X- Integration X- Production (e.g. design) (e.g. product) a-attributes a- feature b- function b- function

Legend Some Shared Objects (virtually any shared - relations is possib.e) X, a and b objects can be singular or plural, general or specific (concept or instance), potential or actual, and proposed or affirmed Objects can be shared and held in common by any other object that is concievably related Instances can belong to multiple concepts Through this data structure, interelationships between objects can be monitored and managed

Copyright Ronald Scott Visscher, 1995

The above multi-layered cards represent data about relationships between object instances and their properties, (e.g. an a by b correlation matrix for each X). Surrounding boxes represent generic Concepts or Types of object classes to which specific Usages or Entities belong. An X is a roles or process in which an IS or language user is involved. X, a and b objects can be singular or plural, general (Concept and Type) or specific (Use and Entity), potential or actual, vision or action, incoming or outgoing, and/or proposed or affirmed. Objects can be held in common or shared and abide in multiple domains or sub-domains wherever relevant, by any other object that is conceivably related. Uses or Entities can belong to multiple Concepts or Types, respectively, as either the same identical instance or as a separate clone or copy of another instance. In the later case the object would be considered a separate instance. By affecting data in this data structure (either through a HS directly modifying the data or indirectly as a result of the actual and potential actions (monitoring, coordination and management functions) relegated to or implemented through a Domain by an IS. Through their Domains a user or IS maintains dominion and control over the interrelationships and interactions between its Domain and other objects.

Each IS or Person involved in a network is in complete control of at least one PD that they have exclusive rights to as the HS. Each of an IS' s exclusive Home PDs (HPD) keep track of planned and actual actions and the other ISs with which those actions interact. Each HPD stores the HS's own data from their perspective about the relationships and interactions in which it is involved. An IS's HPD has a subjective view of everything it is in control of (its assets, actions, etc.). Although an IS can have more than one HPD, an IS will usually want one WE HPD where all of the HS's data and access points to their other HPDs are consolidated. This enables a WE HS to manage and coordinate itself in a holistic way.

A PD also has a reflexive view of everything that it is (not in control of but that it is) interdependent on for the interactions in which the HS is involved. These reflexive views of related ISs and their objects represent the extended existence of a HS and it's interdependencies with other ISs and other objects with which the HS interacts. These reflexive views are encapsulated in Input and Output Objects (IOO s) passed as messages between PD s from a source PD to a destination PD. Each HS has control of the IOO s that pass in and out of its PD. These IOOs represent offers (proposals) and acceptances (affirmations) of agreements to specific action, and commit participating IS s to enact these specified actions at an agreed time. Each IS is in control of its own actions or the interactions that it is involved in because every action requires proactive consent as either a proposition or affirmation by each party involved. These specific actions must be completely explicitly or implicitly negotiated, (see CIOOT below)

An HS can propose a given exchange or interaction with other IS(s) in a common network, but other IS(s), or Prospective Interaction Partners (PIP), must then affirm the proposal before it can be enacted. A PD keeps track of all the IOO s that might, will, have or could have been passed between the HS and its Partner IS's Domains. The way partnerships are controlled and monitored as they are being set-up is similar to how the negotiations of relationships with other newly identified (created, recognized or registered) objects are coordinated. A partner registration would be an example of a main object registration in the first or lowest dimension of a domain. There is a particular sequence of stages that a prospective partnership or other potential external object must go through before it becomes an actual part of a given IS's Domain.

(Please see the chart below about Implementing a Class and Method for a Newly Identified Item or Entity...) Implementing A Class and Method(s) for a Newly Identified Item or Entity and On-going Coordination of Record Entry, Method Processing & Message Flow (Covers Initiation, Authentication, and Coordination of on-going use by Entities) This shows the process (Step 1,2,3,4) of adding a new Entity (User, Item, Domain, Element, Net, Subject, etc.) by implementing a class and a base set of coordinator methods for the Entity. (by putting raw CID datasets and processing classes in a new unused domain or URL)

This same development process or sequence is happening in the Domains that a given IS's Domain is interacting with, only one Domain's proposed object is the other Domain's accepted object. The same sort of sequence involving development and interaction or negotiation happens on higher dimension levels as internal process loops inside each sequence on the lower level. The properties being manipulated at each stage in the sequence (as the CIDs are changing) can mean slightly different things and can be interpreted in slightly different ways. Nonetheless the processing happens in the same way. For example, instead of potential (0) and actual (1) in the preferred implementation on the left side of the CID these properties mean vision (0) and action (1) on a higher dimension level. You can still see that both 0s mean something planned and Is mean something implemented. It just involves another set of digits in the CID to add the ability to record these additional higher dimensional states. Similarly in the preferred implementation the properties on the right side of the CID mean deduct or supply (1) and induct or demand (0) instead of propose (0) and affirm (1). You can see that both are a matter of give and take. To incorporate these higher dimensional states or properties it is accomplished in the preferred implementation CID in a similarly to that shown below (e.g. X-X). Another set of digits (left and right) is merely added for each added dimension (e.g. XX-XX).

By enabling the HS to use the above procedure to control relationship development and object interaction this aspect of the invention provides a way to tightly regulate the security of one of a Domain (e.g. an individual's PD). PDs presumably have private information in them and therefore it would be in the IS's interest to keep the information private. The development of a partnership is the first step in providing at least the potential for a partner to access or receive some of the private data inside a Domain. The above mechanism or protocol also provides a way for coordination of the interaction of multiple domains and there IS's.

There are vocabularies or pieces of ontology (that include Concepts and Types or non-active instance objects without Value) that are shared between IS PD s as IOO Templates (IOOT s) with one or more IOOs. These IOO Templates are shared to prepare IS s for asynchronously envisioning and negotiating a particular exchange. They are made up of one or more Input Output Definition Objects (IODO). An IODO is a generic form of an IOO that is a Concept or Type of some kind that is not specifically active with unit a quantity Value.

Again, each of the IODO s refers to a designated Concept or Type object or subject and like any IOO is represented by a record comprised of different fields. These fields include a word or other symbol (Label), a definition, a LID, a CID, a Value, a Rank and possibly other information such as Number Type, Media Type etc. These fields are used in a uniform way for each record, so the system can allow users to flexibly add new objects represented by unique new IOO records and still know how to handle them. There may be multiple IOO or IODO records that refer to the same Concept or Type in different situations, i.e. in domains and sub parts of domains. The IOO's words and other symbols (e.g. media) used to refer to a specific Concept or Type can differ at the discretion of different HS users and is recorded as a specific Usage of the Concept in appropriate CD or Entity of the Type in TD. This helps gives the system its pragmatic language processing capabilities needed to facilitate the Pragmatic Web.

A Concept Domain (CD) is used to reflect the usage ofa Concept including the users (partners in use) of the Concept and symbols they use to refer to the Concept. In the case ofa CD the Symbol List (SL) has a record of each symbol used to refer to the Concept and the Concept List (CL) has a record of each Domain (user, IS, or other concept) using or related to the Concept. As a result, not only are all the symbols and the users of a given Concept recorded, but also, the context in which the concept is used is also recorded. The popularity of different words for describing the Concept in different contexts is also monitored and this is used to know what word a domain is to use in a particular context. Also, when a IS changes the word or other symbol used to refer to a particular Concept in a Domain under their control, this is reflected in this Concept's Concept Domain (CD).

Through this mechanism a word or symbol user impacts the evolution of ontology, concepts, words or symbols used and their meaning within a Community. This also is how an IS and an IS's PD is able to understand and control interaction with the environment. This (language) processing mechanism can also be used to enable an IS controlled Domain to synthesize visual, auditory or other symbols into commands that humans and other entities that participate in the (semiotic) network can understand.

This processing mechanism can also be used to enable an IS controlled Domain to efficiently and effectively synthesize real (physical objects) into products and packages of products that humans and other entities that participate in the network expect to receive. Once an exchange agreement is made between IS s using the invention, the IS s are obligated to actually make the agreed physical changes or exchanges (e.g. send out the packages of products) and the HS of a particular HD can set their HD to automatically enact agreed physical changes. In this way the disclosed invention enables and requires a Domain to control both physical and mental aspects of an IS's environment.

So through this mechanism IS s connected by a network understand each other and can negotiate and enact agreements about real changes. Again, once future changes are negotiated asynchronously by IS s, the Domain interfaces of these IS s regulate the enactment of these (physical) changes in the environment. These enactments involve physical transformational changes in the IS s and other physical entities that the IOO s actually refer to. Again an IOO refers to a real (quantity) whole or part ofa specific object or entity involved in the real change. The amount of change is determined by the value of the IOO record for each part of an agreed change. Although there is a standard unit of measure, the IODO records in an IOOT describing a change may also encapsulate alternative units of measure used to quantify the amount of change.

In this way the disclosed invention enables an IS and an IS's exclusive PD(s) to synthetically create understandable commands and real changes through interaction with (other entities in) their physical environment.

Lets get more specific about more aspects of the invention. The IOOT is used to efficiently and effectively communicate the language used to describe the context for the activity or change to be negotiated. The IOOT is also used to prepare the specific path within the recipients data storage system that will be used to store information about particular interactions. IOOT s are made up of one or more chains of IODO s. Within the records that define or make up these IODO s is a Link ID (LID) that defines the Object ID used to name and link to the nodes in the (relative) paths through which data is organized in a domain. LIDs are used in related domains to demarcate where within the domain or in relation to the subject of the domain the object identified by the LID is related.

One or more of these LID s make up what is called a Domain Chain (DC). DC s can be used to define the absolute or relative path to data located in a Domain. The data will be located in a file or Uniform Basic Data Set (UBDS) by the name of the active CID. DC s are represented both persistently in the organizing structure of stored data and in memory. DCs are used by Domain data interfaces to know where data is located (for read and write operations).

The IOODT s do not represent (potential or actual) change itself, but are used to organize or give structure and meaning to what is described and negotiated in communications or representations about potential or actual as well as proposed or affirmed change. IOODT s are syntactical representations used to describe a context of action, not representative ofa certain force or extent of an action. An IOODT can be exchanged between Partners once the FIRST PHASE of the Partnership development process is complete where an envisioned Partnership (PIP) is not only Proposed but also Affirmed.

The defined paths of a DC identify locations in which data is stored about a given AIOO. For example, data about a specific most granularly defined change (See IOOVs below) is found in the IOO at the end ofa specific DC within a CIOOT. This DC is identified as a string of one or more LIDs of an AIOO and its parents, as well as the LIDs of the selected Options from the AIOO on down. Each of these LIDs is a node in the path to the IOOs in a represented IOOT or to the real change data in a represented CIOOT. (DC along with) The CID of the AIOO represents the context or the state of the negotiation of the change represented by the IOOT both before and after it is complete. The CID is also the name of the node (or file) located at the nexus of the change represented by the IOOT.

Once CIDs are completely specified and OVs or Values in records representing IOOs describe when, how much and to what extent a change will take place then a CIOOT is defined that can represent a change in its entirety. A CIOOT must have all the elements or IOO s of a change completely specified. An IOO of a change, including future prospective change, is completely specified when each state of each object involved in a change is known by all parties involved, (all 0s or Is in CID)

Again, other objects related to a HS and the states of interaction objects (or status of the relationship between these object and the HS) are reflected in an HS 's PD. These related objects and relationships are represented using Link ID s or LID s (in our preferred implementation) and Relationship Status ID s (called Class ID s or CID s in our preferred implementation). The CID represents the status of an object. A CID is used to describe all the various states objects might have or that must be known about all the objects used to describe a given change is in its entirety in a CIOOT. A CIOOT, or real envisioned or enacted interaction, can only be exchanged between Partners once the SECOND PHASE of the Partnership development process is complete (where an enacted Partnership is Proposed and Affirmed).

Again, these templates or strings of one or more IOO s, complete or otherwise, can only be passed between one IS and another when both parties agreed to relate (See Partnerships). Partners are in either of two states; they are in either an envisioned or FIRST PHASE state (0 in the preferred implementation) or in an actual SECOND PHASE (1 in the preferred implementation) state. In addition to partnerships, the other IOO s (which could represent anything else, information or otherwise, that can be passed between partners) are also in one of these and other evolving states of readiness for ex-change or passing between IS 's Domains. In this way each Domain keeps track of the current state of all IOO s that are part of interactions in the process of being planned or enacted. Current Interactions (CI s) are planned for enactment sometime from the current time they are affirmed into the future. Past Interactions (PI s) are interactions planned or enacted in the past that are logged in Domain archives organizing IOO s of all PI s by CID as they happen or expire. CI s are organized by CID in each IS Partner's Domain and include anticipated date/time of the CI in addition to other information.

All data is not only partitioned by IS, but is also (unitarily) packaged according to the smallest unit size of each piece of an inter-partner exchange. These Unitary Objects (UO s) are exchanged unitarily as well as in groups, when relevant, with the other IOO s with which they are exchanged in a given interaction at an instance in time. A Uniform Basic Data Unit (UBDU) is the way each IOO is represented in a Domain in which it belongs. It is comprised of fields or pieces of information for each of the fields mentioned in the "Terms and Software Objects" list above. One or more UBDU s make up a set or group of UBDU s called a Uniform Basic Data Set (UBDS). A UBDS includes UBDU s that describe Parents, Options, Class, Items, etc. that are related to the data in the UBDS. The UBDUs (items or records) are complete IOO s with CID s the same size as the CID Name (filename) of the UBDS and has all specified states (0 or 1) for each (two) digits for every dimension of the CID in the preferred implementation.

The Active IOO (AIOO) is the UO or IOO at the nexus or interior anchor point of a DC of particular interaction. It is represented by the Active UBDU that is selected in the Interface when the HS chooses to enact or actualize a change. It is the point at which a IOOT whether active or not diverges from one Item IOO per dimension to multiple. By setting the active point prior to sending the sender determines the context and granularity of what is to be sent. Then when the recipient receives the data it includes the DC and other information necessary to put it in the right place. This sending and receiving can be set to be done automatically. When receiving data you have rights to control you can receive in different places than it was sent from. In this way data can be moved from its current location to any other location. This function can be used to change the location or establish an additional location for data. If the user desires the same data objects to be updated in the other locations when it changes somewhere else, the user can elect to have this done. This is controlled and managed through author and use tracking. This mechanism can be used to capture experience or experimental data in one location and have it update detail and summary records of this experiential data in another location.

This AIOO has a time/date value that is the time/date at which the interaction is to actualize. All interactions are made up of UO s or IOOs with completely known states. These known states are negotiated and agreed to between interacting partners during the planning process prior to actualization of the agreed changes. Once the AIOO is triggered by a timer (attached to an all X file), all the sub processes of which a given interaction is made up are initiated. The actualization of the interaction is represented in the form of each IOO that was intended to change as a part of the interaction in an affirmed actual state with a past time/date. (Also in the preferred implementation the OD Quant State part of the CID representing the stage grouping of a UBDS that is now turned from X (potential) to 1 (actual) and the change is complete and archived.

A Domain, its structure, and its coordinated interaction with other Domains enable a network of interacting ISs to coordinate, manage and/or simulate interaction and sharing of IOO s that can represent any object of exchange (including revenues and expenses) in an economic or ecological system. As a result, the system implementation of the present invention enables the planning, simulating, actualizing, organization, motivation, development and control of manmade networks. An embodiment of the invention can also enable simulation of and/or interaction with natural networks, such as evolving biological ecosystems or communities, neural networks in brains, or concept and word networks in ontology. Ontology are made up of shared vocabularies or agreements on what words are to be used to communicate specific concepts and/or describe certain interaction between Domains of concern to particular knowledge domains.

IOO s that are a part of a given interaction are stored in the IS 's Domain as reflections of the way the interaction is stored in the Domains of interaction Domains or partners. For example, in an IOO describing a partnership (in the OD first dimension) we would have information about the partner in a IS s Domain. The information about themselves, the HS, is assumed to be about the currently active Domain of the IS. In this way a Domain only needs a single record to be a particular reflexive relationship, e.g. for an AIOO describing a partnership, around which an interaction takes place. Because each party to an interaction has control of whether it participates in a specific interaction or change and has complete control over specific records that describe their part of the change, the system not only enables self-determination for each IS involved in an interaction, but also enables the system to manage the concurrent writing of data about a specific change, without requiring the prevention or management of the otherwise possible scenario where the same data record or individual IOO to be changed by more than one party at a specific time. Therefore, the system alleviates the need to solve the previously unsatisfactorily solved problem of how to manage concurrent writes of the same data record field by multiple users in at the same time. As a result the system enables each HS of a PD to have exclusive control of specific changes to current state information while still enabling the free flow and coordination of change in data and the real objects the data represents.

An embodiment of the invention in the technical arts is capable of simulating, enabling and/or enacting simultaneous change in multiple respective ISs or their Domains at a distance. Therefore, the method of this invention is one way to explain the Bell phenomenon in quantum physics. Each partner in an in an interaction, must trust that the planned future interactions or changes to the current state of IOO s represented reflexively in different HS Domains will be changed according to previously agreed parameters negotiated by involved partners. When using the System, users are involved in a negotiation process that enables any Partner to initiate (Propose) a particular change to one or more related IOO s. Then the other Partner must decide whether to agree with or affirm this Proposal. For example, if one party wants to share in a partnership with another IS, they would then initiate or propose a partnership with the prospective Partner through their Domain. Then the prospective Partner would be sent a Message, (a communication packet comprised of one or more IODO s), about the proposed Partnership. This prospective Partner would then see this proposal and have an opportunity to agree to (Affirm) the partnership.

An IS is able to send a partner whatever IOOs the IS Authors. There is a dictionary that keeps track of everything an author (HS of a Domain) creates Parts of a Domain can be sent on an as needed basis by setting the active point at the context and level of granularity the sender desires to send the recipient. The sender only sends what they want so share with the partner. In this way an author has total control of the content that it creates. Also, use dictionary that keeps track of the location where everything created is sent and used, so when the data changes, those who elect to be updated can be. This is how all separate Domains are kept in synch with each other.

Within Domains, data about IOO s moves between stages, or staged data locations indicated by the CID (filename) according to the state these IOO s are in at a particular stage in the negotiation process. Domains keep track of the Current State of everything related to the HS. The complex relationships between interrelated aspects of a change or interaction are monitored and controlled by representing IOO s on multiple dimensions in a Domain. IOO s represented at each dimension are able to move or change freely within the dimension in which they are represented, within the confines of the set state of all objects represented in previous or lower dimensions. The IS is provided control over change to IOO s through an Uniform Interface (UI), which presents this complex multi-dimensional data about pending interaction in a form that can be understood and controlled by the IS. A user of a GUI, or other entity implementing AFFIRM, is able to set the state and Domain location of objects it is interested in managing at a particular point in time. Multiple perspectives or views of data about currently pending changes (planning decisions or actualizing actions) can be accessed and controlled by the IS in the UI. The Position Views (PV) are able to show different perspectives of the same context or IOOT. Therefore, the system enables individuals to view and manage data about future change from the perspective of different roles. A given IS can view and control its data from these multiple perspectives, or in a situation where an IS is managed by more than one person (e.g. a group or an organization), each person can see the organization from the authorized perspectives or Position Views (PV s) that are appropriate for their roles within the IS.

As the states of IOO s change they move into successive staging areas for objects in the particular state to which they are changing. Every data set comprised of data for a particular aspect of an interaction is grouped according to state and is linked to other IOO s in the same and other dimensions describing other details about the specific interaction. A particular interaction has multiple related IOO s that have common states and reflexive Link ID s (LID s) in common dimensions. This commonality exists for all dimensions from the AIOO on back through the LID of the Domain Chain for previous dimensions to the first dimension which identifies the specific IS with which the HS is interacting. Each of these commonalities, an AIOO and its ancestors (parents), has a reflexive LID with one that exists in the interacting IS 's Domain. For example, if the HS has money it is exchanging for a product from a partner IS, the partner has the HS 's money, represented as an IOO with a money LID and value, in the reflexive location (with the same Class ID (CID) on the left side and the CID and the opposite (in/out) properties on the right side) denoting a particular reflexive place in the related Domain. This is the method used by a partner (say the original HS mentioned above) in their Domain to represent the others products which the HS plans to exchange for.

Both sides of a reflexive exchange in a particular state like this are represented in each of the given IS s in the same CID location with reflexive LID s. The same IOO is represented in exchanging PD s (with the same Class ID (CID) on the left side and the CID on the right side being opposite) They are in different parts of each Partner's Domain as a result of having the same LID s (except the main OD parent) and different but complementary or opposite Quantitative States (Quant S s) (In/out) in each dimension, (the right side the CID in our preferred implementation).. In our preferred implementation the right side of the CID has opposite signs or spins to designate the complementary state of the SAME IOO s in each partner's domains.

Successive dimensions after the AIOO included in a given interaction focus would have the opposite state (represented in a specific dimension or digit of the CID) in each of the Partners. The Qualitative States (Qual S s) would be the same. Also, all commonalities in a row are recorded in a Domain Chain (a grouping of successive LID s). So each Domain Chain (DC) in a given PD has an equal and opposite DC for a partner domain. Complete IOO s are ready for exchange. Opposing sides or IS s of an interaction represent opposing IOO s, e.g. money paid for products, in the same CIDs in their PD s in the Qual S properties as well as the Quant S properties of CID. They have reflexive LID s and the same IOOs in opposing IS s with opposite Quant S s for each dimension and the same LID s except the far left IS LID which is used to reflect the opposing partner's LID or Domain location in each case. Actually the left side Qual S s will also be opposite outside the OD first dimension when in opposing sides when the actual in one IS is represented as potential in another. This is the essence of how Partnering can enable one IS to capitalize on the resources or assets of another IS. For example, if I produce a product and have it in stock the product is actual in me (Qual S of 1 in preferred implementation) and the product is potential in you (Qual S of 0) if you are interested in the possibility of buying the product. The money you are planning to use to pay for the product had better be actual in you (Qual S of 1).

Utility of the Invention

By using these structures and methods to become more intimate with interaction partners, an AFFIRM user can better manage collaborative goal seeking. AFFIRM enables enhanced management, negotiation, coordination and change of many aspects of and objects within social networks. Much of the benefits of AFFIRM result from the way it provides an integrated solution to many of the common problems experienced when attempting to manage interaction in a social network. There are also several specific features or aspects of AFFIRM that enable it to better address specific requirements of managing social network interaction. Again, the AFFIRM invention and these benefits are also applicable to many other "social networking" situations other than social networks between and made up of humans. The social networks an AFFIRM based computing device can help manage can be networks between and made up of humans and other living things, computing devices, robots and/or other devices from the nano to the macro scale. The point is that the AFFIRM based data structure or domain within a computing device is subject to human control and implements human effect on its environment by regulating managed (planned) action. But the invention will be described in terms of how it enhances security and performance in this area of application, specifically human socioeconomic networks.

AFFIRM is made up of models, methods and tools that enable it to provide these benefits. Specifically there is a generic service-oriented (socioeconomic) model on which the data structures are based. These data structures are designed in such a way that they efficiently and effectively support/enable AFFIRM methods that are used to develop and operate AFFIRM based applications or tools (according to this model). As a result of the AFFIRM models and methods, these AFFIRM based tools, including but not limited to computer network management, business commerce (exchange) applications or other systems based on AFFIRM, are able to develop, negotiate, guide and operate real interaction and transformation in a flexible way that appears intelligent and logical.

Perhaps the greatest benefit of using AFFIRM in socioeconomic network applications is the ability to leverage resource productivity through partner interaction and collaboration (at Internet scale) without jeopardizing security of private information or other property.

Some of the other benefits of AFFIRM based tools include:

• Non-technical end-users can "program" and control their group process interactions

• Data partitioning by Individual Subject (IS) gives IS complete control over their data Collaborative development and sharing of semiotic user determined metadata templates (packages for real object data that give the data meaning) enables evolution of a universal and pragmatic communication medium. Collaborative development and sharing of business process templates (as data that represents negotiated change) enables nimble-quick development of business management applications that reflect business relationships. Collaborative development and sharing of business process template (as data) enables nimble-quick development of real subjects and their objects. Partner relationship and messaging management prevents spread of junk mail, viruses and other forms of attacks Dynamically gather synergistic partners into knowledge-based online collaborative networks. Provide personal real-time work management interface on any Internet device. Coordinate interactive planning, agreement negotiating, group decision-making, and fulfillment. Structure, filter, and aggregate applied knowledge and specific recommendations on demand. Manage the business side of knowledge-based collaboration and innovation. Integrates vertically aligned industry specific socioeconomic entities (e.g. buyers and sellers) as well as horizontal cross industry co-developers in coordinated value creation networks. Interoperate with any existing web content, media, or application. Integrate knowledge-based collaboration across platforms/markets/domains/enterprises/etc. Maintain strict security of private and intellectual property. Manages coordinated interaction of multiple individual domains. Enables access and control from "light-weight" (e.g. wireless/portable) devices.

Example Implementation of the Invention Overview

RSVPortfolio (RSVP) comprises of several tightly integrated but independent components- at server level and at client level. The client level component, called the RSVP Client, is basically a User Interface that is, in our current implementation, displayed by either the client's browser as an applet or by an application using Java Virtual Machine (JVM). The client applet is fetched by the browser from a Web server whereas the application resides locally and is loaded at the time of execution. The client also maintains a local database of records obtained from the server, performs calculations and communicates with the different RSVP servers as needed. The RSVP servers listen to client's requests, perform the requested operations and return the outcome back to the client.

RSVPortfolio Feature List

Basic Parts of the RSVPortfolio system: Server software provides web, data and messaging services Client software makes requests to server, as application or browser applet Browser applet running in secured "sandbox" requires synchronous.

Client Server communication- synchronous, bi-directional, temporary connections Server and client can be on same computer, even wireless handheld device Other servers including web and ftp can also be on the one device

Server to server communication through asynchronous peer-to-peer messaging If initial try of send fails then it is put in queue for retrying later Partner initiation and affirmation (incl. validation of users/domains) Send / Receive coordination and updating Message oriented architecture Enables asynchronous communication Efficient for Internet- doesn't require waiting for connections Enables scalability- doesn't require constant connection Fault tolerant- will retry messages when not received

Graphical User Interface- graphical software that enables user interaction

Toolbar- User interface component that enables user to control Active function

Active Window- Shows active domain component(s) or other Active function IN-Setup and maintenance interface Partners- setup / add / edit partner Bi-directional link requiring initiation and affirmation Prevents or alleviates- Junk mail Spread of viruses Denial of service attacks Hacker vulnerability Media Types- setup / add / edit media type Virtually any application, device or media HTML- web pages Streaming video and audio PDF-protects text from copying Graph- graphic of range of values i.e. trend analysis Document- any document that can be viewed in browser Any MS-Office document Many others Telephony- voice over IP Instant Message Web based E-mail File browsers Any web based application Any web enabled device, i.e. player/recorder Any web media Number Types- setup / add / edit number type Default Number formats Nominal, $, Other Currencies Calculations Sum Averages Etc. Sort or priority User defined Formats Items- setup / find / import / create / edit Item Options- setup / find / import / create / edit Option Ftp Servers- setup / create / edit ftp server List- lists Active Components Send- sends message comprised of Active Components to partner List potential recipient partners Send to multiple partners Send it! - initiates sending of a message Receive- receives message comprised of active components from partner Preview- previews message from a given partner Receive It! - receives message to from a given partner Set Active Point Include parents? From this point down? Overwrite? Refresh- refresh client with a domain's most current data on server Doesn't allow overwrite of components that changed since read Domain Navigator- Structured part of interface outlining components of a domain Component- object (instance) represented by a button Component Types- Option (Column Header)- optional view or path through domain Diagonal Header- link to and aggregate of items Item- individual components under diagonal headers Navigation conventions- Click Header to Activate column and show its Items All Items and their sub Items in sub columns are considered Active Click down arrow to scroll through Items in column Click terminated down arrow to go to next set of Items in column Click any button once to activate it and its linked media Click Item once to activate only it and navigate over a column Click button a 2^nd time to edit the component's properties Edit Component (instance)- by clicking on component's button a 2^nd time Label- short identifier for the component Description- long text describing the component Quantity- a value measure for this component (instance) Number Type- type of value this component's quantity represents Media URL- link location of component program, file or media Sharing links prevents attaching/downloading problems Media Type- type of program, file or media for this component Label with all capital letters plays in same browser session Label with non-capitals plays in separate browser session Save- saves changes to the component instance Replicate- replicates component to new instance Upload- uploads to ftp server and auto-records location in URL Remove- removes instance from Domain Navigator and archives Find/ Add- used to find/add components (Items and Options) Find- find Item/Option in column, domain or shared dictionary GoTo- go to found column Item/Option Replicate- replicate found column Item/Option Use- use found domain Item/Option not in column Import- import found dictionary Item/Option not in domain Create- create Item/Option not found Above prevents duplication, creating only nonexistent Item/Option Media Window- Media- program, file or media linked to component Media plays in media window in right frame or in new browser session New Browser Session-maintains media access when other media is called

Advanced Parts of the RSVPortfolio system:

Business Objects, what they represent, and examples: Domain- one per entity, i.e. patient, doctor, partnership, provider network Knowledge Template- component framework, i.e. OB primary preventive care Template Author- expert that designs standard set of practices, i.e. MD, ACOG Provider- performer/manager of service, i.e. physician, other providers Service Relationship- ongoing shared process, i.e. patient/providers connections Resource- domain possession, i.e.time, info, money, space, equipment, energy, etc Deliverable- simultaneously occurring Service Components, i.e. med procedure Service Component - part of Deliverable derived from Resource, i.e. information Decision Cycle- complete increment of time for planning and delivering services Phases of Exchange- groupings of certain types of interactions between domains Exchange Protocol- model for orderly standards based, but organic, process flow Beneficiary- process result owner, i.e. patient/health, provider/payment

Processing features: Partner Setup- initiates/affirms partner relationship, i.e. patient/doctor relationship Sending and receiving of messages comprised of Service Components, i.e. easy sharing of medical information according to HIPPA regulations Navigation of a domain, relevant applications, and media, i.e. easy access Sharing Knowledge Templates, i.e. recommended medical record best practice Links automatically call program or media, i.e. other application or media display Media version management-keeps everyone updated with current media version Interaction Model- coordinates inter-domain planning, action, and learning Service Management- coordination of services, i.e. by primary physician, HMO Relationship Management- direct result of use, i.e. doctor/patient communication Purpose Driven- shared mission, i.e. patient health planning and monitoring Survey research- evaluate partner needs, i.e. patient registration and review Participant tracking- monitors interaction, i.e. provider / patient performance Performance monitoring and reporting- graphs, reports and calculations Benchmarking Research- turns tacit experience into documented knowledge Portfolio Management- Analyzes and Synthesizes the components of a portfolio

Types of RSVP Servers

Main Server

A main RSVP server not only listens and handles client's requests, but it can also communicate with other main or supporting RSVP servers on a peer-to-peer basis to perform different tasks in a distributed fashion. All the servers are multi-threaded and can handle several requests concurrently. Any requests to the server from a client or from one server to another are made following a predefined request protocol, which may encapsulate other data structures that might be necessary for the request to be handled properly. Similarly, the responses from the servers are also made in a format based on predefined response protocol that encapsulates a response code and any other data that might have been requested.

Upload Server

RSVP Upload server acts as an adjunct server, which can either run as a separate thread of the RSVP Main Server or independently on a separate machine. It runs at a port different from RSVP server. The client's browser applet or application requests to upload a document (could be any of the binary of text based formats) by posting a HTML form encoded using multipart/form- data (as specified by W3's HTTP standard). When the upload server receives such a request, it spawns a new thread to handle it. The submitted data is parsed for the header, request fields and files submitted. Request fields contain values for the server's address, username, password and folder where the file is to be uploaded. The upload server's thread serving the request then opens a connection to the specified server and uploads the document. On success, an appropriate HTTP response is sent to the client along with a complete URL of the uploaded page, which now serves as the address of the document in the cyberspace. The unique feature of RSVP upload is that this address now becomes the URL field of the related record and is saved both on the local client database as well as the back end database on the main RSVP server.

Calculation Server

RSVP calculation server is another server in the pool of RSV servers. Like upload server, it can either run on the same machine as the main server or on a separate machine. Several different kinds of calculations are to be performed by data server on a domain's data. These calculations are then relegated to the calculation server by data server to distribute the load. Message Server

RSVP Message Server maintains a queue of messages for peer-to-peer communications between different RSVP servers. Whenever an RSVP server tries to communicate with another server but fails, the message is then stores in the queue of RSVP message server which then tries to resend the message at periodic intervals.

Data and File Structures

Uniform Domain Structure

Domain is a physical location in a server where data owned by an entity is stored. The name of the database is a combination of host address of the main RSVP server and username.

Dimension

Describes the hierarchical depth or linking in database. In a UI it is same as the number of columns of items.

Uniform Record

It forms of the core of RSVP data structure. All data files on the server are written using this record. The fields are separated by a '|' character and the record is saved as a concantenated string. Similarly, on the client side all the records in the local database, which also directly correspond to buttons on the UI, are an instance of this record. A Uniform Record has following fields: 1. BID/CID: This field is called a CID on the server side and BID on client side. A CID contains a number of 'x', '1' or '0' characters on either side ofa '-'. The number of characters on the left side defines dimension of that record. Any record with equal number of characters on either side of '-' are called items whereas the ones with unequal sizes are called options. A BID on the client side defines type of record (identity or item), depth (dimension), index of the record in the list and the indices followed in the preceding records to reach this particular record. 2. Label: Label of the record 3. Description: A detailed description of the record. 4. URL: Location of the media in the Internet/Intranet. 5. Media Type: The type of media to be used while showing URL of this record. 6. Number Type: Type of the value contained in the record, which is used for formatting the value being displayed and performing calculations on the server side. It also defines min and max possible values and if the values (Items) shown are in any particular sorted order. 7. Value: Quantity as defined by number type. 8. Rank: position of the record within a file. 9. Link ID: A unique identifier of the record. When a record is copied from an original one, it inherits its link id which now defines the relationship between the two. It is generated randomly. 10. Date/Time: of the creation of the record. File Names and Structure

The files have the same name as the identity record they contain. Records other than identity in the file are either options or items.

Types of RSVP (User Creatable Knowledge) objects

RSVP Knowledge Objects

RSVP Knowledge Objects are user creatable and definable objects that populate an RSVP Domain as records and User Interface as Buttons. They are instances of Uniform Records containing all the fields required for a complete record as defined above. On the server side, these records are maintained as lists under an identity record, including the identity record itself, and on the client side they reside in memory as instance of records and can be visually represented by the User Interface as Buttons.

Item Objects

All items are instances of Uniform Record. They belong to a particular set or file of data by virtue of their BID/CID (see BID/CID above) and are listed below headers (See Item Headers below) in the User Interface. • Regular Items Regular items are non-identity records in the data and item button in the user interface. All the items belonging to an identity record are listed as buttons in an item panel and are positioned below the corresponding header (see Item Header below). • Option Items Options items are also non-identity records listed under option identity records in the data and item button in the user interface. They are also defined using Uniform Records, but rather than being actual objects they form classes or categories that are separate locations for data to reside that fit that class or category. • Default Options A default option item is the first option item in the list and is a copy of the option header with only difference between the two being their CIDs. In a user's default view all the items and item header are chained to by using link ids of default options. A user can specify a non-default option to be default, in which case the new option becomes the header (identity) and first option item in the list.

Header Objects

Headers are the "identity records" that identify the dataset they belong to. The Header records are called "identity records" because in a file system (on the server or client) it is the record that has the same CID/BID as the file or table name. On the GUI this Header is represented as a bigger button positioned over an Item Panel. This is why it is called a "Header". The Item Panel is filled with a smaller button for each item record in the dataset.

• Regular Item Headers (Diagonal Headers in the UI) Regular item headers occupy diagonal position in the knowledge navigation table on the client's User Interface. On the server side their CIDs have equal number of characters on either side ofa '-' characters. The first digit in the bid is a 0 and second and third digits are equals. Regular Item Headers are located by an identifier that is a combination of link id of an option having same dimension as the header and an item chosen in the preceding dimension. Described another way, unique paths to all regular items or diagonal headers are formed by a combination of the link of a preceding item and the option category to which this header belongs. Hence all the items belonging to the regular item or diagonal header are accessible by following this unique path. • Option Headers Option header is the same as default option except for its CID. The CID of an option header defines it as the identity record on the data side. On the client side, it appears as an option header button right above option panel. It can only hold positions in the I^st row and any column except the I^st. The cid of an option header has unequal number of characters on either side ofa '-', and on the BID the second and third digits are not equal

Linking Through Datasets that Hold RSVP Object Instance Records

RSVP Knowledge Object instances (as described above) are stored as data on the data server in a labyrinth of datasets that are located according to specific rules that depend on the specific situation. For example before RSVP Instance Objects can be displayed on the GUI, the data describing these instances must be read from the server. Therefore the server must link through the datasets to find the appropriate data for a given client request. In this example then the GUI will be able to display all the appropriate RSVP Objects in the "Knowledge Navigator" described below under User Interface.

For the GUI example the data files for the first column in the UI are found in data dimension 0 in datasets having CID filenames with one digit on both the left and right sides of the CID i.e. X_X). The option item listings are found under the Option Header buttons that start in the second column in the UI. They are still in data dimension 0 because the right side of the CID still only has one digit. Data instances for these option items are found in the dataset name (CID) for successive columns determined by progressively adding one more digit on the left side of the previous columns CID with the right side remaining with one digit, (i.e. XX_X for column 2 / dim 0 or XXX_X for column 3 / dim 0, etc.) These datasets are kept at the same level (dimension 0) of the file system or dataset hierarchy (same level as the top level where the domain begins).

The data for subsequent Diagonal Headers are in datasets (considered to be in further dimensions down and listed in Diagonal Header buttons progressively one more row down for each additional column) that are kept in dataset locations, directories or folders with names that are derived by combining a Link ID from an item in the option file for the subsequent column with a Link ID of an item in the preceding dimension. Once the new location is linked to, the dataset must be located for the items in that next dimension. The CID of the next Dimension is the dataset or file name where items can be located for the next dimension. The CID name of the next dataset holding Regular Item Instance data (to be listed under a Diagonal Header) is determined by adding another digit to both sides of the CID of the previous dimension. (See "CID Growth" in the more detailed description of the invention). Linking through the datasets to pick up appropriate data for a given GUI or other requirement progresses in this way through each path that has data in the next dimension for each relevant item until all there are no more subsequent dimensions with data. There are different ways that the desired instance data is determined for a particular situation. For example, a client can choose to narrow down what is read from the data store to only include the top ten items in a particular dimension.

Dictionary

A dictionary maintains list of all the Uniform Records created for search and updating at a later time. A domain level dictionary contains all records that have been created, used or received by the owner of the domain. A shared dictionary on the other hand keeps all the records used, created and received by domains participating in the share. Each record in the dictionary also contains links to a usage file. This usage file contains a record of all domains and files that are currently using the record. If a user domain has opted to be informed of changes to the original record, then it is informed of such changes. Also, the domain of the author is kept track of so that an item can be prevented from being edited by someone other than the author.

User Interface (UI) Components (See Figure Depicting GUI)

RSVP Window

In the preferred implementation, it is the left frame of the browser window that shows the RSVP applet.

Toolbar

It is the topmost horizontal bar on the Graphical User Interface and contains following buttons: • IN or Setup • List • Send • Receive • Refresh • Home

Active Window

Active window is a container panel right below toolbar and above knowledge navigation panel. It can either show description of a record or other panels depending upon user's actions.

Edit window

This Panel is below the toolbar and contains labels, text fields and buttons. It shows all the fields belonging to a currently selected Uniform Record (UR) other than link id and rank. The labels in the panel define names of the record fields and text fields their corresponding values. Number and Media types are represented as buttons that can be clicked to change their values. The buttons at the bottom of the edit window allow for saving, removing, replicating of the record, whereas upload brings up an upload page in the media window thereby allowing users to upload their documents.

Knowledge Navigator Window and its Buttons

Buttons are instances of Uniform Records that show in the Knowledge Navigator (See figure depiction the GUI) as buttons with a label or graphic. Buttons can represent following records: • Header: These records are also called headers. In case of items, these headers form diagonal buttons on the navigation panel. In case of option these form all the headers on first row except the one on first column. The first click of such a button shows description on edit window and item panel or option panel beneath it. Second click allows for editing of the record on edit window. • Items: The first click on a button shows description of the record whereas second click shows an edit window that allows users to edit different values of a record. If the record has a URL linked to it, it is shown on the media window. When an item button is selected a subsequent identity button is also shown on the navigation panel.

Item Panel It is a panel holding a list of item buttons under an identity record, also represented by diagonal headers in the navigation panel. No more than 10 items can be shown in a given view. A user can see the next or previous 10 listing of items by clicking down or up arrow on the panel correspondingly.

Option Panel

In the same way as item panel, it holds list of options under an option header.

INPanel

InPanel is viewed within Active window and has following components: a) Ftp Server: It shows the list of ftp servers where the user can upload his documents. Such a list is maintained on the servers-side and every time a client wants to view it, a request is made to the server for the list and displayed in FtpPanel upon successful reply. A user also has ability to add new ftp servers to the list, edit and remove existing ones. b) Partners: Much like ftp server list Partner list allows a user to view, add, edit and remove partners. The details of this function are described under Partnership. c) Number Types: Allows to view, add, edit and remove Number Types. d) Media Types: Allows to view, add, edit and remove media types. e) Items: Items can be added to the main dictionary from here. f) Options: Options can be added to the main dictionary from here.

Media window

The right frame of the browser window is called media window and is used to show URLs of a Uniform Record as defined by the record's media type field and currently selected in RSVP window. In addition to Audio / Video, Web pages, Graphics and more, "media" can also be any other software that is accessible from a web browser. See exibit showing all the types of internal and external programs that can be accessed that are outside of but accessible from RSVP. Example Application on

visscher@lntellivlsion.com (616) 399-7236 Confidential Material

INTV is a networked management and communication service that enables others, without prior programming experience, to easily program software applications that can be distributed under the INTV Intellivision name and used to manage communication and interaction in a network. INTV and Intellivision are based on a technology called AFFIRM that enables the capture, control and coordination of the dynamics of networks in a data driven way. Basically it helps any entity to communicate with other entities in the recognition and selection of opportunities as well as the coordination of opportunity realization. AFFIRM is a predictive and prescriptive framework for capturing and controlling the dynamics and behavior of a network. So as a result of the use of an AFFIRM based system, research is automatically being done and applied to enable learning and enhance performance network wide. As applied in health, Intellivision is both an intelligent vision for how healthcare can be greatly improved, as well as a tool by which this and others' visions can be planned and enacted.

Although healthcare networks are only one of many different types of networks that will benefit from being better managed with AFFIRM based tools, discussing the AFFIRM application in this volatile, uncertain, complex and ambiguous environment will shed light on the technology's value in a host of other analogous situations. In terms of health, an AFFIRM based system enables all network participants (those involved in health related activities, actions, interactions, transactions, etc.) to have the intelligent vision necessary to make wise decisions and coordinate secure implementation of those decisions. Thus the AFFIRM based tool will provide users in healthcare with enhanced vision and action, with the economical enhancement of patient health as the driver. The underlying intellectual property (AFFIRM), that makes Intellivision possible, is relatively complex. This document is not intended to give you an in-depth understanding of it, but other companion documents are available to create a deeper understanding. This document will explain the concepts, so you can understand its potential, learn a bit about how it works, and also see some quick examples of its use. Both individuals and whole healthcare delivery networks will benefit from improved quality and efficiency, while reducing medical errors and increasing patient safety. And at the same time, with unparalleled security and control, any individual or organization in the network can be empowered to have an incredible array of valuable new integrative opportunities. These integrative opportunities tend to result from the better data modeling, collection and sharing capabilities that this data driven communication and management technology facilitates.

The core principle of our fourth generation communication networking technology is based on the concept of a Personal Domain. A PD is an individualized "knowledgebase in cyberspace". It makes all of your critical personal or business data (e.g. work, medical, legal, financial, educational, commercial, etc.) electronically accessible and actionable by YOU from anywhere. And last but not least, all of the pieces of data in a PD can be instantly shared (sent and received) with anyone on a secure and as needed basis. Each entity with a PD, e.g. a doctor's office, physician, patient, etc., can take a holistic approach to their performance, physical (health), financial (accounts), etc. In terms of healthcare applications one area in which this invention will be particularly beneficial is in managing (employer, employee) individual health savings accounts (HSAs), a healthcare financing and administration tool recently approved by the US congress.

You can see from points 1-3 above why this invention is a mix of database and communication technology. And as far as databases go, many think that a PD will be to centralized databases, as the PC was to mainframes. You can see by point 4 that there is also some communication technology involved here akin to email or IM. But a PD is also better at communicating structured information than email or IM. One of the beauties of a PD is how it enables the information sharing (or collaborative) process to be organized, efficient and secure by allowing members of a network to share organization templates and each person in the network to immediately see the important or pertinent information, organized according to their priority settings, for their current context or activity.

If you've ever tried to organize your emails, attachments and other related documents into folders, and then tried to share this same information in the same organization scheme with others using different computers, then you know how difficult it is, today, to achieve just one of the benefits that become automatic with PDs and the AFFIRM technology on which they are based.

You may skip the following introductory information and proceed to application (healthcare) specifics starting on slide 9, if you are already familiar with the basics of the AFFIRM invention vs. current art.

To help you better understand the significance of this new communication technology, I will present 1^st the evolution of communication networks, 2^nd why PDs are unique, and 3^rd, why they are valuable in Healthcare. Basically the value or benefits result from finally being able to have the right information, at the right place, at the right time. If you are experienced with the healthcare system, you know this ideal is still just a dream.

Evolution of Communication Networks (First Generation) ' Traditional organizations like our military and many large corporations Chain Strengths: Easy to understand and implement Communication Consistency Limited Scalability Weaknesses: Unique Rigid, not robust or Flexible Individual Insular Low Member Satisfaction

The first generation ofa communication network, such as used in the military and large corporations is the Chain or Top Down network. Its weaknesses include the fact that it is rigid, Insular, and has low member satisfaction.

Evolution of Communication Networks

The second generation, hub and spoke, is not secure, has only moderate member satisfaction, is disaster prone, and scalability is difficult. These weaknesses have plagued many e-commerce hubs.

Evolution of Communication Networks (Third Generation) Current market status: email & instant messaging t Email and instant messaging are not platforms for passing structured data. Strengths: Member Satisfaction Robust strength Medium Scalability Weaknesses: Lack of Secure Protocols Chaotic Formation Difficult for Leaders to Emerge

The current or third generation is used in email and instant messaging. They are not platforms for passing organized (or what we call structured) data. Other programs that do handle organized data like today's spreadsheets and databases, cannot share and integrate data fluidly. The third generation's all channel approach without data structure creates chaos and insecurity, causing users to be subjected to viruses, junk-mail, information overload, and constant interruptions. Instant messaging is no better than a phone in that the doctors need to be online at the same time as the patient. Current methods involving fax and repeated data entry will no longer be necessary. Altogether, the current generation makes it virtually impossible for a professional care provider to use communication and information technology efficiently and effectively. I completely understand why today's health care workers out there are so frustrated with this generation of tools!

In our Fourth Generation communication networks each PD represents a unique individual or organization. Each PD is a separate personalized interactive hub capable of sharing organized data in a secure manner. Anyone who is even remotely familiar with the limitations of current database and communication technology says "WOW"! And we challenge you to show us any weaknesses.

We enable Personal Domain (PD) users to set up "partnerships" by either proposing or approving each private communication link with another PD. We also then enable the sharing of common organization templates between partners. Then enhanced (organized, qualified, and prioritized) communication (including all sorts of media: voice, data, video, email, documents, etc., is easily managed and securely done on an as needed and trusted basis.

Anyone who tries it is amazed at how they can better manage their world through this one window in an Internet browser or hand held device.

So, whatever your field, there are 6 listed here, Intellivision (and other AFFIRM based software or services) offers a unique and valuable solution. As mentioned above using a PD to manage ones health, including a Health Savings Account (HSA) and ones health maintenance activities is an excellent application. One requirement to enjoy the benefits of an HSA, e.g. tax deductibility of all contributions, is that participants owning HS As are responsible for substantiating the legitimacy of expenses from HSAs. Since a PD connected to a health network is able to automatically monitor and track all healthcare transactions, having a PD would be an excellent way for HSA participants (i.e. patients) to do this. The focus of the rest of this description of use in healthcare is on how it can be used to better manage communication and care by sharing Electronic Medical Records (EMRs) across and along the healthcare network.

Traditional ■ Departmentalized ■ Specialized Contemporary ■ Holistic Patient Centered Case Management ■ Evidence-based Futuristic ■ Telemedicine ■ Practice Based Research Networks (PBRN) ■ Accelerated Translation of Research Into Practice (A TRIP) . Etc.

Another beautiful thing about this enhanced communication technology is that it flexibly adapts to any type of network, whether traditional, contemporary or futuristic.

Healthcare leaders anticipate that a national and international electronic health information network will provide a quantum leap in patient power, doctor power, effectiveness of care and reduction of health care spending by over 10%, as well as security and privacy of information. By using AFFIRM technology, INVT Intellivision can be flexibly adapted to work with or support any network model. First, let see how this will work for the above traditional Health Care System model. Each circle represents a personal domain (PD), where each entity has their PD. There are three focal points in this particular model: the patient, the primary care physician working within the PC, and the hospital. The health insurance payer organization is also included. The EMR incorporating the patients history, physical, laboratory, allergies, medications, and life-style is initially developed, under the new HIPAA guidelines, by the Primary Care Physician and is stored at both the patients location (perhaps on the Internet) and on the network of the PC where the physician practices. Selected information, with the patient's permission, is transmitted over an extranet to the health insurance plan administrator. It is important to understand that there is a separate location for patient data for every entity that is exclusively accessed and changed by that entity, i.e. hospital, care provider, payer, patient, etc. Since data is replicated in different locations according to the data owners wishes, everyone can have there own data that they control access to. And since the data flows so easily between these different distributed locations using an AFFIRM based system, the right (amount and parts of) information is still economically available for the right person, for the right reason, at the right place and time. This alleviates data ownership concerns that make centralized community data repositories a problem, while still enabling open sharing under complete control of information owners (information creators, authors, and/or in the case of "private" information, the individual(s) that the information is about). There are other systems that support the distribution of EMR and other data while enabling users to see data from these distributed systems in a common view, but they still rely on preprogrammed transformers that must be specifically programmed for each disparate data source (table format) and view. Because of this, each time the data being kept is changed, the transformers need to be reprogrammed. This means there is a huge expense for maintaining and integrating these other types of distributed systems. Because AFFIRM based systems don't require this, AFFIRM is a unique and valuable technology for healthcare and other applications of distributed computing.

Now whenever and wherever the patient returns for care, the EMR is modified and kept up to date. The physician can decide to add and keep track of any additional type of information that is considered appropriate without disrupting the flow and processing of existing types of information, without "rewriting the application program". The plan administrator (i.e. payer) can easily be consulted for approval of anything in a timely manner. The physician may refer the patient to a consultant, i.e. urologist, with their complete EMR, including specific problems, and/or admit the patient to the hospital. (See example below under the "Transactions" slide.) In either case the relevant aspects of the EMR with the important information summarized is delivered over the extranet to the specialist's, hospital's, and/or other designated party's domain. There is no need to duplicate information entry. The anesthesiologist, the lab, and other health providers would have access to that portion of the patient's information that is pertinent for them and be able to add to the EMR appropriate new data. Even emergency paramedics and other personnel can be given access to the patients EMR wherever authorized or needed through a simple Internet connection. The patient's URL and password can be on an arm band, ID card or other ID that is only accessible in case of emergency by emergency personnel. The finance dept. shares selected information with the payer for reimbursement. This system has great economy; improves patient safety, and improves the quality of care.

Each of these thirty circles represents a unique personal domain. Each individual person or organization sees the information about the patient from their perspective. In order to have a high quality care network, all these different record formats must not only coexist, but also be able to change as new research findings dictate. They are also necessary to reflect the unique perspectives of the different individuals involved in the care network. One big advantage of our system is that we can allow these different perspectives to coexist while still being able to easily unify them all into ONE WINDOW to give a simple yet holistic view of the patient's unique situation, without the normal data conflicts. Now that's Intelligent Vision!

One practical result of this breakthrough is that each unique health-plan administrator, primary care physician, hospital, or sub-specialist can decide, with the permission of the patient, what information they want. (HIPAA)

This enhanced communication technology is very HIPAA compliant and develops trust between the patient, care providers, and others in the system. Another aspect of the AFFIRM technology is how the architecture enables important information to be shared from one aggregation level or sequential stage of the care (providing or receiving) network to the next without necessarily sharing the private details. This enables coordinated data capture, interaction and learning network- wide without requiring all parties to totally trust each other, agree on data formats or reenter data. For example a hospital can aggregate all its performance metrics to include data on each procedure across all patients without requiring data specifics that identify patients or data structures to change. In the same way information from all hospitals in a network could be aggregated to a higher level, with or without details from lower levels, without reprogramming or restructuring data. Data structures don't even have to change to group procedures by any number of different types of procedures or even different schemes for and coding procedures. Also, as work passes from one point in a process to the next, the outputs from one sequential stage shifts to be the inputs for the next sequential stage without requiring reentry of data or changing data structures. For example, a certain type and instance of medical instrument functionality or material supply (e.g. medication) can be the output of the hospital and an input to the physicians procedure or the patients care.

urture Synergistic \ Integration! Relationships and Communication Knowledge \ / Transaction <■ * I Negotiation

PRESERVE VALUE: Securely Share Intellectual Property AND CREATE VALUE: Innovate and Collaborate

The collaborative healthcare enabled by Intellivision (i.e. AFFIRM) satisfies these needs while maintaining privacy. As a result it creates value by better managing complex cases that can consume most resources and minimizing chances of problem escalation, resource over utilization and privacy breaches.

Intellivision offers the opportunity to enhance coordination of care wherever and whenever it is being provided. It enables Healthcare to better manage organization and interaction to improve collaborative healthcare on a 24 X 7 basis over the Web. As a result, care costs are lowered, quality is increased and mistakes are minimized.

This preserves value by securely sharing private information and it creates value through innovation and collaboration. Communicate, Coordinate,

Integrate Examples: ■ Physician-to-Physician: information for second opinion, referral information, lab and radiology results ■ Physician-to-Patient: EMR information, reports, alerts & alarms, prescription information, education materials ■ Health Plan-to-Provider-to-Facilities: EMR data, outcome data, evidence-based findings

Workflow and interaction are enhanced, as all EMR based data can be easily communicated in an organized way on an as needed basis, again 24 hours a day and 7 days a week. Media are shared as URL links to files easily uploaded to the web, they are not shared as attachments. This alleviates passing viruses. [See GUI view showing the underlying properties (e.g. URL) of an Intellivision button object.] Direct IN-EMR. word processing, messaging and other applications keeps everything together in the One Window organized by activity for a given patient care provider, etc.

Transact

Operational examples: ■ Physician-to-Physician: referrals, treatment ideas, EMR templates, on call agreements ■ Physician-to-Patient: Registration, scheduling, prescription refills ■ Health Plan-to-Provider/Facilities: Authorizations, pre- certifications, credentialing

The types of transactions that can be coordinated with the system are unlimited. For example tests can be ordered by the physician, i.e. to be performed by radiology or pathology lab, etc. (in conjunction with the patient), performance of test can be coordinated between the lab and patient, and both physician and patient can be informed of results, and further appropriate patient treatment can even be triggered and performed. The below GUI view shows an example of a radiology test that has been shared with "Patientl" by sending a button to the right location with the Patientl domain and EMR.

The Internet browser view above shows how a given radiology test document has been shared as a button (input/output object) appropriately and automatically placed within the EMR structure for the domain owner, in this case the patient. The button represents that given test and is automatically organized within each recipient's given domain. In the above example it is the patient's domain, but the button would be in the right position(s) within the EMR for each party, i.e. the PCP, specialist, and other domains the links have been sent to, under the control of the data owner/controller. In the case of this radiology test document, each button that represents this document, regardless of which domain(s) it is replicated in, has a link to a single archived radiology test document location (See "URL" text field in below view. Again, the AFFIRM technology enables the button representing this document object to be replicated and link to this one single document version, from the right data location and GUI view position within each of the parties' separate electronic medical record data store domain and viewer.

Any action, not just radiology tests, can be planned and transacted in a very fluidly flowing process using this invention, and it can be done entirely electronically and automatically where appropriate. Going further with this example, if the results of a test are not normal an alert of both physician and patient can be automatically triggered, and actions can be planned and implemented by an AFFIRM based system. These alerts and other messages are prioritized according to severity and/or other factors relevant to each given party for each given party. For example a physician would see issues (represented by buttons and other content, related to potential, planned, enacted or other types of objects, events, activities, processes, etc.) for ALL patients ordered by priority according to that physician's criterion such as urgency of required response. And the patient would see all their individual issues and actions prioritized according to the patient's criterion. This enables each party to more productively manage and communicate their concerns and actions, i.e. the physician's time and care activities, and/or the patient's health treatment/maintenance activities. This was just one example to the unlimited types of things (objects representing the who, what, how, why, when, where, cost and extent ofa shared healthcare process) that can be coordinated through the utilization of the frameworks, functions and interfaces of the AFFIRM invention.

Report and graph: ■ Physician-to-Patient: Health indicators, med compliance, disease progression, care needs ■ Healthplan-to-Physician: provider quality performance, financial performance

Right in line with the medical record, the above types of analyses can be done to make better care decisions. Also, the quality and performance (financial and otherwise) of separate parts or entities in a network can be constantly monitored and tracked as they change over time. The next slide view (below) shows that AFFIRM can calculate and tell participants in a shared process or network "Why" a given product ("Product 1") would be recommended as beneficial for a given market ("Market 1") need. The view shows how an AFFIRM based system can display the particular features of a particular product (e.g. medical procedure) and the particular extent of the benefits of these features for a particular market (e.g. patient). The specific view shown above is intended to communicate the answer to the question "Why". In the medical arena, it would help answer the question, why should my loved one have this particular treatment (e.g. certain surgical procedure)? In this type of situation, an appropriate instance of the type of view shown above would communicate the most important (top) feature ("Feature 1") of the particular surgical product or solution ("Product 1"), and the range of benefits ("Benefit 1-4") that would be produced for the particular patient ("Market 1").

The ability of an AFFIRM based system to do the above evaluation, calculating the above mentioned statistics (based on expert opinion and actual experience in a given environment) as well as to display and use this information in a logical and convenient way for all users' benefit demonstrates an important utility of the AFFIRM invention. Users can both automatically use these evaluations as guidance for future actions and as mentioned above, actually transact or implement recommended actions, all in one integrated and easily accessible view. Also the ability of users to provide further input, e.g. data on the current situation, selection of certain (usually recommended) actions and/or feedback on whether a recommendation worked out as suggested, enable the user to control the system and the network to learn from experience. So for example this new data is then captured and used in subsequent evaluations to better predict the potential results of future recommendations.

Because of the AFFIRM technology, these type of evaluations can be prepared and shared with and between users as standard features and/or non-technical end user customized "plug-ins" of a given AFFIRM based (implementation) and/or network's applications. This is done in a way that is more easily and economical than a multi-user spreadsheet with models and data being shared over a communication network. They use types of quantitative information (e.g. counts, sums, averages, weighted averages, correlations, regressions, etc.) about particular types of subjects (i.e. a patient with certain conditions) and particular types of potential objects (i.e. a medical procedure with certain features and functions) in a network to guide behavior of network participants in a quantitative and qualitative way.

Because of the singular subject focus and networked object oriented reflections of each domain based on the uniform AFFIRM architecture, a collection or aggregate of domains (acting as one subject) is able to capture the dynamics of the behavior of both individuals and entire networks in which individuals are involved. As a result of only data being different, within the uniform AFFIRM framework, representing an individual subject and the objects involved in that subjects network(s), an AFFIRM based system can make recommendations (or predictions) for/of future action based on the context of that individual, thus guiding and enhancing behavior and performance of individuals and networks.

In this way AFFIRM provides the ability to evaluate the advantages and disadvantages of different solutions for any entity involved in a dynamic network or system regardless of the particular situation. It can even go beyond the type of analysis shown above (quality benefit deployment) and use the above information to "visualize" or weigh the relative attractiveness of different alternative courses of action (based on such things as opportunities and threats in the environment and/or strengths and weaknesses in the individual market (i.e. customer) in a holistic way. These AFFIRM based capabilities enable all entities or participants involved in a network to better understand, support and coordinate decision-making and implementation processes.

"start small and expand your horizons as desired" "develop trust in the service, and the variety of applications is only limited by your imagination " "easier to learn than Windows or Excel" "communicate openly & expansively without risking privacy" "organize anything with Hand its accessible from anywhere" "great way to recognize new opportunities for growth" "an ever expanding universe, all for a very low fee"

Here is just one of many business models that can be supported by the application of AFFIRM technology in healthcare. This would normally involve sponsoring partners, e.g. hospital, physicians organization, payer, and/or other provider group in the community, initiating an application specific collaborative network, e.g. IN-Med.Net or IN-NYC-Emergency-Med.Net, etc., and then having other subsequent/alternative partners, e.g. other providers, labs, patients, etc., participate and/or sponsor the network. In this way there can be networks that represent "vertical industries" (e.g. health) and/or "horizontal professions" (e.g. for a particular medical specialty, sub-specialty and/or other type of provider) for a community. These networks enable sharing of applications made up of templates or "interaction threads" for special purposes. They act as structures that enable integration (enhanced delivery of information, goods and services) from the top down and data pipes that channel performance data from the bottom up, all while enhancing coordination of vision and action up, down and sideways throughout extended collaboration networks.

By facilitating transactions, providing vision across and along a network, and enabling better coordination of the network all entities involved will benefit. In terms of professional service networks alone within industries such as healthcare and others, the impact of this new technology and organization (business process) capability will be tremendous. Also as mentioned above, individuals will also be able to have information from multiple networks, e.g. financial (e.g. IN-Fin.Net), insurance (e.g. IN-Sure.Net), medical (e.g. IN-Med.Net), consumer goods, recreation, etc., integrated into their personal domains. This will enable individual entities to take responsibility for not only managing their own health, but also other aspects of their life in a holistic way. (Continued on next page/slide)

Thank YouT^Sy Questions?

Ronald Vlsscher visscher@lnteIIivlslon.com (616) 399-7236 Confidential Material

These same management, communication and coordination benefits in healthcare can be attained in virtually any network of entities collaborating in some way using the AFFIRM technology. Scientists in a variety of fields now believe that this type of technology will be useful in virtually all fields of science, bringing them together, enabling more productive scholarship, and even in synthetically controlling and coordinating physical networks in our universe. This even includes in- vivo networks that could use the technology to simulate and control the health of biological organisms, networks or systems. It will manage and communicate among levels of organization in organisms, such as whole, systems, organs, tissues, cells, organelles, molecules, atoms, etc., capturing and coordinating the dynamics of network behavior from a universal scale down to quantum and/or sub-nanometer scale. AFFIRM based networks provide value at any entity or level of organization by easily sharing structured information and coordinating real-time interaction without giving up privacy, order or integrity. The benefits are unique because of how the uniform personal domain (PD) and messaging technology provides simple, flexible, economical and pragmatic use throughout (e.g. across and along multiple dimensions of) a network. It is scalable because the portable modular technology and (socioeconomic) model enable economical application and network growth. It is sustainable because of the way it securely creates value (by overcoming disintegration, entropy or chaos) by enabling intimate understanding that enables commitment and coordination of purposeful action.

INTV Intellivision One Worldview through One Window!

The Right Combination for Success Value-share organized info and coordinate realtime interaction without giving up privacy Uniqueness- uniform personal domain(PD) and messaging technology provide a simple, flexible, economical, pragmatic unifying solution Scalability- portable modular technology and business model enable "viral" growth Stickiness- Provider / Patient value and "ownership" create commitment and sustainability

It adds value to any operation by sharing structured information and coordinating real-time interaction without giving up privacy. It is unique because the uniform personal domain(PD) and messaging technology provides simple, flexible, economical and pragmatic solutions. It is scalable because the portable modular technology and business model enable viral growth. It creates stickiness because of the way it securely creates Provider and Patient value and commitment in a sustainable way.

Claims

Claims

The embodiment of the AFFIRM design or invention in one or more configurable or programmable computing or memory devices makes it useful. AFFIRM data structures (frameworks) are implemented in one or more computer memory devices. AFFIRM processes (functions) are programmed in software or firmware and run in a computing device. In order to interact with the world, i.e. do real work, an AFFIRM based system must be linked (interfaced) with other real objects, e.g. users, devices, other external systems programs or databases, animate and inanimate objects, etc. The purpose of AFFIRM is to manage relationships between objects (i.e. socioeconomic entities) in a network through which real interaction or work is realized. This is why the described invention is called AFFIRM, Architectural Frameworks, Functions and Interfaces for Relationship Management.

In this context I claim:

1. A computing architecture and system implementation for managing the socioeconomic interaction of any entity or network of entities (e.g. one or more single individual entities, closed groups of formally organized entities, closed groups of self-organizing entities, or open public groups of entities) essentially comprised of: - a uniform subject and object oriented data structure framework where each real entity represented in the system is referenced by a main subjective domain where it is the Home Subject (HS) and also by other reference objects located in other interacting domains where the real entity is reflected as an object (See Figure 1 -Collaborative Value Web Hubs); - uniquely addressable and accessible locations for each Personal Domain (PD) in a network space (See list of "Other Terms Used to Describe the Invention" the Summary Description of the Invention section); - subject and object oriented application programming environment that enables Home Subjects that don't know the syntax ofa scripting language to create, access and operate applications to manage interaction from within their domains by bilaterally interacting with other domains in the process of planning, proposing, selecting, instantiating, staging and modifying reference objects referring to other entities and interactions with them; - reference objects and bilateral links representing new bilateral interactions or changes are able to be created and proposed by one Home Subject and approved by another each in their respective programming environments or domains with each Personal Domains being updated with reference objects that represent the state of the change from the perspective of that domain's Home Subject; - reference objects for agreed changes can include bilateral links representing the joining the two Home Subjects and their PDs in a partnership agreement that will exist until one of the Home Subjects decides to dissolve or discontinue the relationship; and - bilateral discrete messaging, sharing or interaction mechanism where any reference objects in the uniform data structure can be sent by the Home Subject of one domain in its prescribed structure to one or more other partnering domains to be received by their Home Subjects.

2. A computing architecture and system essentially comprised of that in Claim 1 and: * a uniform and universally applicable subject and object oriented data structure framework, instances of which are called Personal Domains (PD) because they are created and applied, separately located and accessed, and exclusively controlled by a single entity or Home Subject (HS), * a subject and object oriented (application) programming language that can be used by the Home Subject to program applications by creating and destroying reference objects and their links and by selecting objects to be used within the above framework without knowing the syntax of a scripting language, * a pre-programmed negotiation and interaction coordination protocol and mechanism that requires the parties (i.e. Home Subjects controlling two or more separate PDs) to an interaction to agree to an interaction (e.g. the creation of a partnership, the sending and receiving of information, the exchange of physical goods or services, etc.) before an interaction can be scheduled to take place, * A pre-programmed monitoring, updating, archiving and learning mechanism that enables incremental interaction to be automatically recorded in the above frameworks and directly evaluated as if it were a scientific experiment, * A pre-programmed process guidance mechanism that can automatically use results of scientific experiments to evaluate alternative actions based on their relative attractiveness, predict behavior, and prescribe recommended actions, * A pre-programmed process control and actualization protocol and mechanism that enables interaction to be asynchronously planned and negotiated and synchronously enacted, * An architecture and protocol for building "pragmatic webs" where a subjects plans, actions and feedback impact the meaning and value of objects (e.g. words in a language) * An architecture and protocol for managing the (dynamic) learning, development, coordination, interaction, protection and performance of any socioeconomic entity.

3. A computational data structure, referred to in Claim 1 and 2, essentially comprised of: * a uniform subject and object oriented data structure framework where each real entity represented in the system is referenced by a main subjective domain where it is the Home Subject and also by other reference objects located in other interacting domains where the real entity is reflected as an object (See Diagram 1), * one or more main subjective domain instances of the uniform structure that are called Personal Domains (PD) which are each used exclusively by a Home Subject (HS) to capture, locate, access, observe and manipulate reference objects about its subjective self and those objects it relates to, * reference object instances which are made up of one or more Input Output Objects (IOO) which are each structured in a uniform way and used to label, describe, symbolize, represent, link to, locate, show, monitor, stage, value, measure and rank the objects they refer to, * reference object instances that exist in a Home Subject's PD and refer to other entities that the Home Subject interacts with, * reference object instances that exist in other PDs that this home entity interacts with as an object and refer to this Home Subject. mputational data structure to in essentially comprised of that in claim 3 and:

* a uniform and modular subjective domain framework that is universally applicable to managing the interactions of objects in a network,

* one or more Personal Domain (PD) objects that are created by instantiating this subjective framework (See Diagram One- You, Me, We),

* each PD having a reference to a (single registered) specific Home Subject (HS) which it represents and can be controlled by,

* each PD having its own data partition or totally separate and secure repository distributed over one or more separate data location(s),

* each PD exclusively accessible and therefore controllable by one HS "super user" or their authorized guardian,

* each PD having one or more sub-domain templates formed according to the uniform and universally applicable domain framework called an Input Output Object Templates (IOOT) instantiated for interactions between the exclusive HS and a particular identified main object (e.g. other entity, role or position) in its environment,

* each complete interaction instance of a IOOT representing interactive behavior recorded with detail on one or more objects, dimensions and perspectives,

* uniform format for a records called reference objects or Input Output Objects (IOO s) that includes fields or basic data components,

* the basic data components for an IOO object include a Link ID (LID), Class ID (CID), Label, Description, Universal Resource Locator (URL), Rank, Value, Media Type, and Number Type (see definitions in the list of terms provided in the detailed description of the invention),

* each LID formatted according standard protocol for uniquely identifying reference objects and linking similar or related reference objects,

* bilateral links between a particular RO in a PD and a reflection PD where the particular RO's referenced object is referred to as the Home Subject (e.g. bilateral Partner link between one PD and another PD where the Partner is the Home Subject),

* uniform method for uniquely identifying and locating a file or class and its instances within a certain dimension and (path) location that combines a Class ID identification (CID) with a Domain Chain (DC) of links (See chart of "Example Domain Chaim (DC) and CID Uded to Access a Record (IOO) in a Domain and a Button in the end comumn of the GUI",

* a uniform CID is the class or file name and identifies the multidimensional qualitative (potential, actual, actuated, etc.) and quantitative (input, output, balance, etc.) states of objects in the class or file,

* a uniform DC that uniquely identifies the specific multidimensional path to or location of one or more particular CIDs,

* bilateral links between related PDs, CIDs, IOOs, DCs, IOOTs and real objects that enable all reference objects that are in the multiple domains, dimensions and perspectives in the data structure and represented by the data structure to be interconnected and organized in a logical way such that objects are accessible, relatable, traversable, communicable and changeable from one interconnected part of the data structure and real objects represented to another in any direction, * data about the current state and potential interaction in the future of the HS and related objects is represented (flows through and is updated) in certain CID files of this data structure while past completed interactions are in others.

5. A subject and object oriented application programming and control language and environment referred to in Claim 1 and 2 and building on Claim 3 and 4 essentially consisting of: * pre-programmed classes and methods for enabling a Home Subject exclusive authority to perform the act of authoring, importing, exporting, creating, defining, encapsulating, abstracting, inheriting, instantiating, storing, accessing, replicating, deriving, morphing, grouping, measuring, processing, evaluating, prioritizing, securing, displaying, sharing, planning, activating, scheduling, actuating, reflecting, aligning, integrating, synthesizing, aggregating, changing, updating, archiving, monitoring, and destroying reference objects in the data structure discussed in Claim 3 and 4. * pre-programmed classes and methods for effecting levels or degrees of inclusiveness, maturity, diversity, complementarity, intimacy, fluidity, material substance and resourcefulness, * A graphical interface that enables a Home Subject entity to do this object oriented programming (from its subjective perspective) and control the use of all aspects of the invention referenced in Claim 1-10 from any location and device with a network connection without needing to script or write codes according to a specific syntax.

6. A pre-programmed negotiation, interaction coordination protocol and mechanism referred to in Claim 2 and augmenting Claim 1 and building on Claim 3 and 4 essentially comprised of: * asynchronous steps over time requiring the parties (i.e. Home Subjects controlling two or more separate PDs) to an interaction to plan, propose, review and otherwise agree to an interaction (e.g. the creation of a partnership, the sending and receiving of information, the exchange of physical goods or services, etc.) before an interaction can be scheduled to be implemented or synchronously enacted at remote locations at a point in time, * steps where data integration pipes can be produced and shared from generalized levels to more specific levels to prepare for collection of detailed information that can be shared and integrated from specialized levels to more general levels, * steps where data can be integrated across geographic locations, time periods, states, cultures, industries, professions, groups, etc., according to user definable matrices.

7. A pre-programmed monitoring, updating, archiving and learning mechanism referred to in Claim 2 and augmenting Claim 1 and building on Claim 3 and 4 essentially comprised of: * bilateral link interfaces between two bilaterally instantiated reference objects that are directly related by a negotiated interact such that communication can flow in either direction between directly related and connected objects in an instantiated network, * steps that enable incremental interaction to be automatically recorded in the frameworks or data structures in Claim 3 and 4 and directly evaluated as if it were a scientific experiment, * methods and steps that enable objects in data structure to be evaluated according to predefined or user defined functions, * steps by which inline analytics can be used to rate performance, predict outcomes and prescribe alternatives, * steps enabling detailed information to be progressively collected, shared and integrated from private to progressively public domains and from specialized levels to more general levels, * steps that enable de-identified data to be received from other domains that can be generalized with other data about similar interactions that can be aggregated as generalized expertise to compare performance, guide performance, share gains, * steps where real objects outside the computer operating system that are referred to by reference objects can be changed by the Home Subject as a result of modifying values and other components of an IOO mentioned in Claim 2, * steps where changes in state of real objects can be monitored through receiving input direct from real objects or sensors that measure the state or change in real objects, * steps where changes in reference objects referring to real objects can be archived over time. * Steps where ones reputation is shared with other domains without necessarily sharing private information,

8. A pre-programmed process guidance protocol and mechanism referred to in Claim 2 and augmenting Claim 1 and building on Claim 3 and 4 essentially comprised of: * steps that can automatically use results of scientific experiments to evaluate alternative actions based on their relative attractiveness, predict behavior, and prescribe recommended actions (See "X a b" box diagram and GUI Slides in the Example Application),

9. A pre-programmed process control and actualization protocol and mechanism referred to in Claim 2 and augmenting Claim 1 and building on Claim 3 and 4 essentially comprised of: * steps that enable interaction to be asynchronously planned and negotiated and synchronously enacted in separate domains and locations,

10. A pre-programmed architecture and protocol for building "pragmatic webs" referred to in Claim 2, augmenting Claim 1 and building Claim 3-9 essentially comprised of: * a computational linguistics model and method, * steps and mechanisms where reference objects shared with other domains that refer to the came concept object can use different words or symbols to describe these same objects according to a domains particular qualitative ontology (dictionary) and quantitative metrology (system of measurements), line of inquiry, or phase of processing or development (in supply chain), * methods where when information is shared the information gets merged by concept not word or symbol, * steps are implemented that enable a subject's plans, actions and feedback to impact the meaning and value of objects (e.g. words in a language) * steps applied to multiple subjects where one subject's usage of another subject as an object (or not) for a particular context directly impacts the state or meaning of the subject as an object by others.