System and methods for automatically distributing a particular shared data object through electronic mail

Abstract

A computer system having a facility for concurrently sharing objects or resources is described. The system includes a publish-and-subscribe facility or "Object Exchange," for facilitating sharing among workgroups. When a data object is "published" by a user ("publisher"), the object is sent from that user's computer to other computer users specified by the publisher. Those interested in the published data object (published pages) may elect to receive or "subscribe" to that data. From that point on, the publisher can choose to update the data, such as whenever the published version changes. The "subscribers" of the published pages automatically get updates. Subscribers of a spreadsheet notebook, for instance, would automatically receive pages as they are published. The Object Manager effects actions by posting messages or "forms" to either the local Object Exchange (assuming one is the publisher) or the Object Exchange of others (subscribers). Connectivity for the system is provided by the various Object Exchange engines negotiating forms. Each Object Exchange posts and retrieves forms at polling intervals (which may be set to continuous polling). By exploiting the connectivity of existing transport media (e.g., LANs), the present invention delivers workgroup computing benefits to users, but without imposing a rigid structure which restricts when and how they work.

Claims

What is claimed is:

1. In a data processing system, a method for sharing data objects among users of a work group according to user-specified criteria, said method comprising:

(a) receiving a publication request from one user of the work group for establishing a data sharing relationship with other users of the work group, said request identifying a particular data object which is to be shared and further specifying user-specified criteria establishing conditions under which the particular data object may be shared;

(b) storing a copy of said particular data object locally in an object store;

(c) based on said user-specified criteria, sending a publication offer as an electronic mail message to a plurality of other users of the work group that said particular data object is available for use;

(d) receiving from at least one other user a subscription response as an electronic mail message for accepting said publication offer, said at least one other user accepting or rejecting said subscription based on whether the user desires to receive said particular data object; and

(e) automatically forwarding through electronic mail a copy of said particular data object to each of said at least one other user of the work group from which an acceptance is received.

2. The method of claim 1, further comprising:

receiving a request from said one user of step (a) for issuing a new version of said particular data object; and

forwarding through electronic mail a copy of the new version of said particular data object to each of said at least one other user of the work group from which an acceptance has been previously received.

3. The method of claim 1, wherein said publication offer provides descriptive text describing said particular data object.

4. The method of claim 1, wherein said request for establishing a data sharing relationship specifies a version depth that said particular data object is to be maintained in object stores of other users.

5. The method of claim 1, wherein step (b) further comprises:

assigning a unique system identifier to said copy of said particular data object, so that each particular copy may always be uniquely identified regardless of where it is stored in the system.

6. The method of claim 1, wherein step (b) further comprises:

assigning a descriptive key to said copy of said particular data object, so that contents of said data object may be identified by a user based on said descriptive key.

7. The method of claim 1, wherein step (c) includes:

at periodic intervals, connecting the system to a computer having a message transport service and transmitting the publication offer via communication services of said message transport service.

8. The method of claim 7, wherein step (d) includes:

polling said message transport service for retrieving any subscription responses sent in response to said publication offer.

9. The method of claim 1, wherein step (c) includes:

retrieving from the message transport service any publication offers proffered by other users of the work group.

10. The method of claim 1, wherein step (a) includes:

specifying at least one spreadsheet page from a spreadsheet notebook which is to be shared with said at least one other user.

11. The method of claim 10, further comprising:

said at least one other user retrieving for use said at least one spreadsheet page which has been forwarded as said particular data object to be shared.

12. The method of claim 11, wherein said retrieving step includes placing said at least one spreadsheet page in a spreadsheet notebook of said at least one other user.

13. The method of claim 1, wherein said publication request comprises a listing specifying said plurality of other users of the work group who may receive a copy of said particular data object.

14. The method of claim 13, wherein step (e) includes:

for each said at least one other user of the work group from which an acceptance is not received, removing the user from the listing.

15. The method of claim 2, further comprising:

forwarding through electronic mail the copy of the new version of said particular data object to an object store of said at least one other user, whereby said at least one other user retrieves said particular data object from the object store when use of the object is desired.

16. A multi-user computer system comprising:

a first computer means having a processor and a memory for processing information stored in a storage device local to said first computer means;

a second computer means having a processor and a memory for processing information stored in a storage device local to said second computer means;

input means for processing a request from a first user that a particular data object stored in said first computer means be made available, according to user-specified criteria, to a second user on said second computer means for sharing with said first user;

means for storing an outgoing copy of said particular data object in the storage device of said first computer means;

means for transmitting an offer notification from said first user on said first computer means to said second user on said second computer means, based on said user-specified criteria, said offer notification offering to share said particular data object with said second user;

connectivity means, operably coupled to said transmitting means and said receiving means, for communicating notifications and data objects between said first computer means and said second computer means wherein said connectivity means includes telecommunication means for transporting notifications and data objects across an electronic mail service;

means for receiving a response notification from said second user on said second computer means to said first computer means, said response notification accepting or rejecting said offer notification based on whether said second user desires to receive said particular data object; and

means, responsive to said response notification, for forwarding said outgoing copy of said particular data object to said second computer means for storage in the storage device of said second computer for use by said second user, upon acceptance of said offer notification offering to share said particular data object.

17. The system of claim 16, further comprising:

means for retrieving the copy of said particular data object from the storage device of said second computer means and using said particular data object in an application process said second user is operating on said second computer means.

18. The system of claim 16, further comprising:

polling means for polling said connectivity means for posting any offer notifications and for retrieving any response notifications, so that sharing of data objects may be deferred.

19. The system of claim 18, wherein said polling means operates in a selected one of manual polling mode and automatic polling mode.

20. The system of claim 19, wherein said automatic polling mode requires said polling means to poll at a user-specified time interval.

21. The system of claim 16, wherein said connectivity means includes a local are network connecting said first computer means to said second computer means.

22. The system of claim 16, wherein said particular data object includes at least one spreadsheet page from a spreadsheet notebook which is to be shared with the other user.

23. The system of claims 16, further comprising:

means, responsive to input from said one user, for issuing a new version of said particular data object if acceptance of the offer notification has been received.

24. The system of claim 16, further comprising:

versioning means for automatically forwarding new versions of said particular data object to said second computer means for storage in the storage device of said second computer if acceptance of the offer notification has been received.

25. The system of claim 24, wherein said versioning means includes:

means for setting a version depth, said version depth specifying how many versions of said particular data object are to be maintained in the storage device of said second computer means.

26. The system of claim 16, wherein said offer notification includes a descriptive message indicating a nature of said particular data object.

27. In a data processing system, a method for sharing data objects among subscribing users of a work group according to user-specified conditions, the method comprising:

(a) receiving from a publishing user a request for publishing a data object stored in the system to other users of the work group, said request specifying at least one condition by which the data object may be shared by other users;

(b) based on said at least one condition, announcing through electronic mail messages sent to the other users availability of a subscription to said data object;

(c) in response to said electronic mail messages receiving from at least some of the other users a confirmation for subscribing to said data object, each confirmation indicating that a user desires to receive said data object through electronic mail; and

(d) automatically providing each user subscribing to said data object with a copy of said data object, said copy being transmitted automatically to each user subscribing to said data object without further input from said publishing user.

28. The method of claim 27, further comprising:

(e) issuing a new version of said data object automatically to each user subscribing to said data object, whereby each user subscribing to said data object is automatically provided with a new version of said data object.

29. The method of claim 28, further comprising:

(f) receiving from at least one subscribing user a cancellation notice, so that the at least one user is no longer automatically provided with a new version of said data object.

30. The method of claim 27, wherein step (b) includes announcing to the other users availability of a subscription to said data object on a "don't ask" basis, so that the other users are automatically provided with a copy of said data object in step (e).

31. The method of claim 27, wherein said request for publishing a data object includes a publication list specifying all users of the work group with whom the data object may be shared.

32. The method of claim 27, wherein steps (b) and (c) are performed at a user-specified time interval, so that sharing of data objects among subscribing users of the work group may be deferred until occurrence of said user-specified time interval.

33. The method of claim 27, wherein the copy of said data object provided to each subscribing user is a read-only copy.

Description

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

The present invention relates generally to data processing environments and, more particularly, to systems for accessing shared information and other resources, such as in a multi-user environment.

The first personal computers (PCs) debuted in a corporate world which was dominated by mainframes and mini-computers--computers which handled large, centralized databases for the most part and ran little or no personal productivity software. As a result, these early PCs went largely unused. With the advent of electronic spreadsheets and other personal productivity software (e.g., wordprocessors), however, individual workers were soon empowered to handle their own data processing needs, thus the PC revolution was born.

Early on in the use of PCs, much emphasis was given to autonomy--removing users from the centralized control which was the hallmark of mainframes and mini-computers. Although this increased freedom led to increased productivity gains, users soon realized that they needed services which had been provided by the large centralized systems: shared printers, electronic mail, shared databases, and easy data transfer.

A solution to this problem was forthcoming in the form of Local Area Networks (LANs). A LAN typically comprises several computers connected together as a group. At least one of the computers functions as a "server," providing network services to "clients" (other computers) connected to the network. In this manner, valuable information and resources, including programs, information tables, memory, disk space, printers, and the like, may be shared by several users.

Early LAN systems were patchwork, unreliable systems that offered little more than printer and file sharing. These systems provided no built-in messaging facilities, no database or communications services, or the like. Moreover, PC operating system software (e.g., MS-DOS) took little or no advantage of LANs. Thus throughout most of the past decade, LANs essentially functioned as large storage and printer sharing devices; their true power had yet to be exploited.

Recently, LAN vendors, such as Novell, standardized on a series of protocols and APIs (Application Programming Interfaces) which allowed software vendors to make use of the LAN operating system itself. Novell, for instance, created NetWare.RTM. Loadable Modules (NLMs) for Netware 386; Microsoft created DLLs for LAN managers. By 1990, Novell's Message Handling System (MHS) protocol was in wide use. Shortly thereafter, Microsoft published its Messaging API (MAPI) specification. With evolving LAN technology, there was a renewed impetus to get corporate data to the decision makers quickly. The way that corporations created and used information began to change.

The most popular approach employed in this new corporate data processing environment is the "client/server" model. Using a client/server database system, for instance, an end user at a personal computer (client) submits a query to the database server, either directly by using the database or indirectly by using an application. The query is sent over the network to the database server, which processes the query and returns the result. Thus, the client/server model has been recognized as a fast way for deploying database applications in the corporate world. Although client/server database applications have finally begun to exploit LAN messaging services to deliver enhanced productivity, these benefits were not quickly extended to other personal productivity software--namely, spreadsheets and wordprocessors.

