WO2005114921A2 - Cadres d'architecture , fonctions et interfaces de gestion de relation (affirm) - Google Patents

Cadres d'architecture , fonctions et interfaces de gestion de relation (affirm) Download PDF

Info

Publication number
WO2005114921A2
WO2005114921A2 PCT/US2005/018046 US2005018046W WO2005114921A2 WO 2005114921 A2 WO2005114921 A2 WO 2005114921A2 US 2005018046 W US2005018046 W US 2005018046W WO 2005114921 A2 WO2005114921 A2 WO 2005114921A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
objects
domain
interaction
subject
Prior art date
Application number
PCT/US2005/018046
Other languages
English (en)
Other versions
WO2005114921A3 (fr
Inventor
Ronald Scott Visscher
Original Assignee
Ronald Scott Visscher
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ronald Scott Visscher filed Critical Ronald Scott Visscher
Publication of WO2005114921A2 publication Critical patent/WO2005114921A2/fr
Publication of WO2005114921A3 publication Critical patent/WO2005114921A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

  • ARCHITECTURAL FRAMEWORKS FUNCTIONS AND INTERFACES FOR RELATIONSHIP MANAGEMENT (AFFIRM)
  • 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.
  • CIT communication and information technology
  • 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.
  • 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.
  • OS operating system
  • 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.
  • PRESERVE VALUE Securely Share Intellectual Property AN D CREATE VALUE: Innovate and Collaborate
  • 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.
  • 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.
  • database application programs e.g. accounting systems
  • database application programs 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.
  • 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.
  • a database e.g. a medical records database
  • the information is usually commingled with information about other individuals of the same type, e.g. other patients.
  • 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.
  • an individual i.e. individual person, group, organization or other entity
  • 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
  • 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.
  • 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.
  • 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”.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • ETL data export, transformation and loading
  • 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.
  • 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.
  • GUI graphical user interface
  • 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.
  • 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.
  • 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).
  • 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.
  • HIPAA Health Insurance Portability and Accountability Act
  • 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.
  • 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 distnaded 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 location of a particular UBDU in a unique combination of instaces of these higher structure instances makes each UBDU instance unique, identifiable, and locatable
  • 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.
  • GUI graphical user interface
  • 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.
  • 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.
  • 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.
  • the buttons are Concepts or Uses they are Column header Option buttons like n the odd numbers 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.
  • LID Link ID
  • 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)
  • 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.
  • Shared Objects virtual or 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
  • 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.
  • 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.
  • 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)
  • 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.
  • 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 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".
  • This invention is able to manage real interaction or transformational change processes between real entities.
  • 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”.
  • 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.
  • IS Individual Subject
  • 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).
  • IS Independent Subject
  • HS Home Subject
  • PD Personal Domain
  • a Home Domain is a Domain under the control of a given Home Subject (HS) under discussion.
  • IOO Input / Output Object
  • PIP Prospective Interaction Partner
  • 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.
  • the PIP has either sent a proposal for partnership to or has received a proposal from the IS under discussion.
  • Input Output Definition Object is a record representing a Concept.
  • CD Concept Domain
  • Type is any meaningful representation of a part of reality.
  • Type Domain 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.
  • Symbol List 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.)
  • CL Concept List
  • Type List 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 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 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).
  • 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
  • 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.
  • CIOOT Complete IOOT
  • 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 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 is a LID used to identify a generic option, class or Concept or a specific option or Usage.
  • Item (Type or Entity) ID 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 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 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 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
  • 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.
  • OR Object Rank
  • Object 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,
  • 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 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 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.
  • DC Domain Chain
  • IOOTs including CIOOTs are identified, located, read, handled and written in accordance with their DC.
  • AIOO Active Input Output Object
  • 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 is the active link of the DC that is determined by the AIOO. It is used to determine what is included in an IOOT.
  • DCBAL DC Before AL
  • DC After AL 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.
  • each new Individual Subject (a user, person, field, concept, type or other main object) (e.g. YOU), with a Domain.
  • 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.
  • WE Whole Entity
  • 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.
  • 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.
  • 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.
  • W, X, a and b we describe multiple dimensions of a PD using the letters W, X, a and b.
  • IOOs User or Entities of Concepts or Types
  • W, X, a and b dimensions of a domain a user can give meaning to these objects.
  • 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.
  • 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.
  • X- Consumption X- Application e.g. project
  • a-attributes a- feature b- benefits b- benefit
  • Shared Objects virtual or 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
  • 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.
  • 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.
  • 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.).
  • 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.
  • IOO s Input and Output Objects
  • 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
  • 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.
  • 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.
  • IOO Templates IOO Templates
  • 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).
  • IODO Input Output Definition Objects
  • 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.
  • 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.
  • a Concept Domain 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.
  • the Symbol List (SL) has a record of each symbol used to refer to the Concept
  • the Concept List (CL) has a record of each Domain (user, IS, or other concept) using or related to the Concept.
  • SL Symbol List
  • CL Concept List
  • 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.
  • 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).
  • 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.
  • 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.
  • the disclosed invention enables and requires a Domain to control both physical and mental aspects of an IS's environment.
  • IS s connected by a network understand each other and can negotiate and enact agreements about real changes.
  • 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.
  • 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.
  • the IODO records in an IOOT describing a change may also encapsulate alternative units of measure used to quantify the amount of change.
  • 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.
  • 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.
  • LID Link ID
  • 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.
  • UBDS Uniform Basic Data Set
  • 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.
  • PIP envisioned Partnership
  • 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 of a 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.
  • 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.
  • CIOOT 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)
  • these templates or strings of one or more IOO s 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.
  • 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.
  • CI s Current Interactions
  • PI s Past Interactions
  • IOO s 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.
  • UO s Unitary Objects
  • UO s Unitary Objects
  • a Uniform Basic Data Unit 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 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.
  • 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.
  • 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.
  • IOO describing a partnership in the OD first dimension
  • 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.
  • 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.
  • An IS is able to send a partner whatever IOOs the IS Authors.
  • 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.
  • IOO s 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.
  • UI Uniform Interface
  • 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.
  • IOO s 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.
  • LID s reflexive Link ID s
  • 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.
  • CID Class ID
  • 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).
  • 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.
  • AFFIRM 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.
  • AFFIRM based tools Some of the other benefits of AFFIRM based tools include:
  • RSVPortfolio comprises of several tightly integrated but independent components- at server level and at client level.
  • the client level component called the RSVP Client
  • the client level component 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).
  • JVM Java Virtual Machine
  • 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.
  • 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
  • Toolbar- User interface component that enables user to control Active function
  • 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.
  • 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
  • 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.
  • Service Component - part of Deliverable derived from Resource i.e.
  • 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
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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
  • RSVP Knowledge Object instances 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • GUI User Interface
  • it is the left frame of the browser window that shows the RSVP applet.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • HSAs health savings accounts
  • 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.
  • 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!
  • 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.
  • 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.
  • AFFIRM based systems don't require this, AFFIRM is a unique and valuable technology for healthcare and other applications of distributed computing.
  • 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
  • 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.)
  • 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.
  • 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!
  • 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.
  • a certain type and instance of medical instrument functionality or material supply e.g. medication
  • PRESERVE VALUE Securely Share Intellectual Property AND CREATE VALUE: Innovate and Collaborate
  • AFFIRM 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.
  • 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
  • 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
  • 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.
  • 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.
  • 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 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.
  • issues represented by buttons and other content, related to potential, planned, enacted or other types of objects, events, activities, processes, etc.
  • Physician-to-Patient Health indicators, med compliance, disease progression, care needs
  • Healthplan-to-Physician provider quality performance, financial performance
  • the next slide view 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”.
  • 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.
  • quantitative information e.g. counts, sums, averages, weighted averages, correlations, regressions, etc.
  • 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.
  • 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.
  • quality benefit deployment quality benefit deployment
  • AFFIRM based capabilities enable all entities or participants involved in a network to better understand, support and coordinate decision-making and implementation processes.
  • 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.
  • 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.

