System for remote microcomputer access and modification of information in host computer

An improved system for communication between a host that keeps and updates information and a microcomputer that accesses, varies or adds to the host information. The microcomputer displays information received from the host and sends information selected or entered by the microcomputer user to the host. A multitude of applications may exist and function on the host and on the micro. A communications network may be used to carry information between the microcomputer and the host. The method provides for switching among physically separated hosts supporting different host applications.

BACKGROUND AND SUMMARY OF THE INVENTION 
the present invention relates to a method of communication between an 
information or service provider and an information consumer. The 
communication consists primarily of requests for "Information Service 
Objects", "Information Service Objects" themselves, and information 
necessary for efficient control of such communications. This interface 
between a Host, having the role of a service provider, and a 
Microcomputer, having a role of a remote information consumer, may be 
called "Host Micro Interface" or HMI protocol. 
A communications network may be used to provide a medium for information 
transfer between any particular information consumer and all the 
information providers he may access. The present invention, HMI uses the 
facilities of this communications network to transfer "information service 
objects" and associated information between these parties. 
Historically, information providers were responsible for preparing the 
information specifically for each user's display. They sent questions to 
the consumer, interpreted his responses, and replied with appropriate 
information as the dialogue proceeded. Information was sent as text 
streams to be displayed as it was received. These streams often contained 
a mixture of displayable characters and display modifying instructions. 
With HMI, the information provider system sends "protocol data units"(PDUs) 
to the information consumer's computer. The information consumer's 
computer application determines what information to display and what 
information to store for later use; it also decides how to display the 
information. Questions may be presented to the user by the computer 
application in the information consumer's computer; they are derived from 
lists of options sent in PDUs from the service provider(s). Responses, 
usually selections, are converted into information requesting PDUs and 
sent to the provider as such. 
Known systems have utilized PDU encapsulation of user specific data. U.S. 
Pat. No. 4,694,397, is specific to exchanges between computers of a 
banking system and a brokerage system, and U.S. Pat. No. 4,506,326, is 
specific to exchanges between computers responsible for maintaining a 
database management system and computers responsible for making inquiries 
of that system and displaying data responses returned from the database 
management system. The present invention is distinguishable from these 
systems in that it defines a multitude of application protocols for an 
ever extensible information system. 
Protocols have been defined and implemented to provide reliable and error 
free exchange of PDUs. These include: XMODEM, Kermet, B Protocol, X.25 and 
X.21. HMI is distinguishable from these in that it is an interface which, 
though it may use these protocols for the purpose they serve, addresses 
application functions and not Network, Data-link and Physical layers. The 
ARPANET (Advanced Research Projects Agency NETwork) is an example of a 
network that supports these lower protocol layers. HMI is unique in that 
it provides an integrated method to switch among applications and PDU 
functions without user interaction. 
There are two main purposes that HMI achieves: (1) provides an efficient 
connection between an end-user and remote-host(s) such that the user need 
not be aware of the actual supporting mechanisms and (2) provides an 
efficient means of conveying requests for information, information flow 
progress and information response components. The remote-hosts need not 
prepare the information for presentation on specific displays. Thus they 
are freed of the associated overhead. Presentation (that is: display) 
details are not sent in HMI; display considerations are the sole 
responsibility of the end-user's application and how the end-user sets it 
up. 
An underlying Transport protocol may be utilized to provide an error free, 
object length independent connection. This may utilize various protocols 
to effect communication between hosts and micros. 
Unlike conventional Session, Application and Presentation protocols, HMI 
protocol uses different PDUs depending upon the direction and purpose of 
information being requested or provided. Also, depending upon the 
capabilities of the remote-host, even the underlying Link and Transport 
protocols may be switched on and off according to instructions from 
packets in HMI. 
Each application may have its own set of PDUs, called a "CompuServe 
Application Protocol"(CAP), named after the assignee corporation of the 
present invention. Every PDU, used in HMI, preferably has a CAP ID number 
and a "Packet Type Identifier"(PTI) number. Every CAP preferably supports 
and makes use of certain "Common CAP PTIs" for frequently used requests 
and responses. 
Common CAP PTIs include: SUCCESS Response, FAILURE Response, TERMINATE 
Request, DATA Response, CANCEL Request, SHUTDOWN Request, DISCONNECT 
Request, EXIT Request, INVOKE-PROTOCOL Request, INVOKE-PROTOCOL Response, 
RESUME-PROTOCOL Request, SUSPEND-PROTOCOL Request, QUOTES-DATA Request, 
QUOTES-DATA Response, RESYNC Request, WAIT Response, TEST Request, WEATHER 
Request, ALERT Request, PROMPT Response and PROMPT Request. 
Within each CAP a large number of specific purpose PTIs may exist. These 
may be stock quote based for financial CAPs or article based for display 
CAPs. The user would not be aware of switching communication links and/or 
protocols that may occur between the remote hosts and the user's 
microcomputer. In this regard HMI is transparent or hidden to the user.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT(S) 
Without HMI, the procedure for a user to receive a local weather report may 
consist of the steps shown in FIG. 1. With HMI, both the user involvement 
and the amount of information passed between the user's micro and the 
information providing system are reduced. To view the same weather report 
with HMI, the steps illustrated in FIG. 2 take place. 
From these examples, it is apparent that with the present invention the 
host, the communications network and the user all have significantly less 
to do to select and view data. Much of this can be credited to the 
intelligent application running on the micro. This "Information Manager" 
is responsible for maintaining communications with the host, for keeping 
track of data it has received from the host, displaying appropriate data 
and, providing selections to the user. 
FIG. 3 is provided as a simplified example of the use of HMI to access a 
remote host, retrieve selected information from one service, retrieve 
information from another service, return to the first service and exit the 
services. It sequences through modem dialup, logging onto a host, starting 
HMI, going to a service, asking for information, going to a different 
service, asking for other information, returning, logging off, and finally 
disconnecting. 
The type and form of the information passed in the START-ARTICLE READ 
request (within DAP, Display Application Protocol) and request XXX info 
sequences (within the new CAP) is CAP and application dependent. Each CAP 
uses the common PTIs (numbered 1 through 30) and its unique PTIs (numbered 
above 30). The format in which the information is sent between the host 
and the user is in CAP packets. The way the information is presented 
(displayed) on the user's micro is entirely up to the HMI application 
running on the user's micro. 
The micro may ask for information from the host and receive it as a stream 
of packets faster than the micro is presenting them to the user. It is up 
to the application on the micro to determine when and how to display this 
data. 
Articles, menus, and other data items are preferably labelled with page 
numbers. This enables efficient recall of previously received items as the 
micro remembers them. This technique is preferred unless the specific data 
has received a PAGE-INVALID request for a saved page. 
The micro may send CONTINUE-ARTICLE-READ Request PDUs to cause it to 
receive information that it may not display immediately. Depending upon 
the user's desires, such pre-received pages may be discarded, viewed now, 
or viewed at a later time. This requesting ahead of displaying is an 
effective way for rapid display advancing without waiting for data. If the 
micro keeps track of such pages, it may recall them from its memory; 
otherwise it may have to request them from the host again. 
For added versatility and efficiency, string data (contained in many PDUs) 
is usually compacted. This may be switched off and on. Also, extended 
8-bit data compaction may be enabled and disabled. These are selected in 
"Initiate Application Protocol" escape sequences. 
When the host application does not support HMI, but uses only ASCII 
terminal protocol, the sequence shown in FIG. 4 is used (starting from 
within DAP). 
Micros may support several CAPs. If they do so, they may support requests 
and responses from multiple CAPs concurrently. Each CAP may have a 
different display application on the micro as needed. Table I contains a 
list of CAPs and their numbers. 
Within each CAP, the Common PTIs (numbers 1 through 30) are shown in Table 
II. Within any given CAP, except where not appropriate, the common PTIs 
may be sent and received as requests and responses without disrupting 
normal operation of the application. For example, stock quotes and weather 
may be requested and received from within the ENS (Electronic New Service) 
CAP. Within the ENS, news item are collected from various source and saved 
in virtual clipping files. 
The present invention may be implemented on an information service with the 
following components: 
a modem for communications over a telephone line between a microprocessor, 
serving an end-user, and a communications network node; 
a communications network providing error free exchange of characters 
between the node and a multitude of server host computers; 
an end-user microprocessor with a random access storage mechanism, an 
instruction sequencing controller with a stored instruction sequence, a 
user display mechanism capable of presenting selections and information to 
an end-user, and an input mechanism capable of receiving end-user 
selections and making them available to the instruction sequencing 
controller; 
a first server host capable of receiving and sending characters from and to 
the communications network. Said characters originating and terminating at 
the modem mentioned above; 
a validating program, that runs on the first server host and exchanges 
sequences of characters, using the communications network, with the end 
user's microprocessor and authenticates the validity of the end-user based 
upon a "login database;" 
a program on the first server host that, upon recognizing that the end-user 
micro has asked for HMI to be used, sends a sequence of characters to the 
micro requesting a corresponding reply list of characters indicating what 
CAPs the micro can process. When such a reply is received, the first 
server host may send a sequence of characters through the communications 
network to the micro requesting the micro to enter into DAP. If said 
program receives an acknowledgement that the micro has entered DAP, it 
will start Transport protocol; 
a stored program in the end-user processor with instructions to send valid 
login sequences through the network to the first server host such that a 
request to use HMI is known. Said stored program supports DAP and 
Transport protocol. Instructions to cause the micro to reply to character 
sequences that request lists of CAPs and/or to start instructions for DAP 
are also stored in the end-user micro program. An Information Manager 
Program (IMP) may be stored as the instruction sequence to effect 
necessary HMI protocol exchanges with the other components; 
program routines in the first server host to perform DAP sufficiently to 
facilitate requests from the micro to perform all "Common CAP" functions. 
If a GET-PAGE request is received from the micro and the specified page is 
not on the first server host, the first server host must have routines to: 
send SUSPEND-PROTOCOL request and cause a network transfer to a second 
server host also attached to the communications network; 
IMP may have routines to suspend and resume protocol in response to PDUs 
with the appropriate PTIs to request such. For every CAP it might request, 
IMP has appropriate instructions to properly process request and response 
PDUs from the server hosts; 
IMP may have routines to prepare for presentation and to display data 
received as a result of end-user selection; and 
a second server host is prepared to accept transfer requests from micros, 
enter requested CAPs specified in GET-PAGE requests, and resume transport 
and HMI protocols. As of this event, the second server host may facilitate 
all the functions of the first server host described above. 
These components may operate in harmony with an end-user at the micro and 
information-administrators at the server hosts. When IMP first determines 
that it needs to access a server host to preferably perform a user 
selected request, it preferably performs the following steps: 
uses the modem to dial one of the local node ports on a network, then 
communicates with the answering node to establish a network connection to 
a first server host; 
sends and receives sequences of characters with the first server host to 
establish the user's identity, authenticate the user, request that HMI 
protocol be used and start the Information Service "top" page program; 
when IMP receives an interrogation sequence of characters from the "top" 
page program, running in the server host, sent through the communications 
network and the modem, it responds with sequences of characters indicating 
which CAPs it supports. When it receives the sequence of characters 
instructing it to start DAP and Transport protocol, IMP acknowledges that 
it will and does so; and 
IMP next sends a GET-PAGE request for the page it has determined has the 
service needed by the user. 
If IMP receives, from the "top" page program on the first server host, a 
SUSPEND-PROTOCOL request: it ceases DAP and Transport protocols. When it 
receives the interrogation sequence of characters, it responds with 
sequences of characters indicating which CAPs it supports. When it 
receives the sequence of characters instructing it to resume Transport 
protocol, IMP acknowledges it will and does so. 
Once the appropriate server host and protocol is running on the host and 
micro, the following takes place: 
An INVOKE-PROTOCOL request is received by IMP. IMP responds with an 
INVOKE-PROTOCOL response (provided it supports the specified CAP); 
IMP sends a START-READ request to the server host. If it receives a DATA 
response PDU, it collects the data and preferably decompresses it for 
presentation to the user as appropriate. IMP may format and display parts 
of the collected data while it is receiving more from the server host. IMP 
sends CONTINUE-READ requests and processes DATA responses similarly until 
it is stopped by one of the following: 
it receives an END-DATA response from the server host. At this point it 
formats whatever data it has collected and displays it; 
IMP decides to cease asking for data until it has displayed sufficient 
amounts of the information to decide to ask for more; or 
the user indicates that he does not want to view any more of the data. 
If the user selects, from what IMP has displayed, an item that implies that 
a GET-PAGE request may be called for, it first checks its storage to see 
if it has collected the page earlier. If it has, it performs whatever 
actions it would upon receiving it. If it hasn't, it sends a GET-PAGE 
request to the server host and the above page access steps are performed. 
When the user determines it is appropriate to disconnect from the 
Information Service, he may select the appropriate icon on the IMP screen. 
IMP sends a SHUTDOWN request to the current server host. IMP will receive 
a DISCONNECT request from the server host and perform appropriate actions 
to hang up the phone via the modem. 
The preceding description alludes to START-READ and CONTINUE-READ requests 
and to DATA and END-DATA responses. The details of actual operation in 
specific CAPs vary. The following details apply to the ENS CAP. Refer to 
Table III for packet types unique to ENS. Refer to Table II for common 
PTIs. 
When the page for ENS is entered via any required access steps, an 
INVOKE-PROTOCOL request and an INVOKE-PROTOCOL response, the end-user 
micro and server host are running their respective ENS application 
programs. It is up to the program on the micro to send the host a 
GET-CONFIG Request. The CONFIGURATION Response, that the host may reply 
with, contains the PDU in FIG. 5. The micro then sends an AGREEMENT 
request PDU to confirm agreement with the data it received in the 
CONFIGURATION Response PDU. The host will reply with a SUCCESS or FAILURE 
PDU. 
At this point the micro sends a GET-FOLDER-OVERVIEW Request packet with the 
form shown in FIG. 6. It receives a FOLDER-OVERVIEW response PDU that 
contains the fields shown in FIG. 7. 
If both user and public folders are determined to be available from the 
CONFIGURATION Response PDU, the micro may make an additional 
GET-FOLDER-OVERVIEW Request to receive a FOLDER-OVERVIEW response 
supplying the other set of folder records. At this point IMP displays the 
names of the folders it was informed of. It also shows the number of 
stories in each. It will react to user selections that select one of the 
displayed folders, and send a START-FOLDER-SEARCH Request for the selected 
one. This PDU is shown in FIG. 8. For ENS user folders, Search Type 0 
(All) is chosen. The reply that comes back from the host may be a 
FOLDER-SEARCH Response PDU shown in FIG. 9. 
IMP displays the titles of the received FOLDER-SEARCH response. IMP offers 
the user options to select a story or to search further. When the user 
chooses the latter, IMP sends CONTINUE-FOLDER-SEARCH Requests of the form 
in FIG. 10. 
If the host has additional stories it will reply with FOLDER-SEARCH 
Responses as it did with the first FOLDER-SEARCH Request. If the host has 
exhausted the search, it will reply with a FOLDER-SEARCH Response with a 
zero count. 
When the user selects a displayed title to be read, IMP sends a 
START-STORY-READ Request with the information illustrated in FIG. 11. If 
the story number is appropriate, IMP will receive DATA Response packets 
from the host as shown in FIG. 12. IMP displays the story as full screens 
of it become available. If the user and IMP elect to do so, IMP will send 
CONTINUE-STORY-READ requests shown in FIG. 13. IMP will receive DATA 
response PDUs in response to CONTINUE-STORY-READ requests until a DATA 
response with zero length is returned. 
IMP provides a way for stories in user folders to be deleted. This option 
is offered to the user both when the story title is displayed and when the 
story has been received. If the user selects deletion of a story, IMP 
sends a DELETE-STORY Request to the host. The form of this PDU is shown in 
FIG. 14. IMP preferably deletes one story at a time. Thus, the count is 
always one. IMP receives a SUCCESS Response when the story has been 
deleted. 
The following details apply to the EMP CAP. Refer to Table IV for PTIs 
unique to EMP. Refer to Table II for common packet types. 
When the page for EMP is entered via the required access steps, an 
INVOKE-PROTOCOL request and an INVOKE-PROTOCOL response, the end-user 
micro and server host are running their respective EMP application 
programs. It is up to the program on the micro to send the host a 
READ-CONFIG Request as in FIG. 15. The CONFIG Response, that the host 
replies with, contains the PDU in FIG. 16. 
At this point the micro sends a SEARCH-MSG Request packet with the form 
shown in FIG. 17. To get all messages: num.sub.-- terms will be patter 
one, type will be set to Unread and pattern gets set to null. It receives 
a MSG-SUMMARY response PDU that contains the fields shown in FIG. 18. IMP 
displays the subjects and originator.sub.-- names from the MSG-SUMMARY 
response and waits for the user to select one to be read. 
When the user indicates which message to read by pointing to its subject 
and choosing "read" from the displayed menu, IMP sends a READ-MSG-HEADER 
request containing the desired message number (see FIG. 19) and receives a 
MSG-HEADER response from the host with appropriate details (see FIG. 20). 
IMP next sends a READ-MSG-CONTENTS request (see FIG. 21) and receives a 
DATA response (see FIG. 23). IMP continues to send READ-MSG-CONTENTS 
requests and receive DATA responses from the host until a DATA response 
with a zero length data segment is received. 
An improved transfer method may be achieved by asking for the message to be 
sent to the micro using "push" style transfers. This is done by requesting 
the contents with a RECEIVE-MSG-CONTENTS request as shown in FIG. 22. When 
push style transfers are used, the host sends DATA response PDUs to the 
micro as fast as the underlying protocols and IMP can convey them. As with 
READ-MSG-CONTENTS requests, the last DATA response PDU will contain a zero 
length data segment. 
The MSG-HEADER response may indicate a type.sub.-- of.sub.-- contents as 
Text; in this case IMP will display the DATA responses in a reformatted 
text window on the micro's screen. However, the MSG-HEADER response may 
indicate a type.sub.-- of.sub.-- contents as JPEG data; in this case IMP 
will give the user the choice of viewing or downloading the data. When 
viewing is selected, IMP converts and displays the DATA responses in a 
graphics window. When downloading is selected, the DATA responses are 
collected in a file of the user's choosing. 
The following details apply to the FAP (Forum Application Protocol) CAP. 
Within the FAP, transactions are performed between an end-user application 
and remote bulletin board subscribers. Refer to Table V for PTIs unique to 
FAP. Refer to Table II for common packet types. 
When the page for FAP is entered via the required access steps, an 
INVOKE-PROTOCOL request and an INVOKE-PROTOCOL response, the end-user 
micro and server host are running their respective FAP application 
programs. It is up to the program on the micro to send the host a 
READ-CONFIG Request. The CONFIG Response, that the host replies with, 
contains the PDU in FIG. 24. IMP uses last.sub.-- access and last.sub.-- 
msg.sub.-- read as well as the msg.sub.-- sections data in future 
Requests. 
IMP now sends a GET-MSG-COUNTS Request PDU (FIG. 25) to the host with the 
msg.sub.-- sections and last.sub.-- msg.sub.-- read obtained from the 
CONFIG-RESPONSE. The MSG-COUNTS Response PDU (FIG. 26) returned by the 
host tells IMP how many new.sub.-- threads and new.sub.-- msgs are in each 
section. 
At this point the micro sends READ-MSG-SECTIONS Request to the host. The 
host replies with a MSG-SECTIONS response PDU of the form shown in FIG. 
27. The micro uses the information returned in the MSG-SECTIONS Response 
PDU along with the counts obtained earlier to display a menu of 
section.sub.-- ids for the user to select among. 
The user may select a section to read and the micro will send a 
START-MSG-SEARCH Request PDU shown in FIG. 28 specifying the selected 
section and the start.sub.-- msg remembered from the MSG-COUNTS Response 
PDU. Also, the number of new messages and subject text are requested. 
The host replies with a MSG-SUMMARY Response PDU containing summary records 
for all messages found. FIG. 29 illustrates the format of this PDU. IMP 
displays subject.sub.-- text and new.sub.-- msgs obtained from this 
MSG-SUMMARY and gives the user the choice of reading or getting a map for 
each message. 
When the user picks a thread to read, IMP sends a READ-MSG-HEADER Request 
with the appropriate message number (see FIG. 30). The host will reply by 
sending a MSG-HEADER Response PDU as shown in FIG. 31. IMP then sends the 
host a START-BODY-READ Request PDU (FIG. 32) to which the host replies 
with a DATA Response PDU (FIG. 34). If the user wants to view more of the 
message, the micro sends CONTINUE-MSG-BODY-READ Requests (FIG. 33) and 
receives DATA Responses until the entire message has been transferred to 
the micro. 
When the user tells IMP to get a message map, the micro sends a READ-MAP 
Request PDU (FIG. 35) with the msg.sub.-- no of the selected message and 
specifying that originator.sub.-- names, recipient.sub.-- names, parents 
and next.sub.-- siblings are desired. A "map" is a visual representation 
of the relationships of one message to other messages. Relationships 
indicating "originating" message, "child" messages, "parent" messages, 
"sibling" messages as well as "recipients" can be shown much like a 
"family tree". 
The host responds by sending as many MAP Responses (FIG. 36) as required to 
completely detail the information asked for in the MAP Request. The micro 
uses the total.sub.-- count field to recognize when the end is reached. 
IMP displays this as a tree allowing the user to select messages based on 
location in the map. If the user selects a place in the map, the micro 
sends READ-MSG-HEADER, a START-BODY-READ and CONTINUE-MSG-BODY-READs to 
obtain the message as described earlier. 
The foregoing description of the invention is illustrative and explanatory 
thereof, and various changes in the details of the above described 
preferred embodiment may be made by those skilled in the art without 
departing from the spirit of the invention.