United States Patent (19)
`Regnier et al.
`
`54
`
`75
`
`73
`
`(21)
`(22
`51
`(52)
`
`58
`
`CLIENTISERVER COMPUTER SYSTEMS
`HAVING CONTROL OF CLIENT-BASED
`APPLICATION PROGRAMS, AND
`APPLICATION-PROGRAM CONTROL
`MEANS THEREFOR
`Inventors: Barbara Ann Regnier, Mazeppa;
`David Nicholas Youngers, Rochester,
`both of Minn.
`Assignee: ShowCase Corporation, Rochester,
`Minn.
`
`Appl. No.: 414,729
`Filed:
`Mar 31, 1995
`Int. Cl. ... G06F 9/46
`U.S. Cl. ......................... 395/682; 395/683; 395/674;
`395/200.01
`Field of Search ..................................... 395/650, 700,
`395/674, 682, 683, 200.01, 800; 364/DIG. 1
`
`III USOO5689708A
`5,689,708
`Nov. 18, 1997
`
`Patent Number:
`Date of Patent:
`
`11
`45
`
`56
`
`References Cited
`U.S. PATENT DOCUMENTS
`5,187,790 2/1993 East et al. ............................... 3957725
`5,432,899 7/1995 Jwatani et al. .......................... 395/145
`Primary Examiner Thomas M. Heckler
`Assistant Examiner Majid A. Banankhah
`Attorney, Agent, or Firm-Schwegman,
`Woessner & Kluth, PA.
`57
`ABSTRACT
`A resource manager in a client/server computer network
`controls the availability of system resources. A system
`administrator generates a set of profiles which specify which
`system resources each user may employ for each of multiple
`application programs. Individual application programs may
`internally configure their possible choices of such system
`resources according to the appropriate profile on a dynamic
`basis.
`
`Lundberg,
`
`9 Claims, 6 Drawing Sheets
`
`210-240
`SERVER
`APP. M
`TOOLS
`SYSTEM
`-wn- -1-
`
`to
`
`260-2AO
`CLEN /
`-1-
`
`GENERATE
`301- RS
`STORE
`302 - SYSTEMS
`o APPS
`a USERS
`
`304 AUTHENTICATE
`USER
`
`EXECUTE
`APPCATON DONE
`314
`
`
`
`
`
`PROCESS
`REQUEST
`
`Ex.1006
`APPLE INC. / Page 1 of 13
`
`

`

`U.S. Patent
`
`Nov. 18, 1997
`
`Sheet 1 of 6
`
`5,689,708
`
`ZS1
`
`OSL
`
`Olt
`
`"00h90udWAWO/I||LYOd
`
`
`SNOLLVISHYOMo/||NIANAS_|SYITIONLNODS3OIARAMOWANSYOSS300Nd
`
`
`
`
`Oc!ctlZLt
`L‘O)4LNOd
`LGL
`
`8f{MAINdNOOYaANaS
`
` |Sel-|LN3M9—___
`—
`eeeLolZecol|vel
`
`\danAZel
`
`LSL
`
`SLL
`
`Ex.1006
`APPLEINC./ Page 2 of 13
`
`Ex.1006
`APPLE INC. / Page 2 of 13
`
`
`
`

`

`U.S. Patent
`
`Nov. 18, 1997
`
`Sheet 2 of 6
`
`5,689,708
`
`2OO
`
`22O
`210
`f 222 215 f 214
`223
`|U1
`(UDataBase
`OS
`DATA AND
`TABLES
`MEADATA
`
`230
`f 232
`APPLN
`DATA
`
`
`
`110
`
`PROCESSOR
`
`OPERATING
`SYSTEM
`
`2
`12
`APPLICATION
`PROGRAMS
`
`
`
`
`
`
`
`f 250
`
`231
`
`PROFILE
`GEN.
`254
`
`(U1//n: DATA WEWS
`1/Uni SECURITY
`1/n. RES, MGMT,
`U 11 - Un-LC. MGNT.
`252.
`253
`251
`
`--240
`SERVER
`MODULE
`
`ge O. O.
`
`150
`
`130-
`140
`
`QUERY
`MGR
`
`26O
`f
`262 261
`(U1DAAYES
`(UEISECURENT
`?jid MSN
`|U11
`RES. MGMT.
`MODULE
`291
`283
`281
`
`27O
`
`
`
`2A1
`
`OTHER
`APPLS.
`
`CLIENTS
`
`260-2AO'
`
`OP.
`SYS.
`284
`
`M/DATA
`SUBSET
`QUERY 292
`
`DATA
`2A2
`
`DATA
`NPUT
`
`29O
`
`28O
`
`2AO
`
`FIG. 2
`
`Ex.1006
`APPLE INC. / Page 3 of 13
`
`

`

`U.S. Patent
`
`Nov. 18, 1997
`
`Sheet 3 of 6
`
`5,689,708
`
`210-240
`SERVER
`APP. /
`CLENT
`TOOLS
`SYSTEM
`-1N- -1- -1N
`
`250
`
`260-2AO
`
`302
`
`STORE
`o SYSTEMS
`o APPLS
`a USERS
`
`
`
`3O3
`
`306
`
`DETECT
`SIGN ON
`
`STORE
`PROFILES
`
`DETECT
`SELECT
`APP.
`
`END
`J.09
`
`
`
`3O4
`
`305
`
`AUTHENTICATE
`USER
`SELECT
`PROFILE
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`NON
`COMPLY
`
`AUTHENTICATE
`
`APP.
`NOW ALLOWED? / YES
`
`
`
`
`
`3.11
`
`
`
`ArtEoN
`INTERFACE
`
`3O8
`
`
`
`313
`
`EXECUTE
`
`35AE DONE
`RESOURCE
`
`
`
`YES
`
`JOO
`
`FIG. 3
`
`
`
`
`
`
`
`
`
`PROCESS
`REQUEST
`
`Ex.1006
`APPLE INC. / Page 4 of 13
`
`

`

`U.S. Patent
`
`Nov. 18, 1997
`
`Sheet 4 of 6
`
`5,689,708
`
`
`
`007
`
`Ex.1006
`APPLE INC. / Page 5 of 13
`
`

`

`U.S. Patent
`
`Nov. 18, 1997
`
`Sheet 5 of 6
`
`5,689,708
`
`
`
`NVOKE
`
`SELECT
`FUNCTION
`
`FUNCTION
`
`FUNCTION
`
`550
`FUNCTION
`
`QUERY
`SCREEN
`ENTER
`QUERY
`CHECK
`QUERY
`SELECT
`MODE
`SEND
`QRY,MODE
`
`Ex.1006
`APPLE INC. / Page 6 of 13
`
`

`

`U.S. Patent
`
`Noy. 18, 1997
`
`Sheet 6 of 6
`
`5,689,708
`
`00
`9
`
`LOVYLXS
`
`JOYNOSSY
`
`SLY
`
`LO9
`
`c09~LXANL395
`
`vO9
`
`JNsdOud
`
`MOY
`
`
`
`SJA/ éTddV
`
`LN3YYND
`
`£09
`
`NOLLOV
`
`4dALONV
`
`Las
`
`ANIVA
`
`
`
`JAOWSYdqaqv
`
`
`
`LOArEOJOIOHO
`
`SJAOWSY
`
`JOIOHS
`
`809
`
`9‘Old
`
`Ex.1006
`APPLEINC./ Page 7 of 13
`
`Ex.1006
`APPLE INC. / Page 7 of 13
`
`
`
`
`
`

`

`5,689,708
`
`1
`CLIENTISERVER COMPUTER SYSTEMS
`HAVING CONTROL OF CLENT-BASED
`APPLICATION PROGRAMS, AND
`APPLICATION-PROGRAM CONTROL
`MEANS THEREFOR
`
`10
`
`15
`
`20
`
`1. Field of the Invention
`The present invention relates to electronic data
`processing, and more particularly concerns the control of
`system resources in computer systems arranged in a client/
`server configuration.
`2. Background of the Invention
`There are several broad types of computer systems. In a
`mainframe computer system, a single central processor
`complex running under an operating system executes appli
`cation programs, stores databases, enforces security, and
`allocates all resources such as processor time, memory
`usage, and subsystem processing. Users interact with the
`system via "dumb" terminals, which essentially only display
`data and receive keystrokes. Peer-to-peer networks of sys
`tems such as personal computers are essentially standalone
`computers each running similar operating system programs,
`which can share application programs and data among each
`other according to a defined protocol. Client/server networks
`have a central server computer coupled via a communica
`tions medium to a number of client computers, usually
`smaller personal computers running under a conventional
`operating system. In the earliest client/server network
`model, the server was only a "file server” which could
`download data to the clients and upload data from them;
`application programs were executed entirely in the client
`computers, That is, the server's function was to store large
`amounts of data, which could then be shared among a
`number of Smaller clients.
`Most present client/server networks implement an
`“application server” model in which some or all application
`programs are split into two portions. A server portion
`executes within the server computer, while a separate client
`portion executes within each client computer from which a
`user can invoke the application. The two portions employ
`cooperative processing to pass data between the server and
`client computers; typically, most of the data is stored in the
`server. The first major application of this model was the
`processing of client queries against a central database, so
`that this model is also sometimes known as a "database
`server" network. Newer applications sometimes employ the
`terms "groupware” and "transaction processing” (TP).
`Advances in technology additionally allow multiple servers
`in the same network, so that a user at a client computer can
`choose to sign on to a number of different servers. A third
`client/server type of network is beginning to emerge; in the
`"distributed object” model, encapsulated objects containing
`both data and executable code may roam about the network,
`run on different platforms, and manage themselves. In this
`model, clients and servers are not fixed in particular com
`55
`puters: a given computer may be simultaneously a server for
`one application and a client for another, and a given appli
`cation may run one computer as its server, and later run
`another computer on the network as a server.
`A network operating system (NOS) mediates communi
`cations between servers and clients in a network. An NOS
`contains a server control module executing within the server
`computer, and a client control module executing within each
`client computer. These control modules cooperate with each
`other to transfer data (and sometimes code or other objects)
`over the network's communications medium between the
`servers and particular clients. They provide interfaces to the
`
`65
`
`2
`operating systems and application-program portions running
`in the client and server.
`A client/server network contains system resources which
`can be shared by some or all of the other computers in the
`network. One or more server processors, for example, are
`scheduled among the tasks of different users. Memory pools
`of various sizes are allocated to tasks being executed and
`awaiting execution. Printers may be physically connected to
`the network as a print server, accessible via a print spooler
`to other computers on the network; storage devices may be
`similarly connected as separate file servers. Other capabili
`ties are also considered to be system resources. For example,
`database applications generally have both an interactive and
`a batch mode for processing queries from a client. The
`interactive-mode resource uses large amounts of processor
`time, and is frequently restricted to short and/or time-critical
`queries; the batch-mode resource batches multiple queries
`togetherfor processing at times of low processor load. Even
`the ability to execute a given application program can be
`considered a resource of the system.
`Each user, sitting at a client computer in a cfs network,
`sees the server as a virtual part of his own system. For
`example, the client portion of a database application, being
`the same in each client computer or workstation, allows any
`user to choose the processor-intensive interactive mode.
`System printers usually appear as possible choices on the
`normal “Print” menu of a word-processing application
`program, alongside choices for local printers available only
`from the user's own computer.
`While system resources appear to be at the total disposal
`of each user, in fact they are shared among all clients on the
`network and among all applications being executed by all
`users. Unlike the more abstract programming objects which
`can be multiplied forever, system resources are physical and
`finite, and must be divided among contending users.
`In a mainframe type of computer organization, conven
`tional central-processor-based operating systems schedule
`system resources, place restrictions upon particular users at
`particular times, block certain users from running certain
`applications or from running them in certain ways, and so
`forth. Servers in cfs networks can place restrictions upon the
`resources themselves, and upon which users can access
`certain resources, based upon the identity of the user. Some
`application programs can specify certain resources they can
`access, on an individual basis. That is, resource management
`in a cfs network is conventionally done by the server system
`(i.e., its operating-system program), or by restrictions which
`are hard-coded into each individual application program at
`the client level or specified by an initialization (INI) file.
`However, nofacilities exist for specifying that user Alice,
`executing a particular program, is restricted to (for instance)
`run database queries only in batch mode, to avoid hogging
`the system with network traffic and processor time; but user
`Bob may run small queries in interactive mode, because he
`accesses only small amounts of data, or needs results
`quickly. The problem is that both users upload and run their
`queries from exactly the same database application program.
`Those in the art might respond by denying system permis
`sion at the server level to user Alice for the interactive mode,
`by restricting the number of database records in a query, or
`killing a query after a certain amount of time has been spent
`processing it. But Alice might also run another application
`program from her terminal for which she needs interactive
`mode for large queries. Or she may occasionally run smaller
`queries which can be serviced in interactive mode without
`significantly delaying other users; many database programs
`have facilities for estimating the resources required to fulfill
`
`25
`
`30
`
`35
`
`45
`
`50
`
`Ex.1006
`APPLE INC. / Page 8 of 13
`
`

`

`3
`a requested query. That is, the nature of present cfs networks
`make it difficult to achieve a sufficient granularity of control
`in allowing or denying particular System resources to par
`ticular users for particular application programs or in
`response to certain factors such as the size of a query.
`Dynamic control of such resources is also precluded.
`SUMMARY OF THE INVENTION
`The present invention provides enhanced and more pre
`cise control over the use of system resources by users and
`applications in a cfs network of computers. This control is
`inexpensive to implement, and does not interfere with con
`ventional control capabilities already provided by the serv
`er's operating system or by the client's terminal.
`The invention avoids the common proclivity of older
`application programs to "break” when new facilities are
`added at the system or network level.
`Moreover, resource restrictions can be imposed in a way
`which is transparent to the user, rather than merely by
`returning an ugly error message if the user attempts to
`engage the forbidden resource.
`The invention achieves these and other advantages
`through the cooperation of a different profile for each user,
`and a control facility in each application program which can
`read the current user's profile in order to manage a specified
`set of system resources. The response of the application to
`a particular profile might range from denying that user the
`ability to run that particular program at all, down to denying
`him the use of real-time queries or mandating the use of a
`certain printer for output of data from that particular appli
`cation. Restrictions can be enforced by changing the pro
`gram's own interface to the user under control of that user's
`profile. For example, forbidden choices may simply no
`longer appear on menus or other user-interface constructs
`within the application program itself, or can be subjected to
`reverification. That is, the application program, which actu
`ally exists as only a single program, appears as though it had
`been customized for each individual user-and this customi
`zation is dynamically variable by a system administrator or
`other authority. The coupling between the profiles and the
`application programs is mediated by parts of the c?s control
`program located in the server and in each client; this is
`simple to do, because both pieces of this program are sold
`together as a single package. Profiles are generated and
`stored in the server by a system administrator. When a user
`signs onto the network from his client terminal, the server
`downloads that user's profile to the terminal. The profile
`interacts with individual application programs in the client.
`When a user executes a particular application program in
`that terminal, the application program itself governs which
`system resources are available to the user, independently of
`the operating systems or other programs running on the
`client or on the server,
`BRIEF DESCRIPTION OF THE DRAWING
`FIG. 1 shows a typical client/server computer network
`which forms the environment of the present invention.
`FIG. 2 is a schematic overview of the client/server net
`work of FIG. 1, incorporating the invention.
`FIG. 3 is a flowchart showing the operation of the
`invention within the system of FIG. 2.
`FIG. 4 details representative profiles of FIG. 2.
`FIG. 5 shows a resource-manager-controlled interface of
`an application program according to the invention.
`FIG. 6 is a flowchart detailing the control of an
`application-program interface of FIG. 5 according to the
`invention.
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`65
`
`5,689,708
`
`O
`
`15
`
`20
`
`25
`
`4
`DETALED DESCRIPTION OF PREFERRED
`EMBODIMENTS
`FIG. 1 shows a network 100 of computers 110-140
`configured in a client/server configuration.
`Server computer 110 may be any type of system, from a
`relatively small personal computer (PC) to a large main
`frame. In the particular implementation discussed below,
`server 110 is a mid-range computer, specifically an IBM
`AS/400 data-processing system. ("IBM", "AS/400." "OS/
`400,” and “400” are registered trademarks of IBM Corp.)
`Very broadly, the AS/400 has one or more processors 111,
`memory 112, input/output devices 113, and workstations
`controllers 114, coupled together by one or more busses 115.
`WSCs 114 are physically a type of I/O device which interact
`with multiple terminals over communication facilities 150.
`A number of conventional facilities, such as APPC
`(Advanced Program-to-Program Communications) routers
`and LU6.2 (Logical Unit version 6.2) are available to handle
`the necessary communications protocols.
`Additional devices, represented by block120, may also be
`coupled to facilities 150 for interaction with the client
`terminals and with server 110. As mentioned previously,
`block 120 may represent one or more complete computer
`systems functioning as multiple servers in network 100.
`Communications 150 may assume any of a number of
`conventional forms, such as cables 151-152, switched tele
`phone lines, wireless devices, and many others.
`Client terminals 130, 140 are commonly personal com
`puters (PCs) coupled to facilities 150 by cable 151 to form
`a local area network (LAN) with server 110. Other
`arrangements, however, may also be employed in any con
`ventional manner. A typical PC 130 contains a processor
`131, memory 132, I/O devices 133, and a port 133 coupled
`to cable 151. An internal bus 135 interconnects these con
`ponents with a display 136 for presenting data to a user and
`a keyboard, mouse, and/or other input devices 137 for
`receiving data and commands from the user.
`FIG. 2 shows clientserver network 100 from the perspec
`tive of the functions 200 performed by the computers of
`FIG. 1. Brackets at the left side indicate the component
`functions occurring within server system 110, communica
`tions facility 150, and one of the client terminals 130. A
`number of different users, represented by the labels U1-UN,
`operate respective ones of the terminals 130-140. Any of the
`users may operate any terminal; the association of a par
`ticular user with a particular terminal is established when
`user U1, say, signs on at terminal 130 by sending his logon
`and password over facilities 150 to server 110. (Again, in
`some networks 100, a user may be able to sign on to any one
`of multiple servers 110-120.) The association of user and
`terminal persists until the user signs off from his session.
`Conventional operating system 210, an IBM OS/400 in
`this example, manages the physical facilities of server 110,
`and controls the execution of tasks such as 220-230 running
`on the server, as symbolized by arrows 211,212. Functional
`modules 213 of the operating system employ a number of
`tabies 214 for a number of conventional purposes such as
`system configuration, task priorities, and security. For
`example, OS/400 employs a number of system user profiles
`215 to specify data for each user U1-UN, including the
`access rights of each user to system objects (data and
`program commands), the language for messages to that user,
`and library lists.
`Of the many applications which can be executed, database
`220 is a typical important example. In FIG. 2, all other
`applications are lumped together as blocks 230. Code mod
`
`Ex.1006
`APPLE INC. / Page 9 of 13
`
`

`

`5,689,708
`
`15
`
`30
`
`35
`
`5
`ules 221, 231 perform the server-resident functions of the
`applications upon data 222, 232. Some data may include
`conventional profiles 223 specifying information unique to
`each user U1-UN, such as the tables accessible to that user.
`Applications 220-230 usually require system resources to
`perform their tasks. For example, server I/O devices 113
`may include printers and archival storage. System
`controlled printers (not shown) may also attach outboard to
`communication facilities 150. Query processor 221 has an
`interactive mode wherein it executes queries and returns
`results as the queries are received, and a batch mode wherein
`operating system 210 stores incoming queries until slack
`periods, whereupon it passes them to be processed together
`in module 221. The ability to run query processor 221 at all
`may be considered a system resource.
`Server control module 240 executes within server 110,
`FIG. 1, to control all communication from server functions
`210-250 within server 110 to client functions 260-2A)
`executing within each oft he client terminals 130-140.
`Client module 270 executes within each client terminal such
`as 130, FIG. 1, to control communication from client func
`tions 260-2A0 to serverfunctions 210-250 executing within
`server 110. The control is physically mediated by transmit
`ting and receiving data over communication facilities 150,
`FIG. 1. Modules 240 and 270 contain conventional cooper
`25
`ating protocols for packaging and timing data to be com
`municated between server 110 and a client 130. In addition,
`these modules implement conventional addressing tech
`niques for identifying which of the clients attached to the
`server is to receive each data package, and for identifying to
`the server which client has sent each data package in the
`reverse direction and which user is signed on at that client.
`Conventional operating system 280, for example
`Microsoft Windows ("Microsoft” is a registered trademark
`of Microsoft Corp.), manages the physical facilities of client
`130, and controls the execution of tasks such as 290-2A0
`running on the server, as symbolized by arrows 281, 282.
`Functional modules 283 of the operating system employ a
`number of tables 284 for a number of conventional purposes
`such as system configuration and task Switching. In a
`multi-server network 100, client module 270 may also
`specify which server 110-120 is to receive particular data
`packages.
`Again using a database as an example of an application
`program, query manager 291 receives queries 292 from the
`user signed on at client terminal 130, and displays a resulting
`subset 293 of the data from tables 212 in the server. As is
`typical in many application programs in a client/server
`network, a portion 211 of the application is physically
`located and executes in the server 110, FIG. 1. Another
`portion 291 of the same application executes in the client
`terminal 130. This client portion 291 may be downloaded
`from server 110 to terminal 130 upon a request from the
`user, or it may reside permanently within terminal 130; in
`either case, it is executed by processor 131 of the terminal.
`Others of the application programs in terminal 130, lumped
`together as 2A0, may have functions similarly split between
`client code portions 2A1 and server portions 231, or they
`may execute entirely within a client terminal, using
`operating-system modules 213 or other modules residing
`within the server.
`Other client terminals include similar modules, indicated
`in FIG. 2 as 260-2A0'. The client modules are usually the
`same in each terminal. Other applications may be the same
`or different among the client terminals.
`A set of tools cooperates with server and client modules
`240 and 270 to provide additional functions by further
`
`6
`controlling the communication of information between
`server 110 and clients 130-140 in network 100. At the
`present time, these tools provide license-management
`functions, security enhancement, and database view control
`as described in commonly assigned application U.S. Ser. No.
`08/414.483, filed on the same date herewith. Each tool has
`a portion which resides within server computer 110, and
`another portion which resides within each client terminal
`130-140. If network 100 has multiple servers, such as 120
`in FIG. 1, then another server portion resides within each
`server. The present invention, which provides control of
`system resources, has a server portion implemented in
`module 251, profiles 252-253, and profile generator 254
`located within server 110, and a client portion implemented
`in module 261 and profile 262 located within each client
`such as 130.
`FIG. 3 is a flowchart of a process 300 for carrying out the
`invention in the system of FIG. 2. The horizontal location of
`each block indicates where that block actually occurs,
`whether in a serverblock 210-240, in the server portion 250
`of the resource manager, in the client portion 260 of the
`resource manager, or in another block270-2A0 of the client.
`Initially, the network or system administrator decides
`which users are allowed to employ which applications to
`access which systems resources. The administrator then
`employs block301 to produce profiles (shown schematically
`in FIG. 4, and discussed below) listing system resources by
`user and by application. For security reasons, access to block
`301 is limited by conventional security facilities of server
`110. Block 302 stores these profiles in a secure form within
`server 110. For a multi-server system, each server may have
`its own set of blocks 301-302, as well as the other blocks in
`the "server tools' column of FIG. 3.
`When a particular user signs on at one of the client
`terminals 130, block 303 in resource manager client module
`260 detects the user's identity as it passes through client
`module 270 to the server 110, or to another server in network
`100 requested by the user. The server then authenticates the
`user's identity at block 304. Block 305 selects the profile
`associated with that user, and transmits it to the proper client
`terminal. The profile is preferably encrypted by any con
`ventional means, to prevent interception on communications
`facility 150, and to prevent alteration within the terminal
`after block 306 receives and stores it. In this embodiment,
`block305 downloads profile portions for each application as
`that application is connected; however, the entire profile
`may be downloaded as one piece if desired.
`When the user then selects an application, via the oper
`ating system or other conventional means, block 307 in
`resource-manager client module 260 determines whether or
`not that application program complies with the present
`invention. In this embodiment, the application name is sent
`along with a password for security against falsification.
`However, other means, such as a database table, could be
`used instead. If the application is not aware of the resource
`manager, dashed line 308 allows it to be executed in a
`conventionalmanner. This provides compatibility with older
`programs and with those which do not employ system
`resources controlled by the invention. Exit 309 terminates
`the client's operation when the user signs off or for any other
`eaSO
`If block 307 senses that the requested application com
`plies with the resource-management system, it transmits the
`identity of the application to block 310 in the server com
`puter for authentication. This step is desirable in preventing
`application spoofing, wherein code at the client pretends to
`
`40
`
`45
`
`50
`
`55
`
`65
`
`Ex.1006
`APPLE INC. / Page 10 of 13
`
`

`

`5,689,708
`
`10
`
`15
`
`20
`
`30
`
`35
`
`40
`
`7
`represent an application that it is not, or to claim resources
`that it is not entitled to. Preferably, the application identity
`is encrypted before transmission, to prevent a network
`eavesdropper from intercepting the true identity and modi
`fying or misusing it. If the authentication is proper, block
`310 transmits a positive response to block 311 in the server.
`Appropriate encryption and authentication methods are con
`ventional in the art. If execution is not allowed, block 311
`returns control to block 307 for selection of another appli
`cation. (Alternatively, it would be possible to have block307
`employ the specific user profile stored by block 306 to
`merely eliminate or dim menu choices for the non-allowed
`applications, so that the user could not choose them in the
`first place.) That is, the ability to run a given application at
`all can be treated as a system resource for the present
`purpose.
`Block 312 actually enforces the resource restrictions
`imposed by the profile stored at 306 for the particular user
`for the particular application program, represented by block
`313. Application 313 may be any one of a number of
`conventional programs, such as database programs,
`spreadsheets, word processors, and so forth. The application
`may run entirely in the client, or, more commonly, may be
`a network version which also includes a portion such as 317
`concurrently executing in the server. When the application
`program requests system resources, block 314 sends a
`message to the appropriate block 317 for processing the
`request. Block 317 may be physically implemented as a
`conventional device driver, a portion of the operating system
`213, in the server portion of a networked application, or in
`other conventional ways. As mentioned previously, the
`profile may also specify the manner of processing a request.
`For example, subblock 318 may queue a batch-mode data
`base query for later processing, or subblock 319 may route
`the request to a different device, such as a low-speed printer.
`In addition, server operating systems 213 frequently contain
`conventional facilities for balancing workloads in different
`subsystems of the network; block 314 could furnish priority
`information for the current user and application obtained
`from stored profiles at block 306. Line 320 returns data or
`any acknowledgements to the application executing in block
`312 of the client.
`Returning to block312, there are various ways to couple
`a profile to an application program so as to control which
`system resources a particular user may obtain from that
`application. For example, a crude method would be to place
`a sentry block (not shown) in line 316 so as to block
`unauthorized requests from ever reaching block 317. While
`such an approach would work, it would create user confu
`sion and frustration by presenting apparently valid choices
`50
`in the application program which would return error mes
`sages when selected, or which might even falsely appear to
`the user as system malfunctions.
`Many modem application programs 313 employ external
`initialization (INI) files, associated either with the specific
`application or with the operating system 283, which contain
`specifications for executing the application, and/or which
`specify choices within the application or choices presented
`to the user. For example, installing a new printer under the
`Microsoft Windows operating system modifies a WIN
`DOWS.INI file to include a reference to the printer, so that
`a separate word-processing program running under Win
`dows can access that file for a list of currently installed
`printers, and present that list-now including the new
`printer-to a user when he requests a PRINT operation for
`a document within the word processor. Block312 could thus
`itself edit such an initialization file dynamically-that is,
`
`45
`
`55
`
`65
`
`8
`whenever a particular user selects an application at block
`3.07-so as to change the application's own menu choices,
`the list of facilities which it presents to the user. Another
`method is to establish a special formal application program
`interface, (commonly known as "API”) a documented call
`which allows one program to access a certain function of
`another program.
`FIG. 4 represents a set 400 of profiles such as 252-253 in
`FIG. 2, which are employed in the procedure 300 described
`in FIG. 3. In the IBM AS/400, the OS/400 operating system
`includes an integrated relational database which uses the
`well-known SQL (structured query language) interface. A
`set of profiles may constitute an ordinary table in this
`database. Each row 410-470 of database table 400 lists a
`user or predefined group of users 401, the name 402 of a
`particular application program, a resource 403 potentially
`used by that program, a value 404 showing a status of that
`resource for that particular user when executing that par
`ticular application, and a change status 405 for the value
`404.
`Column 401 in each row profile contains a representation
`of a sign-on identification, either a user-id for one user or a
`group name which can be specified in a conventional
`AS/400 system profile (not shown) of that user. One person
`may of course have multiple sign-ons or user identifications,
`and may be a member of multiple groups, and thus may have
`different resource privileges for different purposes, even
`within the same application program. The set of rows which
`name one particular user, either specifically or by a group of
`which he is a member, forms a profile such as 252 and 253
`in FIG. 2 for that user.
`Column 402 lists the names of various application pro
`grams which are subject to resource manager 251, FIG.
`2-that is, those which block 307, FIG. 3 recognizes as
`being "compliant.” If an application is compliant, but is not
`listed in any row of table 400 for a particular user or group,
`then that user or group cannot execu