Method and apparatus for structuring and managing human communications by explicitly defining the types of communications permitted between participants5216603
Abstract
A method for managing business, social, and/or personal communications utilizing a programmed computer system including certain defining steps. All communications between a set of participants are defined as moves in conversations for declaring specific realizable possibilities or as moves in conversations for producing actions to complete specific possibilities. These conversations are defined as taking place within a set of declared or understood domains of possibilities. A set of conversational roles played by participants in the conversations is defined. Each participant plays at least one conversational role in any conversation. A set of types of incompletions which occur recurringly within the conversations is also defined. A set of types of permitted moves in conversations is defined on the basis of the defined incompletions, the defined roles, and the specific types of incompletions produced by the permitted moves. For each of the types of moves a set of associated data is defined. A conversation record format for the conversations is defined relative to a data base to be created and maintained for the conversations. The method also includes establishing a conversation management program for enabling interactive computer-controlled management of each of a plurality of the conversations of the participants. The program also includes facilities for use of each participant to review new moves by other participants in all conversations in which the participant plays a conversational role.
Claims
What is claimed is:
1. A computer system which implements a method for assisting users of the computer system to manage at least one of their business, social and personal communications, wherein said computer system includes for each of said users a corresponding input and output interface, processor, memory, and storage device, said method comprising the steps of:
a) creating at least one conversation type record structure for at least one conversation, said at least one conversation having a plurality of states, said conversation type record structure for defining a type of conversation, an identification of each of said users who are to participate in said conversation, a role to be assigned to each of said participating users, the state of the conversation, and a specification of conversational moves permitted for said role at each state of the conversation;
b) creating at least one conversation instance record for a first one of said participating users and for at least one other of said participating users based upon data entered by the first user using said corresponding user input and output interface and the at least one conversation type record structure, wherein each of said at least one other participating users is assigned a predetermined one of said roles defined in said at least one conversation type record structure, storing said entered data in said corresponding conversation instance record for said first user and making said corresponding conversation instance record available to each of said at least one other participating users;
c) updating the corresponding conversation instance record for said participating users based upon data entered by each of said participating users using said corresponding input and output interface, wherein the data which is permitted to be entered by each of said participating users is determined by the user's assigned role and the state of the conversation when said data is being entered.
2. The method defined by claim 1 wherein said at least one conversation type record structure creating step comprises the steps of:
a) specifying the type of conversation as being one of a request type conversation for action, an offer type conversation for action, and a conversation for possibilities;
b) specifying the roles of the participating users as being at least one of a requestor, a promisor and an observer;
c) specifying for each of said specified roles at least one type of permitted conversational move for each state of the conversation;
d) specifying at least one incompletion type record, whereby said conversational moves advance the conversation towards one of a successful and unsuccessful conclusion, through said plurality of conversational states, by defining and undefining incompletion records associated with the conversation.
3. The method defined by claim 2 wherein said at least one conversation type record structure creating step comprises the further step of specifying predetermined times for completion of the incompletions produced by each of said conversational moves.
4. The method defined by claim 3 wherein said at least one conversation instance record creating step comprises the step of:
a) prompting said first user to enter data using said corresponding user to input and output interface, said entered data for defining the conversation type, specifying an address corresponding to at least one of said participating users and specifying times for completion of the incompletions associated with said permitted conversational moves;
b) creating a predetermined conversation instance record corresponding to said first user and storing the entered data in said corresponding conversation instance record.
5. The method defined by claim 2 wherein types of incompletion include a RESPONSE IS MISSING and a FULFILLMENT IS MISSING and wherein said method further comprises the steps of:
a) selecting at least one sort criteria from a list of sort criteria including:
i) a user's RESPONSE IS MISSING;
ii) a user's FULFILLMENT IS MISSING;
iii) incompleted conversations; and
iv) completed conversations;
b) sorting said conversation instance records according to said sort criteria; and
c) presenting the sorted conversation instance records to at least one of said participating users.
6. The method defined by claim 1 wherein said at least one conversation instance record creating step comprises the steps of:
a) prompting said first user to enter data using said corresponding user input and output interface, said entered data for defining the conversation type and specifying an address corresponding to at least one of said participating users;
b) creating a predetermined conversation instance record corresponding to said first user and storing the entered data in said corresponding conversation instance record.
7. The method defined by claim 6 further comprising the steps of
a) delivering at least a predetermined subset of the stored data to each of said specified addresses;
b) receiving the predetermined subset of the stored data at each of said specified addresses;
c) creating a predetermined conversation instance record corresponding to the user at each of said specified addresses and storing the received data in corresponding conversation instance record;
d) notifying the user at each of said specified addresses that said data has been received.
8. The method defined by claim 7 wherein said updating step comprises the steps of:
a) creating a conversation reply record for each of said notified users based upon the contents of said at least one conversation type record structure and the contents of said corresponding conversation instance record for each of said notified users;
b) using the conversation reply record to prompt the corresponding user to enter data using said corresponding user input and output interface for updating the contents of said corresponding conversation instance record;
c) storing the entered data in said conversation instance record for the corresponding user.
9. The method defined by claim 8 further comprising the steps of:
a) delivering at least a predetermined subset of the stored data to each of said addresses specified in the conversation instance record;
b) receiving the predetermined subset of the stored data at each of said specified addresses;
c) updating the contents of the conversation instance record corresponding to the user at each of said specified addresses with received data;
e) notifying the user at each of said specified addresses that said data has been received;
f) deleting said conversation instance record corresponding to said at least one of said participating users when a predetermined set of criteria has been met;
g) repeating steps a)-f) until all of said predetermined conversation instance records corresponding to each of said at least one of said participating users have been deleted.
Description
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to methods for facilitating and managing communications between individuals who are involved in a community of action or purpose. In one sense, aspects of the invention relate to such fields as electronic mail, word processing, data base management and other methods for facilitating the transaction of business between individuals and the management of data and communications related to such transactions.
In another, more important sense, this invention is a pioneering one which establishes a new field of managing business, social and personal communications by integrating state of the art computer and communication tools and methodologies within a new conceptual and methodological framework: managing communications by treating them as moves in conversations in a structured context which encourages participants to carry out their communications in a more meaningful, organized manner and promotes completion of conversations to the satisfaction of all of their participants.
This invention is based on the development of a precise and rigorous language of distinctions which is valid for observation and interpretation of what is happening in the whole gamut of human conversation and simultaneously forms the basis for a method for supporting, enhancing, and coordinating human conversation which can be carried out in a variety of computer and communication system environments.
2. Description of the Prior Art
1. Electronic Mail
The earliest tools for generating utterances, including both spoken and written manifestations of language, were writing implements, from the quill to the typewriter, to the modern word processor. None of these devices operate in accord with what speakers do in language, that is, with what speakers expect or hope to accomplish with their utterances. They deal only with the form of utterances, as sequences of letters, figures, typographical marks, etc. There is no communication management, no helpful machine/human interaction which facilitates accomplishment of the purposes and goals of the communications being prepared.
Many devices have been invented for transmitting visible sequences of marks or audible sounds from one place to another, from the postal service to telephony, facsimile, and more recently, electronic mail systems.
A person who composes an utterance does so within a certain background of understanding as to what is being done. In the current prevalent practice in electronic mail, the relevant structure is the identification of sender and receiver and the times and places of sending and receipt, along with an unstructured natural-text phrase used by readers to identify and group the messages. The user of such a system is provided with choices of action that can be described in terms of this basic "who-where-when" structure. For example, the "Answer" option which is provided in many systems allows a response to be sent to the original sender, while "Forward" sends a copy of the message to a third party.
Some electronic mail systems incorporate various file management facilities such as assigning keyword attributes to files for automated retrieval, automatic aging of files to eliminate old messages, and sorting based on individual or combinational criteria such as sender, date, and the like. The effective use of these facilities is dependent on the ability of the user to integrate these facilities into a personal framework of organization of the work that the person does and the communications related to that work.
Electronic mail systems do not limit or structure the kinds of messages that may be sent, in accordance with either the content or context of previous messages. In particular, there is no assistance providing in structuring the flow of communications toward accomplishment of goals and results. The management of the communications is essentially left to the discretion and ability of the users of the system.
2. Computerized Procedure Management Systems (Systems for Managing Performance of Specified Tasks)
Some system designers have recognized the opportunity to use electronic computer and communication tools to facilitate and organize communications within organizations concerning standard procedures and standard forms. The simplest and most prevalent implementation of repetitive communications is with "forms" in the standard business sense. The existence of tools like a "purchase order" or an "invoice" derives from the existence of certain recurring communications (getting a supplier to send goods, requesting payment, etc.) in which the collection and transmission of relevant details has the same structure each time. Paper-based forms have been developed over centuries, and computer-based forms are prevalent in the current data-processing art.
In addition to standardized forms, there can also be standardized "procedures" in which a sequence of actions follows a regular pattern. For example, the standard procedure in a particular office on receipt of a purchase order can be to send one copy to the billing department, and on receipt of a credit authorization to send another copy to the shipping department. Such procedures have long been codified for human implementation in all kinds of organization.
Computer technology makes it possible to automate forms generation, processing and communication by embedding them as programs in data processing systems. Many computer systems, such as point of sale terminals, automated banking systems, inventory control systems, embody such procedures. A person using such a system communicates within the strict framework of the system and the limited options presented in accordance with the procedures embodied in the computer system. For example, on receiving a purchase order, a user's options may be to "send it through" or "refer it to accounting for a credit check."
3. Conversation Management Theory
In a 1981 Ph.D. thesis entitled "Management and Communication in the Office of the Future", Fernando Flores proposes a "theory of commitment and conversation" which "allows us to provide new guidelines for examining work in an office or organization." The thesis also contains suggestions for design of a prototype system for coordinating conversations based on a speech act model of conversations. This theoretical work provides a foundation for considering new approaches to use of electronic computer and communication technology to manage the flow of communications within a conversational network, but it does not provide a complete, practicable methodology for carrying out management of conversations.
The Flores thesis does not suggest an overall methodology which provides for managing conversations for declaring specific realizable possibilities as distinct from coordinating conversations related to commitments for some specific action. It does not address the concept of "permitted moves" in conversations of various types in various states with various starting and ending "incompletions" and depending upon the "role" of the participant. There are only limited suggestions in the Flores thesis of constructing and managing a data base of conversations and these do not provide a practicable methodology.
SUMMARY OF THE INVENTION
1. Objects of the Invention
It is the principal object of this invention to provide an improved method of managing communications between individuals.
It is another object of this invention to provide a method for managing conversations between individuals within a community of participants on the basis of a methodology which is structured but adaptable to different types and categories of conversations.
It is another object of this invention to provide a method for managing conversation for action of the request and offer type within a structured conversational protocol of permitted moves which comprise a highly useful level of modelling of business and social conversational interaction.
It is another object of this invention to provide a method for managing conversations which incorporates a number of convenient methodological tools for initiating conversations, selecting conversations for making moves, and tracking commitments and incompletions.
2. Features and Advantages of the Invention
This invention features a method for managing communications between individuals utilizing a programmed computer system. The method involves several definitional steps that are critical to achieving a practicable methodology for conversation management. Preferred implementations of these definitional steps lead to a breakthrough in flexibility and performance of methods for coordinating business and social communications. These definitional steps are the following:
a. defining all communications between a set of participants as moves in conversations for declaring specific realizable possibilities or as moves in conversations for producing actions to complete specific possibilities;
b. defining said conversations as taking place within a set of declared or understood domains of possibilities;
c. defining a set of conversational roles played by participants in said conversations, with each participant playing at least one conversational role in any said conversation;
d. defining a set of types of incompletions which occur recurringly within said conversations, including a first type in which a conversational move by at least one participant to declare at least one specific realizable possibility is missing, and a second type in which a conversational move by at least one participant to complete a specific realizable possibility is missing;
e. defining a set of types of permitted moves in conversations on the basis of said defined incompletions, said defined roles, and the specific types of incompletions produced by said permitted moves;
f. defining for each of said types of moves a set of associated data; and
g. defining a conversation record format for said conversations comprising identities and roles of participants, incompletions, and a pre-defined body of data associated with each move of the conversation, including the type of move.
The integrated concepts of "moves in conversations" of two basic types (Conversation for Action and Conversation for Possibilities), conversational roles, types of incompletions, and logical/functional relationships between moves, incompletions, and roles, provide a set of constructs on which a powerful and practicable methodology for conversation management may be built. They provide a basis for defining a meaningful conversation record format which can be integrated into a conversation data base using standard data base building and management tools. More specifically, they are a foundation for establishing a conversation management program with powerful, yet easy to use features for initiating conversations, selecting and making moves in conversations, and automating conversation record management.
The basic methodological steps of the conversation management program of this invention comprise the following:
h. establishing a conversation management program for enabling interactive computer-controlled management of each of a plurality of said conversations including the steps of:
(1) providing facilities for use of each participant in opening a new conversation with an initial move and entering data associated therewith;
(2) creating a new conversation record for each said new conversation by assembling said entered data according to said conversation record format, including said incompletions produced by said initial move and said entered data, and storing said new conversation record in at least one file;
(3) providing facilities for use of each participant in selecting an existing conversation in which to make a move;
(4) deriving from said definition of types of permitted moves and said conversation record corresponding to said selected conversation the set of currently permitted moves consistent with the role of the said participant in said selected conversation;
(5) providing facilities for use of said participant in selecting and making a move from said set of permitted moves in said selected conversation, and entering data associated with said move;
(6) updating said stored conversation record associated with said selected conversation as said participant makes said permitted move, said updating including storing data associated with said permitted move and said types of incompletions produced by said permitted move; and
(7) providing facilities for use of each participant to review new moves by other participants in all conversations in which said participant plays a conversational role.
A system for managing communications which incorporates the methodology of this invention provides a powerful framework for structuring human conversations. This framework facilitates more effective communication and leads to consistent achievement of results and goals. The methodology permits standard data base and file management technologies to be integrated simply and effectively into the organizing and structuring of conversation records for instantaneous retrieval of data which is critical to tracking the status of a conversation and any commitments to action which it involves. Participants using systems which incorporate the methodology of this invention are effectively enabled to organize virtually their entire flow of work, including the commitments which it involves, around the facilities which the conversation management program provides. This produces a coherent framework, leading to consistency and clarity in communications. The inevitable result is a dramatic overall improvement in productivity.
A preferred embodiment of the method of this invention includes a number of features which greatly enhance its utility to the participants in a conversational network. Preferably the step of defining permitted moves includes selecting a name for each move which distinguishes the character of the move to the community of participants involved. The permitted moves are displayed to the participant in a menu and selection is made from that menu. This provides direct coaching to the participant on the moves that can be made and facilitates meaningful and effectice move selection.
A further level of coaching on the meaning of the different permitted moves can be provided by help text associated with each move which can be accessed from the same menu display of permitted moves. The method of this invention further involves creating a body of recommended declarative text for each move which the participant may include in the message as part of the data elements of the move.
The method of this invention also features a variety of conversation data base access facilities using different record sort or collection criteria including the individual incompletions, the domains of the conversation, the participants, and dates, in cases where incompletion are recorded in the form of date tokens. These facilities make it convenient to extract lists of conversations, both for review of the status of the conversations and the selection of a conversation in which to make a next move permitted to that participant.
The method of this invention and the conversation record management and retrieval which it facilitates enables time and date commitments related to calendar activities, such as meeting schedules, appointments and the like, to be integrated into the data base. This data can then be extracted along with other commitments due on a particular date to produce an integrated display of all commitments associated with that date.
Other objects, features and advantages will be apparent from the detailed description given below of the method of this invention and embodiments of systems which incorporate the method of this invention.
BRIEF DESCRIPTION OF THE DRAWINGS
FIGS. 1-10 are schematic diagrams illustrating the structure and operation of a finite state machine implementation of a system incorporating the method of this invention.
FIGS. 11A-11B is a diagram of the conversation record format and record structure employed in a system incorporating the method of this invention.
FIG. 12 is a schematic diagram illustrating the basic functional components and relationships used in a system incorporating the method of this invention.
FIG. 13 illustrates an alternative conversation record structure which may be employed in a system implementing the method of this invention.
FIG. 14 is a flowchart illustrating method steps for opening a conversation and making an initial move in accordance with one embodiment of a system incorporating the method of this invention.
FIG. 15 is a flowchart illustrating method steps for making a move in an existing conversation in accordance with one embodiment of a system incorporating the method of this invention.
FIG. 16 is a flowchart illustrating method steps for determining the permitted moves in a conversation in accordance with one embodiment of a system incorporating the method of this invention.
FIG. 17 is a flowchart illustrating method steps for performing conversation record sort and display operations in accordance with this invention
FIG. 18 is a flowchart illustrating method steps for processing new mail in a system incorporating the method of this invention.
FIG. 19 is a schematic diagram illustrating functional relationships between various features and facilities of a system incorporating the method of this invention.
FIGS. 20-22 are schematic diagrams of alternative computer and communication systems which may be employed in implementing the method of this invention.
GENERAL METHOD OF THIS INVENTION
This invention comprises a method for managing business, social and personal communications utilizing a programmed computer system. The method of this invention may also use electronic telecommunication apparatus in certain embodiments for carrying out the method in specific hardware environments. The method of this invention comprises a powerful, new management tool which can be configured in a variety of ways and with different degrees of complexity to achieve productivity increases and other advantages within the business and social environment of the participants using systems which employ the method.
An essential aspect of the method of this invention is the carrying out of certain definitional steps, some of which are configurable and adaptable to the particular culture or environment of the users/participants and others of which are fixed constructs of the method of the invention. The first of these steps comprises defining all communications between a set of participants as moves in conversations for declaring specific realizable possibilities or as moves in conversations for producing actions to complete specific possibilities.
"Participants" is used to denote individual persons, as well as, for example, individuals who may represent corporations, organizations, institutions, and groups who are involved in communication with and among each other. Within the context of this invention, it is understood that the participants have access to a programmed computer system which is carrying out the method of this invention. "Set of participants" is used in the mathematical sense of the term "set" with the understanding that there would be no meaning for a "null set," but that there is meaning for a set having one member. In other words, this invention encompasses a method of managing communications which one may have with one's self as well as communications with other persons. The importance and significance of this will be illustrated in the discussion of conversations with one role which is given below. "Communications" and "moves in conversations" have at least two dimensions which must be considered and discussed in connection with the method of this invention for managing communications. These constitute the systems dimension comprising transmission of symbols and the dimension comprising human communications in which possibilities for action are distinguished.
In the system dimension of telecommunications and computer technology used for building human communications systems, "communication" denotes the transmission of tokens and symbols, often called messages, from one location to another. This transmission may take place within a computer or database, or across geographical distances via various communication media.
In the other dimension, important to the definitional elements of the methodology of this invention, people produce possibilities for action, and the realization of those possibilities, for themselves and each other, in the conduct of their conversations. Here, based on rigorous observation of human conversations, "communications" refers to the phenomena of "speaking" and "listening" and the unquestioned interpretations that people make as they produce distinctions for themselves in conversation.
The term "moves" within the context of "moves in conversations" denotes a number of important constructs, all grounded in observations of possibilities and actions distinguished by participants in conversations. These observations of human communications provide distinctions which can be mapped to a language of definition for the elements, structure, and operation of communications systems for supporting and managing human conversation.
The term "conversations for declaring specific realizable possibilities" refers to conversations in which participants are seeking to reach common agreement or understanding of a result that can be achieved, some goal that can be attained, and/or some objective that can be reached. The communications involved in such conversations are not action-oriented, but are oriented toward speculation, refinement, assessment, and discussion of what results, goals, or objectives can be attained and of what actions might or must be taken to attain them.
A typical example might be a discussion between the President of a company and the Chairman of the Board of Directors about the desirability of expanding its business into a new product area, either by acquiring an existing business or alternatively by developing a new product directly. Neither participant is asking or expecting any specific action by the other in the initial conversation, except communications of what in ordinary parlance are referred to as "thoughts", "ideas", "feelings" and the like. The conversation conducted between the parties is regarded as a series of moves in a conversation, each of which move is, in the moment of its being made, relevant to the possibilities that the participants are concerned with developing or bringing forth in their conversation. The conversation itself is, without necessarily being specifically declared so, oriented to the goal of declaring specific relevant and realizable possibilities for subsequent action. We interpret the primary conversational moves in this type of conversation as consisting in assessments spoken and listened to by the participants of the directions open or possible for action, in speculation about alternative directions, and in the making of assessments about the declarations of possibilities made in the conversation.
The second construct, "conversations for producing actions to complete specific possibilities" (also called "Conversations for Action" or "CFA" herein), relates to communications which are oriented toward specific action. In the conversations, commitments to action are produced. The same company president might open a CFA with his VP of Research with a request that the VP provide an estimate of the cost of developing the new product internally. Here, a specific action or set of actions is expected, and not simply speaking in the conversation in the form of speculation or assessments, and certainly not communications of "thoughts" and "ideas".
It will be apparent that management and business conversations will sometimes involve both Conversations for Possibilities and Conversations for Action at once. The important consideration is that the basic methodology of this invention has the capability to handle these conversations and the different characteristics that each exhibits.
The second step is defining conversations as taking place within a set of declared or understood domains of possibilities. Again "set" is used in the mathematical sense with the understanding that there is meaning for one domain or plural domains of possibilities. "Domains of possibilities" is a construct that generically designates distinctions made by participants of related objectives, results, concerns, and the like. A lawyer might for example organize conversation in domains of possibilities designated with client names or specific litigation or contract negotiation projects. The company president mentioned above might assign the name "New product XYZ" as the domain of possibilities for the described conversations in which he is engaged.
The third step is defining a set of conversational roles played by participants in conversations, with each participant playing at least one conversational role in any conversation. "Set" is again used in a mathematical sense with the one member and plural member sets having meaning here. A "conversational role" is a construct which relates to a number of aspects of the conversation and the relationship of the participants to the purpose and meaning of the conversation. It is a contextual construct and may have connotations of authority or control, as will be discussed below. Role definition may depend on the type of conversation, the subject of the conversation, and the business or social culture in which the conversation is taking place. For convenience and expedience, the labels that are attached to roles may be somewhat arbitrary in some conversational contexts, but they will have meaning in the overall functioning of the method of this invention.
The fourth step is defining a set of types of incompletions which occur recurringly within conversations, including a first type in which a conversational move by at least one participant to declare at least one specific realizable possibility is missing, and a second type in which a conversational move by at least one participant to complete a specific realizable possibility is missing. The term "incompletions" is a notational construct which lies at the heart of the methodology of conversation management in accordance with this invention. It can be understood as missing elements such as "missing a response" or "missing the promised action" which are the fundamental ones of interest, but the construct is deeper and more general in that there may be other elements required to cause a transition in a conversation from something being incomplete to being fulfilled. There may be a series of related incompletions.
For example, the method of this invention could involve a series of actions which must take place over a period of time to complete an overall action--such actions could be delivering a contract due on one date, acceptance of delivery of equipment on another date, and payment for the equipment on a third date. The construct of incompletions can handle types of incompletions and plural incompletions of the same type related to a Conversation for Action.
Another step of the method of this invention involves defining a set of types of permitted moves in conversations on the basis of the defined incompletions, the defined roles, and the specific types of incompletions produced by the permitted moves. The "permitted move" concept lies at the heart of the method of this invention and the structuring of a system in which participants may construct for themselves conversations which are consistent with the possibilities and actions developed within those conversations in a meaningful way. "Permitted" here is used in the sense of constraint, that is the participants cannot make a move which is not permitted. Different types of conversations have different and particular incompletions and patterns of incompletions, and specific moves have the effect of completing those incompletions for participants in different roles. This will be clear from the examples given below.
Defining permitted moves is accomplished in a manner which fits the observational distinctions as they are applied to people's conversations about possibilities and taking action to complete possibilities. The richness and flexibility of the set of permitted moves can be "tuned" to the participants and the types of conversations in which they are typically engaged. There are, in accordance with this invention, certain specific protocols of permitted moves which are very powerful and adaptable to a wide variety of business or social cultures of participants. The method of this invention contemplates general purpose embodiments which involve standard sets of permitted moves and special purpose embodiments in which customized sets of permitted moves are defined to achieve special purpose conversations within a particular organization.
Another step of the method of this invention involves defining for each of the types of moves a set of associated data. The set of data may have one element or many. It may include text of the message associated with the move, dates and other data values associated with incompletions, and a variety of other and other data values associated with incompletions, and a variety of other data elements. This is an open-ended aspect of the invention, limited only by practicable considerations of management of such data elements.
Another step of the method comprises defining a conversation record format for the conversations comprising identities and roles of participants, incompletions, and a pre-defined body of data associated with each move of the conversation, including the type of move. The method of this invention contemplates building and maintaining a conversation data base. The defining of a conversation record format is an essential element of data base management, but there are many ways of formatting the records and the record elements that are involved in this invention.
In addition to the defining steps discussed above, the method of this invention involves the step of establishing a conversation management program for enabling interactive computer-controlled management of each of a plurality of conversations. One step of this program involves providing facilities for use of each participant in opening a new conversation with an initial move and entering data associated therewith. Some of the permitted moves defined are initial moves. Various approaches can be taken to providing this program facility to the participants for selecting an initial move. Any of the current standard approaches in the art may be employed: selection from menus, keystroke sequences, and the like. This step of the conversation management program, like the others, is relatively straightforward once the overall concept of the method of conversation management in accordance with the invention is understood.
Another step of the conversation management program involves creating a new conversation record for each new conversation by assembling the entered data according to the conversation record format, including incompletions produced by the initial move and the entered data, and storing the new conversation record in at least one file. The conversation management program of this invention may be viewed as a supervisory program which accesses the facilities of a standard database management program in unique ways to achieve a unique purpose.
The management of data elements relating to incompletions is a particularly important aspect of this invention. It should be understood that the data values of the incompletions could be various types. In many applications, the data values should take on dates or, more generally, times. However, there are applications where the values could be binary where the incompletion has no important relation to time. Some incompletions could have dollar values, others could have "mood" values or have values which are based on a mathematical function or formula or on authority relations among roles available.
The conversation management program includes the step of providing facilities for use of each participant in selecting an existing conversation in which to make a move. This can be implemented using any of the standard techniques for accessing stored records in the file or database of conversation records. It can involve sophisticated sorting routines with participant entry of sort criteria. This facility can also be integrated with the step of reviewing new moves which is discussed below. In other words, the participant may be provided with the facility to make a move in a conversation in response to a new move which has just arrived and is being reviewed.
A very important step of the conversation management program is the one which involves deriving from the definition of types of permitted moves and the conversation record corresponding to the selected conversation the set of currently permitted moves consistent with the role of the participant in the selected conversation. This can be done in a variety of ways and conveniently can be done by using look up tables together with steps which analyze the current incompletions to determine whether certain moves should be permitted to the participant. It should be understood that there may be some moves which are always permitted to each participant regardless of role or state of incompletions or other prior moves that have been made. A COMMENT move, for example, may always be appropriate in some embodiments, but there may be some applications in which the COMMENT move would not always be permitted.
The other basic steps of the conversation management program are relatively straightforward and need no amplified explanation beyond the discussion of their implementation in a specific embodiment which is set forth below. These steps are the following:
providing facilities for use of the participant in selecting and making a move from the set of permitted moves in the selected conversation, and entering data associated with the move;
updating the stored conversation record associated with the selected conversation as the participant makes the permitted move, the updating including storing data associated with the permitted move and the types of incompletions produced by the permitted move; and
providing facilities for use of each participant to review new moves by other participants in all conversations in which the participant plays a conversational role.
While these steps are straightforward, that is only true because of the already defined relationship between the moves and the incompletions and the roles. The step of updating stored conversation records importantly involves manipulation of stored incompletions in accordance with the relationships previously defined.
The term "new move" is used to denote a move that is newly coming to the attention of the participant to which it is directed. Once the participant has reviewed that move, it becomes the latest move in the conversation in which it was made. Thereafter it is retrievable using the conversation and move retrieval facilities which are also provided in accordance with the method of this invention.
EMBODIMENTS OF SYSTEMS INCORPORATING THE METHOD OF THIS INVENTION
The current embodiment, Version 1.5 of The Coordinator system (made available in both English and Spanish languages), is a system for managing business, social, and/or personal communications. The current embodiment is programmed to operate on IBM PC-XT-compatible personal computers. Each participant in a conversation works at such a personal computer, each operating a copy of the programs for The Coordinator system. Data communications among the personal computers operated by participants are through standard voice-grade phone lines and commercially-available local area networks. More than one participant may at different times work on the same personal computer, and may engage in conversations with themselves or others working at a single personal computer or at a plurality of personal computers.
a. Defining Communications as Moves in Conversations
With The Coordinator system, communications take place between a set of participants and are defined, interpreted by the programs, and understood by the participants as moves in conversations where participants making moves in conversations are:
(1) declaring specific realizable possibilities--producing in the conversation specific distinctions regarding possibilities that might be realized, and producing distinctions regarding actions that might be taken to bring those possibilities about; and/or
(2) producing in their conversation actions to complete the specific possibilities that have been declared.
The basic unit of interaction in The Coordinator system is the conversation. All communications between individuals are defined as moves in conversations. In this description of the embodiment the word "move" refers to a single communication event consisting of a participant "speaking" (in text) to another participant, together with the opportunity of all current participants to listen to the speaking of the first participant and themselves to speak according to the moves given to them.
Conversations are constituted of moves interpreted by the participants to have a unity--a conversation begins when a participant "opens" a conversation with a move, proceeds through other moves by the participants in the conversation, and is "closed" in the moment that a participant with the authority in the conversation declares the possibilities of the conversation realized, or declares the conversation closed with possibilities unrealized.
Conversations in The Coordinator system are divided into two categories: Conversations for Possibilities and Conversations for Action. There are two types of Conversations for Action, called "REQUEST" and "OFFER" (both of which are conducted with other participants), and one sub-type, those conducted with oneself, called "promise to myself". There is one type of Conversations for Possibilities, those conducted with other participants, and one sub-type, those conducted with oneself.
Table 1 shows a facsimile of the menu presented by The Coordinator system to a participant in the moment that the participant indicates that he wishes to open a new conversation. In the column on the left are presented options for beginning the defined Conversations for Action of two types, shown as "Request" and "Offer", and the option for opening a Conversation for Possibilities is shown as "Declare an opening." To select an option in this embodiment, a participant manipulates the "cursor" on a video screen until the cursor is located on the desired option, and then presses the "enter" button on the keyboard. The options shown in the right-hand column will be introduced later in this description.
b. Conversations Occur within Domains of Possibilities
Each conversation within The Coordinator system takes place within one or more declared or understood domains of possibilities. The Coordinator system includes facilities for declaring domains of possibilities. Whenever a participant initiates a conversation, The Coordinator system presents a menu listing the names of domains he has already declared open for conversations, from which the participant may choose the domain of possibilities that he declares for the conversation. Table 2 shows a facsimile of the type of menu The Coordinator system presents to a participant, containing the names of a number of domains declared by an actual participant using the system over time. The "null" domain, called "none" in the Table, is provided automatically; the participant himself declares all other names that will appear in the menu. As with the previous description of a menu, a participant will place the cursor on the name of the domain in which he will open his conversation and presses a key to select that domain.
At the time of opening a new conversation, a participant may also add a new domain to the list of declared domains and then may select that newly-declared domain as the domain of possibilities for the conversation. Further, each time the participant makes a move, The Coordinator system gives the participant the opportunity to re-name the domain in which a conversation is being conducted.
When a participant initiates a Conversation for Action, "domain" refers to the domain of possibilities in which a participant declares a specific possibility that he will complete with actions that will occur in the conversation.
The method of the invention makes a number of distinctions that are not normally made in peoples' understanding of what is happening in conversations. An example will help clarify the several distinctions of domains, possibilities, specific realizable possibilities, declared possibilities of actions to complete specific declared possibilities, etc.
To illustrate, we describe the following move of a "Mr. Smith." In a domain of possibilities Mr. Smith has called, "career", one day he declares the specific, realizable possibility of "learning about accounting", and makes that declaration as he is making the move of requesting admission to an upcoming night school course (which move of making a request is an action in the conversation that has the possibility of completing the specific declared possibility of learning accounting at some date in the future).
When a participant initiates a Conversation for Possibilities, it is the domain of possibilities in which the participant will declare and define specific realizable possibilities in the conversation.
For the participant, the domain of possibilities is the "senior" declaration of the conversation--it is the participant's name for that domain of possibilities for the sake of which the participant makes requests, promises, assertions, and declarations in the conversation.
Domains of possibility are specific to individual participants in conversations. When one participant names a domain, each other participant in the conversation may "adopt" the same name or give a different name for the domain. For example, a lawyer preparing a patent filing may open a Conversation for Action of the REQUEST type with a client, "Jones", and give the client's name as the domain of possibilities for the conversation. When Jones reads the request, it will make no sense to adopt the name, Jones as the name of the domain.
For Jones, however, an appropriate name to declare for the domain may be "patent", for example. Thus each conversation occurs within at least one understood domain of possibilities, and often the domain of possibilities will be different for different participants in the conversation. Also, the domain of possibilities may change for a given participant as the conversation progresses.
The Coordinator system can present to a participant all his conversations in any domain he has declared. When a participant reviews a conversation, The Coordinator system presents facilities to change the declared domain of the conversation. These features are described later in this document.
c. Participants Play Conversational Roles
In these conversations through The Coordinator system, each participant plays at least one of a set of defined conversational roles. In the current embodiment, three roles are defined--requestor, promisor, and observer. Different participants enter conversations in different roles as they are (1) "addressed" by other participants as they start conversations, and (2) as participants in existing conversations include additional participants as observers in those existing conversations.
The actual "act" of "addressing" a communication to a participant in The Coordinator system is illustrated in Table 3, which shows a facsimile of the menu which the system presents to a participant for addressing his communication to someone in a Conversation for Action. This menu is presented by the system immediately after a participant has selected a domain for a conversation he is opening. Notice at the top of the menu the text, "Skip `To:` to select addressee from list`. This informs the participant that if he does NOT stipulate an addressee in the "To" field of this menu, The Coordinator system will present to him a list of all the participants who he has declared himself to be in day-to-day conversation with through The Coordinator system. (This act of declaring participants with whom a participant is in regular conversation is done with tools described at "Network of Help" in Section j.) Notice the field labeled "Action:". This field is presented for the participant to begin the declaration of a realizable possibility in this conversation. We will say more about this later. The field, "Send copies?", is for defining observers to this conversation, if any. When the participant has filled in the menu, he selects "<Done>".
If, as described above, the "To:" field is left blank, The Coordinator system will next present a list of possible participants for the conversation in a menu of which Table 4 is a facsimile. Here the system lists, in a form defined by the participant, the names of those participants with whom he is in daily communication. The first name, at the top of the left column in this case, is the name of the participant currently working at The Coordinator system, which is necessary insofar as this embodiment may be used for conducting conversations with oneself which are supported by the system. The Coordinator system will allow selection of a single name from the list in this menu.
If the participant has selected "Send copies?", and thereby will be including observers in the conversation, The Coordinator system will next present the menu of which a facsimile is shown in Table 5, containing the names of participants available to this participant to observe this conversation. By selecting more than one name on this list, and through various tools for making and presenting lists of participants, very large numbers of participants may be included in conversations as observers.
One of the more important features of the observer capability in this method, however, has to do with a case where there is only one observer who is a manager is included as an observer of conversations being conducted by subordinates, which thereby gives to the subordinates the capacity of giving reports to the manager without actually doing the separate act of reporting, because the manager is able to observe the business conversations in which they are engaged. In this manner, the manager is not required to engage in any conversations except when, in the process of observing, he may elect to intervene in such conversations.
The Coordinator system distinguishes the above mentioned three different types of conversational roles in conversations. A participant has the role of REQUESTOR when he opens a REQUEST Conversation (a Conversation for Action of the REQUEST type), or when he makes an opening declaration in a Conversation for Possibilities, or when he is the primary addressee of the opening of an OFFER Conversation (a Conversation for Action of the OFFER type) opened by another participant.
A participant has the role of PROMISOR when he opens an OFFER, or when he is the primary addressee of a request in a Conversation for Action of the REQUEST type, or when he is the primary addressee in the opening declaration in a Conversation for Possibilities.
A participant has the role of OBSERVER if he participates in any conversation and does not play either the role of requestor or that of promisor. In the balance of this description we will use the phrase "primary participants" to distinguish conversational participants in the roles of requestor and promisor.
d. Conversations have Recurring Incompletions
The Coordinator system embodies a method that defines a set of types of incompletions which occur recurringly within conversations, including a first type in which a conversational move by at least one participant to declare at least one specific realizable possibility is missing, and a second type in which a conversational move by at least one participant to complete a specific realizable possibility is missing.
The first type of incompletion is referred to as "missing response". Conversations for Possibilities are conversations for declaring specific realizable possibilities. "Missing response" is defined as a type of incompletion that occurs recurringly in all such conversations. In this definition, as participants in a Conversation for Possibilities converse with each other, the most common incompletion--at any moment after the conversation has been opened, and continuing to the moment that the conversation is declared complete--is the missing declaration of the participant next due to speak.
Conversations for Action are conversations to produce actions to complete specific possibilities. The incompletion, "missing response" occurs recurringly in such conversations. Beginning with the opening of a conversation, and continuing until the conversation is declared complete, at each moment some participant is missing some participant's declaration (and sometimes the missing declaration is the participant's own).
For example, when a speaker opens a Conversation for Action, he declares a realizable possibility for himself (at least), and moves in a way defined so as to be consistent with producing action to complete that possibility. The primary addressee of the opening move of such conversations is prompted by that move to distinguish a specific realizable possibility for himself and to respond to the opening move either by declaring for himself the possibility of realizing the declared possibility of the conversation, or by declaring that he will not declare such a possibility for himself.
The opening move of a Conversation for Action (and also of a Conversation for Possibilities) thus produces an incompletion of the first type--the participant opening the conversation is missing a response from the primary addressee.
The second type of incompletion is referred to as "missing fulfillment". The fulfillment that is missing is the declaration of fulfillment of an action to complete a specific realizable possibility declared in the conversation.
The second type of incompletion appears in Conversations for Action, beginning with the opening move of such conversations, and normally remains present for at least one of the participants for as long as the conversation remains "open" (i.e., has not been declared complete).
Since a Conversation for Possibilities is defined not to be a conversation for the completion of specific realizable possibilities, the missing fulfillment type of incompletion is not defined to occur recurringly in such conversations.
Participants in conversations make moves to complete incompletions--as they participate in conversations in which a realizable possibility is being declared, and conversations in which actions are being taken to complete such declared possibilities. As they make moves, incompletions may be completed, and new incompletions may be created. So long as incompletions are present in a conversation, that conversation is said to remain "open". When a conversation no longer has incompletions declared within it, then that conversation is said to be "closed" or in the "final" state.
"Tokens" are defined in The Coordinator system to distinguish the dates declared for completion of incompletions in conversations. These tokens represent dates by which either missing declarations (called "responses") or fulfillments of declared possibilities (called "fulfillment") have been declared by participants in a conversation to be completed.
Each of the primary conversational roles, requestor and promisor, has five tokens associated with it--two response and two fulfillment tokens, and an alert token ("alerts" are described below). That is, the requestor and the promisor in a conversation each have associated with them one token for each of requestor's fulfillment, requestor's response, promisor's fulfillment, promisor's response, and each has one alert.
With these tokens it becomes possible to answer questions of the sort, By when is the next move in the conversation to be made? Who is to make that move? When is (this) request or promise to be fulfilled?
So, for example, in the (fictitious) case that all possible incompletions were simultaneously recorded for both a requestor and a promisor in a conversation, the full set of recorded incompletions would be:
requestor is missing requestor's response
requestor is missing requestor's fulfillment
requestor is missing promisor's response
requestor is missing promisor's fulfillment
requestor is missing alert
promisor is missing promisor's response
promisor is missing promisor's fulfillment
promisor is missing requestor's response
promisor is missing requestor's fulfillment
promisor is missing alert.
Tokens are stored with conversation records, and are recorded as either present or absent. If the token is present then it specifies a date associated with the completion of an incompletion in the conversation.
Each participant in an open conversation, playing any defined role in that conversation, may at any time declare for himself another type of incompletion called "alert". Alerts are private declarations, having no effect on the current incompletions of the conversation as a whole, nor on the incompletions of any other participant in the conversation. An alert is the declaration that the participant making the declaration is missing an "alert" by The Coordinator system to that participant and to be completed at a date specified in the token representing the incompletion of the alert.
The incompletion, "alert", is the only incompletion which may be declared by an observer in any of the categories of conversation defined in The Coordinator system.
The primary method of presentation of tokens to participants for declaration of dates for completion is illustrated in Table 6, where will be found a facsimile of the menu presented to a participant in the moment that he selects a function key representing the option, "commit", meaning that the participant has completed composing the text of his declaration of possibilities or specification of an action to complete a realizable possibility. The specific menu illustrated is from an opening move in a Conversation for Action, which can be deduced by the fact that there are fields presented for the participant to enter tokens of all three types described above: a token (date) for fulfillment of a possibility, called here "Complete-by", a token (date) for declaration of realizable possibilities, called here, "Respond-by", and an alert token.
The system presents to the participant those particular fields corresponding to incompletions that will be present in the conversation immediately following the move the participant is currently engaged in making. A participant using the system enters a date in each such field that he determines will support the completion of the incompletion indicated. For example, in some conversations with colleagues it is not necessary to distinguish a particular moment when a response will be desired IF we are in daily conversation with each other and have standard practices with each other regarding how quickly we will "get back" to each other. On the other hand, for example, if the present conversation being opened is a very urgent matter, entering "tom" in the "Respond-by" field (which the system will automatically translate to tomorrow's date) will be a convenient warning to the addressee that this matter calls for unusual response. There are no requirements or prohibitions about such entries in The Coordinator system; only recommendations of effective practice are provided here.
While entry of dates to accompany tokens by a participant is optional, in fact The Coordinator system is programmed to declare (on behalf of the participant) a specific incompletion date for any incompletion produced by a participant move where the participant does not himself make such a declaration. The dates declared by The Coordinator system for completion of participant incompletions are far future dates, so that they will not operationally interfere with current calendars or other displays of incompletions.
e. Conversational Moves in The Coordinator System
In The Coordinator system, three complete sets of types of permitted moves in conversations are embodied, one set each for each of the three categories of conversation it will manage--Conversations for Action of types OFFER and REQUEST, and Conversations for Possibilities. These moves were defined on the basis of the recurring incompletions in conversations described above, and the roles of requestor, promisor, and observer.
In the following and the accompanying Tables and Figures, these sets of moves are described in terms of the incompletions and roles upon which they are based. The types of incompletions each move produces are also described.
(1) Example of Definition of Initial Conversational Moves
In the moment before a participant initiates a conversation the conversation does not exist, and consequently there can be neither declared possibilities, nor declared incompletions in records in The Coordinator system. The initial move in any type of conversation will at least declare some possibility and create some incompletion.
For example, a participant discovers that he must prepare a report at the end of the week, and, seeking help in preparing the report, opens a Conversation for Action of the REQUEST type with a colleague (e.g., "Please come to my office Thursday at 4 pm").
This move is constituted, (in the language of distinctions of the method of the invention) of (1) a declaration of a specific realizable possibility--which is the possibility of the fulfillment of the request itself (and, there may have been an explicit, prior Conversation for Possibilities in which the realizable possibility of this request was defined), and (2) a declaration of specific action(s) for realizing the specific possibility--namely, that the promisor fulfill the requestor's request.
In the terms defined in the previous section on incompletions, then, the requestor creates for himself, in opening the request, the following incompletions:
the requestor's fulfillment is missing--that is, he has declared the possibility of the request, and until he says it is fulfilled, it is incomplete; and
the promisor's response is missing--that is, the requestor has made a serious request to someone with whom he has previously agreed to be in conversation, and until the promisor makes some move in the conversation opened by the requestor, the requestor is missing "hearing from the promisor", which means specifically that he is missing whatever declaration the promisor will make in response to the request is missing.
In the moment that a participant (in this case, let us say it is a different participant, although it need not be in The Coordinator system), playing the role of the promisor, reads this request, that the promisor then also has two incompletions, corresponding to those of the requestor:
the promisor's response is missing; and
the requestor's fulfillment is missing.
The promisor's own fulfillment is not missing: he has not yet declared for himself any possibility of declaration or action in the conversation.
(2) Example of Definition of Subsequent Conversational Moves
In the current embodiment, moves subsequent to the initial moves in conversations are defined for the purpose of allowing the participants, playing their conversational roles, to declare possibilities, to complete incompletions and to realize the possibilities declared in the conversations.
Let us examine the definition of some moves. For example, here, after the opening move of "request" we have introduced the situation where
the requestor is missing
the requestor's fulfillment
the promisor's response
and the promisor is missing
the requestor's fulfillment
the promisor's response
Let us first define moves for the promisor. One possible move is to have the promisor respond to the requestor and take on as his own the requestor's declared possibility. (For example, "I'll be there at 4 as you ask.") In the moment of declaring for himself the possibility of the requestor, the promisor is now missing his own--the promisor's--fulfillment, which corresponds to the requestor's fulfillment, which the promisor is also still missing. We will call this move, "promise", and we see that in the moment that the promisor makes the move his incompletions in the conversion change to:
the promisor is missing
the requestor's fulfillment
the promisor's fulfillment
Then, in the moment that the requestor reads the response of the promisor, his incompletions also change, to:
the requestor is missing
the requestor's fulfillment
the promisor's fulfillment
Another possible move for the promisor would be to declare that what is a possibility for the requestor will NOT be a possibility for him. (For example, "Sorry, I am out of town all day Thursday.") We will call this move, "decline", and we see that in the moment that the promisor makes the move his incompletions in the conversation change; we might say that he no longer has any incompletions in the conversation. What the requestor proposed as possibilities for the promisor, the promisor has not declared for himself. On the other hand, in defining the moves in the current embodiment, the inventors specified that after making a decline, the promisor would in fact be missing the requestor's response--that due to the way in which people normally work together, such a conversation generally will remain incomplete for the promisor until he has heard that the requestor has listened to the promisor's decline. In the moment that the requestor reads the decline of the promisor, his incompletions change to:
the requestor is missing the requestor's fulfillment, and
the requestor is missing the requestor's response.
That is, the requestor still has a declared, realizable, and unrealized possibility--the report due at the end of the week--preparation of which was to have been fulfilled by the action requested--the assistance of a colleague on Thursday. The request will not be fulfilled; however, the possibility in which the request originally arose is still present until declared complete by the requestor, and the conversation remains open with the incompletion of the requestor's fulfillment, awaiting other action from the requestor.
Now let us look for a moment at the definition of moves for the requestor, beginning at the moment immediately after the request has been made. At this point, the requestor has two incompletions: his own fulfillment, and the promisor's response.
One move would be for requestor to declare that he was no longer incomplete in regards to his own fulfillment, independent of declared actions by the promisor. This would be appropriate if, for example, he were to realize that the report he prepared last week for his own thinking is exactly what the boss now is asking for. ("Cancel Thursday--I just realized I've already done the work!") We call this move "cancel". After making the move, the requestor is still incomplete, missing the promisor's response to this new declaration of no possibility where before there was a possibility. On reading the requestor's cancel, the promisor is no longer missing the requestor's fulfillment--attendance Thursday is no longer a declared possibility for the requestor. However, in the definitions in the current embodiment, the promisor is still missing his own (the promisor's) response in the conversation, an incompletion defined so as to take account for the fact that a requestor's act of cancellation alters the promisor's possibilities. For an example of one case of the working of this particular definition, consider the case where, on reading the request for the Thursday meeting, the promisor immediately cancels his own previously scheduled out-of-town trip so as to be available to the requestor, and, now that the requestor has cancelled, and the promisor is not able to re-schedule the trip. Then the conversation remains open until the promisor declares it complete, whereas before the requestor's cancellation, declaration of completion by the requestor would have removed all records of incompletion in the conversation and so closed it.
(3) Types of Permitted Moves
For each type of conversation in The Coordinator system we define a set of permitted types of moves on the basis of recurring incompletions and the roles defined for participants in the conversation to play.
The types of permitted moves are first defined in terms of the logical method,
"Define a case in which defined incompletions (a,b,c, . . . > occur in a conversation of type <A>;
assess the combination of those incompletions with the role of <role type>;
define types of moves <1,2,3, . . . > that will be permitted in such circumstances in such types of conversations (where "circumstances" is determined by type of conversation, current incompletions, and conversational role);
and, given that a participant makes that type of move, define the completions, remaining incompletions, and new incompletions, of types <x,y,z, . . . > that will be produced by the participant making the move."
Tables 7 through 10 contain descriptions of all the moves defined in The Coordinator system, according to this definitional notation. In addition, later in this section, under "Conversational States", we present these moves a second time, in terms of the development of programs and computational and database "machinery" developed for implementing the method in a practical communications system.
(4) Conversational States
For the programming of the current embodiment the programming notational convention of naming "States of Conversations" was adopted. The notation is used in this way: a series of States, corresponding to general conditions of incompletion found recurringly in conversations, is named. Then, based upon the incompletions found in those states, rules are developed about what roles may be permitted what moves at that state.
This allows the definition and storage of sets of permitted moves in data structures called "finite state machines". The data elements included in these data structures are:
the number of states for each category of conversation;
for each state the name of the state and the number of permitted moves;
for each move the role of the participant that can make that move, the state to which the conversation will change after the move, and the token manipulations associated with the move.
For each category of conversation The Coordinator system defines a set of conversational states.
The states defined for a conversation for possibilities are:
open; and
final.
The states defined for the Conversation for Action of the REQUEST type are:
request;
commit-to-commit;
promise;
counter;
report;
decline;
cancel; and
final.
The states defined for the Conversation for Action of type OFFER are:
offer;
commit-to-commit;
accept;
counter;
report;
decline;
cancel; and
final.
The states defined for the Conversation for Action with one role are:
promise; and
final.
(5) Finite State Machines
Each conversational state then serves as a locus of definitions of sets of permitted moves and incompletions for conversational roles. Once itself defined, a finite state machine defined in terms of these states can be used to determine the permitted moves for every state and for each role that a participant may play in a conversation. As will be shown in detail, requestor and promisor have different permitted moves in any particular state of a conversation.
The following discussion will refer to FIGS. 1 through 10, which illustrate the overall structure and principles of construction of finite state machines (hereafter also referred to as "FSM") in The Coordinator system. In all of these figures, the state-transitions produced by permitted moves for the role of REQUESTOR are shown with double lines, and permitted moves for the role of PROMISOR are shown with single lines. (Permitted roles for OBSERVERS are shown in a separate Figure.) "States" themselves are identified in the Figures by rectangular boxes containing the name of a state, to and from which lines representing state-transitions travel. The names of the moves are shown accompanying the lines, with the notation "R: . . . " to indicate a REQUESTOR move, or "P: . . . " to indicate a PROMISOR move.
FIGS. 5, 6, and 7 also include notation to describe the incompletions and tokens representing incompletions at states in conversations. The token notation will be described later in this section.
(5a) Permitted Moves for REQUESTOR in REQUEST Conversations
Let us begin to examine the finite state machines by looking at FIG. 1. FIG. 1 shows the outline of the finite state machine for the REQUESTOR's moves in a Conversation for Action of the REQUEST type. In The Coordinator system, such conversations are opened by the move called "Request", made by a participant who takes on the role of REQUESTOR in the conversation in the moment of opening the conversation.
Notice the darker line beginning in the left center of the Figure. For each Figure describing a FSM for a conversation of the Conversation for Action category (for example, FIG. 1), a darker single line will be found that traces a set of "basic moves" through the conversation--the path of progression through conversation states which traverses the minimum number of steps if no major changes occur to the realizable possibilities within which the conversation was begun. In FIG. 1, for example, illustrating the FSM for Conversations for Action of the REQUEST type, the basic moves are:
requestor makes request (for example, "Jones" asks "Brown" to prepare an agenda for a meeting three days hence);
promisor makes promise (Brown replies that he will do it);
promisor makes report-complete (Brown delivers the agenda to Jones);
requestor makes declare-complete (Jones says "Thank you").
FIGS. 1 and 2 and FIGS. 3 and 4 are paired with each other. The first pair represent FSMs for REQUEST conversations, and the second pair represent FSMs for OFFER conversations. The first Figure of each pair shows permitted moves for the role of REQUESTOR, plus the "basic moves", and the second of each pair shows the moves for the role of PROMISOR. The descriptions of permitted moves within FSMs are separated in this manner--one role to a Figure--to make them easily readable.
Although the FSMs illustrated in these Figures may be referred to as a "protocol" of conversation, notice that crucial moves for dealing with incompletions, changing circumstances, and changing assessments of the possibilities to be realized in the conversation are present all the time. For example, in FIG. 1 the REQUESTOR is permitted to declare-complete, and permitted to cancel, at any moment after opening the conversation. For example again, in FIG. 2 it can be seen that the PROMISOR has the same freedom to (a) decline the initial request, or (b) to cancel his promise at any moment after opening the conversation. In these ways it may begin to be apparent how this method of defining a system for supporting communications and conversations provides fundamental differences from "protocol-generating" communications methods.
Other features worthy of note include the state, "commit-to-commit" and the accompanying type of move of the same name, appearing in each of FIGS. 1 through 4, which permits participants to declare an incompletion in a conversation without declaring any specific realizable possibilities for himself or for other participants in the conversation until such time as the participant is in condition to make such declarations. This move and state, which are not essentially part of the minimal embodiment of the method, is found in The Coordinator system, and represents an example of the type of refinement of conversational support possible with this method. Another move of similar character, in that it "tunes" the system to particular conversations, can be seen in FIG. 1 in the definition of the "decline-report" move: in the state "report-complete" a requestor can make a decline report move that moves the conversation back to state promise.
(5b) Permitted Moves for PROMISOR in REQUEST Conversations
FIG. 2 illustrates the FSM state machine for PROMISOR's moves in a Conversation for Action of the REQUEST type.
(5c) Permitted Moves for REQUESTOR in OFFER Conversations
FIG. 3 illustrates the FSM for the REQUESTOR's moves in a Conversation for Action of the OFFER type. In The Coordinator system such conversations are opened by a PROMISOR, who takes on that role in the conversation in the moment that he opens it. The next Figure shows the PROMISOR's moves.
(5d) Permitted Moves for PROMISOR in OFFER Conversations
FIG. 4 illustrates the FSM for the PROMISOR's moves in a Conversation for Action of the OFFER type.
(5e) Incompletions at States in Conversations for Action
FIGS. 5 and 7 show the minimum essential set of moves and states for REQUEST and OFFER types of conversations. Not shown in these two Figures is the Commit-to-Commit state, nor are the moves of commit-to-commit, interim-report, decline-report, or cancel/make new promise. These two figures also illustrate the incompletions and tokens representing incompletions at states in conversations. The incompletions of the Commit-to-Commit state in a REQUEST conversation are illustrated in FIG. 6.
We now describe the notation of representation of tokens representing incompletions in FIGS. 5 through 7. Each token of incompletion is represented by two letters. There are illustrated in the Figures a total of four tokens for a requestor and four for a promisor in every state--not all of which will be present in any state. In each box representing a state, the requestor's tokens appear on top in capital letters and the promisor's tokens are indicated on bottom, in lower case letters:
(1) The incompletions of REQUESTOR are remarked in UPPERCASE characters, namely:
RR: missing requestor's response
PR: missing promisor's response
RF: missing requestor's fulfillment
PF: missing promisor's fulfillment
(2) The incompletions of PROMISOR are remarked in lowercase characters, namely
rr: missing requestor's response
pr: missing promisor's response
rf: missing requestor's fulfillment
pf: missing promisor's fulfillment
For the requestor, then, the RF token indicates that he is missing the fulfillment of a request he has made, the PF token indicates that he is missing the fulfillment of a promise made to him. The RR token indicates that it is the requestor's move in the conversation and the PR token indicates that it is promisor's move.
For the promisor, the pf token indicates that he is missing the fulfillment of a promise that he has made, the rf token indicates that he is missing the fulfillment of a request made to him. The response tokens for promisor, pr and rr, have the same meaning as the counterpart response tokens for requestor.
In The Coordinator system, the fulfillment-missing tokens are presented to the participant as "Complete-by" and "New-complete-by" dates, and the response-missing tokens are presented as a "Respond-by" date.
The final states in conversations are defined as the states in which no token is present. That is, there is no incompletion in the conversation. The declare-complete move in a Conversation for Action is interpreted by the system as an instruction to record as "complete" all previously recorded incompletions in the conversation.
Reviewing FIG. 5, note that in the state, "request", if the most recent previous move was a counter-offer by a requestor, different dates of fulfillment and response may have been declared by the participants in the conversation, and the tokens may be correspondingly different. We will give a detailed example of this phenomenon later in this section. What has happened in this example is that REQUESTOR's "requestor's fulfillment" token has recorded a new-complete-by data declared in the counter-offer move, and REQUESTOR's "promisor's response" token has recorded for it a new respond-by date. (PROMISOR's tokens will have corresponding differences.)
Also in FIG. 5, note that in the state, "promise", if the last move was an accept of a counter-offer by the requestor, REQUESTOR's "requestor's fulfillment" token date becomes the complete-by date of the counter-offer (if that date differs from the complete-by date of the original request). PROMISOR's "requestor's fulfillment" token will be modified in similar fashion.
Also in FIG. 5, note that in the state, "decline", PROMISOR's "requestor's fulfillment" token is only present if the last move was promisor's cancel of his promise. This token is not present if the last move was a promisor's decline of the request. The REQUESTOR's "requestor's response" token takes the new respond-by date.
Also in FIG. 5, note that in the state, "cancel", the date of response tokens is that produced in the requestor's cancel move, and is not the date of the original request, nor of the promisor's report-complete move.
In FIG. 7, note that in the state, "accept", if the last move was a promise, the dates given to tokens may differ from those originally given in the conversation. REQUESTOR's "promisor's fulfillment" token is given a "New-complete-by" date if one was produced in the previous counter-offer move by REQUESTOR. Similarly, the date of PROMISOR's "promisor's fulfillment" token changes.
In FIG. 7, note that in the state, "cancel", dates given to response tokens are those produced in PROMISOR's cancel move.
In FIG. 7, note that in the state, "decline", PROMISOR's fulfillment token is only present if the last move was a requestor's decline of his offer. This token is not present if the last move was a requestor's cancel of the offer. PROMISOR's "promisor's response" token takes the respond-by date of the requestor's decline or cancel move.
(5f) Permitted Moves for OBSERVERS in Conversations
For OBSERVERS, open conversations are placed in the state "Observing". FIGS. 8a, 8b, and 8c illustrate the state, "Observing". For an observer in a conversation the state of the conversation has only two states. When an observer receives a communication in a new conversation, that conversation is moved, from the observer's point of view, to the state, "Observing". All conversations remain in that state until a declare-complete move is made by one of the primary participants in the conversation--that is, until a communication is received in which a participant permitted to do so declares the conversation complete. Observers are permitted only "comment" moves in Conversations for Action, and, although they are permitted the moves of PROMISOR in Conversations for Possibilities, such conversations are nevertheless held in the state "Observing" in OBSERVERS' conversation records.
(5g) Permitted Moves in Conversations for Action with One Role
FIG. 9a illustrates the FSM in The Coordinator system for a Conversation for Action in which participants play in only one role. Such conversations may be initiated with either a request or an offer move addressed to the participant himself. In either case, the FSM will interpret the move as a declaration of incompletion of fulfillment of some realizable possibility, in the state "promise". The minimum permitted moves of such conversations are the opening request or offer move, cancel, and declare-complete. The states of such conversations are "promise" and "final". The response and fulfillment tokens are both present at all times while such conversations are open, and both absent when such conversations reach the final state. Thus, in this simple protocol, it is always the participant's turn to make a move in the conversation, and he may declare distinct dates for completion of the incompletions of fulfillment--his "promise-to-himself"--and response--the date for next declaring in the conversation, until he either cancels the promise or declares the conversation complete.
Augmentation of this basic FSM is achieved by adding the cancel/make new promise move and the interim-report move to the repertoire of permitted moves.
(In The Coordinator system, participants are permitted to add observers to conversations they are conducting with themselves.)
(5h) Follow-Up and Acknowledge Moves
The moves, follow-up and acknowledge, are not handled within the FSM of The Coordinator system, but rather are added to those permitted moves derived from a FSM before the full list of permitted moves is presented to a participant by The Coordinator system.
A follow-up move is permitted to REQUESTOR when he is missing requestor's fulfillment, and to either of the primary participants when they are missing the response of the other.
As a consequence, REQUESTOR is permitted follow-up moves from any state until he declares the conversation complete. PROMISOR is permitted follow-up moves in states counter-offer, decline and report.
The rules according to which acknowledge moves are permitted to participants are based not only upon the conversational role of the participant and the current fulfillment and response incompletions of the conversation, but also upon a type of incompletion not previously discussed, in which what is missing is the declaration that a participant has listened to a specific declaration by another participant. In normal human conversations, an acknowledge is a kind of move made by a participant to complete an incompletion--the concern that a participant is not listening--that will in turn make it possible for the next declaration to be made in confidence.
The rules governing the making of an acknowledge move are: (a) the participant preparing to make a move must not have previously made a move in response to the move he might now acknowledge, (b) the move being acknowledged must have been made by a participant participating in this conversation in the role of requestor or promisor, and (c) the move being acknowledged may not be itself an acknowledge move.
Follow-up and acknowledge moves do not cause any change in the state of a conversation.
(5i) The Comment (or "Free-form") Move
The move, "Comment" (called "Free-form") move is always permitted, even in conversations that have been closed (i.e., conversations that are in final state).
Comment moves do not cause any change in the state of the conversation.
(5j) Permitted Moves in Conversations for Possibilities
FIG. 10 illustrates the FSM for Conversations for Possibilities. In Conversations for Possibilities The Coordinator system manipulates only two tokens for each role in the conversation: the requestor's response and the promisor's response tokens. The conversation states are r-open, p-open, and final. The difference between the two open states is given by the token combination.
(5k) Permitted Moves in Conversations for Possibilities with One Role
FIG. 9b illustrates The Coordinator system's protocol for a Conversation for Possibilities with one role. The conversation is initiated by an opening declaration of a possibility addressed to the participant himself. Only one recurring incompletion is recorded in the conversation: missing response.
In this protocol the response token is present at all times in the open state: it is always the participant's turn to respond to himself (or to his role) in the conversation. The continuing moves in the conversation may update the associated date of the response token. The conversation is terminated when the participant declares it complete.
(In The Coordinator system, participants are permitted to add observers to conversations they are conducting with themselves.)
(6) Operation of Finite State Machines
In the following we give examples of the operation of The Coordinator system's finite state machines during the conduct of conversations among participants in a sample set of conversations. An example of the functioning of these machines for each type and sub-type of conversation in The Coordinator system is provided.
Each description includes two parts: a part in which moves are described in the language of an observer who is observing participants in a conversation, and a part in the language of an observer who is specifying the structure and operation of the system which is recording the conversation and placing tokens (and other data) in database to represent incompletions and the declared dates of completion for those incompletions.
(6a) Example of a Conversation for Action of the Request Type
As an example of this type of conversation, consider a conversation opened by "Alex" making a request to "Robin", in the domain "newsales".
Throughout this discussion the reader will find it useful to consult FIG. 5, which shows the structure of permitted moves given the minimum defined set of permitted moves in this type of conversation. The Figure is organized to show the moves according to the notational construction of "Conversational States", and thus shows moves as transitions from and to the states of a conversation.
The specific incompletions found at each state (i.e., produced by moves which deliver the conversation to that state), and the representative tokens to be found in the conversation record at that state are also indicated in the FIG. Incompletions are noted with alphabetic characters inside boxes representing the states of the conversation as described above in this section. Now let us examine a conversation. It begins when Alex makes a request to Robin, asking Robin to deliver a budget to him by Oct. 1st (the "complete-by", or "missing fulfillment" token date).
In addition, he asks Robin to confirm that Robin will be able to fulfill the promise before Sep. 15th (by entering a "Respond-by" date for the incompletion he is creating for the "missing response").
In the conversation record in The Coordinator system that Alex uses, the conversation opened by Alex is in the state "request" after Alex makes the request. For Alex, the requestor, two tokens are recorded: the promisor's response token (PR) for the date he declared for completion of the incompletion of Robin's response he created in making the request, and the requestor's fulfillment token (RF) for the date he declared for completion of the incompletion he declared, of the possibility of Robin fulfilling Alex's possibility of a new budget.
It becomes simpler to follow if we produce a "picture" of the tokens. Immediately after making his initial move, The Coordinator system conversation records show tokens for Alex as illustrated in Table 12. The numbers shown in the Table are date-references: 100185 expands to Oct. 1, 1985.
The Coordinator system that Robin uses receives the request from Alex, processes the communication using the algorithm illustrated in FIG. 5, and creates a new conversation record the token structure of which shows the conversation to be in the state, request. For Robin, as promisor, the tokens recorded are the promisor's response token (pr), indicating an incompletion regarding his speaking to Alex, and the requestor's fulfillment token (rf), indicating the incompletion of Alex's missing fulfillment of an action for realizing a possibility.
The token records in Robin's conversation records for this conversation in the state, REQUEST, are illustrated in Table 12.
When Robin reads the request from Alex at his personal computer, he decides to answer immediately, and presses a function key that has the indicated function, "answer". The Coordinator system constructs a list of permitted moves according to processes that will be described later, and presents a menu to Alex on which are listed the moves permitted to the promisor at this moment in this type of Conversation for Action (of the "REQUEST" type). Table 11 shows a facsimile of the menu which The Coordinator system will present to a participant making such a move. On the right-hand column notice the four moves permitted to promisor--"Promise", "Counter-offer", "Decline", and "Report-completion". (The options in the left-hand column will be introduced later.) Now turn to FIG. 5 again. Notice the two thin arrows showing permitted moves of decline and counteroffer, and the dark lines indicating promise and report-complete. (Permitting the report-complete move directly from the state of Request is a variation in which, in the moment of the report, the promisor assumes incompletions equivalent to those he would have if he had in fact first promised, and then reported. Doing the two moves in one is a move to produce facility in the system.)
For a next move, from among those permitted and presented on the screen, Robin will make a counteroffer to respond to Alex's request. Robin counteroffers that he is willing to commit himself to complete the budget, not as Alex has asked for on the 1st of Oct., but on the 10th of Oct. Having selected the move counteroffer, which produces a new incompletion for the promisor of the promisor's fulfillment, The Coordinator system presents a "token menu" for Robin to fill in as he "commits" to his counteroffer, showing these fields:
"New-complete-by:"
"Respond-by:"
"New-complete-by" allows Robin to declare a date for the incompletion of his own fulfillment that he is creating by making the move, counteroffer. When he does the move of a counteroffer, that is, he is declaring into existence that he is now incomplete in this conversation, and his incompletion has to do with fulfillment of an action, and the date he declares for fulfillment is Oct. 10th.
The Coordinator system records the move in Robin's conversation records and sends a record of the move to Alex as well. In Robin's personal computer this counteroffer changes the conversational state recorded in his conversation records to "Counteroffer", and triggers the following token manipulations: for Robin, the promisor, the promisor's response token is removed, since his response is no longer missing; the requestor's response token is added with the date of Sep. 25th, since now Alex's response is missing; the promisor's fulfillment token is added with the date of Oct. 10th. The requestor's fulfillment token remains unchanged, since the requestor's declared incompletion is still incomplete, and will remain so until he accepts the counteroffer or takes another permitted move towards fulfillment.
Robin's token records are illustrated, now for the state, COUNTEROFFER, in Table 12.
When Alex, the requestor, receives this counteroffer, the Coordinator system that he uses processes it, changes the conversational state in his conversation record "Counteroffer", and changes the records of incompletions for Alex, the requestor, in his token records. The promisor's response token is removed, since the promisor has responded. The requestor's response token is added, with the date of Sep. 25th. The promisor's fulfillment token is added with the date of Oct. 10th, since now the promisor's is incomplete with respect to fulfillment of some action in this conversation. The requestor's fulfillment token remains unchanged. Notice now that in both Robin and Alex's conversation records the tokens of fulfillment show different dates (see Table 12 for state, COUNTEROFFER.)
As indicated in FIG. 5, in the state of counteroffer, in a Conversation for Action of type REQUEST, three tokens,
requestor's response,
requestor's fulfillment, and
promisor's fulfillment
. . are recorded for the requestor, and three tokens,
requestor's response,
promisor's fulfillment, and
requestor's fulfillment
. . are recorded for the promisor.
Now, suppose that Alex reads Robin's counteroffer, presses the function key for "answer", and, from among the presented permitted moves, selects the move "accept", declaring that he will accept Robin's counteroffer, and thereby take on as his own the declaration of missing fulfillment with which Robin has countered. Once he has "committed" to his move, the conversation record in Alex's personal computer has its conversational state changed from counteroffer to "promise". The requestor's response token is removed, since Alex, the requestor, has responded; and the date associated with the requestor's fulfillment token is changed from Oct. 1st to Oct. 10th, since, by accepting the counteroffer, he has declared for himself a new date for completing that incomplete fulfillment. The promisor's fulfillment token is left unchanged. (See Table 12.)
The move arrives at The Coordinator system that Robin uses, is processed, and the conversational state in his conversation records are changed from counteroffer to promise. The requestor's response token is removed: the requestor has responded. The date associated with the requestor's fulfillment token is changed from Oct. 1st to Oct. 10th. The promisor's fulfillment token is left unchanged. Robin's token records for this conversation in the state, PROMISE, are again illustrated in Table 12.
As can be seen in FIG. 5, in the state, "promise", in a Conversation for Action of the REQUEST type, the requestor's fulfillment and promisor's fulfillment tokens are recorded for the requestor and the promisor's fulfillment and requestor's fulfillment tokens are recorded for the promisor.
FIG. 5 also discloses that in the promise state Robin has two moves available: cancel and report-complete. In this state, Alex's possible moves are: cancel and declare-complete, the latter being a move he might make if someone else already had fulfilled the request.
Now, suppose for the next move in the conversation, Robin makes a report-complete, after finishing the preparation of the budget. Suppose also that when Robin makes this move he asks Alex to respond by Oct. 11th. In the conversation record the conversational state is changed from promise to report-complete. Notice the token changes in Table 12. The requestor's response token is added with the date by which Robin declares for response. The promisor's fulfillment token is removed, since Robin is declaring that the promise's conditions of satisfaction have been fulfilled. The requestor's fulfillment token is not changed: it will not be removed until Alex accepts Robin's report (or either of the participants take other relevant action in the conversation).
When Alex's personal computer receives the report move, the conversational state his conversation records is changed from promise to report. Again, refer to Table 12. The requestor's response token is added, with its date declared to match the respond-by date declared by Robin. The requestor's fulfillment and promisor's fulfillment tokens are not changed, since Alex's request and Robin's promise to him will remain pending until he accepts Robin's report and declares the conversation complete.
Finally, suppose that Alex accepts Robin's report and declares the conversation complete. In the conversation record the conversational state is changed from report-complete to the state, "final" and, as Table 12 shows, all tokens are removed, since no incompletions remain in the conversation. And, when The Coordinator system that Robin uses receives Alex's declaration, the conversational state is changed from that of report-complete to that of final and all tokens are removed.
As long as a conversation is not purged from a participant's conversation records, that participant will be able to review it by using The Coordinator system's selection tools (described below). Sorting criteria that could be used to gain access to this conversation while in the final state include: "closed conversations", domain ("newsales"), specific participant and dates of moves.
In this discussion, we examine only one move at each state. But the manner in which alternative moves would be described should be evident on the basis of that examination. Note also that in this discussion we do not deal with more complex conversations, e.g., conversations that include such moves as commit-to-commit, free-form and follow-up. The manner in which such moves would occur will be evident from the present discussion and FIGS. 1 and 2.
A traditional problem in methodologies for development of social systems of communication can be referred to as "getting messages crossed". It is the problem of conflicting declarations when systems have been structured in the presupposition that what people are doing when they are communicating is matching descriptions of some external physical reality. In such systems, the question of whose declaration will be given precedence in being recorded as the "accurate", "final", or "authoritative" declaration in a database is a major issue.
The present methodology presents an entirely alternative approach, and the problem of conflicting declarations does not arise in this methodology in the way it arises in traditional methodologies. The reason for this is that the "objects" worked upon in this methodology are participants' individual declarations of possibilities for action and declared incompletions with regard to actions to complete possibilities; and these declarations are linguistic objects which, as such, are always attributable to particular declarers, rather than being objects which (as is often supposed) exist independent of declarations (and which are therefore not attributable). Conflicts will arise in the conduct of conversations on systems built according to this method. For example, one participant may promise in the moment that the requestor cancels. And, when such conflicts arise, they arise within the very domain in which the system is itself a method for producing resolution--that is, in the domain of human conversations, where people will have conversations about coordinating their actions and possibilities.
(6b) Example of a Conversation for Action of the Offer Type
Throughout this discussion the reader will find it useful to consult FIG. 7. As the Figure indicates, a variety of moves are possible in each state of this type of conversation. Changes in conversational state and results of token manipulation triggered by each of the various moves are also indicated there. Again, in this discussion, we examine only one move at each state.
As an example of this type of conversation, consider a conversation initiated by an offer Alex makes to Dianne on Sep. 25th in a domain of possibilities he called "personel". Alex enters Oct. 3rd as the complete-by date and Oct. 1st as the respond-by date. In the conversation record begun when Alex makes this move, the conversational state is termed "offer" and the tokens that are recorded for Alex, the promisor, include: requestor's response, with the date of Oct. 1st, and promisor's fulfillment with the date of Oct. 3rd. Now, suppose that in composing his offer, the opportunity to declare an alert date leads Alex to open a brief private conversation with himself concerning whether or not to declared an alert date. Further suppose that in this brief conversation Alex concludes he will prompt (remind) himself to get certain personnel records into his hands before the respond-by date he has specified. (He declares to himself that failure to have those records in hand by that date might cause him to miss the possibility of fulfilling his promise.) Consequently, Alex specifies an alert date in this conversation for Sep. 30th, one day before the date by which he has requested a response. An alert token dated Sep. 30th is stored in the token records in Alex's personal computer, and an alert will appear in his daily calendar for Sep. 30th, as well as appearing in lists of commitments due on that date.
For example, Table 13 presents a facsimile of the "calendar" that The Coordinator system produces when a participant selects options presented under the name, "Today's appointments and commitments". In the calendar can be seen numbers of alerts. A participant may place the cursor on the screen at the location of any of the summaries shown, and The Coordinator system will go to the conversation records and retrieve to the screen the latest move in the conversation so selected. Further, the participant can then instruct The Coordinator system, with "control key commands", or by going to other menu and function key commands, to "trace backwards" in the selected conversation. Tracing backwards (and forwards) allows a participant to thereby review the entire history of the conversation so selected, and, as alerts are incompletions declared for the purpose of completing declared realizable possibilities, the participant can, in the moment of review, move in the conversation to declare new actions, declare new possibilities, or take other relevant action.
Declaring an alert allows the participant to request and be given by The Coordinator system summaries of conversations in such alerts have been declared, and to have these summaries displayed, in pre-defined formats, in displays of "commitments due" on the date of the alert. Such displays include daily calendars, lists of "commitments due" on particular dates, and also it is possible to get a list of all conversations in which alerts have been declared. Table 14 presents a facsimile of one of the types of pre-defined formats of conversational summaries which The Coordinator system will present on a participant's instructions.
Alerts disappear from conversation records only when one of the principal participants in the conversation makes a move that affects the state of the conversation (i.e., not interim-report, comment, acknowledgement, or followup). A move that affects the state of the conversation will cause alerts declared by the primary participants in the conversation to be removed from their respective conversation records--alerts in the records of the maker of the move being removed in the moment that the move is recorded in his conversation records, and alerts declared by the other primary participant (requestor or promisor, whoever is "receiving" the move), and occuring in their respective conversation records being removed in the moment that this "other" participant's copy of The Coordinator system stores the new move in his own conversation records. (This "moment" will be approximately the same for both participants if they are working at the same personal computer, and will be different moments if they are working at personal computers attached to different storage devices with communications facilities between them.)
Once The Coordinator system that Dianne uses processes Alex's offer a new conversation record is opened and it shows the conversation to be in the state of offer. For Dianne, the requestor, the tokens recorded are requestor's response, for Oct. 1st, and promisor's fulfillment for Oct. 3rd.
Suppose Dianne accepts Alex's offer rather than exercising her option to make a counteroffer. In the conversation record, the conversational state is changed to that of accept, the requestor's response token is removed and the requestor's fulfillment token is added, with the date of Oct. 3rd.
After Alex's personal computer processes Diane's accept move, the conversational state in his personal computer's conversation record is changed to that of accept, the requestor's response token is removed, since Dianne has answered Alex's offer, the requestor's fulfillment token is added with the date of Oct. 3rd, and Alex's alert token for this conversation is removed from Alex's conversation records.
Suppose that Alex decides that he cannot fulfill his original offer and so makes a cancel move with a respond-by date of Oct. 2nd. The conversational state is changed to that of cancel, the requestor's fulfillment and promisor's fulfillment tokens are removed and the requestor's response token is added with the date of Oct. 2nd.
After Dianne's personal computer processes Alex's cancel move, the conversational state in her personal computer's conversation record is changed to cancel, the promisor's fulfillment and requestor's fulfillment tokens are removed and a requestor's response token with the date of Oct. 2nd is added.
Suppose, next, that Dianne then declares the conversation complete. In the conversation record in her personal computer, the conversational state is changed from cancel to the state termed "final" and all tokens are removed, since no incompletions remain in the conversation.
When The Coordinator system that Alex uses receives Dianne's declaration, the conversational state is changed from that of cancel to that of final and all tokens are removed.
As long as the conversation is not purged from a participant's conversation records that participant can review it by using The Coordinator system's selection mechanisms. Illustrated in Table 15 is the most general tool provided in The Coordinator system for selecting conversation and move records from a participant's conversation records database. Brief examination of the Table reveals that sorting criteria available there that could be used to gain access to this conversation in its final state include: "closed conversations", selection by domain ("personel"), selection of all conversations within some time parameter, selection of specific participant and selections by specific dates of moves.
Table 16 illustrates a list of conversation summaries sorted according to the person with whom the participant is in conversation. This can be helpful, for example, in conducting meetings with personnel whom one works with, where The Coordinator system assists in the preparation of an assessment of the current conversations between colleagues, manager and subordinate, customer and supplier, etc.
(6c) Example of a Conversation for Possibilities
We recommend the reader consult FIG. 10 during the following discussion.
As an example of a Conversation for Possibilities, consider a conversation that Alex opens in the domain "sales" with Dianne, proposing certain writing that he has done as a possible basis of a new advertising initiative, and asking that she review the writing and give some response by Oct. 10th. In the conversation record opened in Alex's personal computer when he makes this move, the conversational state is "r-open" and the promisor's response token is recorded with a date of Oct. 10th.
When The Coordinator system that Dianne uses processes Alex's move, a new conversation record is opened, showing the conversation to be in the state of p-open, and a promisor's response token is recorded with a date of Oct. 10th. Suppose she responds to Alex's declaration with a "reformulation of the same declaration"--which in this means that she comments within and edits and delivers back to Alex the same writing he gave to her with her modifications--and suppose she declares a respond-by date of Oct. 4th. This move changes the conversational state to r-open, the promisor's response token is removed and a requestor's response token is added with the date of Oct. 4th.
After Alex's personal computer receives the new move from Dianne, the conversational state in his personal computer's conversation record is changed to r-open, the promisor's response token is removed and a requestor's response token is added with the date of Oct. 4th.
We may suppose that this conversation continues in a similar fashion for several interactions, until Alex declares the Conversation for Possibilities complete. In the conversation record in his personal computer, the conversational state is then changed from open to the state termed "final" and all tokens are removed, since no incompletions remain in the conversation.
When The Coordinator system that Dianne uses receives Alex's declaration, it changes the conversational state from that of cancel to that of final and removes all tokens.
As long as the conversation is not purged from a participant's conversation records that participant can review it by using The Coordinator system's selection mechanisms. Sorting criteria that could be used to gain access to this conversation include: "closed conversations", domain ("sales"), specific participant and dates of moves.
Table 17 presents an example of a list of conversations sorted according to the domain of possibilities in which conversations have been conducted.
(6d) Example of a Conversation for Action with One Role
Suppose that Dianne initiates a REQUEST conversation in the domain "vacation", selects herself as the "other" participant in the conversation, enters Nov. 1st as the date of completion and Oct. 25th as the date of response. The Coordinator system identifies her move as a "promise to myself", which opens a type of conversation having its own finite state machine. FIG. 9a illustrates this type of FSM.
Once The Coordinator system processes the move, a new conversation record is opened and it shows the conversation to be in the state of promise; a response token is recorded with an associated date of Oct. 25th, and a fulfillment token is recorded with an associated date of Nov. 1st. This conversation will appear among summaries of conversations selected from menus in The Coordinator system with the choice, "missing my response" and also in summaries of conversations selected with the choice, "my promises" (see Tables 1 and 15) It will also appear in the daily calendar on Oct. 25th with the warning, "my response due", and on Nov. 1st with the warning, "my promise due".
If Dianne selects this conversation as one in which to make a move, her options will be: cancel, declare-complete, cancel and make a new promise (cancel/new promise) and interim-report. Suppose that she chooses to make an interim-report. She may indicate a new response date in the communication. If she makes an interim-report the conversation will remain in the same state but the response token will be updated to the new response date, if she assigns one.
Eventually Dianne declares the conversation complete. Then, in the conversation record in her personal computer, the conversational state is changed from open to the state termed "final" and both tokens are removed, since no incompletions remain in the conversation.
As long as the conversation is not purged from Dianne's conversation records she can review it by using The Coordinator system's selection mechanisms. Once in final state, sorting criteria that could be used to gain access to this conversation include: "closed conversations", domain ("vacation"), "conversations with Dianne" and dates of moves.
(6e) Example of a Conversation for Possibilities with One Role
FIG. 9b illustrates the FSM that The Coordinator system uses to manage a Conversation for Possibilities with one role. Suppose Alex makes an opening declaration of a possibility and addresses the conversation to himself and enters Nov. 10th as the date for response.
The Coordinator system identifies the move as an opening in a Conversation for Possibilities with himself. The conversational state in the conversation record begun for this conversation is termed "open". A response token is recorded with an associated date of Nov. 10th. At this juncture Alex's possible moves are: make a new declaration, re-formulate the current declaration and declare the conversation complete.
Should he make a new declaration in the conversation, the conversation would remain in the same state. The response token would be updated whenever a new move included specification of a new date of response.
Suppose Alex eventually declares the conversation complete. Then, in the conversation record in his personal computer, the conversational state is changed from open to the state termed "final" and the token is removed.
As long as the conversation is not purged from Alex's conversation records he can review it by using The Coordinator system's selection mechanisms. At that time, sorting criteria that could be used to gain access to this conversation include: "closed conversations", domain, "conversations with Alex" and dates of moves.
sections f and g
f. Data Associated with Moves
For each type of move, a set of data associated with that move is defined. Below, the data associated with the moves of the three types of conversations defined in the current embodiment are described.
(1) Data Associated with Moves in Conversations for Possibilities
In a Conversation for Possibilities, the initial move, DECLARE A POSSIBILITY OPEN, has the following data associated with it:
(a) identity of participants, including:
identity of requestor
identity of promisor
identities of any observers
(b) domain of possibilities,
where the domain of possibilities of the conversation is the particular name given by the participant to the domain in which the participant will interpret the conversation;
(c) tokens representing the incompletions of the conversation, including data representing:
the type of token ("missing response" or "alert"), and
the data declared for completion of the incompletion which the token represents;
(d) tokens representing declared possibilities, including:
the "possibility" of the conversation, which is the phrase-name given to the declared possibility of the conversation, and
the "text" associated with the move, which includes the specific spelling-out of the declaration of specific realizable possibilities.
Notice that, as a consequence of our employment of conversations as the basic unit of recordkeeping in this methodology, the identities and roles of participants, declaration of domain of possibilities, previous incompletions of the conversation, and previous moves of the conversation, all are defined already in the moment that a participant makes a move after the initial move in any conversation.
Three other moves are permitted in a Conversation for Possibilities, namely:
MAKE A NEW DECLARATION
RE-FORMULATE CURRENT DECLARATION
DECLARE-COMPLETE
In the case of each of the three, the data associated with the move are:
(a) identities of speaker, listener, and any observers
(b) tokens representing the incompletion of the conversation, including data representing:
the type of token ("missing response" or "alert"), and
the date declared for completion of the incompletion which the token represents;
(c) tokens representing declared possibilities, including:
the "possibility" of the conversation, which is the phrase-name given to the declared possibility of the conversation, and
the "text" associated with the move, which includes the specific spelling-out of the declaration of specific realizable possibilities.
(2) Data Associated with Moves in REQUEST Conversations
In a Conversation for Action of the REQUEST type, the initial move, request, has the following data associated with it:
(a) identity of participants, including:
identity of requestor
identity of promisor
identities of any observers
(b) domain of possibilities, where the domain of possibilities of the conversation is the particular name given by the participant to the domain in which the participant will interpret the conversation;
(c) tokens representing the incompletions of the conversation, including data representing:
the type of token ("missing response""missing fulfillment" or "alert"), and
the date declared for completion of the incompletion which the token represents;
(d) tokens representing declared possibilities, including:
the "action" of the conversation, which is the phrase-name given to the action(s) declared in the move for completing a realizable possibility in the conversation, and
the "text" associated with the move, which includes the specific spelling-out of the declaration of action(s) for completing specific realizable possibilities.
Fifteen other moves are permitted in a Conversation for Action of the REQUEST type, namely:
CANCEL
DECLARE-COMPLETE
PROMISE
|