Abstract

L'invention a trait à un processus et/ou mécanisme qui autorise des individus à conserver leurs propres dictionnaires des mots qu'ils utilisent et leurs significations tout en contribuant à une construction sociale d'une ontologie de mots et leurs significations conceptuelles dans un ou plusieurs réseaux ou contextes sociaux dans lesquels ils sont engagés. Ceci permet à des individus qui utilisent différents mots ou différentes langues pour se référer aux mêmes concepts ou objets à mieux communiquer et se comprendre entre eux. La signification conceptuelle à laquelle se réfère un utilisateur de sujet individuel lorsqu'il utilise un mot dans un contexte particulier qui peut être des bases inférées sur l'architecture logique de la structure de données de l'invention, affecte la signification conceptuelle attribuée aux mots et autres symboles dans l'ontologie de domaines qui partagent et représentent un contexte d'utilisation, en l'occurrence, un domaine d'étude, avec le sujet individuel.
PCT/US2005/018046 2004-05-21 2005-05-23 Cadres d'architecture , fonctions et interfaces de gestion de relation (affirm) WO2005114921A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US57326404P 2004-05-21 2004-05-21
US57372604P 2004-05-21 2004-05-21
US60/573,726 2004-05-21
US60/573,264 2004-05-21

Publications (2)

Publication Number Publication Date
WO2005114921A2 true WO2005114921A2 (fr) 2005-12-01
WO2005114921A3 WO2005114921A3 (fr) 2007-08-02

Family

ID=35429109

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/018046 WO2005114921A2 (fr) 2004-05-21 2005-05-23 Cadres d'architecture , fonctions et interfaces de gestion de relation (affirm)

Country Status (1)