As Local Area Networks proliferated, it was recognized that the connectivity that LANs provided to client/server databases could be extended to other applications. The basic approach is that of a "workgroup." The premise of workgroup computing is that by imposing a structure--usually a logical organization consisting of rules-based automatic data distribution--on network-connected PCs, a group of people working together can achieve more than if each individual set out on his or her own and used the network only when necessary.

Currently-available workgroup products are server-based, network-specific implementations. These workgroup products impose a rigid structure on those who use them and do not yield results unless entire organizations commit to them completely. Every user in a workgroup must commit to using the workgroup software in a particular fashion before productivity gains for the group may be realized.

Dynamic working relationships within organizations are constantly forming and dissolving as tasks are completed and organizational objectives evolve, however. What is needed is a workgroup solution for enabling a workgroup, without restricting how each individual user completes his or her work, or interfering in how workgroup members connect to each other. The present invention fulfills this and other needs.

SUMMARY OF THE INVENTION

The system of the present invention comprises a computer system providing an Object Exchange module for sharing data objects among application processes (both remote and local). From a user's perspective, the Object Exchange is a publish-and-subscribe facility, which facilitates sharing among workgroups. When a data object, such as one or more spreadsheet pages from a spreadsheet notebook, is "published," it is sent from a desktop computer to other computer users specified by the publisher. Those interested in the published data object (published pages) may elect to receive or "subscribe" to that data. From that point on, the publisher can choose to update the data, such as whenever the published version changes. The "subscribers" of the published pages automatically get updates. Subscribers of a spreadsheet notebook, for instance, would automatically receive pages as they are published.

The system of the present invention includes a preferred interface and methods for publishing several versions of data objects. The first time a user publishes one or more pages from a notebook, he or she establishes the publication for that notebook by making it available to one or more workgroup members. After establishing a publication for a notebook, one can then issue new versions of the publication whenever desired. The user can also clear the current publication from the active notebook and then establish a new publication, or change the subscriber list at any time. After establishing a publication for a notebook, the user can issue new versions of that publication at any time. When one issues a new version, he or she can change the publication's contents, subscriber list, or both. One can also change the subscriber list without issuing a new version.

When a user publishes, issues versions, or mails data objects, the system submits the published or mailed objects to the Object Exchange, for holding them in its outgoing queues. When the Object Exchange polls an account, it transmits all the objects--notebooks, sets of pages, or individual pages--that the user has sent to that account, and picks up all the objects that the user has received to that account since the Object Exchange last polled it. The Object Exchange holds incoming objects in the user's Object Store, ready for use. Thus the Object Store holds copies of shared data objects and, thus, behaves like a database of the shared objects sent to the user. The Object Store makes all of the user's shared objects continuously available for use in any notebook, whether or not the user is currently connected to messaging services. In a preferred embodiment, shared objects remain in the Object Exchange until deleted.

The Object Exchange is preferably implemented not as an application in itself, but as a middle link between applications and the outside world. In other words, it interacts with the operating system and messaging services to provide workgroup and communication services to applications. The Object Exchange implements an object-sharing API (Application Programming Interface) so that existing applications (clients) can issue commands to the Object Exchange to add workgroup capabilities. Communication between the Object Exchange and a client application is effected through an interprocess communication link, such as available with Windows Dynamic Data Exchange (DDE) or Object-Linking and Embedding (OLE).

The Object Exchange (through its Object Manager) effects actions by posting messages or "forms" to either the local Object Exchange (assuming one is the publisher) or the Object Exchange of others (subscribers). Connectivity for the system is provided by the various Object Exchange engines negotiating forms. Each Object Exchange posts and retrieves forms at polling intervals (which may be set to continuous polling).

Publication to potential subscribers can occur in two forms: available ("ask") subscriptions and automatic ("don't ask") subscriptions. When an object is published on an "ask" basis, announcement of an available subscription is sent to subscribers. Subscribers may "accept" or "reject" the subscription. The former reply makes the subscriber active; the latter reply removes the subscriber from the authorized list. Subscribers who accept the subscription receive versions of the object.

"Don't ask" instructs the Object Exchange to send an "automatic subscription"--that is, one that does not require consent by the subscriber. Objects of this type are announced to users in a manner similar to normal E-mail: announcement (i.e., the declaration part) of the object arrives at the in-boxes of users, without asking those users beforehand. This requires the subscriber to respond by accepting the subscription. Once the reply is processed by the publisher, subsequent issues are automatically sent.

The protocol of distributing objects is, therefore, one of negotiating forms between various Object Exchange engines. The approach affords "deferred connectivity," allowing members to contribute to the workgroup--freely exchanging data objects--without being constrained in place or time. By exploiting the connectivity of existing transport media (e.g., LANs), the present invention delivers workgroup computing benefits to users, but without imposing a rigid structure which restricts when and how they work. Users may add as much or as little structure to workgroups as is necessary for the task at hand.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram of a computer system in which the present invention may be embodied.

FIG. 1B is a block diagram of a software system of the present invention, which includes operating system, application software, and user interface components.

FIG. 1C is a block diagram of a multi-user computing environment, such as a client/server system connected via a Local Area Network (LAN), in which the present invention is most preferably embodied.

FIG. 1D is a bitmap screenshot illustrating the basic architecture and functionality of a graphical user interface in which the present invention may be embodied.

FIG. 2A is a bitmap screenshot illustrating a spreadsheet notebook interface employed in a preferred embodiment of the present invention.

FIG. 2B is a bitmap screenshot of a toolbar component of the interface of FIG. 2A.

FIGS. 2C-D are bitmap screenshots illustrating page identifiers for rapidly accessing and manipulating individual pages of the notebook interface.

FIG. 3A is a diagram illustrating information (data object) flow according to the present invention.

FIG. 3B is a bitmap screenshot illustrating an Object Exchange interface of the present invention; a sample model (worksheet) has been loaded into the system.

FIG. 3C is a bitmap screenshot of a toolbar component of the interface of FIG. 3B.

FIG. 3D is a bitmap screenshot illustrating a configuration dialog for receiving user input specifying configuration for object exchanging.

FIG. 3E is a bitmap screenshot illustrating creation of new Object Exchange accounts, using the dialog of FIG. 3D.

FIGS. 3F-G are bitmap screenshots illustrating exemplary dialogs for configuring messaging (transport) accounts.

FIGS. 4A-D are bitmap screenshots illustrating exemplary dialogs for creating address books and grouping addresses within those books.

FIG. 5A is a bitmap screenshot illustrating an exemplary dialog for publishing a data object of interest.

FIG. 5B is a bitmap screenshot illustrating selection of recipients (subscribers) for the published object.

FIG. 5C is a bitmap screenshot illustrating selection of a data object (e.g., spreadsheet notebook pages) for publication.

FIG. 5D is a bitmap screenshot illustrating a dialog for issuing versions of a publication.

FIG. 5E is a bitmap screenshot illustrating a dialog for "mailing" a data object.

FIG. 6A is a bitmap screenshot illustrating an exemplary interface for using data objects (e.g., notebooks and pages) which a user has received (in his or her role as a subscriber).

FIG. 6B is a bitmap screenshot illustrating insertion of a data object (e.g., page) into one's current data (e.g., spreadsheet notebook).

FIG. 7 is a block diagram illustrating an Object Exchange Engine of the present invention, and its relation to client processes (applications) and messaging services (transports).

FIG. 8 is a block diagram illustrating connecting remote object exchanges through one or more messaging services in accordance with the present invention, thereby establishing a deferred connectivity workgroup system.

FIGS. 9A-G are block diagrams illustrating a distributed object protocol of the present invention.

GLOSSARY

accounts list: List of all accounts created with OBEX, along with icons that indicate the current status of each account. The accounts list appears on the left side of OBEX window.

account name: A unique name that is given to an OBEX account when it is created. The account name appears in the account's list on the left side of OBEX window.

address: The unique electronic mail or communication system address that is used when mailing or publishing objects to other members of a workgroup.

address book: A set of files that contain addresses of other OBEX users to whom information may be distributed.

address group: A group of users within an address book. Groups may be used as distribution lists when publishing objects.

alert: An OBEX error message. OBEX generates alerts when it encounters problems polling or queuing messages to accounts.

alias: A "nickname" that may be used in place of a complete address.

automatic updating: The process by which published data automatically appears in a subscriber application.

connection script: A string of commands that enables connection with MCI Mail when direct dial in does not work. A connection script consists of commands both issued and received by OBEX.

DDE: Stands for Dynamic Data Exchange, a protocol for memory-based communication between Windows applications.

DDE client: An application that initiates a DDE conversation with a named DDE server and makes requests of it.

DDE item: A string that acts like a server-owned variable within a particular DDE topic. In OBEX, every item is classified according to how it can be used, as follows:

Action: The client can poke Action items with specified values to trigger an OBEX action.

ReadOnly: The client can request ReadOnly items, but cannot poke them.

ReadWrite: The client can both request and poke ReadWrite items.

DDE server: An application that offers services to other applications via DDE. When a server opens, it registers its server name with the DDE system, making it available to DDE client applications. When the OBEX Enabling Kit is used, OBEX is a DDE server.

DDE topic: A string defining the type of service requested (sent from the DDE client to the DDE server).

hot link: A DDE link where the DDE server sends data to the DDE client whenever the data changes.

LAN mailbox: A directory that is created on a network file server that enables the LAN to store and forward objects and messages.

mail system: Like MCI, MHS, and Windows for Workgroups, mail systems provide messaging and communication services over LANs, WANS, or telephone lines.

manual updating: The process by which published data appears in the subscriber application only when the subscriber requests an update.

messaging account: Accounts created with OBEX that enable communication with existing messaging service accounts. Messaging services include mail systems such as MCI and MHS, as well as Windows for Workgroups, cc:Mail, and a variety of LANs.

messaging service: Messaging services include mail systems such as MCI, MHS, and Windows for Workgroups, as well as E-mail programs such as cc:Mail and Microsoft Mail.

modem: A device that transmits and receives data through telephone lines. Modems modulate digital computer signals into analog signals that telephone lines can carry, and demodulate analog signals received through telephone lines back into digital signals before passing them to a computer.

OBEX.TM.: Object Exchange module which is the agent that enables users to establish and manage ongoing publication-distribution relationships among workgroup members and applications.

object: Any data component packaged and distributed as a message. For example, spreadsheet objects can be notebooks, pages, and sets of pages. Database objects can be results of queries and tables.

object store: A private OBEX directory that stores shared objects mailed or published to the user.

poke: Set the value of an item in a DDE conversation.

polling: The process of sending out and picking up objects. OBEX polls, or contacts, an account both to transmit outgoing objects and pick up incoming ones. Accounts may be polled manually, or OBEX can poll the accounts automatically at specified intervals.

post office: A directory that contains mailbox subdirectories. OBEX uses post offices and mailboxes to let users send objects over LANs.

publishing and subscribing: When information is sent to other workgroup members, that information is published. Those who receive the information are subscribers.

primary account: When there are multiple accounts for a messaging service, one account is designated as primary. OBEX automatically queues messages into the primary account.

request: A message from a DDE client to a DDE server to send data, receive data, or execute a command.

server name: A string used by the DDE system to identify the server in a DDE dialog. For many applications, the server name is the same as the file name. For example, the server name for the application OBEX.EXE is "obex".

transport: Transports include mail systems such as MCI, MHS, and Windows for Workgroups, as well as E-mail programs such as cc:Mail and Microsoft Mail. OBEX also uses a variety of LANs to exchange messages and objects.

version: One of possibly many variations of a published object. The act of modifying published data and publishing the new data to subscribers is called issuing a new version of that publication.

version depth: The number of versions of given publication available to a subscriber. The version depth is set by the publisher.

warm link: A DDE link where the DDE server notifies the DDE client whenever data changes.

workgroup: A group of two or more people responsible for or involved with a particular task for a particular period of time.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

System Hardware

As shown in FIG. 1A, the present invention may be embodied on a computer system such as the system 100, which comprises a central processor 101, a main memory 102, an input/output controller 103, a keyboard 104, a pointing device 105 (e.g., mouse, track ball, pen device, or the like), a display device 106, and a mass storage 107 (e.g., hard disk). Additional input/output devices, such as a printing device 108, may be included in the system 100 as desired. As illustrated, the various components of the system 100 communicate through a system bus 110 or similar architecture. In a preferred embodiment, the computer system 100 includes an IBM-compatible personal computer, which is available from several vendors (including IBM of Armonk, N.Y.).

Illustrated in FIG. 1B, a computer software system 120 is provided for directing the operation of the computer system 100. Software system 120, which is stored in system memory 102 and on disk memory 107, includes a kernel or operating system 121 and a windows shell 123. One or more application programs, such as application software 122, may be "loaded" (i.e., transferred from storage 107 into memory 102) for execution by the system 100. The system 100 receives user commands and data through user interface 126; these inputs may then be acted upon by the system 100 in accordance with instructions from operating module 121 and/or application module 122. The interface 126, which is preferably a Graphical User Interface (GUI), also serves to display results, whereupon the user may supply additional inputs or terminate the session. In a preferred embodiment, operating system 121 is MS-DOS, and shell 123 is Microsoft.RTM. Windows; both are available from Microsoft Corporation of Redmond, Wash. Application(s) module 122, on the other hand, includes spreadsheet application software in a preferred embodiment (as described in further detail hereinbelow).

As shown, the system 120 also includes an Object Exchange Engine 125 of the present invention. In response to requests from client processes (e.g., applications 122), the Object Exchange 125 effects data sharing with other remote systems. For local storage, the Object Exchange 125 includes an Object Store 127--storage (typically allocated from device 107) for holding data objects to be shared. Before the Object Exchange and Object Store are described in further detail, however, other features of the present invention will first be presented.

Network Architecture

While the present invention is operative within a single (standalone) computer (e.g., system 100 of FIG. 1A), the present invention may be embodied in a multi-user computer system, such as the client/server system 130 of FIG. 1C. Specifically, system 130 includes a first computer or server 131 and one or more second computers or clients 150. In an exemplary embodiment, the clients or workstations 150 are connected to server 131 through a computer network 141, which may be a conventional Local Area Network (LAN). Network 141 includes cabling 145 for connecting the server and each workstation to the network. The workstations themselves will be similar to or the same as system 100; additionally, each typically includes a network connector or adapter 143 for receiving the network cable 145, as is known in the art. Server 131 may also be similar to or the same as system 100. Because the server manages multiple resources for the clients, it should preferably include a relatively faster processor, larger mass storage, and more system memory than is found on each workstation.

Overall operation of the system 130 is directed by a networking operating system 137, which may be stored in the server's system memory; in a preferred embodiment, OS 137 includes NetWare.RTM., available from Novell of Provo, Utah. In response to requests from the clients 150, the server 131 provides various network resources and services. For instance, multiple users (e.g., workstations A, B, and C) may view a database table stored in file server storage 139, while another user (e.g., workstation E) sends a document to a network printer (not shown).

The general construction and operation of a computer network has been well documented in the technical, trade, and patent literature. For a general introduction to a Local Area Network operating under NetWare, see Freed, L. et al., PC Magazine Guide to Using NetWare, Ziff-Davis Press, 1991. A more detailed discussion is available in NetWare.RTM. and accompanying documentation, which is available from Novell of Provo, Utah. For a discussion of a computer network employing Microsoft Networks/OpenNet File Sharing Protocol, see METHOD AND SYSTEM FOR OPPORTUNISTIC LOCKING IN A NETWORKED COMPUTER SYSTEM, Intl. Application No. PCT/US90/04570, Intl. Publication No. WO 91/03024, Intl. Publication Date Mar. 7, 1991. The disclosures of each of the foregoing are hereby incorporated by reference.

Interface

A. Introduction

The following description will focus on the presently preferred embodiments of the present invention, which are embodied in spreadsheet application software operative in the Microsoft.RTM. Windows environment. The present invention, however, is not limited to any particular application or any particular environment. Instead, those skilled in the art will find that the teachings of the present invention may be advantageously applied to a variety of other applications, including database management systems, wordprocessors, and the like. Moreover, the present invention may be embodied on a variety of different platforms, including Macintosh, UNIX, NextStep, and the like. The present invention is particularly advantageous when applied in those instances where data objects are to be shared. Therefore, the description of the exemplary embodiments which follows is for purposes of illustration and not limitation.

Referring now to FIG. 1D, the system 100 includes a windowing interface or workspace 160. Window 160 is a rectangular, Graphical User Interface (GUI) for display on screen 106; additional windowing elements may be displayed in various sizes and formats (e.g., tiled or cascaded), as desired. At the top of window 160 is a menu bar 170 with a plurality of user-command choices, each of which may invoke additional submenus and software tools for use with application objects. Window 160 includes a client area 180 for displaying and manipulating screen objects, such as graphic object 181 and text object 182. In essence, the client area is a workspace or viewport for the user to interact with data objects which reside within the computer system 100.

Windowing interface 160 includes a screen cursor or pointer 185 for selecting and otherwise invoking screen objects of interest. In response to user movement signals from the pointing device 105, the cursor 185 floats (i.e., freely moves) across the screen 106 to a desired screen location. During or after cursor movement, the user may generate user-event signals (e.g., mouse button "clicks" and "drags") for selecting and manipulating objects, as is known in the art. For example, Window 160 may be closed, resized, or scrolled by "clicking" (selecting) screen components 172, 174/5, and 177/8, respectively.

In a preferred embodiment, screen cursor 185 is controlled with a mouse device. Single-button, double-button, or triple-button mouse devices are available from a variety of vendors, including Apple Computer of Cupertino, Calif., Microsoft Corporation of Redmond, Wash., and Logitech Corporation of Fremont, Calif., respectively. More preferably, screen cursor control device 105 is a two-button mouse device, including both right and left "mouse buttons."

Programming techniques and operations for mouse devices are well documented in the programming and hardware literature; see e.g., Microsoft Mouse Programmer's Reference, Microsoft Press, 1989. The general construction and operation of a GUI event-driven system, such as Windows, is also known in the art; see, e.g., Petzold, C., Programming Windows, Second Edition, Microsoft Press, 1990. The disclosures of each are hereby incorporated by reference.

B. Preferred interface

Shown in FIG. 2A, a spreadsheet notebook interface employed in the preferred embodiment will now be described. The spreadsheet notebook or workbook includes a notebook workspace 200 for receiving, processing, and presenting information, including alphanumeric as well as graphic information. Notebook workspace 200 includes a menu bar 210, a toolbar 220, a current cell indicator 230, an input line 231, a status line 240, and a notebook window 250. The menu bar 210 displays and invokes, in response to user inputs, a main level of user commands. Menu 210 also invokes additional pulldown menus, as is known in windowing applications. Input line 231 accepts user commands and information for the entry and editing of cell contents, which may include data, formulas, macros, and the like. Indicator 230 displays an address for the current cursor (i.e., active cell) position. At the status line 240, system 100 displays information about the current state of the workbook; for example, a "READY" indicator means that the system is ready for the user to select another task to be performed.

The toolbar 220, shown in further detail in FIG. 2B, comprises a row or palette of tools which provide a quick way for the user to choose commonly-used menu commands or properties. In an exemplary embodiment, toolbar 220 includes Cut, Copy, and Paste buttons 221, a Power Button tool 222, a Graph tool 223, Alignment buttons 224, Font buttons 225, a Style List 226 with pulldown 227, Insert/Delete and Fit buttons 228, Action (e.g., sort, sum, and the like) buttons 229, and an "Expert" (tutor) button 230. The functions of these buttons are suggested by their names. For instance, buttons 221 cut, copy and paste data and objects to and from Windows' clipboard. The same actions are also available as corresponding commands in the Edit menu (available from menu bar 210). Tool 220 creates "powerbuttons" which allow a user to run spreadsheet macros; in a specific embodiment, powerbuttons appear as floating objects in a layer above spreadsheet cells. In a similar fashion, the Graph tool 223 creates floating graphs that appear above spreadsheet cells.

The notebook, which provides an interface for entering and displaying information of interest, includes a plurality of spreadsheet pages. Each page may include conventional windowing features and operations, such as moving, resizing, and deleting. In a preferred embodiment, the notebook includes 256 spreadsheet pages and one Graphs page, all of which are saved as a single disk file on the mass storage 107. Workspace 200 may display one or more notebooks, each sized and positioned (e.g., tiled, overlapping, and the like) according to user-specified constraints.

Each spreadsheet page of a notebook includes a 2-D spread. Page A from the notebook 200, for example, includes a grid in row and column format, such as row 3 and column F. At each row/column intersection, a box or cell (e.g., cell C4) is provided for entering, processing, and displaying information in a conventional manner. Each cell is addressable, with a selector being provided for indicating a currently active one (i.e., the cell that is currently selected).

As shown in FIGS. 2C-D, individual notebook pages are identified by page identifiers 260, preferably located along one edge of a notebook. In a preferred embodiment, each page identifier is in the form of a tab member (e.g., members 261a, 262a, 263a) situated along a bottom edge of the notebook. Each tab member may include representative indicia, such as textual or graphic labels, including user-selected titles representing the contents of a corresponding page. In FIG. 2C, the tab members 260 are set to their respective default names. For example, the first three tab members (members 261a, 262a, 263a) are respectively set to A, B, and C. Tab members are typically given descriptive names provided by the user, however. As shown in FIG. 2D, for example, the first three tab members have now been set to "Contents" (tab member 261b), "Summary" (tab member 262b), and "Jan" (tab member 263b). In a similar manner, the remaining tabs are set to subsequent months of the year. In this manner, the user associates the page identifiers with familiar tabs from an ordinary paper notebook. Thus, the user already knows how to select a page or spread of interest: simply select the tab corresponding to the page (as one would do when selecting a page from a paper notebook).

In addition to aiding in the selection of an appropriate page of information, the user-customizable page identifiers aid in the entry of spreadsheet formulas. For example, when entering a formula referring to cells on another page, the user may simply use the descriptive page name in the formula itself, thus making it easier for the user to understand the relationship of the cell(s) or information being referenced.

A general description of the features and operation of the spreadsheet notebook interface may be found in Quattro.RTM. Pro for Windows (Getting Started, User's Guide and Building Spreadsheet Applications), available from Borland International; additional description may be found in U.S. patent application Ser. No. 07/866,658, commonly owned by the present assignee.

Distributed Object Architecture

A. Introduction

The present invention exploits the connectivity of existing transport media (e.g., LANs, email, and the like) in order to deliver workgroup computing benefits to users, but without imposing a rigid structure which restricts when and how they work. The present invention makes sharing of data over the network or through messaging services completely transparent to the computer user, thus allowing that user to specify when and how sharing will take place.

The system of the present invention employs an object exchange architecture, which may be viewed from two perspectives. From the user's perspective, the Object Exchange is a publish-and-subscribe facility, as shown in FIG. 3A, which facilitates sharing among workgroups. When a data object, such as one or more spreadsheet pages from notebook 310, is "published," it is sent from a desktop computer to other computer users specified by the publisher. Those interested in the published data object (published pages 320) may elect to receive or "subscribe" to that data. From that point on, the publisher can choose to update the data, such as whenever the published version changes. The "subscribers" of the published pages 320 automatically get updates. For this example, the spreadsheet notebook of each subscriber (e.g., notebook 330) would automatically receive pages as they are published.

The publish/subscription model is well suited for solving real-world data processing needs. Consider, for instance, a hypothetical company having four sales districts, each having a manager responsible for reporting sales activities. These four managers report to a country manager, who in turn presents a summary report every week to the vice president of Sales for the company. Restated in terms of a publish/subscribe model, the job of all four district managers is to publish their sales reports at the end of the week. The sales director subscribes to these reports, thereby receiving an update automatically (e.g., upon polling by the system). With each new instance or versions of previously subscribed objects, the system automatically updates the sales director's summary sheet. The director then sends the updated summary report, via publication, to the VP of Sales (and any other interested subscribers).

Employing this model, the system of the present invention enables users to add as much or as little structure to workgroups as is necessary for the task at hand. A group may choose to poll published media every morning, or implement automatic polling, or use lists of subscribers so that published data is distributed in an organized manner. Thus, the system's publish-and-subscribe facility works the way users do.

B. Tools

As shown in FIG. 3B, the system of the present invention includes workgroup tools. The figure shows a spreadsheet notebook 350 displaying a first page ("East"). The page or spread includes a hypothetical model for monthly sales of a beverage company. Upon invocation of a Workgroup Desktop command (Data.vertline.Workgroup Desktop, from the main menu), the system displays a Workgroup Desktop Toolbar 360, which includes preferred tools of the present invention for effecting workgroup management.

Shown in further detail in FIG. 3C, these tools will now be described. Mail button 361 allows a user to mail a data object, such as a page, a set of pages, an entire spreadsheet notebook, or other data object, to selected other users. Publish button 362 lets the user publish a data object to selected other users, set a version depth, issue new versions of published data objects, manage a subscriber list, and clear any current publication from the active notebook. Use button 363 lets the user insert mailed or published data objects into his or her own notebooks, use mailed notebooks, and delete objects from the Object Exchange module. Manage Pages button 364 lets the user see information on mailed and published pages inserted into the active notebook; rename, update, and change the update method of mailed and published pages individually; change the version of published pages individually, and remove mailed and published pages from the active notebook. Index button 365 displays a "workgroup index" (a special notebook page named "Workgroup") that contains information on the active notebook's current publication and all shared pages currently inserted into it. Address button 366 lets the user create and select address books, create and manage address groups, and manage addresses of workgroup desktop users contained in the address books and groups. The Poll button 367 instructs the Object Exchange module of the system to poll one or more (primary) messaging accounts.

Active Account box 368 functions to display the name of the primary account that the Object Exchange module is currently polling. Outgoing box 369 indicates how many items in the Object Exchange module are waiting to be sent. Finally, an Alerts button 370 is provided for allowing the user to view, delete, and clear any alerts (e.g., error messages) from the Object Exchange module.

C. User configuration

The system of the present invention includes a preferred interface for creating, configuring, modifying, and deleting messaging accounts, for creating and selecting address books, and for creating and managing address groups. With reference to FIGS. 3D-G, the preferred interface will now be described.

The user interface for the Object Exchange module is shown in FIG. 3D. Object Exchange window 380 includes a menu bar 381, Account Status indicator 382a, Polling Mode indicator 382b, Active Transport indicator 383, Poll Now button 384, and Object Exchange Detail (status) area 385.

Menu bar 381 includes an Accounts submenu (submenu 386 of FIG. 3E) for adding, deleting, and configuring messaging or transport accounts. The Account Status indicator 382a tells the user how many objects are waiting to be sent through each account. As shown, for instance, the Object Exchange dialog 380 of FIG. 3D has no (zero) objects waiting to be sent via MCI Mail. Polling Mode indicator 382b allows the user to specify a polling mode (e.g., automatic or manual) for each messaging account; if desired, polling may also be deactivated for particular accounts. The right side of the Object Exchange window 380--the Active Transport indicator 383--displays each step of the polling process. Screen indicators are provided for telling the user when the Object Exchange module is logging into an account, querying an account for objects to transmit or pick up, sending objects, or logging out of an account. Indicator 383 includes a message box beneath the polling indicators for displaying screen messages of activity when the Object Exchange module polls an account. The Poll Now button 384, when activated by the user, instructs the Object Exchange module to poll the currently selected messaging account (as highlighted in 382a).

Object Exchange detail area 385 provides a list of all outgoing objects waiting to be sent by the Object Exchange. Alerts (system messages) are displayed in a drop-down list box. The bottom box shows the status of the Object Exchange outgoing queue and provides details about each object waiting to be sent out; details include the sender's user name and messaging service that the object is being sent through.

The first time a user invokes the Object Exchange module, the Accounts list (as displayed in indicator region 382a) is empty. Therefore, an interface is provided for configuring new accounts. Each account created by the user includes a descriptive name for the account, which will appear in the Accounts list 382a. Each account corresponds to a messaging service account or LAN mailbox. The user can create as many accounts as are needed for each messaging service. When configuring an account, the user simply supplies information needed to connect with his or her messaging service accounts or mailboxes. Also at this time, the user can set a polling frequency for each messaging account, telling the system how often and between what hours to poll.

As shown in FIG. 3E, the user defines a new account by selecting New from the account's submenu 386. In response, the system displays the New Account dialog box 387. From the dialog 387, the user selects a desired messaging service (e.g., MCI, MHS, LAN, MAPI, and the like) from the Transport list. Upon selection of a particular messaging service, the system displays a Configuration Dialog box for receiving user-supplied account information. Exemplary configuration dialog boxes for MCI and LAN accounts will be illustrated.

FIG. 3F illustrates an MCI Configuration Dialog 390 which is displayed when the user selects MCI from the Transport list (of dialog 387). The user is required to supply his or her MCI user name and password in Account Information region 391. Modem Configuration region 393 and Communication region 394 receive user input for specifying a modem type and communication port/protocol.

Polling Input region 392 allows the user to specify that the messaging account is to be polled automatically. Here the user indicates a frequency: how often the Object Exchange module is to poll the account. The user may also specify 24-hour polling, for round-the-clock polling. Alternatively, the user may select "from" and "to" for restricting polling to certain hours.

FIG. 3G illustrates a Configuration dialog for configuring a LAN account. The dialog receives user input specifying an account name, a mailbox name, and a post office path (the location of the drive and directory that contains the LAN mailbox). In a similar manner, configuration dialogs may be provided for receiving the particulars of other messaging accounts.

F. Address Book

The system of the present invention includes electronic address books, in the form of spreadsheet notebooks, for storing addresses of workgroup desktop users. Although one does not have to use an address book to mail or publish, address books greatly simplify the process of managing mailing and subscriber lists. Address books can reside either on a shared computer for use by all workgroup members (who have access rights to it), or on any user's local computer. For shared address books created and maintained by a system administrator, each workgroup user need only select a particular address book to gain access to all of the addresses contained in it. The user is given the option of creating his or her own local or private address books, organized in a fashion that is convenient for the user.

Each address book includes entries having an alias--a unique user name that can be used in place of a full address--and a delivery address. If a user has more than one address (e.g., has both MHS and LAN addresses), the address book can contain both addresses, with a different alias for each.

Every address book contains one default group (named "Everybody"), which includes every address entered into that address book. The user can create additional address groups comprising addresses from the Everybody group. In this manner, the groups can function as distribution lists for addressing mail or publications to many workgroup desktop users at once. For instance, an address book might include one address group for a company, department, project, or the like. Address groups can share addresses with other groups, and the user can modify a group membership at any time.

Referring now to FIGS. 4A-D, a preferred interface for managing workgroup addresses will be illustrated. Upon selecting the Workgroup Address button (button 366 from FIG. 3C), the system displays an Address Book dialog box 410, as shown in FIG. 4A. The path and name of the currently selected address book appears in Selected Book edit field 412. To select a different address book, the user chooses Select Book radio button 411, and then chooses "Ok" (from buttons 418); in response, the system displays a filename dialog box for selecting a new address book.

To create a new address book the user chooses the Create New Book radio button 419 and selects "Ok". The user can now enter aliases, addresses, and groups into the new address book. After naming the address book (e.g., with a descriptive title), the user proceeds to enter names and addresses.

As shown in FIG. 4B, the system provides a Manage People dialog 420 for receiving the alias (name) and address for each address book entry. As shown, the dialog includes an Alias edit field 428 and an Address edit field 429; these receive alias and address information, respectively. To assist with data entry, the dialog 420 includes button tools 421-427. New button 421 creates a new, blank entry, which is added after the last (previous) entry. Delete button 422 erases the active entry. Go Next button 423 displays the next entry. Go Previous button 424 displays the previous entry. Revert button 425 cancels edits to the current entry, thus restoring original data. Search button 426 turns on a search mode which allows the user to search for entries in the address book. When the user has completed address book data entry, Close button 427 is selected.

In a preferred embodiment, the user can create groups for selected address books at any time. Groups serve as distribution lists to use when one is building mailing and subscriber lists. The user can populate groups with addresses from the Everybody group. The user can create as many groups as desired in an address book.

From the Address Book dialog 410 (of FIG. 4A), the user selects Create New Group radio button 415 and chooses "Ok." In response, the system displays Create New Group dialog box 430, as shown in FIG. 4C. Dialog 430 includes a Group Name edit field 431, for receiving a user-specified name. Buttons 433 allow the user to accept or cancel the new group name.

After specifying a name for the new group (e.g., selecting "Ok" button 433), the system displays Group Management dialog box 440 for the user-specified group, as shown in FIG. 4D. The dialog 440 includes an Aliases box 442 listing all of the addresses (by alias), and includes a Group list box 441 for listing all of the groups in the current address book. To add an address to the group, the user selects an alias from the Alias box 442 (or types an alias in the Alias text box) and then chooses Add button (from buttons 444). To add all members of any existing group to a new group, the user selects the group from the Groups List 441 and then chooses the Add Group button (from buttons 444). To remove addresses from the group, the user selects the address desired to be removed in the Members box (right-hand side) and chooses Remove button (from buttons 444). Remove All button removes all addresses from the group. To save a new group with addresses added, the user chooses "Ok" from buttons 443. To save the new group without entering any addresses into it, the user chooses Cancel. To delete a new group, the user chooses Clear.

E. Sharing data objects: Pages and Notebooks

Once an Object Exchange account has been created, the system is ready to begin publishing and mailing data objects. Publishing and subscribing of data objects, such as spreadsheet notebook pages, establishes ongoing data-sharing relationships between one's own data objects and those of remote users. When a user publishes notebook pages and other workgroup members subscribe to them, the data in those pages appear in the subscriber notebooks exactly as it appears in the user's own notebook. After establishing a publication for a notebook, one can change the data in his or her pages or the set of pages he or she is publishing and issue new versions of the publication to subscribers. The subscribers in turn can decide to have those changes appear automatically in their notebooks, or to appear only when they request an update.

The user can set a "version depth" for each publication. The version depth determines how many versions of a publication will be available to subscribers at any given time. If a user wants subscribers to have access to the last twelve months of a monthly sales report, for instance, he or she would set the version depth to twelve. This gives subscribers access to the most recent version as well as to the eleven previous versions. Similarly, if one wanted to publish a scenario page with six pages of variables serving as input, the user would create a single publication with a version depth of six and issue each variables page as a version of that publication. Since subscribers can use any available version, they can insert each version of the variables page in a separate notebook page, or insert the variables page once and simply change the version number to see how many different sets of data affect the scenario.

In a preferred embodiment, published pages are read-only pages. In other words, the published pages are "owned" by the publisher. Subscribers can copy the published data, refer to it in spreadsheet formulas, and redistribute it.

1. Establishing a publication

Referring now to FIG. 5A, a preferred method and interface for publishing a data object will now be described. The first time a user publishes one or more pages from a notebook, he or she establishes the publication for that notebook by making it available to one or more workgroup members. After establishing a publication for a notebook, one can then issue new versions of the publication whenever desired. The user can also clear the current publication from the active notebook and then establish a new publication, or change the subscriber list at any time.

To establish a publication, the user selects the Publish button 362 (from FIG. 3C). In response, the system displays Publish dialog box 510, as shown in FIG. 5A. The user enters a description for the publication in Description edit field 511. As subscribers will see available publications listed by description, users will typically include descriptive text here. Next, subscribers are specified in the Subscribers edit field 513. By selecting the accompanying Names button, the user may display a dialog for selecting subscribers. Contents field 515 allows the user to specify data objects of the notebook to be published. Version Depth edit field 517 allows the user to in enter a value of version depth; the default is 1. Finally, the user may proceed to publication by selecting the Publish button (from buttons 519). Alternatively, the user may abort the process by selecting the Cancel button.

FIG. 5B shows a Select Names dialog box 520 which is displayed upon selection of the Names button (from the dialog 510 of FIG. 5A). The Alias box 521 lists all of the addresses (by alias) and Groups box 523 lists all of the groups, in the current address book. Complete addresses appear in Names list 525 when the user chooses Add Name button (from buttons 524). To add a subscriber to the list, one selects an alias and then chooses Add Name. To add a group of subscribers to the list, one selects the group name from the Groups drop-down list 523, and selects Add Group. The user selects Everybody to publish to all subscribers listed in the address book. To add a subscriber who does not appear in the Alias box, the user types the subscriber's complete address in Additional Address edit field 527. To remove subscribers from the subscriber list, one selects the name desired to be removed in the Names List box 525, and then chooses Remove Name. Remove All removes all subscribers from the subscriber list. After creating the subscriber list, the user may close the dialog by selecting "Ok" button (from buttons 526); this returns the user to the Publish dialog box 510 (of FIG. 5A). Alternatively, the user may cancel the dialog by selecting Cancel.

Upon selection of the Select button of the contents field 515 (of FIG. 5A), the system displays Select Pages dialog box 530 as shown in FIG. 5C. Here, the user selects the contents of the publication. The Named Pages box 533 lists all of the named pages in the active notebook (except for the Graphs and Workgroup pages). Description field 531 displays the descriptive text (which the user had previously entered). To add a page to the selected set, one selects the page and chooses Add Page (from buttons 535), or enters the page letter in Page edit field 537; the user then chooses Add. To publish all listed pages, one chooses Add All. To add an unnamed page to the selected set, one enters the page's letter in the Page edit field 537 and chooses Add. To remove a page from the selected set, one selects the page desired to be removed in the Selected Pages list 536 and chooses Remove. A Remove All button is provided for removing all pages from the selected set. After completion of data entry, the user concludes the dialog by selecting "Ok" or Cancel (from buttons 534). Closing the dialog 530 returns the user back to the Publish dialog box 510. At this point, the Object Exchange stores the publication in its outgoing queues until the next time it polls the messaging services.

2. Issuing new version of a publication

After establishing a publication for a notebook, the user can issue new versions of that publication at any time. When one issues a new version, he or she can change the publication's contents, subscriber list, or both. One can also change the subscriber list without issuing a new version.

Referring now to FIG. 5D, an interface and method for issuing a new version of a publication will be illustrated. First, the user opens a notebook in which he or she established the original publication. Next, the user selects the Publish button 362 (of FIG. 3C). In response, the system displays Publication dialog 540 for the active publication. Description field 541 displays the previously-entered descriptive text for the publication. Subscribers field 542 displays the subscribers for the publication. If one desires to modify the publication's contents, new information would be entered into the Contents field 543. If one wants to modify the subscriber list, Manage button (from buttons 545) is selected. The Select Names dialog 520 (of FIG. 5B) is redisplayed for editing the subscriber list for this publication. Finally, the user issues the new version by choosing Issue (from buttons 545).

The user can clear a publication from a notebook at any time. Clearing a publication removes that publication's settings from the active notebook. (It does not delete the corresponding spreadsheet data.) In a preferred embodiment, published pages that subscribers have already inserted into their notebooks remain as they are, until those subscribers delete them. Once a publication is cleared from the active notebook, the user can establish a new publication at any time. To clear the publication from the notebook, the user selects Clear from the Publication dialog box 540.

3. Mailing notebooks and pages

The user may "mail" a notebook, sending the entire notebook and all of its properties. Recipients receive all data values, cell formats, formulas, graphs, graphics, and the like. Mailing a notebook is useful when one wants to distribute a model or template, such as a form that should be filled out a certain way, to a number of users. The user can also mail selected pages from a notebook. This is done when one wants to send a set of data or a report to a group of users once, but does not need to update them later. As with publishing, mailing pages sends the data values and cell formats from the original notebook pages (but in a preferred embodiment does not send formulas, graphs, or graphics). Recipients can copy mailed data, referred to at end formulas, and redistribute it. Preferably, however, they cannot change it and save the changes, because mailed pages are read-only pages "owned" by the sender.

Referring now to FIG. 5E, an interface and method for mailing data objects will now be illustrated. Upon the user selecting the Mail button 361 (of FIG. 3C), the system displays Mail dialog 550, as shown in FIG. 5E. In Description edit field 551, the user enters a description of the notebook or sets of pages. In To edit field 552, the user creates a mailing list (in the same manner as was done for creating the above-described subscriber list). The user selects contents from Contents field 553, in the same manner as was done above. Upon completion of data entry, the user selects Mail (from buttons 555); the process may be cancelled if desired. Upon receiving the instruction to mail a data object, the Object Exchange holds the notebooks or pages desired to be sent in its outgoing queue until the next time it polls the messaging services.

When a user publishes, issues versions, or mails data objects, the system submits the published or mailed objects to the Object Exchange, for holding them in its outgoing queues. When the Object Exchange polls an account, it transmits all the objects--notebooks, sets of pages, or individual pages--that the user has sent to that account, and picks up all the objects that the user has received to that account since the Object Exchange last polled it. The Object Exchange holds incoming objects in the user's Object Store, ready for use. Thus the Object Store holds copies of share data objects and, thus, behaves like a database of the shared objects sent to the user. The Object Store makes all of the user's shared objects continuously available for use in any notebook, whether or not the user is currently connected to messaging services. In a preferred embodiment, shared objects remain in the Object Exchange until deleted.

F. Using shared pages and notebooks

Pages published and mailed to a user as a set are grouped together under one description. To use mailed pages or subscribe to published pages, the user inserts them into a notebook of his or her choice. In this manner, the user can insert mailed and published pages from a variety of sources into a single notebook, limited only by the number of available blank pages. The user can insert the set of pages into a notebook, or can insert selected pages from the set. The user can also insert the same page or set of pages simultaneously into many notebooks.

When a user inserts published pages, he or she becomes a subscriber. Subscribing establishes remote, dynamic links with the publisher's notebook. When the publisher issues new versions of the published pages, the user's Object Exchange automatically receives them and responds accordingly to the update method specified by the user (i.e., automatic or manual updating).

Automatic updating automatically inserts new versions of published pages into the user's notebooks when his or her Object Exchange receives them. Manual updating, on the other hand, inserts new versions only when the user requests an update.

The version depth (set by the publisher in a preferred embodiment) determines how many versions of a set of published pages the Object Exchange can store at any one time. If the publisher sets the version depth to 12, the object store of the subscriber holds the 12 most recent versions that the publisher has issued. The subscriber can use any available version of a publication at any time.

Unlike published pages, mailed pages are single-issue only. The user inserts mailed and published pages into his or her notebooks in the same way, but mailed pages cannot be updated. Mailed pages are useful when a workgroup member wants to send a set of data or a report once, but does not need to issue new versions of it later.

Referring now to FIG. 6A, a preferred interface and method for using published or mailed objects will now be illustrated. Initially, the user selects the Workgroup Use button 363 (from FIG. 3C). In response, the system displays Use Notebooks and Pages dialog box 610. The dialog 610 includes a Description list 611 describing all objects --pages, sets of pages, and notebooks--currently stored in the user's Object Exchange. As the user scrolls through the list, the bottom part of the dialog changes to show information on the selected object. The Contents field 612 shows the selected object's type (e.g., mailed pages, published pages, mailed notebook, or the like). Distributed By field 613 includes the address of the user who mailed or published the selected object. If the selected object is one of the user's own publication, "OBEX" (for Object Exchange) appears here. Last Distributed field 614 displays the data and time the last version of the selected object was published, or when it was mailed. For published pages having more than one version (i.e., the publisher has specified a version depth greater than 1), the user can select a particular version to insert through Version box 615. Update Method box 616, on the other hand, allows the user to select an update method (manual or automatic). Pages field 617 allows the user to select only some of the pages into the notebook. By default, all of the pages in a selected set are inserted into the notebook. The user selects or deletes objects using the buttons 618. Selected pages are inserted into the active notebook, using the first available empty, unnamed pages.

Referring now to FIG. 6B, a preferred interface and method for managing inserted pages will now be described. After the user has opened the notebook that contains the inserted pages, he or she selects the Manage Pages button 364 (from FIG. 3C). In response, the system displays Manage Inserted Pages dialog box 620. The dialog box 620 lists in Inserted Pages box 620, although the mailed and published page is inserted in the active notebook. As the user scrolls through the list, the right side of the dialog box changes to show information about each selected page. Description field 622 shows a description of the object the page came from. Distributed By field 623 shows the address of the person who mailed or published the page. Date Last Distributed field 624 shows the date the last version of the page was mailed or published. Status field 625 shows the update status of the selected page: "Dynamic" means the selected page uses automatic updating; "Current" means the selected page uses manual updating, with the latest version being inserted into the notebook; and "Out of date" means the selected page uses manual updating, and the latest version has not yet been inserted into the notebook. Original Name field 626 keeps track of the original name of the selected page. Version box 627 shows the version of the in selected page. By default, Current is the most recent version. To insert a previous version, the user selects Back. To enter the change, the user selects Update from buttons 629. Update Method box 628 shows whether the selected page is set to automatic or manual updating. This may be changed by the user as desired. To rename an inserted page, the user selects Rename from buttons 629. Likewise, to remove an inserted page, the user selects Remove from buttons 629. The user concludes the dialog by selecting Close from buttons 630.

Internal Operation

A. Introduction

The Object Exchange lets users share information (objects) between different applications and different users of the same application. As previously described, a user can share notebooks, notebook pages, or sets of notebook pages from a spreadsheet. As another example, in a database environment users can share tables, query results, folders, and the like. The Object Exchange is preferably implemented not as an application in itself, but as a middle link between applications and the outside world. In other words, it interacts with the operating system and messaging services to provide workgroup and communication services to applications. The Object Exchange maintains a store of shared objects on a user's local computer, which makes shared data continuously available to the user without requiring that user to be continuously connected to a communications network. This object store lets a user use shared pages and notebooks even if a local area network is inaccessible.

Workgroup applications use a publish and subscribe model for describing ongoing data-sharing relationships. Publishing means making a data object available to other workgroup members. Subscribing means using that published data object remotely in another application or in another file of the same application. The Object Exchange is the agent that enables users to establish and manage ongoing publication relationships among workgroup members and applications. Sending an object to other workgroup members one time only--in other words, without establishing ongoing sharing relationships--is sometimes called mailing. Any workgroup member can establish a publication by defining a distribution list from a list of addressees connected to that user by any available communication service. When a recipient of a publication subscribes to the publication, the published data appears in the subscriber's application exactly as it appears in the publisher's application. Publishers can make changes to the source data and issue new versions of it to subscribers. When a publisher issues a new version, it is sent out over the appropriate messaging services and automatically stored in each subscriber's Object Exchange. Once an object is stored in the Object Exchange, that object is available to any file in any application that interacts with the Object Exchange.

The Object Exchange also supports version depth for publications. The version depth determines how many versions of a publication the Object Exchange holds for subscribers at any given time. Through dynamic links with objects stored in the Object Exchange, subscriber applications can support both manual and automatic updating. With automatic updating, changes to the original data that publishers make and issue appear automatically in the subscriber application. With manual updating, those changes appear in the subscriber application only when the subscriber requests them.

B. Object Management

1. Objects

The Object Exchange stores information as objects. These objects have properties: System properties and User-defined properties. System properties are defined and assigned by the Object Exchange. User-defined properties, on the other hand, are created by the application. The user or application is responsible for assigning and interpreting these properties.

The Object Exchange supports simple structured property definition, for example

name: Simon

address: Santa Cruz

telephone: 12345

The Object Exchange also supports typed properties. Any Windows clipboard data can be passed to the Object Exchange as a typed property, for example

Type of my.sub.-- picture: bitmap

picture: clipboard

Type of my.sub.-- file: file

my.sub.-- file: <my path to the file>

When an object is created, the Object Exchange assigns it a unique ID. In addition, the user or application can add a key, which is just an alias for the object. Either the ID or the key can be used to access the object.

2. Areas

The Object Exchange areas provide a way to classify objects with "areas." An Object Exchange area typically does not correspond to a physical area or directory on disk; it is instead a way to group objects. However, one may think of objects as being stored in areas. For example, the Object Exchange stores publications, in a Publications area, suscriptions in a Subscriptions area, alerts in an Alerts area, and the like. Objects can be put into areas at object storage time, they can be forced into a different area on the subscriber side, and the subscriber can also have "filters" on the areas which decide whether an object will get automatically filed in that area.

3. Addresses

Objects are addressed to recipients. An address is a unique communication or system address for publishing or mailing objects to other members of a workgroup. In a preferred address format (i.e., one employed by the preferred embodiment), addresses are not case-sensitive and are followed with the messaging service name, enclosed in parentheses, as shown below.

LAN

Syntax: mailbox(LAN)

Description: mailbox=LAN mailbox

Example: SKing(LAN)

MHS

Syntax: user@workgroup(MHS)

Description: user=MHS user workgroup=MHS workgroup

Example: JHass@Tech(MHS)

MCI

Syntax: name/MCI ID: number(MCI)

Description: name=MCI username number=MCI account number

Example: Aphra Behn/MCI ID: 123-4567(MCI)

MAPI

Syntax: username(MAPI)

Description: username=MAPI services username for Workgroups alias or short name

Example: Simon King(MAPI)

MHS to MCI Via Gateway

Syntax: user@mcimail(MHS)

Description: user=MHS username mcimail=MHS name for MCI

Example: JHaas@mcimail(MHS)

NGM

Syntax: user@workgroup(MHS)

Description: user=NGM username workgroup=NGM workgroup hierarchy

Example: JHaas@Tech.Admin.Holt(MHS)

cc:Mail

Syntax: username(CCMAIL)

Description: username=cc:Mail user name

Example: foxglove(CCMAIL)

WordPerfect Office

Syntax: username(WPO)

Description: username=network user name

Example: SKing(WPO)

Lotus Notes

Syntax: userID/domain(NOTES)

Description: userID=Notes user ID domain=Notes domain

Example: SKing/Borland(NOTES)

Multiline Addresses

To enter multiline addresses, separate each line of the address with a vertical bar character (.vertline.). For example, to send mail from MCI Mail to MHS:

JDixon.vertline.ems:fortune.vertline.mbx:Jdixon.obex@fortune(mci)

4. Transports (Messaging Services)

Transports or messaging services are the means by which a user's computer communicates with the outside world. Messaging services are employed to send and receive electronic mail, and to establish workgroup relationships with remote users. The Object Exchange lets the user use multiple messaging services simultaneously, and automatically manages the connections to them. The user can use the Object Exchange to configure one or more messaging accounts for each installed messaging service. In a preferred embodiment, the following messaging services are supported:

(1) MCI: MCI Mail, a global electronic mail service.

(2) MHS: Novell's NetWare Message Handling Service (MHS), or its upgrade, NetWare Global Messaging (NGM), mail systems for local area networks.

(3) LAN: Local area networks such as Novell NetWare, Banyan 5.0, Microsoft LAN Manager 2.1, AT&T StarGroup 3.5.1, IBM LAN Server 2.0, and 3Com 3+ and 3Com 3+ Open, or the like.

(4) MAPI: Microsoft's Mail Application Programming Interface, such as in Windows for Workgroups, as well as with other MAPI-compliant messaging services such as Microsoft Mail.

(5) ccMAIL: Lotus cc:Mail, an electronic mail program. The Object Exchange also supports other VIM-compliant messaging services, such as Lotus Notes. VIM is Vendor Independent Messaging, a messaging protocol supported by many major software vendors.

(6) WPO: WordPerfect Office, a popular electronic mail program.

Specifications describing the protocol of the above messaging services are available from the respective vendors.

5. Accounts

The Object Exchange interacts with the various messaging services through one or more "accounts." Each Object Exchange account corresponds to a messaging service account or LAN mailbox. The user can create as many Object Exchange accounts as needed for each messaging service. When configuring Object Exchange accounts, the user supplies them with the information they need to connect with his or her messaging service accounts or mailboxes. The Object Exchange in turn polls, or contacts, messaging services to transmit outgoing objects and to pick up incoming objects. As previously described, the user can set an automatic polling frequency for each messaging account, and tell it how often and between what hours to poll.

C. Object Exchange API

Construction and operation of the Object Exchange is perhaps best described by examining its functionality, which is serviced through an OBEX.TM. API (Application Programming Interface). The API may be divided into the following functional groupings:

Account: Functions for managing OBEX accounts and transports

Address Book: Functions for managing address books and groups in an address book

Area: Functions for requesting properties and contents of a specified OBEX area

AreasInfo: Functions for requesting information about all OBEX areas

Declaration: Functions for creating and configuring declarations

Entry: Functions for managing the entries in an address book group and the addresses the entry contains

Mail: Functions for creating and managing mail objects

OBEX: Functions for managing and connecting with OBEX

Object: Functions for creating and managing objects

Publish/Subscriber: Functions for managing subscriber lists and publication forms

Each of these will be examined in turn.

1. Account

Account functions, which are provided for creating, configuring, and managing accounts, include the following:

    ______________________________________
    ObxAccountGetName: gets the name of an account.
    ObxAccountGetPollFrequencyHours
                       gets the hours in an account's
                       poll frequency.
    ObxAccountGetPollFrequencyMinutes:
                       gets the minutes in an account's
                       poll frequency.
    ObxAccountGetPollFrequencySeconds:
                       gets the seconds in an account's
                       poll frequency.
    ObxAccountGetPollFromHours:
                       gets the hour of the time an
                       account starts polling auto-
                       matically.
    ObxAccountGetPollFromMinutes:
                       gets the minute of the time an
                       account starts polling
                       automatically.
    ObxAccountGetPollFromSeconds:
                       gets the second of the time
                       an account starts polling
                       automatically.
    ObxAccountGetPollToHours:
                       gets the hour of the time an
                       account stops polling
                       automatically.
    ObxAccountGetPollToMinutes:
                       gets the minute of the time an
                       account stops polling
                       automatically.
    ObxAccountGetPollToSeconds:
                       gets the second of the time an
                       account stops polling
                       automatically.
    ObxAccountGetTransportName:
                       gets the name of the transport
                       (e.g., LAN, MCI, cc:MAIL)
                       associated with an account.
    ObxAccountGetTransportParam:
                       gets a parameter setting of an
                       account.
    ObxAccountSetActive:
                       enables or disables an account.
    ObxAccountSetAllDay:
                       specifies whether an account
                       polls automatically all day.
    ObxAccountSetAutomatic:
                       specifies whether an account
                       polls automatically
                       or only when initiated
                       by the OBEX user.
    ObxAccountSetManual:
                       specifies whether an account
                       polls automatically
                       or only when initiated
                       by the OBEX user.
    ObxAccountSetPartDay:
                       specifies whether an account
                       polls automatically
                       only part of the day.
    ObxAccountSetPollFrequency:
                       specifies how frequently
                       an account polls
                       automatically.
    ObxAccountSetPollFrom:
                       sets the time an account starts
                       polling automatically.
    ObxAccountSetPollTo:
                       sets the time an account stops
                       polling automatically.
    ObxAccountSetPrimary:
                       specifies whether the account
                       is the primary account.
    ObxAccountSetTransportParam:
                       sets a parameter setting of an
                       account.
    ObxAddAccountToPollQueue:
                       adds an account to the list of
                       accounts to poll.
    ObxCancelPoll:     cancels all active polling.
    ObxGetAccount:     gets a handle to reference an
                       account.
    ObxGetAccountBeingPolled:
                       gets the name of the account
                       being polled.
    ObxGetAccountByName:
                       gets a handle to reference an
                       account being polled using the
                       account name.
    ObxGetBlankAccount:
                       allocates room for a new OBEX
                       account.
    ObxGetCountOfAccounts:
                       gets the number of accounts that
                       exist in OBEX.
    ObxRemoveAccountFromPollQueue:
                       removes an account from the
                       list of accounts to poll.
    ObxUpdateAccount:  saves the changes made to an
                       account.
    ______________________________________

    ______________________________________
    ObxAccountGetName
    const char * .sub.-- export .sub.-- pascal ObxAccountGetName (hAccount);
      ADDRESS   hAccount /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxAccountGetPollFrequencyHours
    int .sub.-- export .sub.-- pascal ObxAccountGetPollFrequencyHours
    (hAccount);
      ADDRESS   hAccount /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxAccountGetPollFrequencyMinutes
    int .sub.-- export .sub.-- pascal ObxAccountGetPollFrequencyMinutes
    (hAccount);
      ADDRESS   hAccount /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxAccountGetPollFrequencySeconds
    int .sub.-- export .sub.-- pascal ObxAccountGetPollFrequencySeconds
    (hAccount);
      ADDRESS   hAccount /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxAccountGetPollFromHours
    int .sub.-- export .sub.-- pascal ObxAccountGetPollFromHours (hAccount);
      ADDRESS   hAccount /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxAccountGetPollToMinutes
    int .sub.-- export .sub.-- pascal ObxAccountGetPollToMinutes (hAccount);
      ADDRESS   hAccount /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxAccountGetPollToSeconds
    int .sub.-- export .sub.-- pascal ObxAccountGetPollToSeconds (hAccount);
      ADDRESS   hAccount /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxAccountGetTransportName
    const char * .sub.-- export .sub.-- pascal ObxAccountGetTransportName
    (hAccount);
      ADDRESS   hAccount /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxAccountGetTransportParam
    const char * .sub.-- export .sub.-- pascal ObxAccountGetTransportParam
    (hAccount,
    szParameter);
      ADDRESS   hAccount /* Handle to an OBEX account */
      const char *  szParameter /* Name of the parameter to retrieve
    */
    ______________________________________

    ______________________________________
    ObxAccountSetActive
    void .sub.-- export .sub.-- pascal ObxAccountSetActive(hAccount,
    nYesorNo);
    ACCOUNT   hAccount /* Handle to an OBEX account */
    int       hYesorNo /* 1 to activate account, 0 to deactivate
    it */
    ______________________________________

    ______________________________________
    ObxAccountSetAllDay
    void .sub.-- export .sub.-- pascal ObxAccountSetAllDay(hAccount);
    ACCOUNT     hAccount /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxAccountSetAutomatic
    void .sub.-- export .sub.-- pascal ObxAccountSetAutomatic(hAccount);
    ACCOUNT     hAccount /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxAccountSetManual
    void .sub.-- export .sub.-- pascal ObxAccountSetManual(hAccount);
    ACCOUNT     hAccount /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxAccountSetPartDay
    void .sub.-- export .sub.-- pascal ObxAccountSetPartDay(hAccount);
    ACCOUNT     hAccount /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxAccountSetPollFrequency
    void .sub.-- export .sub.-- pascal ObxAccountSetPollFrequency(hAccount,
    nHours,
    nMinutes, nSeconds);
     ACCOUNT hAccount /* Handle to an OBEX account */
     int     nHours   /* Number from 0 to 23 indicating the
                      number of hours in the polling frequency
                      */
     int     nMinutes /* Number from 0 to 59 indicating the
                      number of minutes in the polling frequency
                      */
     int     nSeconds /* Number from 0 to 59 indicating the
                      number of minutes in the polling frequency
                      */
    ______________________________________

    ______________________________________
    ObxAccountSetPollFrom
    void .sub.-- export .sub.-- pascal ObxAccountSetPollFrom(hAccount,
    nHours,
    nMinutes, nSeconds) ;
    ACCOUNT   hAccount /* Handle to an OBEX account */
    int       nHours   /* Number from 0 to 23 indicating the
                       starting hour to poll */
    int       nMinutes /* Number from 0 to 59 indicating the
                       starting minute to poll */
    int       nSeconds /* Number from 0 to 59 indicating the
                       starting second to poll */
    ______________________________________

    ______________________________________
    ObxAccountSetPollTo
    void .sub.-- export .sub.-- pascal ObxAccountSetPollTo(hAccount, nHours,
    nMinutes, nSeconds);
     ACCOUNT hAccount /* Handle to an OBEX account */
     int     nHours   /* Number from 0 to 23 indicating the hour
                      to stop polling */
     int     nMinutes /* Number from 0 to 59 indicating the
                      minute to stop polling */
     int     nSeconds /* Number from 0 to 59 indicating the
                      second to stop polling */
    ______________________________________

    ______________________________________
    ObxAccountSetPrimary
    void .sub.-- export .sub.-- pascal ObxAccountSetAutomatic(hAccount,
    nYesorNo);
    ACCOUNT   hAccount /* Handle to an OBEX account */
    int       nYesorNo /* 1 to make this the primary account
    ______________________________________
                       */

    ______________________________________
    ObxAccountSetTransportParam
    BOOL .sub.-- export .sub.-- pascal ObxAccountSetTransportParam(hAccount,
    szParameter, szSetting);
    ADDRESS   hAccount  /* Handle to an OBEX account */
    const char *
              szParameter
                        /* Name of the parameter to retrieve
    */
    const char *
              szSetting /* New parameter setting */
    ______________________________________

    ______________________________________
    szParameter Set szSetting to
    ______________________________________
    Account Name
                account name (LAN, MCI2, and so on)
    Username    username used to connect to the
                messaging service.
    Password    password used to connect to the message
                service.
    Modem       modem type used for dial-in messaging
                services such as MCI.
    Phone #     phone number dialed to connect to the
                messaging service.
    Prefix      number to dial before dialing the phone.
    Dialing     Tone or Pulse to specify dialing method.
    Port        name of the COM (serial) port the modem
                is connected to (COM2, COM3, and so on).
    Data        length of the data (in bits) transmitted
                by the modem.
    Baud        baud rate (bits per second) of the
                transmission.
    Stop        stop code of the transmission in bits.
    Parity      parity rate of the transmission.
    Script      string representing a connection script
                used to connect to a messaging service.
    Allow 8-bit transfers
                1 to allow 8-bit transfers, 0 otherwise.
    Workgroup   name of the workgroup used by an MHS
                account.
    Mailbox Name
                name of the mailbox directory used by a
                LAN account.
    Post Office Path
                name of the post office directory used
                by all accounts.
    ______________________________________

    ______________________________________
    ObxAddAccountToPollQueue
    BOOL .sub.-- export .sub.-- pascal ObxAddAccountToPollQueue(szAcctName);
    const char * szAcctName
                    /* String containing the name of the
                    account to poll */
    ______________________________________

    ______________________________________
    ObxCancelPoll
    BOOL .sub.-- export .sub.-- pascal ObxCancelPoll( );
    ______________________________________

    ______________________________________
    ObxGetAccount
    ACCOUNT .sub.-- export .sub.-- pascal ObxGetAccount (nIndex);
    int      nIndex  /* Index of the account to retrieve */
    ______________________________________

    ______________________________________
    ObxGetAccountBeingPolled
    int .sub.-- export .sub.-- pascal ObxGetAccountBeingPolled(szAccountName,
    nIndex);
    char * szAccountName
                   /* String containing the account being
                   polled   */
    int nIndex     /* Index into a account list
                   */
    ______________________________________

    ______________________________________
    ObxGetAccountByName
    ACCOUNT .sub.-- export .sub.-- pascal ObxGetAccountByName(szAccountName);
    const char * szAccountName
                     /* Name of the account to retrieve
    */
    ______________________________________

    ______________________________________
    ObxGetBlankAccount
    ACCOUNT .sub.-- export .sub.-- pascal ObxGetBlankAccount(szAccountName,
    szTransport);
    const char * szAccountName
                     /* Name of the account to create */
    const char * szTransport
                     /* Name of transport used by the
                     account */
    ______________________________________

    ______________________________________
    String   Messaging service
    ______________________________________
    MCI      MCI Mail
    MHS      Novell's NetWare Message Handling Service
             (MHS), version 1.5, or its upgrade, NetWare
             Global Messaging (NGM)
    LAN      Local area networks such as Novell NetWare,
             Banyan 5.0, Microsoft LAN Manager 2.1, AT&T
             StarGroup 3.5.1, IBM LAN Server 2.0, and 3Com
             3+ and 3Com 3+ Open.
    MAPI     Microsoft's Mail Application Programming
             Interface.
    ccMAIL   Lotus cc:Mail and other VIM-compliant
             messaging services. VIM is Vendor
             Independent Messaging.
    WPO      WordPerfect Office, version 4.0a or later.
    NOTES    Lotus Notes, version 3.0 or later.
    ______________________________________

    ______________________________________
    ObxGetCountOfAccounts
    int .sub.-- export .sub.-- pascal ObxGetCountOfAccounts (
    ______________________________________
    );

    ______________________________________
    ObxRemoveAccountFromPollQueue
    BOOL .sub.-- export .sub.-- pascal ObxRemoveAccountFromPollQueue
    (szAcctName);
    const char * szAcctName
                    /* String containing the name of the
                    account to remove */
    ______________________________________

    ______________________________________
    ObxUpdateAccount
    BOOL .sub.-- export .sub.-- pascal ObxUpdateAccount(hAccount);
    ACCOUNT   hAccount  /* Handle to an OBEX account */
    ______________________________________

    ______________________________________
    ObxCloseAddressBook
    int .sub.-- export .sub.-- pascal ObxCloseAddressBook( );
    AB      hAddressBook
                       /* Handle to an address book */
    ______________________________________

    ______________________________________
    ObxOpenAddressBook
    AB .sub.-- export .sub.-- pascal ObxCloseAddressBook(szBookName);
    const char * szBookName
                    /* Name of the address book to open
                    */
    ______________________________________

    ______________________________________
    ObxABAddGroup
    GROUP .sub.-- export .sub.-- pascal ObxABAddGroup(hAddressBook,
    szGroupName);
    AB hAddressBook /* Handle to an address book */
    const char * szGroupName
                    /* Name of the new group */
    ______________________________________

    ______________________________________
    ObxABGetCountOfGroups
    int .sub.-- export .sub.-- pascal ObxABGetCountOfGroups(hAddressBook);
    AB hAddressBook
                   /* Handle to an address book */
    ______________________________________

    ______________________________________
    ObxABGetGroup
    GROUP .sub.-- export .sub.-- pascal ObxABGetGroup(hAddressBook, nIndex);
    AB hAddressBook
                 /* Handle to an address book */
    int nIndex   /* Index number of the group to get */
    ______________________________________

    __________________________________________________________________________
    ObxABGetGroupByName
    GROUP .sub.-- export .sub.-- pascal ObxABGetGroupByName(hAddressBook,
    szGroupName);
    AB AddressBook
                  /* Handle to an address book */
    const char * szGroupName
                  /* Name of the group */
    __________________________________________________________________________

    ______________________________________
    ObxABRemoveGroup
    BOOL .sub.-- export .sub.-- pascal ObxABRemoveGroup(hAddressBook,
    szGroupName);
    AB hAddressBook /* Handle to an address book */
    const char * szGroupName
                    /* Name of the group to remove */
    ______________________________________

    ______________________________________
    ObxAreaGetDescription
    const char * .sub.-- export .sub.-- pascal ObxAreaGetDescription(hArea);
    AREA hArea   /* Handle to an AREA  */
    ______________________________________

    ______________________________________
    ObxAreaGetName
    const char * .sub.-- export .sub.-- pascal ObxAreaGetName(hArea);
    AREA hArea   /* Handle to an AREA  */
    ______________________________________

    ______________________________________
    ObxAreaGetTOC
    AREATOC .sub.-- export .sub.-- pascal ObxAreaGetTOC(hArea);
    AREA hArea   /* Handle to an AREA  */
    ______________________________________

    ______________________________________
    Field        Description
    ______________________________________
    Id           Unique identifier for the object,
                 supplied by OBEX.
    Key          User-defined identifier. For practical
                 purposes, it should be unique, but OBEX
                 does not require or enforce uniqueness.
    Description  Text describing the object.
    Publisher    Publisher's name. It is "obex" for
                 Publications.
    DateCreated  Date the object was created.
    DateLastModified
                 Date of the last version issued.
    LocalTag     A field for keyword data maintained in
                 the user's object store. This is the
                 only property that is not transmitted
                 with the object.
    Tag          Application-specific field for keyword
                 data. Unlike LocalTag, this data is
                 transmitted with the object.
    NumberOfVersions
                 Number of versions of the object
                 currently in the object store.
    ______________________________________


______________________________________
    ObxAreaTocGetCount
    int .sub.-- export .sub.-- pascal ObxAreaTocGetCount(hAreaTOC);
      AREATOC hAreaTOC  /* Handle to AREATOC  */
    ______________________________________

    ______________________________________
    ObxAreaTocGetDateCreated
    long .sub.-- export .sub.-- pascal ObxAreaTocGetDateCreated(hAreaTOC,
    nRow);
      AREATOC hAreaTOC  /* Handle to AreaTOC  */
      int nRow   /* Row number within the AreaTOC  */
    ______________________________________

    ______________________________________
    ObxAreaTocGetDateLastModified
    long .sub.-- export .sub.-- pascal ObxAreaTocGetDateLastModified(hAreaTOC,
    nRow);
      AREATOC hAreaTOC  /* Handle to an AreaTOC  */
      int nRow   /* Row number within the AreaTOC  */
    ______________________________________

    ______________________________________
    ObxAreaTocGetDescription
    const char * .sub.-- export .sub.-- pascal ObxAreaTocGetDescription(hAreaT
    OC,
    nRow);
      AREATOC hAreaTOC  /* Handle to an AreaTOC  */
      int nRow   /* Row number within the AreaTOC  */
    ______________________________________

    ______________________________________
    ObxAreaTocGetId
    const char * .sub.-- export .sub.-- pascal ObxAreaTocGetId(hAreaTOC,
    nRow);
      AREATOC hAreaTOC  /* Handle to an AreaTOC  */
      int nRow   /* Row number within the AreaTOC  */
    ______________________________________

    ______________________________________
    ObxAreaTocGetKey
    const char * .sub.-- export .sub.-- pascal ObxAreaTocGetKey(hAreaTOC,
    nRow);
      AREATOC hAreaTOC  /* Handle to an AreaTOC  */
      int nRow   /* Row number within the AreaTOC  */
    ______________________________________

    ______________________________________
    ObxAreaTocGetLocalTag
    const char * .sub.-- export .sub.-- pascal ObxAreaTocGetLocalTag(hAreaTOC,
    nRow);
      AREATOC hAreaTOC  /* Handle to an AreaTOC  */
      int nRow   /* Row number within the AreaTOC  */
    ______________________________________

    ______________________________________
    ObxAreaTocGetNumberOfVersions
    int .sub.-- export .sub.-- pascal ObxAreaTocGetNumberOfVersions(hAreaTOC,
    nRow);
      AREATOC hAreaTOC  /* Handle to an ObxAreaTOC  */
      int nRow   /* Row number within the ObxAreaTOC  */
    ______________________________________

    ______________________________________
    ObxAreaTocGetPublisher
    const char * .sub.-- export .sub.-- pascal ObxAreaTocGetPublisher(hAreaTOC
    nRow);
     AREATOC hAreaTOC
                  /* Handle to an AreaTOC   */
     int nRow     /* Row number within the AreaTOC   */
    ______________________________________

    __________________________________________________________________________
    ObxAreaTocNotifyOnUpdate
    NOTE .sub.-- export .sub.-- pascal ObxAreaTocNotifyOnUpdate(hAreaTOC,
    szProc);
    AREATOC hAreaTOC   /* Handle to an AreaTOC   */
    AREATOCCALLBACKPROC szProc
                       /* Name of the callback procedure
    */
    __________________________________________________________________________

    ______________________________________
    ObxCreateArea
    AREA .sub.-- export .sub.-- pascal ObxCreateArea(szAreaName, szAreaDesc,
    szAreaTag);
    const char * szAreaName
                    /* Name of the new area*/
    const char * szDescription
                    /* Description of the new area */
    const char * szAreaTag
                    /* Internal description of the new
    area */
    ______________________________________