[19]
`United States Patent
`4,805,134
`[451
`C310 et a1.
`Date of Patent:
`Feb. 14, 1989
`
`Patent Number:
`
`[11]
`
`[54] ELECTRONIC SYSTEM FOR ACCESSING
`GRAPHICAL AND TEXTUAL
`INFORMATION
`
`[75]
`
`Inventors: Seraphin B. Calo, Peekskill;
`Krishnamurthi Kannan, Yorktown
`Heights; Suk S. 800, Mount Kisco;
`Thomas G. Burket, Pleasantville;
`John W. Wiley, Jr., Yorktown
`Heights, all of NY.
`
`[73] Assignee:
`
`International Business Machines
`Corporation, Armonk, NY.
`
`[21] Appl. No.: 817,389
`
`[22]
`
`Filed:
`
`Jan. 9, 1986
`
`[51]
`[52]
`[581
`
`[56]
`
`GOGF 13/00
`Int. Cl.‘
`
`US. Cl. .................................................... 364/900
`Field of Search
`364/200 MS File, 900 MS File;
`358/85, 86, 142; 370/89, 86, 90, 60, 58, 54, 85,
`103, 104; 340/717, 721, 711, 703, 797; 379/94,
`221, 40, 50, 200, 100, 94, 96
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`6/1982 Guillou ............................... 358/114
`4,337,483
`
`6/1982 Chambers
`358/147
`4,337,485
`
`4,379,947 4/ l 983 Warner ................ 179/1
`4,479,196 10/1984 Ferret et al.
`364/9“)
`
`4,533,943
`8/1985 McNamara et a1.
`...... 358/86
`
`4,555,781 11/1985 Baldry et a1.
`.. 370/60
`
`4,649,533 3/ 1987 Chorley et a1.
`.. 370/58
`..
`
`4,691.340 9/1987 Maeda et a1.
`379/96
`
`OTHER PUBLICATIONS
`
`Kumamoto et al. “Captain System.” Japan Telecommu-
`nication Review (Jul. 1980), pp. 215—222.
`Marti et al. “The Antiope Videotex System.” IEEE
`Transaction on Computer Electronics, vol. CE—ZS, No.
`3 (Jul. 1979), pp. 327-333.
`Robinson et a]. “Touch-Tone Teletext a Combined
`Teletext—Viewdata System.” IEEE Transactions on
`Computer Electronics, vol. CE—ZS, No. 3 (Jul. 1979),
`pp. 298-303.
`J. P. Gray, “Network Services in Systems Network
`Architecture," IEEE Transactions on Communications,
`vol. COM-25, No. 1, pp. 104—116, Jan. 1977.
`
`Primary Examiner—David Y. Eng
`Assistant Examiner—Robert B. Harrell
`Attorney, Agent. or Firm—Thomas P. Dowd; Marc D.
`Schechter
`
`[57]
`
`ABSTRACT
`
`An architecture for the implementation of an informa-
`tion utility for accessing information and executing
`transactions on an interactive basis between Videotex
`databases and individual end user terminals, some or all
`of which may be remotely located with respect to each
`other. The utility may be associated with a Videotex
`Application Network (VAN) and includes a combina-
`tion of distributed, semiautonomous Operations Nodes
`(0N3), each characterized by (1) one or more affiliated
`users, (2) the inclusion of some form of database, and (3)
`one or more customized application programs, and each
`is also capable of “standalone" operation. Each data-
`base comprises pages of control information and dis-
`playable data. Each node comprises a directory of data-
`bases at other nodes.
`
`50 Claims, 12 Drawing Sheets
`
`C outrun
`' mm mm
`m 0
`I
`mm svsmt
`OPERATIONS
`OPERATIGIS
`not):
`MOE
`
`an
`
`CABIE TV
`
`M mm
`MRATIONS
`m
`
`VAN
`
`OTI'ER
`[‘Im INTERFACE
`OPERATIONS
`MOE
`
`ESTABLISO'IEIIT
`OPERATIONS
`MOE
`
`TON O.-
`
`DMCTW
`DAT“
`
`TERMINAL
`OPERATIONS
`m
`
`.
`DATABASE m '
`OPERATIONS
`arms:
`non:
`
`.
`ESTABLISHED" m '
`MTIPLE
`MRAIIWS
`ll
`OHM
`ORGANIZATION
`"°°‘
`can» av
`OPERATIONS NOW
`
`m
`
`DATAEASE
`
`mm...
`
`®®
`
`1.3
`
`@ ®
`
`Amazon EX. 1007
`
`IPR Petition - USP 7,827,587
`
`Page 1
`
`

`

` .m-53.255335.;:59:FIE23532'oo.muaan8353§H.323.3(5)qu
`5385333mam;em56.
`
`
`
`«gangs'a.3333aw0‘9asM,
`
`:a$2553so:“82So:I.
`
`
`
`1@35635.3.:9555.392:53mzozsmaoZ:98
`
`wig22:5833
`
`
`~82.II
`
`
`
`
`
`
`3222323892:58 33:3.2oEE1so:92:“qu32.d3AAg
`
`
`
`1wax:95.25%52:2.3:55.éofiuuw..525.2358zp
`S“82
`
`US. Patent
`
`h
`
`4,805,134
`
`“SB:ggar:3335:3
`
`Page 2
`
`

`

`US. Patent
`
`Feb. 14,1989
`
`Sheet 2 of 12
`
`4,805,134
`
`Database. Network
`and Transactional 4— 20
`
`Machine (HOST)
`
`22 ————93
`COMMUNICATlON CHANNEL
`Subsystem“)
`
`4—— 2|
`
`Distribution
`
`4——23——+
`
`Terminal Population connected via dial-up or
`
`local area network
`
`Overall Architecture of a. Videotex Operations Node.
`
`FIG. 2
`
`Page 3
`
`

`

`US. Patent
`
`Feb. 14,1989
`
`Sheet 3 of 12
`
`4,805,134
`
`F I G . I 3
`
` HOST
`370 CLASS MACHINE
`
`
`
`
`
`
`
`
`
`TAPES
`
`
`
`
`d TELECOM
`
`
`SERIES/I
`
`
`
`CONTROL
`
`UNIT
`
`TERMINAL
`ENTROLLER
`
`TERMINALS
`
`
`
`
`Example Hardware Configuration for an ON Host
`
`Page 4
`
`

`

`US. Patent
`
`Feb. 14, 1989
`
`Sheet 4 of 12
`
`4,805,134
`
`
`
`«urchmau¢|—‘V98:55.5
`
`
`
`Ex225525:flllv“8..I
`
`um<a<p<=
`
`pzzu<z<zNM
`
`
`
`5552a3:8.fix
`
`5.5.5555
`
`mm
`
`mz_x¢olhuz
`
`w¢<zhmom
`
`2:3m>ma:
`
`3:223:93
`33334.33,
`
`20:39.52:
`
`.8.:3.:2ES.“so:
`
`
`zo_hu<mz<¢._.mmzmhm>mm2mAII;mzo;<¢wmomm
`
`
`
`
`
`Eco—Suzhou0385:.5503953:33:83-20.0Ecmcozsum.V.omI.—
`
`
`
`
`
`Page 5
`
`
`
`
`

`

`US. Patent
`
`Feb. 14,1939
`
`Sheet 5 of 12
`
`4,805,134
`
`HOST Control Blocks Built
`
`at Initialization
`
`
`
`
`Cache Ngmt
`Structures
`
`Task Control Blocks
`
`
`
`
`
`Hork CBS
`l per agent
`
`EPATABLE entrys
`
`System Control Flgs
`
`
`
`
`
`XnOI—GD-GDUr-pcaorm
`
`
`
`
`
`
`
`
`
`
`
`
`Scheduler Q anchors ‘
`
`
`
`Resource Control Table
`
`Active Element Data
`
`
`
`Global Data Block in an ON Host
`F I G e 5
`
`TRANSACTION APPLICATION SUSSYSTEM (TAS)
`
`Initiator
`
` Transaction
`Subsystem
`
`F IG . 6 Overview of Transaction Application Subsystem
`
`Page 6
`
`

`

`US. Patent
`
`Feb. 14, 1989
`
`Sheet 6 0f 12
`
`4,805,134
`
`
`
`Auc4<_azo_hu<mz<¢h.was”gum:
`
`
`
`
`
`
`
`uanc_Law::0»;
`
`
`
`uzac_mo>_uuoL
`
`co_HUMmanuN:0
`
`
`
`yawnxp>ouwuhu
`
`cueunuchucu
`
`.umua
`
`.Lo__ou
`
`vcucuVLQILOm
`
`._Q:_E.0uLon:
`
`
`
`uncommobaunhuxo
`
`
`ovum:nnEuancm:
`
`
`:_nun—anuuu
`
`
`
`«manumvucucufigonLO
`
`qu50m__03UgOHm
`
`use“c.omunXh>
`
`coonxh>In:u._:n
`
`
`
`
`new:>_&azuco:
`
`a.»
`
`¢_h
`
`¢_h
`
`¢.h
`
`¢.h
`
`xo_bu<mz<xh
`
`mudmxmhz_
`
`wwz_h:ox
`
`.*.¢<z>u¢
`
`mmuuoha
`
`o__u>Econe
`
`.wu<¢»uu.uga4_=o
`
`Mann>Ecan.
`cauv_>o.muu<g¢o»m
`
`ucu¢<t>u¢.g<tazum
`
`ILu>oa:nun
`
`
`
`aweurea>n_
`
`
`
`:u_zucom...
`
`
`
`vunE_mm4a<z
`
`....¢<:azum
`
`comuao
`
`
`
`gum:agoyou
`
`Annevm<t>ux
`
`.omcoamu.
`
`oncoamug
`
`D>flm...
`
`mmuuogn
`
`
`
`DonnumEmcxu
`
`mu<mm¢0hm
`
`«mouoLa
`
`uma4_:¢
`
`cumc_sguu
`
`«muuoga
`
`co_uunmcmhuozu>n
`
`
`
`tum:unu_>uomxuu
`
`.Emgmoga
`
`
`
`95.50:3..on3:03anoifiamN.O—m
`
`
`
`
`
`Page 7
`
`
`

`

`US. Patent
`
`Feb. 14, 1989
`
`Sheet 7 of 12
`
`4,805,134
`
`TRANSACTION SESSION MANAGEMENT CONTROL STRUCTURES
`
`Host Anchor Point
`I
`
`COMMON STORAGE AREA (multipIe regions)
`
`
`SSBLOCK
`TAS TABLE
`ASCB AODR
`
`
`VSHPTR
`SUBID
`
`ECB AODR
`
`GLOBPTR -—
`
`QCHS/FLGS
`
`
`TASTPTR
`
`ADDRESS SPACE
`ADDRESS SPACE
`
`
`
`
`
`
`
`
`TAS GLOBAL
`DATA AREA
`
`
`
`HDRK AGENT
`REQUEST
`BLOCK TBL
`POINTER
`
`
`
`REQUEST
`BLOCK ENTRY
`
`TAB/ON
`
`RCT SEGMENTS
`
`RCTPTR
`
`trans entry
`
`trans entry
`
`DAC -—§OB entry
`
`SAC —>user entry
`
`
`
`
`
`
`_caADDR
`SA—lou
`
`
`
`
`
`
`
`Overview of Transaction Data Areas
`
`FIG. 8
`
`Page 8
`
`

`

`US. Patent
`
`900w
`
`1_b.“no:3:3.v57a33R.mELCQSéu
`
`
`
`4",mun“._I:O_un_ugnun»:cozuumpi:
`DH.m»
`
`T_
`
`
`
`zoxuqmvcuzoxqu05¢mLoqum;~g
`
`zm__nnHmm
`
`cuumugcu
`
`
`
`
`
`Eoumxmnzmco_u:n_.um_osong
`
`
`
`
`
`oumnmmmuutu<w<hounawmmohut<hmoz20
`
`In0SmOHMEcum>m
`...o=__co:3:032“:
`
`
`
`
`
`run»manhutlus:mum
`
`8
`
`4,805,134
`
`:552:23:452_H”acum<
`
`150:duguLMum03x5:unsuumcou
`
`
`
`
`
`xou00u_>can“.gown:
`
`
`
`«chum::quU
`
`Bo."—uficx—5:08:8923m
`
`57a82
`
`Page 9
`
`
`

`

`US. Patent
`
`Feb. 14,1989
`
`Sheet 9 0f 12
`
`4,805,134
`
`To/From Host Machine (20}
`
`channel (22)
`
`channel attachment feature
`
`
`2i
`Processor
`—
`
`
`
`SlZKB - 102MB storage
`
`
`4—. diskette
`
`4—9 disk
`
`i/O controller
`
`terminal 4——b
`
`I/O controller
`
`FIG.1O
`
`userterminalslfil
`
`Example Distribution Subsystem Hardware Environment
`
`To/From Distribution Subsystem (21)
`
`asynch ronous line
`
`line controller
`
`4—. diskette
`
`e—o disk
`
`color <—
`monitor
`
`256KB or more storage
`
`25
`
`
`
`
`
`keyboard
`
`monochrome monitor
`
`F I G °
`
`1 2 Example Hardware Configuration for End-User Interface.
`
`Page 10
`
`

`

`US. Patent
`
`Feb.l4,1989
`
`Shafl100f12
`
`
`:o:o~__o.:=H35.5:o:
`
`
`Ea.oo.am;0.u:m:lag;
`
`
`>u.>_uu<All!uu_>.um
`ww—thUUNLF
`no;CNF
`
`soLmoLa
`
`woo.AIVLow:
`
`w_uc_ELuu
`
`my:2
`
`
`
`vEuuno:All'_occn;u
`
`ugonaam
`
`nunuu<
`
`m:
`
`
`
`cuuuu<.uchLQ
`
`E05005;
`
`
`
`
`
`uu_>uv:UMuuu—uccm:u
`
`uu:uELOmLo¢
`
`Lo~_:o:
`
`goumguao
`
`Engmohm
`
`
`
`auan*mn=w=o_u=a_.um_=
`
`
`
`lu_>;u>oogulquM
`
`2.0:
`
`hmo:cu
`
`:<xuoaaaozpzou>aoma_>oagmmu_>xww
`
`Page 11
`
`
`
`
`
`
`
`

`

`US. Patent
`
`Feb. 14,1989
`
`Sheet 11 of 12
`
`4,805,134
`
`Application Hanager
`
`
`
`
`132
`
`153
`
`Dispiay functions
`
`._, NAPLPS
`decoder
`
`
`
`
`
`
`keyboard
`i
`4——-D Screen
`
`
`
`151
`
`134/
`
`t
`
`110
`
`l/O Controller Subsys
`
`i
`
`
`
`Graphics Support
`
`
`
`
`
`monitor
`Distribution Subsystem
`___._-—__—————__—_—---——---_——-——---
`
`S E R V i
`
`C
`
`E S
`
`P R 0 V I
`
`D E D
`
`B Y
`
`E 0 N T R 0 L
`
`P R 0 G R A H
`
`Software Configuration for End-User Terminal
`
`FIG. 13
`
`Page 12
`
`

`

`US. Patent
`
`Feb. 14,1989
`
`Sheet 12 of 12
`
`4,805,134
`
`1/0 Receiver
`Task
`
`Q
`
`140
`
`f_.
`
` [/0 Service
`
`Manager
`
`Task
`
`
`
`Hardware and Operating System
`
`F I G .
`
`1 4 IOCS Structure on the End-User Terminal
`
`,14111
`
`Interrupt handler
`and
`Cp interface
`
`<—-——> Screen Mgr
`
`/
`
`131
`
`150/
`Key Defs
`<——-— Tab1e
`
`commands and field
`data
`
`msgs +
`help
`
`and
`
`,151
`
`Window Hanager
`
`
`
`Character
`fonts
`
`
`
`
`
`
`152
` y/
`
`Command Parsing
`
`
`Command Handlers
`
`
`
`110
`Communications «*1
`Layer
`(1065)
`
`
`
`153
`
`
`
`154
`
`155
`
`F I G .
`
`1 5 Keyboard Processing on the End-User Terminal
`
`Page 13
`
`

`

`1
`
`4,805,134
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`2
`customized application programs. Each node is also
`capable of “stand alone" operation, that is, it can service
`the needs of its user population and need not be con-
`nected to any other node.
`A typical Operations Node with end-user terminals,
`which may be referred to as an Establishment Opera-
`tions Node (EON), supports a unique user interface
`through which users get controlled and secure access to
`a wide variety of databases stored locally and/or re-
`motely. Through this node, users may also interact with
`a large number of application programs distributed over
`the entire VAN which provide additional and special-
`ized services to users of the node. The user interface,
`the mechanisms for secure access to information, and
`the application environment supported by the ON are
`important features of the invention.
`Provision is made for Operations Nodes to be
`adapted to special functions within the network. For
`example, while a typical node may consist of a system
`with one or more databases and end user terminals
`(EON), another node may consist only of specialized
`databases (DON) maintained by information providers
`(IPs) without end users or application programs. Simi-
`larly, a third node may merely consist of a directory
`databasee with a number of unrelated end user terminals
`(TON). An operations node may be configured with a
`directory database and just a set of application pro-
`grams providing services to users on the network
`(PON). A number of small inhouse users may cooperate
`to form a multiorganization node (MOON) and special
`nodes may be formed to handle access to other net-
`works (NON) or to interface with third party databases
`(ION). Finally, an Operations Node may assume the
`role of a Systems Operations Node (SON) which main-
`tains a global directory of databases and application
`programs available at various nodes and may act
`to
`supervise and coordinate the interactions and opera-
`tions of all the nodes in the system. In all, the applica-
`tion architecture and specific implementation disclosed
`offer valuable capabilities and services to end users.
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`ELECTRONIC SYSTEM FOR ACCESSING
`GRAPHICAL AND TEXTUAL INFORMATION
`
`BACKGROUND OF THE INVENTION
`
`The present invention relates to electronic informa-
`tion and communication systems and more particularly
`to a combination of operational nodes incorporating
`databases and application programs
`for providing
`graphical and textual information (Videotex) and trans-
`actional capabilities to end-user terminals connected
`thereto.
`A Videotex service is a medium for conveying infor-
`mation electronically in an effective, user friendly, and
`relatively inexpensive manner to a large user popula-
`tion. It combines color, graphics and text in a single
`display to provide an attractive presentation of informa-
`tion to experienced as well as novice users. It is assumed
`that as its popularity increases the majority of users,
`while not being trained in data processing, will be inter-
`ested in using it for message exchange and transactional
`activities, in addition to using it to access a wide range
`of information bases. Experienced users will generally
`wish to obtain specific information in a quick and direct
`fashion while novice users will tend to browse through
`databases trying to determine the value of the informa-
`tion being offered.
`First and second generation Videotex services have
`tended to be limited both in the range of information
`bases offered and in the ability of the system to cater to
`the capabilities of a wide range of end-users. 0n the
`other hand, Data Processing Networks, such as the
`IBM VNET and the XEROX ETHERNET, have been
`developed to improve and integrate communication
`between and among individual computer terminals and
`databases. However,
`these networks essentially are
`either in-house, local area systems wherein the majority
`of the operating devices, work stations and data bases
`are proximately disposed, such as within an office or a
`plant, or are non-interactive and provide for a file trans-
`fer mode of operation.
`Other networks such as the IBM Information Net-
`work (IN) and IBM’s PVM systems do provide on-line
`interactive sessions between centralized data processing
`machines and their users who may be located remotely.
`However, these networks do not offer the consistent
`and easy-to-use interfaces for which Videotex services
`are well known.
`With the increasing growth in large, centralized spe-
`cial—purpose databases along with integrated individual
`compact work stations capable of handling information
`presentations in color, graphics, and text (Videotex), the
`desirability of developing an extended architecture to
`foster cooperation among a wide range of remotely
`located terminals and databases has become manifest.
`
`SUMMARY OF THE INVENTION
`
`The present invention involves an architecture for
`and the implementation of an information utility for
`accessing information and executing transactions on an
`interactive basis between Videotex databases and indi-
`vidual end user terminals, some or all of which may be
`remotely located with respect to each other, A Video-
`tex Application Network (VAN) toward which the
`invention is directed includes a combination of distrib-
`uted, semiautonomous Operations Nodes (ONs), each
`characterized by (1) one or more affiliated users, (2) the
`inclusion of some form of database, and (3) one or more
`
`45
`
`50
`
`55
`
`65
`
`FIG. 1 illustrates a Videotex Application Network
`(VAN) in which the present invention may be imple-
`mented and various configurations that an Operations
`Node may assume.
`FIG. 2 shows the overall architecture of an Opera-
`tions Node (ON) in accordance with the present inven—
`tion.
`FIG. 3 is an example of a hardware and software
`configuration for an 0N host.
`FIG. 4 shows the relationship of ON—specific soft-
`ware to other exemplary components that may exist on
`an ON host.
`FIG. 5 illustrates the global data structure in an ON
`host.
`
`FIG. 6 is an overview of a Transaction Application
`Subsystem (TAS).
`FIG. 7 is an outline of a sample application program
`running under TAS.
`FIG. 8 is an overview of the transaction data area
`maintained by an ON host
`FIG. 9 details the logic involved in starting an appli-
`cation program on the host.
`FIG. 10 is an example of the hardware involved in
`implementing the distribution subsystem.
`
`Page 14
`
`

`

`3
`FIG. 11 shows the software involved in executing the
`logic of the distribution subsystem.
`FIG. 12 is an example of a typical end user terminal
`configuration that may be connected to an ON distribu-
`tion subsystem.
`FIG. 13 shows the software involved in executing the
`logic of the end user terminal.
`FIG. 14 provides details of the Input/Output Control
`System on the end user terminal.
`FIG. 15 shows how keystrokes input by end users are
`processed by the terminal software.
`DESCRIPTION OF THE PREFERRED
`EMBODIMENTS
`
`A system generally embodying the main components
`of the present invention connected to a Videotex Appli—
`cation Network (VAN) is illustrated in FIG. 1. A fun-
`damental component in the architecture is the Opera-
`tions Node (ON), which is the unit through which all
`end-user terminals are connected to the system and
`wherein resides one or more databases with Videotex
`information available to other connected nodes. The
`nodes in their various forms, their interactions with end
`users and their services together make up an informaion
`utility or system.
`First considering the system conceptually, all of the
`nodes, irrespective of their particular forms, are semiau-
`tonomous in that they are capable of many functions
`and operations on their own, that is, they may carry out
`in-house data processing and information exchange
`between their local databases and terminals without
`interacting with the system at large. The Operations
`Nodes are also distributed,
`that is, remotely located
`with respect to each other, and each may be connected
`to one or more other nodes in the system. The commu-
`nications paths also support multiple concurrent “con-
`versations" both from and to any particular Operations
`Node as well as between any pair of Operations Nodes.
`At the same time the paths are such that the addition or
`deletion of any one or more nodes causes a minimal
`amount of disruption to the network.
`The VAN does not support a “single system image”,
`so that each ON will recognize (hold a user profile for)
`only that set of users with which it expects to be dealing
`on a regular basis. Each such profile is identified by an
`ON-unique identifier. The identifier takes the form of an
`identification name, number, or symbol ( the ON-ID),
`concatenated with a System Access Code ( SAC). The
`SAC/ON—ID combination is unique within the VAN. A
`user for whom there is an identifiable profile on an
`Operations Node is said to be affiliated with that ON. A
`user may be permitted to be affiliated with more than
`one ON. Profile records of a user at different ONs need
`not be identical; indeed, for various reasons of security
`and economy, a user may have different profiles at
`different ONs. However, a user can be serviced only at
`ONs with which he is affiliated. Servicing includes the
`process of logging on to the system, information re-
`trieval, and the conduct of various transactional func-
`tions (e.g., data collection).
`Information at an Operations Node is preferably or-
`ganized in terms of pages. A page is a variable length
`data structure consisting of control information and
`displayable data. Displayable data in a page is normally
`encoded in accordance with the North American Pre-
`sentation Level Protocol Syntax (NAPLPS), an indus-
`try standard, and preferably read out in color, graphics,
`
`[0
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`65
`
`4,805,134
`
`4
`and text form on a display device at the terminal of an
`end user.
`Pages may be organized as scroll sequences for pur-
`poses of continuity of presentation, animation effects or
`for other reasons. Such sequences are known as page-
`sets. There is no conceptual limitation on the number of
`pages comprising a pageset. A group of pagesets that
`are related by some semantics may be recognized by the
`system as belonging to a database. Each such database is
`identified by a unique identifier in the form of an ON-ID
`concatenated with a Database Access Code (DAC).
`Databases may be owned by Information Providers
`(IPs) who are responsible for their creation and mainte-
`nance.
`
`An IP may be one person or may be an organization
`consisting of several people or entities, each with one or
`more assigned roles.
`A VAN database is said to be local to an Operations
`Node if its pages are permanently stored at that ON and
`are maintained by privileged users (IPs) affiliated with
`that ON. Similarly, if the pages of a database are stored
`elsewhere in the VAN, such a database would be
`viewed as being remotely situated. In either case it is
`preferred that all VAN databases share a common
`welldefined structure, and the pages or pagesets of a
`particular database are always stored within and main-
`tained by a single ON.
`One or more exit paths may be defined for a page.
`These exit paths allow the user to navigate from the
`currently displayed page to another page. Two types of
`exit paths are defined. The first type, user-deined exit
`paths, are those that are derived by the system from the
`user’s prior behavior. For instance, an exit path to the
`previous page displayed is known to the system because
`it keeps track of a limited history of page accesses by the
`user. Other such exit paths are described more fully
`below. The other types, Information Provider-defined
`exit paths, are embedded in the control area of a page
`and are invoked by certain functions also described
`below.
`Users can request information from VAN databases
`and Third Party Databases (TPDs). Information on
`TPDs may be organized differently from VAN data-
`bases, but access mechanisms for the two types of data-
`bases are adapted to be very similar.
`VAN databases, as mentioned, may be locally or
`remotely situated. However, because all such databases
`are structurally identical, accesses to non-local as well
`as local Videotex databases are carried out in such a
`way that the user is unaware of the locality of the data-
`bases. This is done by keeping implicit both the process
`of connecting to a remote ON for access to a non-local
`database, and the process of disconnecting from it when
`the user signals a context change.
`VAN databases, whether local or remote, that are
`accessible from a given ON, have entries in the database
`directory of that ON. This directory enables the On to
`determine the location and type of the database in ques-
`tion. It is to be noted that not all VAN databases are
`necessarily accessible from every ON in the network.
`The accessibility of a VAN database from a given ON
`will typically be a matter of negotiation between the
`ON wishing access and the database-owning IP.
`The procedures for handling accesses to TPDs, as
`mentioned, will be similar. An exit path from a local or
`remotely situated VAN database page will indicate that
`a page from a TPD is to be retrieved. Like VAN data-
`bases, TPDs are also represented by an entry in the
`
`Page 15
`
`

`

`5
`ON’s database directory. If the requested TPD is acces-
`sible from the ON with which the user is affiliated, then
`an entry will have been set up in the ON's directory.
`This entry enables the ON to make requests to the (ex-
`ternal) system on which the TPD is resident. The TPD
`system, while maintaining its databases independent of
`the VAN, will recognize the page, pageset, and data-
`base semantics in order to carry out a meaningful access
`session with the VAN user. The particular manner in
`which communication between a TPD system and the
`VAN is conducted will vary and be within the purview
`of those skilled in the art and so will not be discussed
`here in detail.
`
`END-USER FUNCTIONS
`
`A comprehensive repertoire of functions is available
`to the end user to access information within the ON
`with which he is affiliated as well as on other ONs.
`These are discussed in this section in the context of
`
`5
`
`lo
`
`15
`
`using a computer keyboard at the end user terminal to 20
`call up and control function operation and display.
`A scroll function allows the end user to access pages
`in their sequence order within a pageset. The user may
`scroll forward to access the next page in sequence or
`may scroll back to access the previous page. The point
`of reference in scrolling is always the currently dis-
`played page. The exit paths associated with scrolling
`are always embedded in the control section of the cur-
`rently displayed page’s data structure.
`A retrace function allows the end-user to trace back
`(in time sequence) to pages previously displayed. The
`exit path for the retrace function is derrived by the
`system based on past user actions.
`A menu selection function allows the end user to
`make a selection of an integer within a given range such
`that each such selection causes the system to undertake
`a potentially different exit path. Each such exit path
`must be defined in the control section of the currently
`displayed page. The various types of exits for a selection
`are:
`
`25
`
`30
`
`35
`
`Null: This path indicates that the selection is currently
`inactive and is therefore not a valid exit path.
`Direct Reference:
`In this case,
`the exit
`identifies
`uniquely a page within some database in some Opera-
`tions Node within the VAN.
`Description based search: This exit provides a program
`identifier that is invoked by the system. The program
`conducts a search of the current database according
`to some search criteria and produces one or more
`pages containing the results of that search. The crite-
`ria may be provided by the end-user in the form of
`responses to prompt strings specified in the exit path.
`Program Trigger: This exit is a generalization of the
`description based search exit. Whereas the descrip—
`tion based search exit provides for the activation of a
`special purpose program to search a VAN database,
`program triggers allow for the activation of any pro-
`gram. The logic of such programs may not be known
`to the system.
`Command String: This exit allows for simulation of
`other types of exits from within a menu selection. For
`example, this exit may be used to simulate the scroll
`function described above.
`It should be noted that not all pages may have menu
`selection exits defined in their control sections. A page
`that has menu selection defined for it is known as an
`index page.
`
`45
`
`50
`
`SS
`
`60
`
`65
`
`4,805,134
`
`6
`A find function permits a page within a database to be
`accessed directly by a user. The find function requires
`the user to specify the database name, the pageset and
`page identifiers. A user session manager at each ON will
`maintain context (or present state)
`information for
`every active user. The database context of a user is the
`database to which the currently displayed page belongs.
`Because the current database is always known to the
`system, a user need not specify the database name if he
`wishes to find a page within the current database. An IP
`intending to create a database for access by the VAN
`user community must specify a database name which is
`used by the session managing ON when accessing that
`database on behalf of a user. An IP may own more than
`one database within an ON.
`A backup function is used to display the last index
`page prior to display of the currently displayed page.
`Successive backups works backwards through a (lim-
`ited) sequence of previously seen indexes.
`A next function is used to take the next exit path on
`the last index page displayed prior to the display of the
`currently displayed page. It is equivalent to a backup
`followed by an increment of the choice number, saving
`the intermediate display. Its prime use is for browsing
`through a list of items.
`A mark function causes the system to “remember”
`the currently displayed page for later access via a recall
`function.
`
`A recall function is used to display the page that was
`“marked”. If several pages are marked before a recall is
`issued, the most recently marked page will be displayed.
`Context information is saved with the mark and re-
`stored with recall, so that if the end user has retrieved a
`page via menu choice, marked it, and later recalled it,
`the backup function would return to the menu from
`which the end user originally retrieved the page.
`A define function allows the end user to define syn—
`onyms for the currently displayed page or to define
`string substitutions. Thus users may “name” often-dis-
`played pages with identifiers that are most meaningful
`for them and have such pages accessed by name at a
`later time. String substitutions allow users to abbreviate
`frequently used command strings.
`A tell function displays the definition of a specific
`synonym or all the synonyms.
`A last command function causes the system to display
`the last command string that was entered by the user.
`Successive “last commands” work backwards through
`a sequence of previously entered commands, eventually
`returning to the newest command in a circular form.
`Last command has two corollary functions, as well.
`One moves through the list in the opposite direction and
`the second repeatedly retrieves the most recent com-
`mand without moving through the list of saved com-
`mand strings.
`A home function causes a previously designated page
`to be displayed and restores the end-user to a known
`state.
`
`A cancel function allows the user to terminate pro-
`cessing of the last function by the system.
`A help function may be invoked by the user to dis-
`play information about how to use the system or to
`provide information pertinent
`to the currently dis-
`played page.
`A reshow functin redisplays the current page.
`A capture function saves the current page in a file
`local to the end-user terminal for offline review.
`
`Page 16
`
`

`

`4,805,134
`
`8
`
`Modes of Interaction
`
`7
`An unsolicited keyword search function allows the
`user to enter a term that represents a topic covered
`within the current database. The user is presented with
`a menu specifying the pagesets within the database that
`cover that topic. The user may then examine the “hits”
`if desired through simple menu selection or the other
`navigational functions. Keyword search lets the user
`break out of a menu hierarachy more directly to a topic
`of interest.
`
`SYSTEM/USER INTERFACE
`
`Screen Management
`
`The display area on the end-user’s terminal is con-
`trolled by the use of multiple overlaying windows. The
`use of such windows facilitates management of the con-
`tents of the screen without losing information that may
`be important to the user, and provides for adequate and
`timely interactions between the user and the system.
`In the following discussion, several types of windows
`are described. These windows overlay the underlying
`page image when necessary and the overlayed area is
`always restored when the window is no longer needed.
`A Command line window—appears, for example, at the
`bottom of the screen whenever the end user begins
`typing something during a display mode. (Dispaly
`modes will be described later in this section.) The
`command line window is preferably wide enough to
`accommodate a single line of text and function key
`definitions. The command window can be made to
`disappear (and have the underlying screen restored)
`by pressing a pre-designated key. This key can be
`used to toggle between the command window and
`the underlying screen. If the key is not used to toggle
`between the window and the screen, the window will
`appear when the user begins a command sequence
`and disappear when the command has been accepted
`for execution by the system. One of the customization
`options would be the placement of this command
`window, e. g., at the top of the screen or bottom of the
`screen. and another would be the specific toggle key.
`A Prompt window—allows the system to prompt the
`end user with a short text string and obtain a response
`back. This is used in conjunction with program trig-
`gers that require one or more parameters from the
`user. The prompt window appears when a user makes
`a menu choice requiring a prompt and disappears
`after user input has been received.
`An Action menu window—is a window of variable
`height (depending on the number of action items).
`The window appears on the screen when an action
`key is pressed and disappears when the user has se-
`lected a choice from the action menu. (The action key
`and its use are described below).
`A Message window—allows the system to put up infor-
`mational and/or error messages. Error messages usu-
`ally appear in response to a command that could not
`be executed by the system for some reason (e.g., secu-
`rity violation, page not found, etc). The message
`window disappears when the user strikes a key to
`begin a new command string. The message window
`may also be used for display of one-line messages sent
`to one end user by another end user.
`A Help text window—is used to show brief help infor-
`mation. The amount of information will not normally
`exceed a few lines. Its location is also subject to cus-
`tomization.
`
`There are two distinct modes of interaction which the
`user might be in at any time, a display mode and an
`action mode. Once the user has successfully logged on
`the system, he is deemed to be in the display mode.
`In the dispay mode, the user can invoke all of the
`information access functions which include: SCROLL-
`ING; MARK/RECALL; MENU CHOICE SELEC‘
`TIONS and accompanying prompts,
`if any,; BACK.
`UP/NEXT; RETRACE; TELL/DEFINE; FIND;
`HOME; HELP; AND CANCEL. Any of these com-
`mands may be invoked via a function key/synonym
`combination on the terminal keyboard. Such function
`keys may be defined in one of three ways: (1) shorthand
`cursor control keys, such as those that move the cursor
`back to the beginning of the line; (2) shorthand keys for
`a text string; and (3) keys for direct mapping into a
`command. Cursor control functions never leave screen
`management and are thus not of particular inter