Country Link
WO (1) WO2005114921A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102201994A (zh) * 2011-05-31 2011-09-28 杭州华三通信技术有限公司 一种用于oaa的上下文标识协商方法、服务器及客户端
WO2013169916A2 (fr) * 2012-05-08 2013-11-14 24/7 Customer, Inc. Application d'assistance aux données pour des dispositifs mobiles
CN110546615A (zh) * 2017-04-29 2019-12-06 思科技术公司 超动态java管理扩展
US11599752B2 (en) 2019-06-03 2023-03-07 Cerebri AI Inc. Distributed and redundant machine learning quality management

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6278967B1 (en) * 1992-08-31 2001-08-21 Logovista Corporation Automated system for generating natural language translations that are domain-specific, grammar rule-based, and/or based on part-of-speech analysis
US20030115170A1 (en) * 2001-12-14 2003-06-19 Richard Turner Knowledge acquisition in expert systems

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6278967B1 (en) * 1992-08-31 2001-08-21 Logovista Corporation Automated system for generating natural language translations that are domain-specific, grammar rule-based, and/or based on part-of-speech analysis
US20030115170A1 (en) * 2001-12-14 2003-06-19 Richard Turner Knowledge acquisition in expert systems

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102201994A (zh) * 2011-05-31 2011-09-28 杭州华三通信技术有限公司 一种用于oaa的上下文标识协商方法、服务器及客户端
WO2013169916A2 (fr) * 2012-05-08 2013-11-14 24/7 Customer, Inc. Application d'assistance aux données pour des dispositifs mobiles
WO2013169916A3 (fr) * 2012-05-08 2014-01-16 24/7 Customer, Inc. Application d'assistance aux données pour des dispositifs mobiles
US9198010B2 (en) 2012-05-08 2015-11-24 24/7 Customer, Inc. Data assistance application for mobile devices
US9736668B2 (en) 2012-05-08 2017-08-15 24/7 Customer, Inc. Data assistance application for mobile devices
US10616729B2 (en) 2012-05-08 2020-04-07 [24]7.ai, Inc. Data assistance application for mobile devices
CN110546615A (zh) * 2017-04-29 2019-12-06 思科技术公司 超动态java管理扩展
CN110546615B (zh) * 2017-04-29 2023-07-21 思科技术公司 超动态java管理扩展
US11599752B2 (en) 2019-06-03 2023-03-07 Cerebri AI Inc. Distributed and redundant machine learning quality management
US11615271B2 (en) 2019-06-03 2023-03-28 Cerebri AI Inc. Machine learning pipeline optimization
US11620477B2 (en) 2019-06-03 2023-04-04 Cerebri AI Inc. Decoupled scalable data engineering architecture
US11776060B2 (en) 2019-06-03 2023-10-03 Cerebri AI Inc. Object-oriented machine learning governance

Also Published As

Publication number Publication date
WO2005114921A3 (fr) 2007-08-02

Similar Documents

Publication Publication Date Title
US20220342915A1 (en) Architectural Frameworks, Functions and Interfaces for Relationship Management (AFFIRM)
Piorkowski et al. How ai developers overcome communication challenges in a multidisciplinary team: A case study
Gupta et al. Creating knowledge based organizations
Wainwright et al. Three domains for implementing integrated information systems: redressing the balance between technology, strategic and organisational analysis
Gottschalk Knowledge Management Systems: Value Shop Creation: Value Shop Creation
Norta et al. eContractual choreography-language properties towards cross-organizational business collaboration
US20120089418A1 (en) INTEGRATED INTERACTIVE SYSTEMS AND METHODS WITH SINGLE TRANSACTIONAL DATABASE AND REPORTING APPLICATION FOR eCLINICAL TRIALS
Berler et al. Using key performance indicators as knowledge-management tools at a regional health-care authority level
Kovac E-health demystified: An e-government showcase
Hadzic et al. Application of digital ecosystem design methodology within the health domain
Esmaeilzadeh Benefits and concerns associated with blockchain-based health information exchange (HIE): a qualitative study from physicians' perspectives
Mohan et al. Traceability-based knowledge integration in group decision and negotiation activities
Androwich et al. Clinical information systems: A framework for reaching the vision
Woolley Getting along with frenemies: enhancing multi-competitor coopetition governance through artificial intelligence and blockchain
WO2005114921A2 (fr) Cadres d'architecture , fonctions et interfaces de gestion de relation (affirm)
Pietrewicz Coordination in the age of Industry 4.0
Kim et al. A collaborative design framework for the Korean automotive parts industry
CN117083603A (zh) 用于跨不同系统、平台和/或业务的过程协调和互操作的系统
Atkinson Soft Information Systems and Technologies Methodology, SISTeM¢*: A case study on developing the electronic patient record
Cao et al. An agent-based knowledge management framework for electronic health record interoperability
Ochuba et al. Strategic partnerships in the satellite and telecommunications sectors: a conceptual review of data analytics-enabled identification and capitalization of synergies
Stefanelli Artificial intelligence for building learning health care organizations
Waghmare et al. Create digital transformation using chatbots
Metaxiotis E-health versus KM-based health: A dilemma in researchers' minds
Akbar Patient information system for national health care: An intranet internet-based model for the State of Kuwait

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase in:

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase