(PICTURE)(PICTURE) (PICTURE)Europäis hes Patentamt
(1 9) (PICTURE) European Patent Offi_e
(PICTURE) Offi_e euroPéen des brevets (1 1 ) E _ O _92 493 B_
(1 2) EUROPEAN PATENT _PECl FICATlON
(45) Date of pUbliCation and mention (51 ) Int CI.6_. _O6F _ _J3O, _O6F _ _/6O
of the grant of the patent_.
11 _O8_1999 BUlletin 1999l32 (86) InternationaI appIication number_.
PCTIUS95l147O1
(21 ) Application number_. 959399O2.3 (87) International publication number_.
(PICTURE)(22) Date of filing_. O8.11 .1995 wo g6l155o5 (23.o5.1gg6 _azette 1gg6l23)
(54) AN ONLINE _ERVICE DEVELOPMENT TOOL WITH FEE _ETTING CAPABILITIE_
HERSTELLUNGSHILFE FüR ONLINE-Dl ENSTE MIT G EBüH RENFESTSTELLUNG
OUTIL DE DEVELOPPEMENT DE SERVICES EN LIGN E A FONCTlONS D'ETABLISSEMENT DE
(PICTURE)(PICTURE)
TAXATlON
__
__
_
_
__ Note.. w._th._n n._ne months from the pubI._Cat._on of the ment._on of the grant of the European patent, any person may g._ve
o nOtiCe tO the EUrOpean Patent OffiCe Of OppOSitiOn tO the EUrOpean patent granted. NOtiCe Of OppOSitiOn Shall be filed in
ii a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art.
w (PICTURE)99(1 ) European Patent Convention). Printed by Jouve, 75OO1 PARIS (FR)
EP O 792 493 B1
Des_ription
(PICTURE)FIELD F THE INVENTION
5 [OOO1] The present invention relates to the field of online computer services. In particular, the present invention
discloses a software tool for setting fees in an online service, as part of a visually oriented tool for creating online
SerVICeS.
BACKGROUND OF THE INVENTION
1O (PICTURE)
[OOO2] With the increasing popularity of computer communications, many companies are becoming interested in
advertising and supporting their products using an online computer service that can be accessed by customers. How-
ever, creating a large online computer service is an extensive task. To develop a sophisticated online service, such as
America Online_, CompuServe_, Genie_, or Prodigy_, a company must have a large mainframe computer and cus-
15 tomized software. Developing the customized software requires a competent programming staff and a good deal of
time. Most companies do not have the resources required to develop such systems, and thus cannot easily develop
and maintain an online presence.
[OOO3] One way a company can contact millions of potential customers is to use the global Internet. The global
Internet is a network of computer networks that links together millions of computer systems using the well defined TCP/
2O l P protocol.
[OOO4] A new method of distributing and viewing information known as the World-Wide Web has recently become
very popular on the global Internet. The World-Wide Web is a collection of servers connected tothe Internet that provide
multi-media information to users that request the information. The users access the information using client programs
called ''browsers'' to display the multi-media information.
25 [OOO5] World-Wide Web servers store multi-media information in a document format known as HyperText Markup
Language (HTML). The World-Wide Web servers distribute the HTML formatted documents using a specific commu-
nication protocol known as the HyperText Transfer Protocol (HTTP).
[OOO6] To access the multi-media information available on World-Wide Web servers, a user runs a client browser
program that accesses the HTML formatted documents stored on the HTTP servers connected to the global Internet.
3O The client browser program retrieves the formatted information and provides the information in an appropriate manner
to the user. For example, the client browser program displays graphical image information as images on the user's
graphical display screen; plays video information as video animation on the user's graphical display screen; displays
text information as text on the user's screen; and plays sound samples using the speakers on the user's computer
system. ''Mosaic'', one popular client browser program, is widely available to the users of the global Internet.
35 [OOO7] For a company that wishes to develop an online presence, creating a World-Wide Web Server would provide
a feature rich online service available to customers and clients. A World-Wide Web Server can store images, text,
animation, and sounds that provide information about the company. Furthermore, World-Wide Web Servers can be
implemented on relatively simple computer systems, including personal computers.
[OOO8] Most World-Wide Web Servers are coupled to the global Internet. By deploying a World-Wide Web Server
4O on the global Internet a company would create online service that is accessible to the millions of global Internet users.
[OOO9] Alternatively, a company can deploy a HTTP server that is available to customers through dial-up phone
service. A dial-up HTTP server would be accessible to customers and clients that do not have Internet access. Thus,
by creating a simple HTTP server, any organization or corporation can create an online presence.
[OO1 O] However, quickly creating the HTML formatted documents required for a World-Wide Web Server is not a
45 trivial task. Moreover, the standard HTTP server software, without any additional programming, is very limited. For
example, without custom extensions, an HTTP server cannot accommodate complex transactions between a user and
the HTTP server or integrate a database system into an online service. Although it is possible to write custom extensions
to the HTTP server software using a conventional programming language, such custom extensions are difficult to write
except by experienced programmers. Thus, to be able to quickly deploy full-featured HTTP servers, it would be desir-
5O able to have a development tool usable by non-programmers that allows a developer to quickly and easily create a
full-featured online service based upon the HTTP and HTML standards.
[OO11] Many programming development tools are known in the art. These programming development tools range
from tools which are developed and marketed as general purpose programming development tools to sophisticated
special purpose development tools for developing specific types of applications.
55 [OO12] For example, the Information Exchange Facility (l EF) general development tool, which is available from Texas
Instruments, is used by professional programmers to develop application programs. Essentially, l EF provides a facility
that allows a programmer to write ''pseudo code'' and l EF generates an intermediate source code program in a high
Ievel programming language (such as COBOL or C code) based on the ''pseudo code''. IEF is an example of what will
2
EP O 792 493 B1
be referred to herein as a ''general purpose development tool'' because it allows development of programs for essentially
any purpose or application dependent on the input provided by the programmer.
[OO13] In contrast to general purpose software development tools, many application programs themselves provide
special purpose ''development tool'' capability. An example is the ParadoxTM database program available from Borland
5 International of Scotts Valley, California. The ParadoxTM database allows end users to develop sophisticated database
applications which would have been developed by professional programmers afewyears ago. The ParadoxTM database
is but one example of a special purpose development tool.
[OO14] Another example of a special purpose development tool, perhaps more pertinent to the present invention, is
the Application Development Environment of Lotus NotesTM which is available from Lotus Development Corporation
1O of Cambridge, Massachusetts. The Application Development Environment of Lotus Notes provides features which are
said to allow for rapid development of workgroup applications such as sharing of documents between users over a
network. Generally, Lotus Notes and, thus, its Application Development Environment, is directed at sharing of docu-
ments among persons in an authorized work group. For example, a Lotus Notes application can be envisioned which
would allowfor sharing of key patent applications among patent examiners in a particular art group at the United States
15 Patent Office.
[OO15] The Lotus Notes Application Development Environment provides for such features as (i) application design
templates which are said to allow sophisticated applications to be built by customizing pre-built applications such as
document libraries, form-based approval systems, project tracking applications and status reporting systems; (ii) se-
curity; (iii) database access; and (iv) discussion groups. However, while these features are useful, the Lotus Notes
2O Application Development Environment, as well as Lotus Notes itself, has its shortcomings as admitted to by even Lotus
Development Corporation itself_.
Lotus Notes was not intended to be used as a transaction-processing front-end to an operational database sys-
tem. Operational systems are those which support transactions that are essential to the operation of an organization.
25 Examples of these systems would be traditional order entry...
(PICTURE) October, 1 993, pg. 1 1
[OO16] It has been recognized by the present invention that many of these functions neglected by Lotus Notes are
very important when developing publicly accessible online systems. Specifically, the ability to perform commercial
transactions that involve order enty systems would allow an online system to sell goods and services to computer
3O users. It is now recognized by the present invention that many functions such as traditional order enty systems and
the like will someday be carried out over computer networks by allowing a customer to place orders for goods and
services directly with an online service. By way of example, even today, food orders can be placed with restaurants
over computer networks; videos can be reserved at the local video store; and banking transactions can be carried out
simply by logging onto a computer network.
35 [OO17] Four different types of commercial transactions might commonly occur in a commercial online service. First,
a user may be charged for the right to access all or parts of a useful publicly accessible online system. Second, the
online service may pay the userfor performing some type of action such as winning a contest or completing a marketing
survey. Third, an online service may charge a content provider for placing certain information on the online service.
For example, a content provider can be charged for placing an advertisement on the online service. Finally, a content
4O provider can be paid by the online service for providing information that users may wish to access. That be can be
provided on a for-fee basis. Conversely, an online service provider may wish to pay third party content providers for
placing useful material on the online service.
[OO18] Thus, when creating a publicly accessible online system, it is desirable to include the ability to define fee
structures for accessing parts of the online system and/or ordering other goods or services. However, creating a so-
45 phisticated commercial online service with such features usually requires specialized programming.
[OO19] The ability to set fees to be paid by the user for an amount of data accessed, the time spent ''logged on'' to
the online service, or the purchase of particular merchandise is one example of distinction from Lotus Notes. Lotus
Notes is not only admitted (by even Lotus Development Corporation) as lacking transaction oriented capability as may
be required by such applications, but it also does not provide the metering functions to keep track of the information
5O necessary to assign such fees as is required by these applications. As such, the video store, restaurant or bank (by
way of example) is left with the need to employ professional programmers for their individual applications.
[OO2O] Thus, it has been discovered that there exists a need to create online system development tools that include
features, functions and capabilities to support commercial online services such as the aforementioned fee setting
function.
55 [OO21] These and other aspects of the present invention will be described in greater detail with reference to the below
detailed description and the accompanying figures.
[OO22] A computer system for realising an online service is known from US-A-5 2O4 897, EP-A-O 483 576 and l BM
Technical Disclosure Bulletin, Vol. 37 No. 6B, June 1 994, New York, US, pages 451 -46O. These documents teach the
3
EP O 792 493 B1
provision of a fee specification for billing a user accessing objects on the online server. However, the systems taught
in these documents are complex and hard to use for non-skilled computer operators and are time consuming to develop
into practical systems. An advanced development tool allowing easy generation of fee specifications and objects is
hitherto unknown from the prior art.
5 (PICTURE)SUMMARY AND OBJECTS OF THE INVENTION
[OO23] It is an object of the invention as claimed to provide a fee setting tool that allows a developer to assign easily
a system of fees, or a fee structure, for an online service. This object is achieved by providing an editor for editing fee
1O specifications associated with portions of an online service, such as documents and scripts, herein called document
objects. The fee setting tool preferably uses a well-defined scripting language that allows for the definition of complex
fee arrangements. The fee structure can be used to levy fees against both users and providers on an online service
by use of a fee specification that associates a fee with an entity and a document object, and an event occurring in
connection with the document object. For example, a user can be levied fees for logging on to an online service,
15 performing a search, or downloading information. The fee is calculated, using a search as an example, using the fee
defined for the searched document, in view of the user searching and the fact that a search is the action performed.
Third party content providers can be levied fees for submitting advertisements, or executing a transaction with a user,
or maintaining information content on a computer for a given period of time. The fee is calculated, using advertisement
submission as an example, using the fee defined for a new document, in view of the provider of the advertisement and
2O the fact that document uploading is the action pe_ormed. Similarly, the fee setting tool also allows the online service
developer to assign a payment system whereby users or providers can be paid for certain actions using the same fee
specifications and by allowing both negative and positive values for fee computations and by assigning one type as
payment and the other type as debit. For example, a user may be paid when filling out a marketing questionnaire or
when winning a contest. A provider may be paid when that content provider supplies information to a user of the online
25 service. The fee setting tool preferably provides a visual editing interface that uses a template to define the fee spec-
ification and a list to maintain fee specifications.
[OO24] According to a first aspect, the invention provides a system for specifying fees for an entity associated with
an online service, comprising_.
3O (a) means associated with an object of the online service for defining at least one of a plurality of triggering actions
for a fee_,
(b) means associated with a triggering action for defining a fee specification for the entity;
(c) means for editing a plurality of fee specifications for the entity; and
(d) means for storing the plurality of fee specifications using the editing means, characterised in that the editing
35 means comprises_.
(e) means for displaying a visual representation of the fee specification having user-modifiable portions, wherein
a user-modifiable portion is provided for entry of an indication of an object of the online service, an indication of a
triggering action in connection with the object, and a fee specification; and
(f) means for receiving user input to edit the fee specification using the visual representation and for storing edited
4O fee specifications.
[OO25] Accordingly, one aspect of the invention is an editorfor allowing editing fee specifications for an online service.
The editor allows a developer to define a triggering event, an object of the online service and a fee computation asso-
ciated with the triggering action and the object. Preferably the fee specification is edited using a visual user interface
45 using a template for a fee specification. The fee specification also may identify an individual against whom the fee may
be levied to allow for fees to be applied and defined generally for all individuals, including providers and users.
[OO26] Another object of the invention is to provide a structure that easily and simply defines a fee structure for an
online service. To achieve this object, a record called a fee specification is used which identifies a document object, a
triggering event for that object which invokes a fee, an individual against whom the fee is levied and a fee computation.
5O The fee computation, as described above, is preferably defined using a well defined scripting language.
[OO27] Accordingly, one aspect of the invention is a mechanism for specifying fees for an online service, including
1 ) means, associated with a document object of the online service, for defining a triggering event for a fee and 2)
means, associated with the triggering event, for defining a formula for computation of the fee. An indication of an
individual against whom the fee is to be levied is also preferably provided. An editor is provided for editing a plurality
55 of such fee specifications.
[OO28] Additionally, it is an object of the invention to provide a fee calculation mechanism which processes fee spec-
ifications in response to actions on document objects to determine the fee associated with the action. Since fee spec-
ifications are maintained in a listfor each online service, the specification list is searched upon occurrence of atriggering
4
EP O 792 493 B1
event to identify the fee associated with the triggering event, the individual against whom the fee is levied and the
document object in relation to which the event occurred. The result ofthis search is afeeformula which is then computed
to define the fee, either a payment or a debit. The fee calculation mechanism is part of the server which makes the
online service available.
5 [OO29] Accordingly, another aspect of the invention is a mechanism for determining a fee for an online service. This
mechanism detects an event associated with an object of the online service. In response to detection of the event, a
fee specification for the event and the associated object is then identified. The fee specification is then used to define
the fee. This aspect of the invention is used in combination with a fee specification. This fee specification associates
an object of the online service with a triggering event and a fee computation which defines the fee for the object and
1O event. An editor allows for editing a plurality of such fee specifications.
[OO3O] It is another object of the present invention to provide a fast, user-friendly method of designing and deploying
a distributed online service. In particular, it is an object ofthe present invention to allowa developerto create customized
HTTP server software, such as scripts, and accompanying HTML documents for deployment on a World-Wide Web
server. This object is achieved by providing a visual editor that allows a developer to easily create the subservices that
15 constitute the online service. These subservices generally include scripts and documents which are designed to meet
a specific need. A variety of templates of suitable scripts and documents are provided for a variety of typical kinds of
online services. For example, such subservices may include a Hyperdocument/Commerce subservice for displaying
hyperdocuments and performing electronic transactions, a Classified Advertisement subservice for implementing elec-
tronic classified advertisements, a Reference subservice for implementing online reference works, a Director Lookup
2O subservice for implementing online searchable directories of information, a Bulletin Board subse_ice for providing a
means for allowing users to post and view messages, a Document Retrieval subserviceto provide a means for retrieving
documents, an Electronic Publishing subservice that provides electronic editions of newspapers or magazines that
may be downloaded, and Meta-Service subservice that provides access to other external online services.
[OO31] Accordingly, another aspect of the present invention is a computer system for designing online services. The
25 system includes an editing module for manipulating a collection of documents as a se_ice. This editing module pref-
erably contains a number of sets of templates of scripts and documents which can be used to generate an online
service quickly. A viewing module allows for display of summary views of the service.
[OO32] Another aspect of the invention is a computer system for editing an online service that includes a first editing
module that has editing functions for visually editing relationships between document objects of a service. For example,
3O a hyperlink editor with a link view, which is a graphical display of document objects and hypertext links between them,
may be provided. A second editing module is used to allow editing of particular document objects. Such a system is
provided with the fee setting tool of this invention and the associated fee specifications.
[OO33] In any of the foregoing aspects of the invention fees may be triggered by a defined user action, such as access
by said user to one of said visual objects on said online system, or submittal of an object for inclusion in said data store
35 of said online service, or a traverse of a hyperlink, or connection to an online service. Fees may also be triggered by
passage of a defined amount of time.
[OO34] Additionally, in any of the foregoing aspects of the invention, a fee specification particularly may have a first
field specifying a fee action that triggers said fee. Another field defines the fee computation. An optional field is a field
specifying an entity to whom the fee is directed. A field specifying an object associated with said fee event allows
4O different objects within an online service to have different fees. A script may be used to specify the fee computation.
The script preferably has at least one fee setting script primitive, but may have more. By allowing both negative and
positive fee values and credit and debit system can be implemented. For example, if a fee is positive, a fee is charged
to the entity, and if a fee is negative, a payment is made to the entity. A script editor is preferably used to edit scripts
specifying fee computations.
45 [OO35] The foregoing aspects of the invention are particularly useful in the World-Wide Web of the global Internet
for use in generating HTML documents and scripts.
(PICTURE)BRIEF DESCRIPTION OF THE DRAWINGS
5O [OO36] The objects, features, and advantages of the present invention will be apparent from the following detailed
description of the preferred embodiment of the invention with references to the following drawings.
[OO37] Figure 1 illustrates a blockdiagram overviewof an online service that is implemented with the Molisa platform.
[OO38] Figure 2 lists the general steps for an electronic commerce transaction with an online service.
[OO39] Figure 3a illustrates how the Online Designer is used to create an online service.
55 [OO4O] Figure 3b illustrates how a hyperdocument is edited using the Online Designer.
[OO41] Figure 4 lists the available subservice design programs.
[OO42] Figure 5 illustrates a hyperlinkfrom a Reference subservice to an order form in a HyperdocumenUCommerce
subservice. 5
EP O 792 493 B1
[OO43] Figure 6 illustrates a hyperlink from a Directoy Lookup subservice to an rental form in a HyperdocumenU
Commerce subservice.
[OO44] Figure 7 illustrates the set of Utility Subtools in the Online Designer development tool.
[OO45] Figure 8 illustrates a block diagram example of an online service.
5 [OO46] Figure 9 illustrates a service gallery containing online services that may be edited.
[OO47] Figure 1 O illustrates a Connectivity View of the online service of Figure 8.
[OO48] Figure 1 1 illustrates a WYSIWYG view of a hypermedia document.
[OO49] Figure 1 2 illustrates a screen display of the Hyperdocument Designer Script View.
[OO5O] Figure 1 3 illustrates a hyperlink view of a hyperdocument.
1O [OO51] Figure 1 4 illustrates a block diagram of the views supported by the Hyperdocument Designer.
[OO52] Figure 1 5 illustrates a screen display of a hypermedia document.
[OO53] Figure 1 6 illustrates a screen display of a hypermedia document used to order a product.
[OO54] Figure 1 7 lists the different views provided by the Lookup Designer subtool.
[OO55] Figure 1 8 illustrates a submit form in the Form View of the Lookup Designer subtool.
15 [OO56] Figure 1 9 illustrates a view form in the Form View of the Lookup Designer subtool.
[OO57] Figure 2O illustrates a query form in the Form View of the Lookup Designer subtool.
[OO58] Figure 21 a illustrates a first screen display of the Script Editor.
[OO59] Figure 21 b illustrates a second screen display of the Script Editor.
[OO6O] Figure 22 illustrates an SQL query between an online subservice and an SQL database.
2O [OO61] Figure 23 illustrates a screen display of the Fee Setting subtool.
[OO62] Figure 24 illustrates a screen display of the Fee Specifier editor sub tool.
(PICTURE)NOTATION AND NOMENCLATURE
25 [OO63] The detailed descriptions which follow are presented largely in terms of algorithms and symbolic representa-
tions of operations within a computer system. These algorithmic descriptions and representations are the means used
by those skilled in the data processing arts to convey the substance of their work most effectively to others skilled in
the art.
[OO64] Generally, and within the context of this application, an algorithm is conceived to be a self-consistent sequence
3O of steps leading to a desired result. These steps are those requiring physical manipulations of physical quantities.
Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored,
transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of
common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical
35 quantities and are merely convenient labels applied to these quantities.
[OO65] Further, the manipulations performed are often referred to in terms, such as adding or comparing, which are
commonly associated with mental operations performed by a human operator. No such capability of a human operator
is necessay, or desirable in most cases, in any of the operations described herein which form part of the present
invention; the operations are machine operations. Useful machines for performing the operations of the present inven-
4O tion include general purpose digital computers or other similar devices. In all cases, a distinction is maintained between
the method of operations in operating a computer and the method of computation itself. The present invention relates
to method steps for operating a computer in processing electrical or other physical signals (e.g. , mechanical, chemical)
to generate other desired physical signals.
[OO66] The present invention also relates to apparatus for performing these operations. This apparatus may be spe-
45 cially constructed for the required purposes, or it may comprise a general purpose computer as selectively activated
or reconfigured by a computer program stored in the computer. The algorithms presented herein are not inherently
related to a particular computer or other apparatus. In particular, various general purpose machines may be used with
programs written in accordance with the teachings herein, or it may prove more convenient to construct more special-
ized apparatus to perform the required method steps. The required structure for a variety of these machines will appear
5O from the following description.
(PICTURE)DETAI LED DESCRIP ION OF AN EMBODI MENT OF THE PRESENT I NVENTION
[OO67] Methods and apparatus for implementing a development tool for creating online services are disclosed. In
55 the following description, for purposes of explanation, specific nomenclature is set fo_h to provide a thorough under-
standing of the present invention. However, it will be apparent to one skilled in the art that these specific details are
not required to practice the present invention. For example, the present invention is disclosed with specific reference
to the HyperText Markup Language (HTML) and the HyperText Transfer Protocol (HTTP). However, the teachings of
6
EP O 792 493 B1
the present invention can easily be used with other hypertext document formats and other transport protocols.
(PICTURE)Ov rview
5 [OO68] The present invention provides a visually oriented software development tool for the design, construction and
modification of online computer services. The development tool of the present invention allows a user to create online
services using existing information sources such as databases, files, and applications that are external to the online
service itself. An online computer service created with the development tool can offer the following options_.
1O _ Search, view and edit information
_ Download, print or file information
_ Enable the information for commerce
_ Control access to the information
15 [OO69] Examples of types of online services that can be built with development tool of the present invention include
document viewing services, electronic commerce services, directoy lookup services, classified advertisement servic-
es, reference services, electronic bulletin board systems, document retrieval services, electronic publishing services,
an electronic service store for purchasing online services, and a global service-of-services that is used to locate and
connect to other online services. To create commercial online services, the development tool of the present invention
2O includes a sophisticated fee setting tool that levies of pays fees to users and content providers underdefined conditions.
[OO7O] The online service development tool of the present invention is one part of a comprehensive architected
platform for deploying distributed online services. The online services created with the development tool of the present
invention utilize standardized Application Program Interfaces (APl's) for communication between the various compo-
nents. The overall platform architecture is referred to as the Modular Online Information Services Architecture, or
25 Molisa. Molisa includes client software, server software, administrative software for recording and analyzing online
service usage, and the online service development tool described in this document. The software components of the
Molisa platform are hardware independent, and thus can be implemented on several different computer architectures.
[OO71] The invention's design characteristics are described here in the context of its preferred embodiment, a de-
velopment tool for the Molisa online services platform. The Molisa platform leverages existing HyperText Transfer
3O Protocol (HTTP) based World-Wide Web servers, and Mosaic and other HTTP client browsers (with software exten-
sions), on the global Internet. However, the design principles of the present invention are largely applicable to online
services in other settings, including non-architected centralized online services, other decentralized online services,
and services in which the client and server software reside on a single machine (such as CD-ROM based information
services).
35 [OO72] The Application Program Interfaces that define communication between the client software and server soft-
ware are largely independent of the underlying transport protocol. For example, the development tool of the present
invention does not require that the client and server computers communicate using HTTP or the underlying TCP/l P
protocol. Any suitable transport protocol, across Local Area Networks (LAN's), Wide Area Networks (WAN's), dial-up
or leased telephone lines, etc., may be used between the client hardware and the server hardware.
4O [OO73] Figure 1 illustrates a block diagram overview of an online service being used by three users that is imple-
mented with the Molisa platform. A server hardware platform 1 OO comprises a general purpose computer system
coupled to a communications network 15O. The HTTP server software 1 O1 and HTTP extension software 1 O3 run on
the server hardware platform 1 OO. The HTTP server software 1 O1 drives the online service using information stored
within the service repository 1 O7. The HTTP extension software 1 O3 provides additional functionality for the online
45 service that is not available in standard HTTP server software. For example, the HTTP extension software 1 O3 might
access a back end database.
[OO74] An online service development tool 1 O9 is used to create the data structures, documents, and scripts that are
stored in the server service repository 1 O7 and supply the HTTP extension software 1 O3. The HTTP server software
1 O1 accesses the data structures, documents, and scripts stored in the service repository 1 O7 to implement an online
5O service. Software for the development tool 1 O9 is usually located on a development computer system that is coupled
to the server system across a communications network 15O as illustrated in Figure 1 . Alternatively, software for the
development tool 1 O9 may run on the actual server computer system.
[OO75] Each user accesses an online service created with the development tool 1 O9 using compatible client software.
In Figure 1 , three client hardware platforms_. Windows_ platform 16O, Macintosh_platform 17O, and UNIX_/X-Windows
55 platform 18O are illustrated. Each different client hardware platform must have a copy of client browser software that
is compatible with the HTTP server software 1 O1 and the information stored within the service repository 1 O7. Each
client hardware platform may also have a local service repository. The local service repositoy at each client hardware
platform contains information that is available locally to the user of the specific client hardware platform. The local
7
EP O 792 493 B1
service repository can also act as a cache to store information retrieved from the main service repository 1 O7.
[OO76] The communications network 1 5O couples the users running client software with the online service server
software running on the server hardware. In the present embodiment, the communications network 1 5O is a packet
switched network implemented using TCP/l P protocol. However, the communications network 1 5O could simply be the
5 existing telephone network.
[OO77] Using the Molisa platform as illustrated in Figure 1 , small and large service providers can run an online service
using existing heterogeneous computer equipment and existing data in its original native form and location. Since the
Molisa platform uses standardized well-defined Application Program Interfaces (APl's), third parties can develop en-
hancements, extensions, or replacements for the client software, the server software, the metering software, or the
1O online service development tool software.
[OO78] Furthermore, the online service development tool software of the present invention is divided into several
different subtools that each have well defined subtool Application Program Interfaces (APl's). By having well defined
subtool APl's, third parties may create improved subtools to replace the original subtools. Alternatively, new subtools
can be added to the development tool software to handle unforeseen development.
15 (PICTURE)EIe_tr ni_ Commer_e
[OO79] The Molisa platform places a particular emphasis on commerce-enabling any information source that is elec-
tronically accessible. The Molisa platform uses the general steps illustrated in Figure 2 for electronic commerce in an
2O online service. lnitially, the se_ice user views general online information about goods or services that are external to
the service, as stated in step 21 O. This is usually done using a hypermedia document that contains images and text
describing the goods and services. Next, the user initiates an electronic transaction to download, price, purchase, rent,
reserve, etc. the online hyperdocument itself or the goods/services that the hypermedia document information de-
scribes, as stated in step 22O. In response to the user's action, the online service processes the electronic transaction
25 initiated by the user, as stated in step 23O. Using a Fee Computation defined in the Computation Language of the
present invention, the online service may charge or pay a user or content provider as stated in step 24O. Finally, the
user views the results of the electronic transaction, by viewing the downloaded information, or by viewing a confirmation
of the electronic transaction involving goods or services, as stated in step 25O.
[OO8O] In the transaction model of Figure 2, the notion of ''transaction'' can take several forms, and the development
3O tool invention supports each of the following_.
_ ReaI-time eIectronic transaction_. A transaction can debit a user's account, check and subtract from inventory, mark
(PICTURE)an item s reserved, reference up-to-date online information, etc. , all by immediately accessing the electronic
databases that contain the relevant data. The invention supports such real-time transactions with a Script Language
35 that provides direct access to any electronic databases that are accessible from the server.
_ ReaI-time manuaI transaction_. For manual systems (e.g. , a clerk checks inventory by looking in the back room,
(PICTURE)and the responds to the user in real-time), or electronic systems that are not accessible from the server computer,
human intervention might be required to complete a transaction. The invention supports these transactions with
4O Script Language primitives that allow for real-time cooperative activity between users and a representative of the
online service provider.
_ (PICTURE) In certain cases, an online service may wish to queue a series of transactions for
Iater batch processing. For example, an online service could queue all the transactions for a particular day and
45 transmit all the transactions for that day during the night to save on long-distance telephone charges when dialing-
up a remote computer. Alternatively, an online service may wish to issue a transaction against a computer that
provides only electronic mail access. To support these delayed electronic transactions, the invention includes Script
Language primitives that_. (1 ) perform file input/output (to queue transaction requests), and (2) send/receive elec-
tronic mail to automatic agents on other computers.
5O _ (PICTURE) Some online services can require manual transactions that do not occur in real-time.
For example, an online service run by an antique dealer can allow users to submit bids for items advertised on
the service, and the antique dealer can consider all received bids at the end of the business day. To support these
transactions, the invention's Script Language includes primitives that can submit and receive electronic mail be-
55 tween the user and a representative of the service provider.
[OO81] The use of examples will best illustrate how the development tool can be used to commerce-enable existing
sources of electronic information. For example, the development tool can convert the digital source information used
8
EP O 792 493 B1
to create a printed catalog into a commerce enabled online service. The created online service displays the contents
of the catalog on a user's display screen. A user can check the available stock and place an order for any item in the
catalog. Also, for example, the development tool can convert a list of classified advertisements into an online service
where advertised goods may be electronically reserved with a deposit or purchased outright. To update the electronic
5 list of classified advertisements, users may electronically submit new advertisements to the online service for a set fee.
[OO82] Another type of online service the development tool can create is a service that selects specific items from a
collection of netwsfeeds. based on a user's previously registered interests, and assembles a customized electronic
newspaper for which the user is charged a fee. Payment for any transaction with any online service can be handled
using secure, authenticated electronic transaction techniques as is well known in the art. Alternatively, other methods
1O of payment such as credit card payment, electronic funds transfer, or external payment mechanisms (e.g., mailing a
check) can be used.
[OO83] To create online systems that are prepared for commerce, the online system development tool includes a Fee
Setter for assigning fees and a sophisticated Script Language for creating scripts that control commerce transactions.
The online system development tool of the invention embodiment is referred to as the Online Designer. The Online
15 Designer is a visual editing system that allows a developer to create online services using graphical screen displays
and cursor control device such as a mouse. The Online Designer is composed of several distinct, cooperating, visually
compatible subtools. Although some of the Online Designer subtools are implemented as separate programs, all of
the Online Designer subtools appear to the user as an integral part of the Online Designer, and are described here as
such.
2O [OO84] The Online Designer online system development tool can be used to create sophisticated, yet easy-to-use
online services. Some of the features of an online service designed using the Online Designer development tool include_.
_ (PICTURE)(PICTURE)(PICTURE)(PICTURE) Hypermedia documents present text, images, video, and/or sound to a user
of the online service. Hypermedia documents may function as on-screen input forms by including visual objects
25 for user input_. text fields, checkboxes, option buttons, command buttons, and drop-down list boxes. ln the present
embodiment, the hypermedia document format supported by Online Designer is the HyperText Markup Language
(HTML). HTML is the HyperText format supported by HTTP servers comprising the World-Wide Web (WWW) on
the global Internet.
3O _ (PICTURE)(PICTURE) Portable documents preserve the exact printed appearance of a document (fonts,
illustrations, etc.), and can be viewed on different hardware and software platforms. A portable document can be
generated by any software application that supports printing. A specially designed print driver converts the printer
commands into the portable document format. Examples of portable document formats include Acrobat_ by Adobe
of Mountain View, California and WordPerfect_ Envoy by WordPerfect Corporation of Orem, Utah. The portable
35 document may be viewed on a workstation display screen as part of an online service. Collectively, hypermedia
documents and portable documents are referred to in this document as ''hyperdocuments.''
_ (PICTURE) Hyperlinks are visual buttons, images, or highlighted text that are associated with other
documents, images, sound clips, video clips, or other online services. To move to the associated object, a user
4O selects a ''hotspot'' with a cursor control device or chooses the hyperlink with the computer keyboard. Hyperlinks
appear within hyperdocuments.
_ (PICTURE) Allows for quick search through large collections of online documents.
The user can specify the search criteria using an appropriately designed hypermedia input form.
45 _ (PICTURE) A user may search through documents by specifying various document attributes such
as the date of the last update, the size of the document, the size of the fee for downloading the document, etc.
_ (PICTURE) Allows data or programs to be downloaded from the online service to the local
5O client computer system. Downloaded data or programs can later be executed, viewed, printed, or filed at the local
client system.
_ (PICTURE)_. Service-to-Service Protocol is a communication pro-
tocol whereby different online services can communicate information. Using the Service-to-Service protocol of the
55 present invention, an online service can_. (1 ) transfer control to another online service; (2) act on behalf of the user
to query or update another online service; (3) automatically update another online service without user initiation;
(4) appear to be seamlessly part of another online service; (5) keep a record of how many times users traverse to
another online service; (6) pass along automatic user registration data to another online service; (7) automatically
9
EP O 792 493 B1
register a new online service with a service-of-services or ''yellow pages'' service; (8) checkwhether another server
is running a particular online service or type of service; and (9) exchange usage and metering information, for
aggregation and later analysis.
5 _ (PICTURE) The Online Designer supports two different types of scripts_.
Event Scripts and Function Scripts. An Event Script is associated with a particular event for a particular visual
object in the online service. For example, there could be an Event Script associated with a ''Mouse Down'' event
for a ''Search'' button on a ''ListingQueryForm'' hypermedia document in an electronic ''white pages'' service. The
event script associated with the mouse-down event would specify how to convert the user input fields on the
1O ''ListingQueryForm'' form into a quey for the text search/retrieval engine on the server. In general, there can be
several Event Scripts associated with a single visual object, potentially one script for each type of event that is
defined for that visual object. A Function Script contains a single named function (subroutine) that can be shared
and invoked by multiple other scripts in the same service.
15 _ (PICTURE) These capabilities are achieved using inter-application com-
munication techniques such as Windows DDE, Windows OLE, OpenDoc, keystroke stuffing, terminal emulation,
command-line invocation, batch file invocation, and the like. For example, an online service can compute the
quantity discount for a catalog item by automatically launching a spreadsheet program, plugging the item number
and quantity into certain prearranged spreadsheet cells, invoking a spreadsheet macro to compute the discount,
2O and obtaining the item price from a prearranged result cell. Other examples include launching and controlling
applications for payroll, inventory, purchasing, and Manufacturing Resources Planning (MRP).
_ (PICTURE)(PICTURE) Structured Query Language (SQL), Open Database
Connectivity (ODBC), and other published and proprietary data access methods can be used to access real time
25 data sources. For example, a catalog shopping online service can check the available stock on a certain merchan-
dise item by issuing an appropriate SQL query to the inventory database. The inventory database would return
the information to the online service software such that the online service could provide the information to the user
or perform an electronic transaction.
3O _ (PICTURE) Equipment such as heating/ventilation/air-conditioning systems,
security systems, and lighting can be accessed and controlled.
_ (PICTURE) The service's content and structure can be replicated to other online services
on-demand or on an automatic, regularly scheduled basis.
35 _ (PICTURE) This can include the number of users who access the
service, the duration of each user's connection time, the number of times that a certain part of the service is
accessed, the number of times that a user was ''referred'' to this service by hyperlinking from another service, etc.
This data can be used to levy fees for users, advertisers, or information providers, or to tune the service itself.
4O _ (PICTURE) The available information on an online service can be controlled utilizing pass-
words, encyption, and assigning specific access rights to specific users.
_ (PICTURE) Support of real-time cooperative activity between two or more users, or between
45 users and a representative of the online service provider. For example, a multi-person game between users, or a
user entering an online query and receiving a real-time response from a service representative.
_ (PICTURE)(PICTURE) Allowing a user or service operator to capture an image to be displayed as part of
an online service (for example, a logo for a ''vellow pages'' directoy listing, or a photograph to accompany an
5O online classified advertisement), by faxing an image directly to the server, sending an image to the server using
electronic mail, or scanning an image at the client workstation and electronically transmitting the image to the
server. If a user does not have access to facsimile or scanning equipment, the user may physically send or deliver
the photograph or graphic to a service operator, who will electronically capture the image on behalf of the user
and transmit the image to the online service server.
55 _ (PICTURE) Allows a userto download entire online services (the structure and/or content),
usually for a fee. The user can then deploy those services on the user's own computer equipment.
1 O
(PICTURE)(PICTURE)
EP O 792 493 B1
_ (PICTURE)_. Allows a user to access a service-of-services which will search
and connect to other online services.
5 (PICTURE)
[OO85] Using the Online Designer, a user (referred to here as the online service ''developer'') can develop one or
more online services using a graphical editor. Each online service consists of one or more types of ''subservices.'' Each
subservice is a server program for handling a particular type of online service user interaction. Each subservice program
has an associated database that stores the information that can be provided to the user and a set of scripts for handling
1O events.
[OO86] Figures 3a and 3b illustrate how the Online Designer is used to create a set of subservices that comprise an
online service. First, at step 31 O user decides if another subservice should be created or edited, if not, then the online
service is complete. When creating a new subservice, the developer may retrieve an existing sample subservice to
start from as stated at step 31 5. At steps 32O and 325, the developer loads in an existing subservice document. If no
15 document (database) exists for the new subservice, the developer can import an existing document. If the developer
wants to preserve the printed appearance of the existing document, the Portable Document Converter is used as stated
at step 335, otherwise the Hypermedia Document Converter is used at step 337. The developer then edits the sub-
service by editing the associated document (database) at step 34O.
[OO87] Figure 3b illustrates, in detail, how a document can be edited using the Online Designer. The Hypermedia
2O Editor is used to modify the appearance of the document at step 342. The Hypermedia Editor cannot be used if the
document is a portable document. Any inline images can be edited using third party image design tools such as paint
programs at step 344. The interactive elements of a subservice are edited by creating input forms with the Hypermedia
Editor at step 346, and creating event scripts that process the input using the script editor at step 347.
[OO88] Referring back to Figure 3a, the hyperlinks within a document and to other online services or subservices
25 can be created and edited using the Hyperlink Editor at step 351 . Finally, the developer can save the created subservice
for the online service at step 362.
[OO89] The Online Designer includes specific Designer Subtools for designing each different type of subservice. In
general, an online service may include more than one subservice of the same type or of different types. The following
nine types of subservices are examples of subservices supported by the Online Designer_. HyperdocumenUCommerce,
3O Directoy Lookup, Classified Advertisement, Reference, Bulletin Board, Document Retrieval, Electronic Publishing,
and Meta-Service. Additional types of subservices can be added later.
[OO9O] Figure 4 illustrates a block diagram of all the subservice designer tools of the Online Designer. More sub-
service design tools can be added in the future. As illustrated in Figure 4, the Lookup Designer 41 4 is used to design
Directoy Lookup subservices, Classified Advertisement subservices, and Reference subservices since these three
35 types of subservices share many similarities.
[OO91] Referring to Figure 4, the Hyperdocument Designer 41 2 is used to design Hyperdocument/Commerce sub-
4O services. A HyperdocumenUCommerce subservice displays hypermedia information to a user of an online service. A
Hyperdocument/Commerce subservice can optionally allow a user to purchase goods or services described by the
displayed hypermedia information. Hyperlinks and full-text searches allow the user to move through the different hy-
perdocuments that comprise a Hyperdocument/Commerce subservice.
[OO92] An example of a Hyperdocument/Commerce subservice is an electronic shopping system, where the user
45 views an online catalog of goods or se_ices and potentially submits an electronic order for goods. The user's electronic
order is processed by an event script associated with the Hyperdocument/ Commerce subservice. The Hyperdocument/
Commerce subservice can also be used to display online documentation or help.
5O (PICTURE)(PICTURE)
[OO93] Referring to Figure 4, the Lookup Designer 41 4 is used to design Directory Lookup subservices. A Directoy
Lookup subservice provides an online, searchable directory of information. For example, a Directoy Lookup subservice
can store a directory of persons, companies, or other entities. Each entry in the directoy can list a name, an address,
and any other related information; essentially, an online implementation of telephone ''white pages'' listings. Alterna-
55 tively, the entries in a directory can be hyperdocuments that include company descriptions and adve_isements, and
can be arranged in categories, much like conventional telephone book ''yellow pages'' listings. In either case, entries
are searchable by name, by category, or using full-text search techniques with user-specified keywords.
[OO94] Each directoy entry can optionally provide hyperlinks to other entries. Furthermore, each entry can contain
EP O 792 493 B1
a hyperlink to a dedicated online service that provides additional information about the entry. Using the directory sub-
service, qualified users can submit new entries, which immediately become available for retrieval in subsequent search-
es of the directoy subservice by other users.
5 (PICTURE)Classified Adve_isement Subse_ice
[OO95] Referring to Figure 4, the Lookup Designer 41 4 is also used to design Classified Advertisement subservices.
A Classified Advertisement subservice implements an online version of classified advertisements. Users can search
existing classified advertisement listings. Classified advertisement submissions are searchable by category, geograph-
1O ical area, the name of the submitter, or using full-text search techniques with user-specified keywords. Furthermore,
end users can submit new classified advertisement listings of their own. The online service can charge a fee for sub-
mitting a new classified advertisement.
Reference Subservice
15 (PICTURE)
[OO96] Referring to Figure 4, the Lookup Designer 41 4 is also used to design Reference subservices. A Reference
subservice implements an online reference work, such as a dictionary, thesaurus, or encyclopedia. A user can search
the contents of a Reference subservice by the name of the enty, or using full-text search techniques with user-specified
keywords. The online service provider controls the content of a Reference subservice. However, the online service
2O allows the user to submit additional personal entries that are seamlessly integrated into the subservice, but are only
seen by that user. These personal entries can be stored within the service repositoy of the client hardware system.
(PICTURE)BuIIetin Board Subservice
25 [OO97] Referring to Figure 4, the Bulletin Board Designer 41 6 is used to design Bulletin Board subservices. A Bulletin
Board subservice provides a means for allowing users to post and view messages about a particular topic. Users may
read and search through the existing messages. A user may reply to an existing message, or reply to a reply, thus
creating a ''conversation thread'' from an original message.
[OO98] The messages are divided into different sections. Messages within a given section conform to a submission
3O form designed for that section by the online service developer. The submission form can contain various data fields
that are specific to that message section, in addition to a text input area on the form for typing the message to be
posted. The developer also specifies which message data fields should appear in the summary view for each bulletin
board section. The summary view lists the relevant header information for the messages in that section.
35 (PICTURE)Document Retrieval Subservice
[OO99] Referring to Figure 4, the Retrieval Designer 41 8 is used to design Document Retrieval subservices. A doc-
ument Retrieval subservice provides a means for users to retrieve documents and other files such as word processing
documents, spreadsheets, text files, databases, images, sound files, video files, executables, etc. Users can find such
4O documents using full-text search techniques with user-specified keywords, forthose document types that can be viewed
as text. Users can also find documents by category and subcategory, when hierarchical browsing is supported by the
online service. A document Retrieval service can be used to provide searchable access to a large corpus of text, to
make files on a file server available to geographically remote offices within a company, or to provide software updates
to customers.
45 (PICTURE)
[O1 OO] Referring to Figure 4, the Publishing Designer 42O is used to design electronic Publishing subservices. An
Electronic Publishing subservice provides a user with an electronic edition of a newspaper or magazine that the user
5O may download to the user's local client hardware. An Electronic Publishing subse_ice can create a customized daily
newspaper, that provides only news stories that match certain criteria provided previously by the user. Downloaded
material may take the form of static documents, or hypermedia documents with images, sound, video, and hyperlinks
to move through the hypermedia document.
55 (PICTURE)Meta-Se_ice Subse_ice
[O1 O1] Referring to Figure 4, the Meta-Service Designer 422 is used to design Meta-Service subservices. A Meta-
Service subservice provides a service-of-services that is designed specifically to help a user find another online service.
1 2
(PICTURE)(PICTURE)
EP O 792 493 B1
Using the Meta-Service subservice, a user can look for another online service, using keyword searches, categories,
alphabetic listings, etc. An online service listing can include a description of the online service, the categories to which
the online service belongs, and a visual icon for the online service. Once the user finds a desired online service, the
meta-service provides a direct connection to the online service. A Meta-Service subservice can itself lead to other
5 meta-service subservices, in a hierarchical or network fashion.
[O1 O2] In a common use for the invention, a HyperdocumenUCommerce subservice will be combined with other
1O subservices to commerce-enable those other subse_ices.
[O1 O3] For example, an online service that includes a Reference subservice that allows the user to peruse the current
Books In Print can also include a Hyperdocument/Commerce subservice to enable books to be reserved or purchased.
This is illustrated in Figure 5, in which a Reference subservice containing book descriptions has a particular book
reference with a hyperlink. When viewing a particular book entry in the Reference subservice, the user clicks a button
15 on that book enty to transfer directly to the HyperdocumenUCommerce subservice. The HyperdocumenU Commerce
subservice will be invoked to display an on-screen order form so the end user can buy the book. The user types the
necessary ordering information into the order form and transmits the information. The Hyperdocument/ Commerce
subservice contains a script for processing the information entered on the on-screen order form.
[O1 O4] A second electronic commerce example is provided with reference to Figure 6. Figure 6 illustrates an auto-
2O mobile rental agent's use of the Online Designer to create and deploy an online se_ice that includes a Directory Lookup
subservice that displays information about the available cars to rent. If a user selects a particular car from the Directory
Lookup subservice, then the online service transfers control to a HyperdocumenUCommerce subservice that displays
an automobile rental form to the user. To rent the car, the user fills in the on-screen form. The information entered into
the on-screen form is processed by a script in the subservice electronically transmitted to the automobile rental agency.
25 [O1 O5] The Online Designer makes a distinction between the ''framework'', the ''structure'', and the ''content'' of an
online service. The ''framework'' is the architected online services platform Molisa for which Online Designer develops
online services. The Molisa framework provides the domain independent infrastructure and includes the Online De-
signer, the subservice programs created with the Online Designer, the documents created with the Online Designer
for use by the subservices, and the client software used to access the online service created with the Online Designer.
3O [O1 O6] The ''structure'' of an online service is composed of those portions of the service that define its behavior.
Classified advertisement classifications, a bulletin board submission form, and hyperlink attributes are examples of
the components that comprise the structure of an online service. The structure includes the selected subservices and
how the selected subservices are connected together.
[O1 O7] The ''content'' of an online service is the information that the each of the subservices delivers to users. Some
35 of the content of an online service can be static, provided by the developer when the online service is designed; and
some of the content can be dynamic, provided by the developer or other users at run-time without requiring further
online service design work. Examples of static content includes the Screen displays for different regions of an online
service. Examples of dynamic content includes bulletin board messages written by users and classified advertisements
submitted by users.
4O [O1 O8] Hyperdocuments are sometimes part of the structure of an online service, and sometimes part of the content.
For the purposes of Online Designer, a hyperdocument is considered part of the service's structure if it is in a Hyper-
document/Commerce subservice, or if it is a form. Otherwise, the hyperdocument is considered a part of the service's
content if the hyperdocument is displayed in any other type of subservice.
[O1 O9] Using the Online Designer, a developer can create ''templates'' for the structure and/or content of an online
45 service, in addition to developing entire online services. A ''structure template'' is a pa_ially developed online service
structure, whose development can be easily completed by developers who provide the missing details to create a fully
functional and customized online service. Similarly, a ''content template'' is a partially developed content module for
an online service. Templates can be separately packaged and provided to other developers to expedite the development
of online services using Online Designer.
5O [O1 1 O] The structure and content of an online service are stored in the Service Repository. The Service Repository
is a database system that is potentially distributed between the client workstation and one or more servers, depending
on the design of the particular online service. When the data is distributed, it still appears to the developer and user
as a seamless whole. Each Online Designer subtool stores the data for its subservice in the Service Repository, and
the various Utility Subtools access data from the repositoy for a single subservice or multiple subservices.
55 [O1 1 1] The Online Designer includes replication support for the Service Repositoy itself. This is useful in cases
where the developer's workstation does not have full-time direct access to the Service Repositoy for a certain online
service. For example, this can occur if the service was originally, developed by another person. In such cases, Online
Designer can replicate the components of the online service from the server where the service resides down to the
1 3
(PICTURE)(PICTURE)(PICTURE)(PICTURE)
EP O 792 493 B1
developer's workstation, and then replicate the components back to the server when the modifications are complete.
[O1 1 2] There can also be more than one developer who regularly maintains an online service. In such cases, it
becomes important to prevent multiple developers from modifying the same part of the service simultaneously, because
one developer's work will overwrite another when the changes are replicated back to the server. To address this issue,
5 Online Designer supports version control techniques, as known in the art, allowing a developer to ''check out'' a service
component for modification. When checked-out, the component may be viewed but not modified by any other developer
until the component is later ''checked-in'' by the developer who checked it out.
1O (PICTURE)
[O1 1 3] The Online Designer tool provides the organizational structure for developing online services. It also provides
access to the various subtools that allow the developer to design the details of online services. Online Designer includes
specific Designer Subtools for each type of subservice. The various Utility Sub tools are accessible directly from the
Online Designer tool, as well as from those Designer Subtools that apply.
15 [O1 1 4] Figure 7 illustrates a block diagram of the Utility Subtools. The list of Utility Subtools that support Online
Designer and the Designer Sub tools include a Hypermedia Editor 71 1 , a Portable Document Editor 71 2, a Hyperlink
Editor 71 4, a Hypermedia Document Converter 71 6, a Document Harvester 71 8, a Script Editor 72O, a Fee Setter 722,
a Replicator 724, a Metering Tool 726, a Repository Browser 728, a Debugger 73O, and a Help Editor 732. A description
of each utility subtool is hereby provided.
2O (PICTURE)(PICTURE)
[O1 1 5] The Hypermedia Editor 71 1 is a What-You-See-ls-What-You-Get (WYSIWYG) visual editor for creating and
editing hypermedia documents. The Hypermedia Editor 71 1 can edit text, visual elements, sound elements, user-input
25 objects, and hotspots for hyperlinks within hypermedia documents. Figure 3b illustrates how the Hypermedia Editor
71 1 can be used to lay out user input forms for the various types of subservices that require user input. In the described
embodiment, the Hypermedia Editor is used to create and modify documents in the HyperText Markup Language
(HTML) format. However, any other hypermedia format can also be supported.
3O (PICTURE)Po_able Document Editor
[O1 1 6] The Portable Document Editor 71 2 is a visual editor for adding hyperlink button hotspots to portable docu-
ments. Since portable documents preserve the exact printed appearance of a page, the portable document format is
inherently less flexible for on-screen viewing than the format of a hypermedia documents. Thus, only hyperlink buttons
35 can be added to portable documents. For situations where video, sound, or user input are required, the online service
developer should use a hypermedia document instead of a portable document.
4O [O1 1 7] The Hyperlink Editor 71 4 is a tool that displays and manipulates hyperlinks within an online service. The
Hyperlink Editor is described in greater detail in a dedicated subsection, below.
45 [O1 1 8] The Hypermedia Document Converter 71 6 is a Conversion tool that translates documents from various doc-
ument file formats into a hypermedia document format supported by the Online Designer. For example, the Hypermedia
Document Converter can convert various word processor files into HTML files. Once a document is in a hypermedia
document format such as HTML, the hypermedia document format can be edited with the Hypermedia Editor 71 1 .
5O (PICTURE)Po_able Document Converter
[O1 1 9] The Portable Document Converter is a conversion tool that translates documents from various document file
formats into the portable document format supported by the Online Designer. For example, the Portable Document
Converter may translate a Postscript_ file into a portable document format supported by the Online Designer.
55 (PICTURE)Docu ent Harvester
[O1 2O] The Document Harvester 71 8 is a visual tool for specifying which files, directories, and volumes should be
1 4
__3344
1,,,,
ooo
(PICTURE)(PICTURE)(PICTURE)(PICTURE)(PICTURE)(PICTURE)(PICTURE)
asdcsdocsa
[pg[[[[[
u_u
oooooo
,a
,,e
uas
npe
rre
r,
os
e
111111
a
bv,ne
dor
upv
a
vep
2a22222
senr
c
nos__s
,e
2__a345r67
ec
,
dg,,
eoes
,u_c
]]],]]]
dse
r
ee
,re__
vpT
ra__
v,,,
s
reeoo
d__
e____
s,
e,
s
,
cc
j
TTTTrrTT
e,
ro,
ue
rey
e
aos
,,
,e,
,,,,,,
snc
sd
__a,
ns,
e
rBe
eaeeeee
a__
_c
__
d,
eme
b
,,,
grr
ns
Aop
D
_eoH
F_
r_,
__ou
ep
une
sumsw
s
e,
eee
en__
sge
,r
,c
o
o,p__
a
ecv
ppbd,
psn
e,
____po
v
,pu
aeee
ae
,oue,
u
rd
S__n
,eo
c,r
sc
nrr,E
g
es
rrr
,c
e__ej
n
eaer
__
jns
,g
__7d
d
eem
,
d
by,
,r
,s
bg,o
,e
s2,
s__
oe
__
e__,
__end
eaoa
coro
ur
8ve
rTy
c
sa(_
rn__,
__
us
cb7r
ne
7_o__
,
e,poo
7,,
,su,
B3
e7
__,
e)
2doo
n
d,rn
2n
d
aeo3
r
dr,o
4,s
,
ep
s
2o,
g
,e
r
ro2
,vm__
e
7
vmn
g__
so
w
a
__ed
ss
nc
s__
2
____de
ea__
su,Sr
c
es
osea
6,a
o__
day
e
uben
reen
n
as
e
,ga
v
ss
ss,
,,__
srrb
,e
,
msre
__
av
e,_
o
scu,
,_s
e
u__e
7r
co
gcT
__v
ueb
aaT
ec,u
br2
,o
p,oc
e,
b,__
_ye
j
,p
,c
__s8co
o
,so
r
o,
,Tae
pe
o(e
e
ea
oo,
b
nun
o3_
c__
,o
o
,p,
s
o_D,
eb,
j)w
_
,
ee__
e
,re
r,
,o
,,
,
b,
__e
,ea,
,p
co,x__
,re
,n
aF,
e,,
eb
ea
,roao,,
o,
aos
s
s
d_
e,e
pe,u
aw,d
s
o,s
,
our
v__
e,g
,,r
,oa
____
w,e
sod
__,
ns
b
__
em
,c,nog
o
sn,
Spn
,ep
_r
,,
aa
rao
__,ge
o
pro
,_s
nev
,,
eye
,,
__,a
w
or
eev
sec__
ee
j
,Ta,
py
,a7
cen,__
ds__
__o,,
nv
c
e,o
sa,,
__,3
m__
,oa
,,ge
,
e,
ra
eoop
,
__eo,
e,p
7saj
erwe
nos
__e
s
vsc7p
,c
2d
n__
,,ru
s
s
u
____2
mo
,,r
ad
2
cp,
,,c
,o
s__
b6o
d
s,p
e,
,
eae
o,
uap
__s,,y
seev
,
o_
wsa
__
,rebr
ee,
,ss__se
Fe
n__
n,
,__ua
a
r
pac
,e,
opvd
uda
g
__,
o,
s
n
a,r
e,,
se
,e__e,
re,je__
cp
__e
nb
co
asvow
ea
r
pe,e
s,
aee
er
c
ga
xe,
on
rr,
e,de
m
po
__rr
es
a,,d
nn__,
oe
e
r__
o,
,
,so
bn
vp
me
c____
,
,n
cppn
nd
__eo
e,
e
enn
__a__
r
e
,
pp__
en
c,
d
__
eer,un
bg
cs
,,
ar
s
,se
__,
e,
s__n
eae
aer
o__eo
_,
s,je
n,
j,
,,o_,
sna
(a
er
ue__a
eu
un
a
__m
e
m
,ujn
dn
r,
ss__
ss
sg
vc
ve,
bd
a(da
p
jpo
__e
e_e
__
__nw
jr
_o
c
ne,
ae
err
rd
s,
),
g__
d
e
yse
r,o
__,o
c
cn,p
jee
we
)_,
oe
,n
__
,dr
c,dsr
mb
,,
y
T,e
s,
oa
aa
u,
eau,
e(
,es
,,,
,__o
n
n4,b
c,__g
,m,s
an
o,
,e
er
s
_,)
e
,__o
be
,a
e__o
un
e,
,s
wo
__e
eFns
sn,
sc
,u
__r
dp
p__
n
ev,
ew
o,,e
nna__
cdos
an
,
e__
re
n,
b__,c
,____
ovcn
__,
,s
es
r
,
,no
eo
se,
a,
a
ce,
Sep
,p
__e__w
,s
s
c__
rn
,
ue
nroe
ne
,ego
ede
j
uen
m,rc
wD
,c
__
evs,
rr
,d__
,
aas__
,v
,__
ess,
e
d,
en
__7o
,
e__
,,__
nre__
ec
su
rc
nc
2,c
e
d,s
dob
__sr
o7,e
4eugS,
v,
u
js
spa
n
2
aj
sjmne
__
aabece
_a
u,s
2,,
n_,,e
__s,
co
nr
re
nec
,p
bc,
__
dv
uer
ce
ds,
en
ese_b
__w
c__,
_,
ecc
e
po
,
eT
b,
,e
__e
,so
s
soe
s,,
aun
ra
r__
s,y
o
sejc
v
ne__a
__rj
d,
_,
dec
s
enre
__
,a
,co
cb
__v
e__,
necue
njc
,,d,
er
o,e
s__
,oerp
cp
eb,
ee
oe
e
,c
c__,
spo
ceo__
ees
rve
crv,
rs,
_o__
w
s
mu
_s
__,c
de
os
bao
beuo
n__s
we
_,
,
aj,_
nasw
errn
oo
,e
ds
v__T
,,a
sa
,oe
d,
_pr
er
__
____
eeyo
ocn
ng,nb
ue
n_____
den,
ndn
neeey
ss
,r
j
EP O 792 493 B1
indexed for full-text search and retrieval. The Document Harvester displays the file/directory/volume entities in a graph-
ical tree structure such that a developer can specify pa,icular entities for indexing using a cursor control device. In a
similar fashion, the developer can specify which specific users or groups of users have the right to access which entities.
5 (PICTURE)
[O1 21] The Script Editor 72O is a visual editor for creating and editing the Event Scripts and Function Scripts of an
online service. The Script Editor is described in greater detail a dedicated subsection, below. To facilitate quick devel-
opment of an online system, many sample scripts for many application domains are provided with the Online Designer.
1O Fee Se,,er
,,
a,,,',,',d,,,,',.,,_,,g,',,,,m,'.,.,,,',,,s,;m,,,,,,in,',,,,,'c,,,;,,',u,,',,,d,,',,;,,n,',,.,;_,_,.,,,',,,e,,',,,n,,',',u,.,'.,,s,,,,,,,',t,,m;.,,,m,o',_;,'b,,,,'a,,,,'rms,,.,,m,,,',,k,,'ew,,,',y,,,ws,',,'t,,.,r,',,o,,,,,'k,;e,,,',,_,,,',,h',,,o',,m,r,,t'.,c,,,,,',u,,,';t,_,,,',,,,,'a,,,,'n,,,,'d,,,,',,,m,,'.,,,,.,'o,,,,,,u,',,,s',,,,,e',,,,,,t',e,',,,_,,,',,h,'m,n,',,,,i,'q,,,,u,,',e,',,.,s,,m',,'s,m',,u,',,,c,,'.,'h,w.,,,,,'a,.,,,,s'',,,,,,d',',o,,,',,u,,.,b,,',,,l,'e,m,,,-,;,,,,_'',m,c,',,;',,i,n'm,,g,',,,,',,a,'w,n,',-,dm',',,;,',w,',r',a,,,',g,,',m,-,,a,';,._,,,d,,',,,,--.
1 5
(PICTURE)
EP O 792 493 B1
[O129] Figure 8 illustrates a blockdiagram example of an online service that can be created with the Online Designer.
The online service illustrated in Figure 8 will be used as the basis for a series of examples throughout this document.
5 [O13O] The online service structure of Figure 8 initially shows the user an introductory page for the company. From
the introductory page, a user can go to a company personnel directoy, a catalog of products made by the company,
a list of tips and tricks for using the company's products, a company, newsletter, and a listing of corporate information.
The example online service illustrated in Figure 8 can be used as a template for any company that wants to quickly
create an online service for its customers.
1O [O131] When the Online Designer is initially invoked, it displays the Service Gallery, which shows all existing online
services that are available for modification. Figure 9 illustrates how the Service Galley appears to a developer. Each
online service is represented by an icon, with the name of the online service displayed beneath. From this screen
display, the developer can cut, copy, paste, and delete entire online services.
[O132] To ''open'' an existing online service, the developer double-clicks with the mouse on the icon for the desired
15 online service. This action opens a Se_ice Window, which displays the components of that se_ice. There are four
''views'' for a Service Window_. Connectivity View, Script View, Link View, and Fee View. The initial view for a Service
Window is the Connectivity View. To switch between the views, the developer chooses the appropriate pull-down menu
item or clicks on the appropriate button on a Service Window toolbar.
[O133] The Connectivity View of the Service Windowfor an online service displays all of the subservices, data sourc-
2O es, and content corpuses that comprise the online service. The Connectivity View also illustrates hyperlinks to other
external online services to which this online service connects. For example, Figure 1 O illustrates a Connectivity View
forthe online service of Figure 8. As illustrated in Figure 1 O, each subservice is displayed with the name of the element
subservice beneath.
[O134] From the Connectivity View, the developer can cut, copy, paste, and delete entire subservices. The developer
25 can change the data sources (SQL databases, ODBC databases, CD ROM databases, server-based files, data on the
Iocal client workstation, etc.) for each subservice; change which content corpuses the service uses within those data
sources; and change the hyperlink connections to other online services, including access to all features of the inven-
tion's Service-to-Service Protocol. For data sources, the developer can specify and modify the necessay logon infor-
mation and other parameters necessary for accessing the data.
3O [O135] From the Connectivity View, the developer can double-click on a subservice icon to edit that subservice.
Double-clicking on a subservice icon invokes the design tool forthat particulartype of subservice. For example, double-
clicking on the Hyperdocument/Commerce subservice icon for the Company Introduction Page invokes the Hyper-
document Designer tool.
[O136] Figure 1 3 illustrates how the internal structure of the hyperdocument for the Company Introduction Page may
35 appear. As illustrated in Figure 13, the Hyperdocument Designer tool provides access to the hypermedia documents
that comprise the Company Introduction Page Hyperdocument subservice.
[O137] Double-clicking on a hypermedia document (shown in Figure 13) invokes the Hypermedia Editor. Figure 11
illustrates a Hypermedia Editor view of the Company Introduction Page. The Hypermedia Editor is a What-You-See-
Is-What-You-Get (WYSIWYG) editor that displays a hypermedia document as the hypermedia document will appear
4O to an end user. The developer can edit the hypermedia document until the developer is satisfied with its appearance.
[O138] The Script View of an online service displays a list of all the scripts in that service. Figure 12 illustrates a
Script View for the online catalog. Each script has a descriptor. The descriptor for an Event Script consists of the name
of the event, the name of the visual object to which it applies, the name of the document containing that visual object,
and the name of the subservice containing that document. The descriptor for a Function Script is simply the name of
45 the function
[O139] The developer can invoke the Script Editor to view and modify a script by double-clicking on that script's
descriptor in the Script View. Alternatively, the developer can access an Event Script by double clicking on the visual
object associated with the script from within the appropriate Designer Subtool. Function Scripts, on the other hand,
can only be accessed from the Script View.
5O [O14O] When the developer chooses the Link View of an online service, the Hyperlink Editor is invoked to view and
modify the hyperlinks between the subservices of the online service. For hyperlinks between individual documents and
files, see the Link View of the Hyperdocument Designer, below. For hyperlinks between whole services, see the Con-
nectivity View of the Online Designer, above.
[O141] The Fee View of an online service provides access to the Fee Setter subtool. When invoked from the Con-
55 nectivity View, the Fee Setter subtool allows the developer to specify the cost (if any) of accessing the service as a
whole. To specify fees for individual documents or parts of a service, the developer invokes the Fee Setter subtool
from the individual Designer Subtools such as the Hyperdocument Designer Subtool.
[O142] At any time while running the Online Designer, the developer may access the Replicator tool to specify rep-
16
(PICTURE)(PICTURE)
EP O 792 493 B1
lication behavior among services and subservices. The Metering Tool can be accessed to specify service and sub-
service metering characteristics, and the Repositoy Browser can be used to view and manipulate the contents of the
Service Repository. In addition. the developer may invoke the Debugger to run and debug an online service or a single
subservice.
5 (PICTURE)
[O143] Each of the Designer Subtools is used to develop a particular type of subservice within an online service. The
most important and original Designer Subtools are_. (1 ) the Hyperdocument Designer, for subservices that consist of
1O linked hypermedia and portable documents; and (2) the Lookup Designer, for Directory Lookup, Classified Advertise-
ment, and Reference subservices. This section describes these two Designer subtools in detail.
15 [O144] The Hyperdocument Designer 412 subtool is used to design Hyperdocument/Commerce subservices. Spe-
cifically, any subservice that displays hyperdocuments and supports hyperlinks between hyperdocuments is designed
using the Hyperdocument Designer subtool. A typical online service will require these features to some degree, so
most online services include at least one Hyperdocument/Commerce subservice.
[O145] When the developer double-clicks on a Hyperdocument/Commerce subservice icon from the Connectivity
2O View of the Service Window for an online se_ice, the Hyperdocument Designer is automatically invoked. Hyperdocu-
ment Designer supports four differentviews_. Document View, Script View, Link View, and Fee View. Figure 14 illustrates
a block diagram of the different views supported Hyperdocument Designer. To switch between views, the developer
chooses the appropriate menu item or clicks on the appropriate button on the Hyperdocument Designer toolbar
[O146] Initially, Hyperdocument Designer displays the Document View, which shows one icon for each of the hyper-
25 documents that comprise the subse_ice. An example of a hyperdocument being viewed with the document view is
illustrated in Figure 13. Beneath each icon is the name of the document. The document icons are visually shown in
the arrangement laid out by the developer. The developer may rearrange the document icons in the Document View
using drag-and-drop mouse techniques, and the icon arrangement is preserved between sessions with Online Design-
er. The icon arrangement in the Document View is for developer convenience only, and has no bearing on the behavior
3O of the hyperlinks that define the order in which the user sees documents. Double-clicking on a hypermedia document
icon or portable document icon invokes the Hypermedia Editor or Portable Document Editor, respectively, to view and
modify that document.
[O147] From the Document View, the developer may invoke the Hypermedia Document Converter or Portable Doc-
ument Converter from the Hyperdocument Designer menus or toolbar. These two Converter tools translate preexisting
35 documents from various file formats into the Online Designer's standard hypermedia document format or portable
document format. After translating a document, the developer assigns a name and icon to the new hyperdocument,
and repositions the new icon within the Document View as desired. The developer may then edit the hyperdocument
to add visual objects using the Hypermedia Editor. The developer can connect the new hyperdocument using the
hyperlink editor to edit hyperlinks that integrate the document into the subservice.
4O [O148] The Script View, Link View, and Fee View of the Hyperdocument Designer are analogous to the same views
in the Online Designer tool itself. The Script View provides access to the Event Scripts and Function Scripts that pertain
to the particular Hyperdocument/Commerce subservice. When the developer chooses the Hyperdocument Designer's
Link View, the Hyperlink Editor is invoked toview and modifythe hyperlinks between all documents and files associated
with the subservice. The Fee View of the Hyperdocument Designer invokes the Fee Setter subtool to specify fees for
45 individual documents and files in the subservice.
[O149] In effect, the Hyperdocument Designer is a Designer Subtool that provides organized access to the Utility
Subtools that are most often used in designing a hypermedia and/or commerce subservice. For example, suppose
that an existing mail-order catalog shopping company wishes to use the invention to design and deploy and online
service that is the electronic equivalent of an existing mail-order catalog service. The developer could invoke the Hy-
5O perdocument Designer to create a new Hyperdocument/Commerce subservice.
[O15O] The developer could use the Portable Document Converter to convert an electronic version of the company's
catalog into a portable document. Using the Portable Document Editor, the developer could add hyperlink buttons to
the portable document, which lead the user to the electronic order form from the catalog. From the Document View,
the developer could invoke the Hypermedia Editor to create an electronic order form with a button to submit the order.
55 Figure 15 illustrates a hyperdocument that displays information about a product. The hyperdocument of Figure 15
includes a ''Place Order'' button 1 53O that moves the user to a purchase order screen.
[O151] Figure 16 illustrates a purchase order screen that could be connected to the ''Place Order'' button with a
hyperlink. The purchase order screen allows an end user to enter information to order the product. After the user has
17
(PICTURE)
EP O 792 493 B1
entered the necessary information, the user selects the ''Purchase'' button to buy the product. An event script processes
the information and orders the product. To edit the event script, a developer double-clicks on the ''Purchase'' button
1 63O from the Hypermedia Editor. The developer edits the script associated with the ''Purchase'' button 1 63O script
such that the script gathers the information from the form and submits the order as a transaction against the back-end
5 order/inventory database system. When the design is complete, the deployed service allows users to view the catalog
online, and place orders in real-time, without human intervention.
1O [O1 52] The Lookup Designer tool designs Directory Lookup, Classified Advertisement, and Reference subservices.
In each of these types of subservices, the user can search through a database of entries, and in some cases, the user
can submit new entries. The differences between the subservice types include the kinds of visual objects found in the
entries, the browsing and searching techniques supported, and whether or not the user can submit new entries for
public viewing.
15 [O1 53] When the developer double-clicks on one of the three types of lookup subservices in the Connectivity View
of the Service Window for an online service, the Lookup Designer is automatically invoked. As illustrated in Figure 1 7,
the Lookup Designer supports six views_. Form View, Category View, Options View, Script View, Link View, and Fee
View. As with the other Designer Subtools, the developer uses menus orthe Lookup Designertoolbar to switch between
the different views.
2O [O1 54] The initial viewfor Lookup Designer is the Form View. From the Form View, the developer uses the Hypermedia
Editor to design the Submit Form, View Form, and Quey Form for the subservice.
[O1 55] The Submit Form allows a user to submit a new entry to be listed on the subservice. Figure 1 8 illustrates an
example screen display for a submit form for the Corporate Personnel Directory subservice of Figure 8.
[O1 56] The View Form is the template that displays the contents of an enty to the user. Figure 1 9 illustrates an
25 example screen display for a view form for the Corporate Personnel Directory subse_ice of Figure 8.
[O1 57] The Query Form allows the user to search for entries based on various criteria. Figure 2O illustrates an ex-
ample screen display for a query form for the Corporate Personnel Directory subservice of Figure 8.
[O1 58] There are certain standard input fields that the various Lookup Designer forms may provide. A form need not
use all of the standard fields. However, for the standard fields that are used, the form should also use the standard
3O internal names for those fields so that the fields will be properly recognized and handled by Molisa. If a given form
does not yet exist for a subservice, Online Designer provides a default form containing all standard supported fields,
which the developer can modify.
[O1 59] The standard Lookup Designer form fields are as follows_.
35 Name For Directory Lookup subservices, this is the person or entity name for the enty.
For Reference subservices, this is the name of the item for which reference infor-
mation is being provided. For Classified Advertisement subservices, this is the
name of the person submitting the enty.
4O Address, Phone, Fa_, E-mail For Directory Lookup subservices, these fields pertain to the person or entity listed
in the entry. For Classified Advertisement subservices, they pertain to the person
submitting the entry. These fields are typically not used for Reference subservices.
Categories The categories under which the enty should be listed. Typically, this is a pairing
45 of two visual objects_. a drop-down list box showing all of the categories recognized
by the subservice, and a text entry field that displays the list of categories that the
user has chosen so far for this entry. Note that the user must choose from among
the categories specified by the developer in the Category View of the Lookup De-
signer when the subservice was designed. (The developer can of course change
5O the list of categories at a later time using Online Designer.) This field is typically
used in Classified Advertisement and ''yellow pages'' Directoy Lookup subserv-
ices. The categories are used for browsing purposes, in that all entries that belong
to a given category are shown together under that category name. In Classified
Advertisement subservices, the categories can be used as part of the search cri-
55 teria on a Query Form.
Keywords Similar to categories, but users can type in any keywords they deem appropriate,
ratherthan being constrained to choose from a fixed list. Entries sharing a common
1 8
EP O 792 493 B1
keyword are not listed together in the subservice browser, but users can search
the keyword fields of entries using the Query Form.
Slogan Advertising slogan. This field is typically only used in ''yellow pages'' style Directory
5 Lookup subservices.
Des_ription The descriptive text for the entry. For Classified Advertisement subservices, this
is the text of the advertisement itself. For Reference subservices, this is the infor-
mation about the named entry. For ''yellow pages'' style Directoy Lookup subserv-
1O ices, this is the description of company products and services, hours of operation,
etc. This field is typically not used for ''white pages'' style Directory Lookup sub-
SeNICeS.
Image A graphic image to be displayed with the enty. In the Submit Form, this is a text
15 field for the user to specify a directory path to the file containing the image. ln the
View Form, this is a picture field that displays the image itself. This field is typically
used in ''yellow pages'' Directory Lookup subservices fora company logo or related
graphic, or optionally in a Reference subservice for a picture of the named item.
2O _emoval Date Date after which an entry should be automatically removed from the subseNice.
This is typically used for Classified Advertisement subservices, but it can also be
used in Directory Lookup subservices to reduce costs for the submitter. A Classi-
fied Advertisement subservice can also have a global automatic limit on the
number of days that an entry is listed (see the Options View, below).
25 Servi_e Link Used for entries that provide a hyperlink icon leading to another online service.
For example, a ''yellow pages'' enty can provide a linktoan online seNice provided
by the company listed in the enty. On the Submit Form, this is a text field for the
user to provide the URL of the other online seNice. On the View Form, this is
3O displayed as the hyperlink icon itself.
[O16O] In addition to the standard Lookup Designerform fields, the developer may include other input fields that have
specific meaning to the subservice being developed. Such fields make it easier to query the database of entries. For
example, a Classified Advertisement subservice devoted to the purchase and sale of pre-owned automobiles can
35 include form fields for the year, make, and model of the car. The end user can type specific information into those fields
on the Quey Form to find a matching enty, instead of performing a less-precise full-text search on the Description
field of the entry.
[O161] The developer should associate any required scripts with the visual objects on a form, to specify the behavior
of those visual objects. For example, on a Quey Form, the developer should provide a script for the Search button on
4O the form that specifies how to convert user input in the various fields of the form into a query against the subservice
database of entries. To invoke the Script Editor to create a script for a visual object, the developer double-clicks on
that visual object while viewing the associated form in the Hypermedia Editor.
[O162] The Categoy View of the Lookup Designer simply displays a list of the category names supported by the
subservice. The developer can add, delete, and modify the categories from the categoy view.
45 [O163] In the Options View of the Lookup Designer, the developer specifies certain options about the behavior of the
subservice. These include_.
Updatable A checkbox that indicates whether users can submit new entries to the subseNice for other users to
view. If this box is not checked (e.g., for a Reference subservice), any entries submitted by a user can
5O later be viewed by that user, but no one else.
Moderated A checkbox that indicates whether this subservice is moderated. If this box is checked, any newly
submitted entries are not directly posted to the subseNice. Instead, they are transparently transmitted
by electronic mail to the moderator for the subseNice. The moderator reviews the enty, and if it is
55 deemed appropriate, the moderator posts the entry on behalf of the original submitter. This option is
ignored if the Updatable checkbox is not checked.
Categorized A checkbox that indicates whether this subservice supports browsing by category. If this box is
19
(PICTURE)(PICTURE)
EP O 792 493 B1
checked, all entries in a common category are grouped together underthat category name for browsing
by users. If a single entry is in more than one category, it appears under each of those categories.
Typically, this box is checked for ''yellow pages'' Directory Lookup subservices and Classified Adver-
tisement subservices. Whether or not this box is checked, the user may still perform standard queries
5 against the database of entries using the Query Form for the subservice.
Sorting A drop-down list box that indicates how entries are sorted within a categoy for user browsing. Entries
may be sorted in forward or reverse order based on the contents of any of the enty fields, and sec-
ondary and tertiay sort keys are supported with additional drop-down list boxes in the tool. In addition,
1O the entry's date of posting is available as a sort key, even if that date is not displayed as part the enty
itself. Typically, a ''yellow pages'' Directory Lookup subservice will sort in forward order based on the
contents of the Name field, and a Classified Advertisement subservice will typically sort in reverse
order of posting date.
15 E_piration The number of days that each enty remains listed on the subse_ice before it is automatically removed.
This option may also be left blank, in which case there is no automatic expiration date for entries. If
an entry has an individually specified Removal Date that occurs before automatic expiration, the entry's
Removal Date is honored. Otherwise, the automatic expiration date is used.
2O [O164] The Script View and the Link View in the Lookup Designer are analogous to the Script View and the Link View
in the Online Designer tool itself and in the Hyperdocument Designer.
[O165] The Fee View of the Lookup Designer is an optional feature that invokes the Fee Setter subtool, allowing the
developer to specify the formula for computing the cost of viewing an entry (if any), and submitting an entry (if any).
The Fee Setter subtool is described in greater detail in a separate section below.
25 (PICTURE)
[O166] The Utility Subtools provide capabilities that are useful in the design of multiple types of subservices. These
subtools are accessed from the Designer Subtools, and from the Online Designer itself. The most significant and
3O original Utility Subtools are_. (1 ) the Hyperlink Editor, for manipulating hyperlinks within an online service; (2) the Script
Editor, for editing the various scripts that control the behavior of an online service; (3) the Fee Setter, which allows the
developer to specify any fees that should be charged to users or advertisers; (4) the Metering Tool, which provides
instructions to the online service server regarding the usage statistics that should be tracked; and (5) the Debugger,
which provides interactive running and debugging capabilities for an online service. This section provides the details
35 on the five Utility Subtools.
[O167] The Hyperlink Editor Subtool is a Utility Subtool that is used to display and manipulate hyperlinks within an
4O online service. The hyperlinks within an online service can be viewed and modified at various levels of abstraction. For
example the Hyperlink Editor Subtool can display and manipulate the links between different subservices within an
online service, the links between different documents within a subservice, the links within a single document, or the
individual attributes of the links themselves.
[O168] With the Hyperlink Editor, the developer can assign attributes to hyperlinks. Some important examples of
45 hyperlink attributes include_. (1 ) whether the hyperlink leads to the same documen_ile or to a different documenUfile;
(2) whether the hyperlink leads to the same online service or a different online service; (3) whether the hyperlink leads
to a service that the developer controls or doesn't; (4) the size of the document_ile a link points to; (5) whether the link
Ieads to a free service or one that has additional charges; and (6) the semantics of the hyperlink. The latter attribute
is a semantics tag taken from a known list of possibilities, which includes simple linking, making a purchase, returning
5O to the home page of the service, initiating a search, linking to a form that requests shipping address information, etc.
The semantics attribute of hyperlinks provides some additional structure to online services, and encourages a degree
of standardization in hyperlink usage.
[O169] The Hyperlink Editor supports both a Graphical View and a List View of hyperlinks. The Graphical View dis-
plays the hyperlinks as a directed graph, with the source and target of a hyperlink represented by visual icons, and
55 displays the hyperlink itself as a directed arc connecting them. An arc's particular appearance (color, width, arrow
design, and other visual cues) depends on the various attributes (above) associated with that hyperlink. The List Vew
displays a list of the hyperlinks, showing the names of the linked entities and visual cues indicating the attributes
associated with each hyperlink. The developer can modify the hyperlinks and attributes from either view.
2O
(PICTURE)
EP O 792 493 B1
[O17O] A search facility within the Hyperlink Editor allows the developer to search through the online service for
hyperlinks that satisfy a list of criteria. The search criteria are expressed as a set of attribute values associated with
the hyperlinks, which the developer types into a search query form.
5 (PICTURE)
[O171] The Script Editor is a Utility Subtool for editing the Event Scripts and Function Scripts of an online service.
The script editor is accessed from the Script Views of the various Designer Subtools and the Online Designer itself.
The developer can also invoke the Script Editor to edit the Event Scripts associated with a visual object by double-
1O clicking on the visual object itself from within the appropriate Designer Subtool.
[O172] For example, Figures 21a and 21 b illustrate screen displays for the Script Editor editing an event script for
the for the MouseDown event on the ''Purchase-Button'' of the hyperdocument illustrated in Figure 16. The Purchase
event script of Figures 21a and 21 b checks the inventory, charges the customer, and updates the inventoy if a sale
is completed.
15 [O173] Event Scripts and Function Scripts conform to the invention's Script Language, a procedural programming
Ianguage similar to the language BASIC (Beginner's All-Purpose Symbolic Instruction Code). The Online Designer
Script Language includes variable declarations, numeric and string operations, conditional statements (''if...then...
else''), control statements for looping (''for'' and ''while''), and functions (subroutines) with parameter passing. The Script
Language includes a number of programming constructs and built-in functions. The programming constructs and built-
2O in functions are collectively referred to as the Script Language ''primitives''. The primitives included in the Script Lan-
guage have been chosen and optimized for implementing common features supported by online services.
[O174] Using the Script Editor, a developer can directly type and edit an event or function script. In addition, the script
editor provides a menu-driven facility to paste script statement and function invocation archetypes into a script, which
the developer can then modify appropriately. For example, the developer can use the menus to insert a ''for'' statement
25 archetype that has placeholders for the conditional expression and statement body. Similarly, archetypes for all of the
built-in functions and programming constructs can be inserted, with placeholders for the various function arguments.
[O175] Many of the key features of the present invention are accessed primarily through the primitives of the Script
Language. In addition to normal programming language primitives for arithmetic, file input/output, etc., specific primi-
tives are included to support for online services. The following sets of script primitives exist to support online services.
3O (PICTURE)
[O176] A set of primitives are provided for transferring program control to another document, subservice, or service.
This is the dynamic form of a hyperlink. By using these primitives in a script, the developer can choose the destination
35 of a hyperlink at ''run-time,'' in response to previous input from the user, or depending on the context in which the
particular hyperdocument is displayed.
4O [O177] A set of primitives exist for performing various telecommunication tasks such as downloading files to a client
system. For example, in electronic publishing, the user can click on a button to download the electronic version of a
magazine. The Event Script associated with the ''Mouse Down'' event on that button would invoke the primitive to
download the document. As another example, a script can invoke the primitive to download software for viewing JPEG
compressed images if it does not find that external viewer already resident on the client workstation.
45 (PICTURE)
[O178] Primitives are provided to specify the various types of text search criteria_. natural language, Boolean, and
conceptual. Other primitives are provided to initiate the search, using the previously specified criteria, against specified
5O data sources. For example, to pe_orm a search based on the contents of a query form, a script should construct an
appropriate Boolean text query from the keywords typed into the user input fields on the form, and submit that query
using the Boolean criteria language primitives. Then, the script should invoke the built-in function that initiates the
search, passing an argument to that function that specifies the ID of the target database for the search.
55 (PICTURE)
[O179] Direct access to external databases and real-time data is provided using specific script primitives. The external
database primitives provide the most common and standardized constructs supported by Structured Query Language
21
(PICTURE)(PICTURE)(PICTURE)
EP O 792 493 B1
(SQL), to access relational database systems. In addition, the Script Language includes a general SQL primitive that
can accept any sequence of native SQL statements, either as an argument to the function or contained in a specified
file, and pass those SQL statements directly to the relevant database system as illustrated in Figure 22. Any results
from the database query are returned to the subservice that made the query. For non-SQL databases (and certain
5 SQL databases), there are primitives for Open Database Connectivity (ODBC).
[O18O] A set of primitives exist that allow an online service to communicate with other programs and users. For
1O example, the primitives are provided with allow a script to send an electronic mail message, a facsimile transmission,
a voice mail message (using text-to-voice techniques), or a message to an electronic wireless pager.
15 [O181] The Script Language provides various primitives for launching other application programs, sending data to
those programs, and receiving data from those programs. The names and semantics of the external program control
primitives differ according to the server platform that will run the online service.
[O182] For example, under a Microsoft Windows NT Server Version ofthe Online Designer, there are Script Language
primitives for Dynamic Data Exchange (DDE), launching another application with optional keystroke stuffing, and batch
2O invocation. _o suppo_ an online se_ice acting as a DDE client, there are primitives for standard DDE Connect, Dis-
connect, Execute, Poke, Request, Advise, and Unadvise actions. In addition, the developer may write Event Scripts
that trigger on DDE Advise events from other programs.
[O183] For launching and keystroke stuffing, the Script Language provides primitives that launch a named software
application, optionally waitforthe application tofinish or let it run concurrently, and optionally ''stuff'' specified keystrokes
25 into the launched application with suitable pauses at specified points in the keystroke stream. The batch primitives
simply launch a batch file or batch-style application with a given command line, and the Script Language file l/O prim-
itives can then be used to read and parse the output of the batch process (if any). For other server platforms (OS/2,
UNIX, etc.), other application control primitives are provided that are appropriate on those platforms. For example,
terminal emulation primitives are one mechanism provided under UNIX.
3O (PICTURE)
[O184] Script Language primitives are provided that send commands to, and receive data from, electronically con-
trolled equipment such as heating systems, ventilation systems, air-conditioning systems, security systems, and light-
35 ing.
[O185] Using the access control primitives of the Script Language, a script can request a password from the user,
4O encrypt and decrypt files to be downloaded or sent to another service, and dynamically determine whether a given
user should be given access (read only, write only, read/write, or none) to a particular document or part of a service.
These run-time language primitives augment the static access control mechanisms that the developer can specify at
design time using the invention.
45 (PICTURE)
[O186] The Script Language provides service-to-service communication primitives that allow one online service to_.
(1 ) act on behalf of the user to quey or update another online service; (2) automatically update another online service
without user initiation; (3) appear to be seamlessly part of another online service; (4) keep a record of how many times
5O users traverse to another online service; (5) pass along automatic user registration data to another online service; (6)
automatically register a new online service with a service-of-services or ''yellow pages'' service; (7) check whether
another server is running a particular online service or type of service; and (8) exchange usage and metering informa-
tion, for aggregation and later analysis. Each of these primitives opens a virtual connection to the target service, using
the service-to-service protocol.
55 (PICTURE)
[O187] User communication primitives exist that allow users to engage in real-time cooperative activity. These user
22
(PICTURE)
EP O 792 493 B1
communication Script Language primitives provide a Named Pipes style communications interface between two or
more users, or between users and a representative of the online service provider. For example, such primitives can
support a multi-person game between users, or a user entering an online query and receiving a real-time response
from a representative of the service provider. The primitives to establish a connection include the ability to specify a
5 specific user with whom to communicate, or a ''broadcast'' facility to find any current user on a given server who wishes
to establish a given class of cooperative connection.
1O [O188] Primitives are provided that_. (1 ) command the server software to accept a facsimile that is sent to the server's
fax modem from a user's fax modem or fax machine having a given identification, (2) command the server software to
accept an image transmitted by electronic mail to the server, or (3) command the client software to accept a scanned
image (using the TWAl N scanning standard) and transmit that image to the server. Once captured, other Script Lan-
guage primitives allow the image data to be incorporated into other documents. For example, a logo for a ''yellow
15 pages'' listing or a photograph for an online classified adve_isement.
[O189] The Script Editor works cooperativelv with the Debugger, to allow single-stepping through scripts, displaying
script variables, etc. In debug mode, the Script Editor allows certain limited changes to a script. More major script
changes require that the developer stops the simulation first.
2O (PICTURE)__e Fee _e__e_ _ub_oo_
(PICTURE)Fee S tter Introduction
[O19O] The Fee Setter subtool allows the developer of an online service to specify the fees that will be levied on or
25 paid to users, as users use the se_ice and access the information it contains. The Fee Setter subtool of the Online
Designer can also be used to define fees levied on or paid to information content providers. The online service frame-
work automatically levies and pays the fees according to the Fee Setter instructions, on behalf of the organization that
operates the online service.
[O191] The actual transfer of monetay funds specified by the Fee Setter can be effected on an immediate or periodic
3O basis using mechanisms external to the Fee Setter itself. For example, the Fee Setter can use credit card charges or
electronic funds transferto charge users of an online service. Similarly, the Fee Setter can use electronic funds transfer
or traditional paper-based billing and payment mechanisms to bill content providers, or other similar means. The Fee
Setter specifies the fees to be levied and the payments to make, and the external mechanisms arrange the funds
transfer to actually cover those fees and payments.
35 [O192] The Fee Setter is used for all of the various chargeable entities in an online service. As such, the Fee Setter
is accessible from the Fee Views of the Online Designer itself and from the Fee Views of each of the Designer Subtools.
For example, the Fee Setter can be accessed from the Fee View of the Hyperdocument Designer to charge fees for
documents and forfollowing hyperlinks to other subservices. Similarly, the Fee Setter can be accessed from the Lookup
Designer to charge fees to users who view/download entries and those who submit new entries.
4O [O193] Many fees are simply constant monetary amounts; e.g., a $2.OO fee to download a particular document. Other
fees are more complex. The fees can depend on the size of a document, the time of day, the load on the server, the
identity of the user, the number of previous documents downloaded or submitted by this user, etc., depending on the
information provider's policies and intentions. For classified advertisement submissions, the fee for submitting the
advertisement can include the size of any graphic image in the advertisement, the number of categories under which
45 the advertisement is listed, and the number of days that it is listed.
[O194] The Fee Computation in a Fee Specifier supports simple and complex fee structures. The formula itself is
specified using a subset of the online service Script Language. When writing the Fee Formula, the developer writes a
sequence of script statements, possibly including variable declarations, such that the appropriate fee is assigned to
the reserved global variable ''Fee@'' some point before the end of the script.
5O (PICTURE)
[O195] To illustrate some of the types of fee structures that can be created using the Fee Setter, several examples
of fees that can be defined with the Fee Setter are listed below. It should be understood that these are examples only,
55 and that many other types of fee structures can be created using the Fee Setter of the present invention_.
(PICTURE)Levying a fixed fee on users whenever certain textual or graphic information is viewed or downloaded from
23
EP O 792 493 B1
the online service.
Levying a variable fee on a user for accessing information, depending on the amount of information that par-
ticular user has accessed in the past. Thus, a quantity discount can be offered to users that frequently access a
particular online service.
5 Levying a variable fee on users for accessing information, wherein the fee charged depends on the time of
day that the information is accessed or on the current load on the online service server. Thus, the amount of the
fee would discourage access during peak periods by assigning a premium during peak hours.
Levying variable fees on users depending on the size of the information accessed, or on the amount of time
required to access, view, or download the information.
1O Levying different fees on different classes of users. For example, users that have paid for an annual member-
ship will receive a discount.
Levying a fee on users for simply connecting to a given online service. For example, an online service that
provides investment advice could charge for access.
Levying a fee on users who access certain parts of an otherwise free online service. For example, in an online
15 service provided by a free newspaper publisher, a fee could be charged for users who wish to access the full-text
search capabilities on back issues.
In a classified advertising online service, levying a variable fee on users who electronically submit new listings
to the service, depending on the size of the listing.
2O (PICTURE)
Paying a fixed fee to a user in exchange for that user filling out a market survey questionnaire.
Paying a fixed monetary prize to a user as winnings from a contest run by the online service operator.
Paying a variable fee to a user as proceeds from (legal) gambling conducted on the online service. Thus,
users could engage in gambling from home.
25 (PICTURE)
Levying a fixed fee on a content provider whenever a user views or downloads that provider's textual or graphic
information from the online service. For example, when a user views or downloads a content provider's advertising
brochure or investment prospectus, a small fee would be levied on the content provider.
3O Levying a variable fee on a content provider when a user accesses the provider's information, depending on
the amount of information that all users have accessed from that provider in the past. Thus, an advertising quantity
discount to the content provider.
Levying variable fees on content providers depending on the amount or size of information carried on the
online service, and on how many days that information is carried on the service.
35 Levying different fees on different classes of content providers. For example, an online service provider could
give a discount to non-profit organizations that advertise on the online service.
Levying a fee on another online service provider whenever a user clicks on a hyperlink from the current online
service that leads to the content provider's own online service. This would in effect be a referral fee.
In a ''yellow pages'' style online service, levying a variable fee on a content provider depending on the number
4O of categories under which the provider's listing (and advertisement) is carried. Thus the easier it is to find the
content provider's advertisement, the more the online service provider would charge.
(PICTURE)Paying a fixed fee to a content provider whenever a user views or downloads a particular document or program
45 posted by that content provider. Thus content providers can supply informative repo_s, software programs, images,
sounds, etc. that would be available to users of the online service. When a user requests the content provider's
material, the users would be a charged for the material and the fees charged to the user would be divided between
the content provider and the online service operator.
Paying a variable fee to a content provider depending on the size of the provider's textual or graphic information
5O that is downloaded by all users.
Paying a variable fee to a content provider when users perform full-text searches across the provider's data-
base of documents. The fee paid tothe content provider depends on how much time was spent performing searches
(even if no documents were ultimately viewed or downloaded).
Paying a variable fee to a content provider of (say) stock photo images when an end-user downloads an
55 image, where the fee depends on the total number of images downloaded by all end-users in the past_, in effect,
a quantity discount to the online service operator on paying for content.
24
(PICTURE)
EP O 792 493 B1
[O196] The Fee Setter allows the developer to use the mouse, toolbar, and menus to create, modify, and delete
individual Fee Specifiers. A Fee Specifier is a tuple that consists of four different parts_. (1 ) An action that triggers the
5 fee. This can be a traverse of a hyperlink, the downloading of a document, the uploading of an advertisement, etc.; (2)
The argument values (if any) that are required by the specified action; (3) The entity to whom the fee should be charged
or to whom the payment should be made. This can be a user of the online system or a content provider; (4) A Fee
Computation that specifies exactly how a fee or payment is computed.
[O197] The Fee Setter displays the Fee Specifiers in a list For example, Figure 23 illustrates a list of Fee Specifiers
1O that can be used to assign fees in one particular online service. Each Fee Specifier describes one particular type of
fee for using the online service. The Fee Computation is not displayed directly in the Fee Setter list. Instead, in each
Fee Specifier, an on-screen button is displayed that can be clicked by the developer to access the Script Editor to view
and edit that Fee Computation. Figure 24 illustrates a Computation Script Editor view of a Fee Specifier.
[O198] The detailed descriptions of each element in the Fee Specifier tuple are given below_.
15 Action_. This is the type of action that triggers the fee to be charged or the payment to be made. The allowable
Action values are_.
Access The action of a user accessing (viewing, downloading, ''running'') an object. The supported
2O objects are_. document, image, video clip, sound clip, and script.
Submit The action of a user submitting (uploading) an object. The supported objects are_. document,
image, video clip, and sound clip.
25 Traverse The action of a user clicking on (traversing) a hyperlink in a particular document.
Connect The action of connecting to the online service.
Daily Indicates that the fee or payment is recomputed and reassessed once each day.
3O Weekly Indicates that the fee or payment is recomputed and reassessed once each week.
Monthly Indicates that the fee or payment is recomputed and reassessed once each month.
35 Annually Indicates that the fee or payment is recomputed and reassessed once each year.
Argument_. This is the argument value (if any) required by the action element of the Fee Specifier. The Argument
values required by each of the various types of Action are as follows_.
4O Access The file system path of the affected object. For example, ''/pub/www/clothing/order.html.''
Submit The file system path of the document form that was used to submit the object. For example,
''/pub/www/classifieds/newlisting.html.''
45 Traverse The hyperlink being traversed. lt is specified as the path of the document containing the hy-
perlink, followed by three slashes (''///''), followed by the URL of the hyperlink itself as con-
t,,ained in that document. For example, ''/pub/www/yellow/acme.html///http_.//www.ac me.com.
5O Connect Requires no argument. The argument field should be left blank.
Daily Requires no argument. The argument field should be left blank.
Weekly Requires no argument. The argument field should be left blank.
55 Monthly Requires no argument. The argument field should be left blank.
Annually Requires no argument. The argument field should be left blank.
25
EP O 792 493 B1
Entity_. This is the entity to whom a fee should be levied or paid from the online service operator. The allowable
Entity values are_.
Provider The fee should be levied or a payment should be made to the content provider.
5 User The fee should be levied or a payment should be made to the user.
[O199] Note that if the action element of the Fee Specifier is ''Daily'' the entity element is ''Provider'', the Fee Specifier
is recomputed and reassessed for evey content provider in the online service each day. Similarly, if the action is ''Daily''
1O and the entity is ''User'', then the Fee Specifier is recomputed for evey user of the online service each day. The same
principle holds for fees that have the action triggers of ''Weekly'', ''Monthly'', and ''Annually.''
Fee Computation. This is a script, written in the Computation Language, that specifies how the fee to be levied
or paid is to be computed. Details of the Fee Computation are provided in a separate section below.
15 (PICTURE)(PICTURE)
[O2OO] To best illustrate the use of Fee Specifiers, two examples of Fee Specifiers are listed below _.
Example Fee Specifier #1
2O [O2O1] <
25 _
CCe5S,
(pub )_________ / reSearch_' írop-forecast-91.htm__
User,
Fee_ _ 5.OO
3O >
[O2O2] This first Fee Specifier indicates that afee should be charged whenever a user accesses (views or downloads)
the document identified by the path ''/pub/www/research/crop-forecast-94.html,'' since the action is ''Access'' and the
35 argument is the ''/pub/www/research/crop-forecast-94.html'' path name. When a users performs such an access, the
online service should levy a fee of $5.OO on the user.
Example Fee Specifier #2
4o [o2o3] < Daily,
45 ,
Provider,
Fee_ = O.O
Fo_ iOXo _ _ _o _roviderFjle_ou__OX _provjde_ox _
- O( OJ
5o Fee_ = Fee_ + (_E-6 ' File_e_(__ovide_Fjle_a___(__ovide_oX,, ioxo)))
_ex_ iOXo
>
[O2O4] This second example Fee Specifier indicates that each day, a particularfee should be charged to each content
55 provider. The daily fee is calculated by charging $O.OOOOO1 for each byte of file data that is owned by that content
provider on the online service. Stated more simply, each content provider is charged approximately $1 .OO for each
megabyte of data stored on the online service per day. Note again that the list of Fee Specifiers shown in the Fee
Setter do not actually contain the entire Fee Computation above. Instead, an on-screen button in the Fee Specifier
26
(PICTURE)(PICTURE)
EP O 792 493 B1
tuple can be clicked to launch the Script Editor, allowing the developer to view and modify the Fee Computation.
[O2O5] The online service framework automatically executes the appropriate Fee Specifiers whenever their associ-
ated actions occur. Thus, when the user accesses a document, the ''Access'' Fee Specifiers (if any) whose argument
element is the path tothat document will be executed, resulting in a fee being levied or paid for each such Fee Specifier.
5 Once a day the ''Daily'' Fee Specifiers are executed, and so on.
[O2O6] Note that, in many cases, a Fee Specifier that levies a fee on a user for accessing information will be accom-
panied by another Fee Specifier that pays part of that fee back to the content provider. Conversely, a Fee Specifier
that pays a fee to the user (e.g., for filling out a market survey questionnaire) will often be accompanied by a Fee
Specifier that levies a comparable fee on the content provider.
1O (PICTURE)
[O2O7] The Fee Computation in a Fee Specifier supports simple and complex fee structures. Each Fee Computation
is expressed using the Computation Language, which is a subset of the online system development tool's full Script
15 Language. When specifying the Fee Computation, the developer writes a sequence of script statements such that
when the script is executed by the server, the appropriate fee is assigned to the predefined global variable ''Fee@'' at
some point before the end of the script. If the final value of Fee@ is positive, then a fee is levied on the entity by the
online service operator; if it is negative, the fee is paid to the entity by the service operator.
2O (PICTURE)
[O2O8] The Computation Language is a subset of the invention's Script Language, which is itself similar to the com-
puter programming language BASIC (Beginner's All-purpose Symbolic Instruction Code). A very brief overview of the
Computation Language is provided below. The reader is referred to any comprehensive reference on the BASIC pro-
25 gramming language for a description of the detailed semantics of these programming constructs.
3O
35 [o2og] ln the Computation Language of the present invention, explicit variable declarations are not used or required.
Instead, the suffix character used on a variable name determines the data type of the variable_.
4O
45 [O21 O] The Currency data type (variables with the @ suffix) supports up to 4 digits to the right of the decimal point.
It maintains exact decimal accuracy, making it especially suitable for monetary calculations. In the Date_ime data
type, the base unit is days such that adding or subtracting an integer adds or subtracts days; adding or subtracting a
fraction adds or subtracts time as a fraction of a day For example, adding 1 O adds 1 O days, while subtracting 1/24
5O subtracts one hour. '
(PICTURE)Predefi ed GIobaI VariabIes
[O211] There are 5 predefined global variables available to a script that comprises a Fee Computation The 5 pre-
55 def.ined global var.iables are def.ined below.. '
Fee@ When the Computation Language script that defines the Fee Computation is complete, the final value of
27
EP O 792 493 B1
the Fee @ predefined global variable is the fee that is levied on the entity (if the value is positive) or paid
to the entity (if the value is negative).
Arg$ The value of the argument element of the Fee Specifier. The Arg$ is provided as a notational convenience.
5 PrOViderOX_ The prOVider identifier nUmber Of the COntent prOVider aSSOCiated With the aCtiOn that triggered the Fee
Specifier. This predefined global variable is available when the entity element of the Fee Specifier is
''PrOVider''. If the aCtiOn iS ''ACCeSS'', the VaIUe Of PrOViderOX_ iS the identifier nUmber Of the COntent prOVider
that owns the information that was accessed. If the action is ''Daily'', ''Weekly'', ''Monthly'', or ''Annually''
1O (and the Fee Specifier is ''Provider''), the Fee Specifier is evaluated once for each content provider of
the Online SeNiCe. In thiS CaSe, the PrOViderOX_ VaIUe iS the prOVider identifier nUmber Of the CUrrent COntent
provider being referenced in this iteration of the Fee Specifier computation.
USerOX_ The USer identifier nUmber Of the USer aSSOCiated With the aCtiOn that triggered the Fee SpeCifier. ThiS
15 predefined global variable is available when the entity element of the Fee Specifier is ''User''. lf the action
iS ''ACCeSS'' Or ''SUbmit'', the VaIUe Of USerOX_ iS the l D nUmber Of the USer that aCCeSSed Or SUbmitted the
information. If the action is ''Daily'', ''Weekly'', ''Monthly'', or ''Annually'' (and the Fee Specifier is ''User''),
the Fee SpeCifier iS eVaIUated OnCe fOr eaCh USer Of the Online SeNiCe. In thiS CaSe, the USerOX_ VaIUe iS
the user identifier number of the current user being referenced in this iteration of the Fee Specifier com-
2O putation.
AccessTime#The amount of elapsed time that was required to access the current object. This predefined global variable
is valid only in ''Access'' or ''Submit'' Fee Specifiers.
25 (PICTURE)Available Built-ln Functions
[O21 2] All of the primitives of the Script Language are available in the Computation Language. These primitives
include built-in functions for general computing purposes (e.g. , ''Now()'' to obtain the current date/time, ''FileLen()
'' to determine the length of a file, etc.), as well as built-in functions that are specific to online services. The online
3O service primitives that are of particular interest for creating Fee Computations are detailed below_.
PrOViderFileCOUntOX_()
Returns the total number of files, carried on the online seNice, belonging to the content provider whose provider
identifier is .
35 ProviderFilePath$(, )
Returns the path of the file at index in the list of files associated with the content provider whose
prOVider identifier iS . The allOWable range Of iS 1 thrOUgh PrOViderFileCOUntOX_
(), inclusive.
4O PrOViderT_taIACCeSSCOUntOX_()
Returns the total number of files, belonging to the content provider whose provider identifier is ,
that haVe eVer been aCCeSSed by any USerS On thiS Online SerViCe. The PrOViderT_taIACCeSSCOUntOX_ fUnCtiOn iS
useful for computing quantity discounts.
45 PrOViderT_taIACCeSSSiZeOX_()
Returns the total size of the files, belonging to the content provider whose provider identifier is ,
that haVe eVer been aCCeSSed by any USerS On thiS Online SerViCe. The PrOViderT_taIACCeSSSiZeOX_ fUnCtiOn iS
useful for computing quantity discounts.
5O PrOViderT_taICOntentCOUntOX_()
Returns the total number of files on this online service belonging to the content provider whose provider iden-
tifier is .
55 ProviderTotaIContentSizeOXo()
Returns the total size of all files on this online seNice belonging to the content provider whose provider identifier
is . 28
(PICTURE)
EP O 792 493 B1
ProviderAttrSet(, , )
Associates, with the content whose provider identifier is , an attributed name
having value . If that attribute already exists for that provider, replaces the value of the attribute with this
new value. One example of using attributes on content providers might be to record in a ''Non-profit'' attribute the
5 value ''Yes'' or ''No,'' depending on whether the provider is a non-profit organization.
ProviderAttrGet$(, )
Gets the value of the attribute named for the content provider whose provider identifier is
. The value is returned as a string, but can be converted to any other appropriate type using the
1O data type conversion functions provided by the Computation Language and the Script Language. Text to data
conversion functions are well known in the art and are not discussed in this document.
USerT_taIACCeSSCOUntOX_()
Returnsthetotal numberoffiles that have ever been accessed bythe userwhose user identifier is .
15 The UserTotalAccessCountFunctionOXo is useful for computing quantity discounts.
USerT_taIACCeSSSiZeOX_()
Returnsthe total size ofthe files that have ever been accessed bythe userwhose user identifier is .
The UserTotaIAccessSizeFunction is useful for computing quantity discounts.
2O UserAttrSet(, , )
Associates, with the user whose user identifier is , an attribute name having value
. If that attribute already exists for that user, replaces the value of the attribute with this new value. One
example of using attributes on users might beto use an ''Age'' attribute to recordthe age ofthe user. This information
25 might be used to offer senior citizen discounts on downloading fees, for example.
UserAttrGet$(, )
Gets the value of the attribute named for the user whose user identifier is . The
value is returned as a string, but can be converted to any other appropriate type using the data type conversion
3O functions provided by the Computation Language and the Script Language.
UserSearchTime#(, )
Returns the total amount of time that the user whose user identifier is has been searching the
content databases of the content provider whose provider identifier is , in this session.
35 EntryCategOryCOUntOX_()
In a ''yellow pages'' or classified advertisement style service, returns the total number of categories under
which the entry, whose file path name is , has been listed. Entries that are listed under many categories
can be charged a higher fee than entries that are listed in only a few categories.
4O ServerLoad!()
Returns the current load on the server as a value between O.OO and 1 .OO, with O.OO meaning no server load
and 1 .OO meaning that the server is fully loaded. The ServerLoad function can be used to set fees depending on
the current load on the server. To discourage access during peak usage periods, higher prices can be assigned
45 during peak usage times.
[O213] A wide variety of metering capabilities are provided by the Molisa online service platform. The metering ca-
5O pabilities track the usage patterns of an online service, and the usage by users and other services. The metering
information can provide invaluable feedback on the volume and duration of access to documents, subservices, and
the online service as a whole. Furthermore, the metering information is available from the Fee Computation language
using defined functions such that fees can be based on user usage.
[O214] It would be an unnecessay performance burden for the server to gather all possible statistics on all possible
55 online service entities. With the Metering Tool, the developer indicates specifically which statistics should be gathered,
and on which parts of the online service. The online service server tracks service usage in the ways specified in the
metering subtool. (The server also gathers the specific usage data required by the fees indicated in the Fee Setter
subtool.) 29
(PICTURE)(PICTURE)
EP O 792 493 B1
[O215] The Metering subtool allows the developer to manipulate a list of Metering Specifiers. Each Metering Specifier
is a pair consisting of_. (1 ) an online service entity (document, hyperlink, subservice, service, etc.), and (2) the particular
property of that entity that should be metered. The properties that can be metered include_. number of users who access
the entity, number of minutes that they use the entity, total number of times that the entity was accessed, number of
5 times the entity was viewed vs. downloaded, number of times the entity was requested by another service, times of
day that entity is accessed, etc.
[O216] After gathering metering information, the online service provider can view the metering information in graph,
chart, and numeric form, using separately provided analysis software. The metering information can be used to tune
the performance of a server. For example, a developer can expand certain service areas that receive heavy use.
1O Similarly, a developer can discard portions of an online service that are infrequently used, cost-justify a more powerful
server to run the service, assess how often a user is ''referred'' to this service from another service, etc.
15 [O217] To facilitate the development of an online service, a Debugger subtool exists. The Debugger subtool provides
a means for the developer to ''run'' an online service that is being developed. The Debugger subtool simulates an
access to an online service from user client software such that a developer can test an online service by accessing
the online service in the same manner that a user would,
[O218] The Debugger subtool, can be stopped at any point. When the Debugger is stopped, the developer can use
2O an appropriate Utility Subtool to modify the currently displayed hyperdocument or subservice infrastructure (or any
other part of the service). After modifying the subservice, the developer can resume the simulation of the online service
from the stopping place. The Debugger also allows the developer to single-step through scripts, inspect and change
script variables, and even modify the scripts themselves, like conventional debuggers for interpreted languages in
other application domains.
25 Claims
1 . A system for specifying fees for an entity associated with an online service, comprising_.
3O (a) means associated with an object of the online service for defining at least one of a plurality of triggering
actions for a fee_,
(b) means associated with a triggering action for defining a fee specification for the entity;
(c) means for editing a plurality of fee specifications for the entity; and
35 (d) means for storing the plurality of fee specifications using the editing means, characterised in that the editing
means comprises_.
(e) means fordisplaying avisual representation of the fee specification having user-modifiable portions, where-
in a user-modifiable portion is provided for entry of an indication of an object of the online service, an indication
of a triggering action in connection with the object, and a fee specification; and
4O (f) means for receiving user input to edit the fee specification using the visual representation and for storing
edited fee specifications.
2. A system for determining a fee for an entity associated with an online service according to Claim 1 , further char-
acterised by comprising_.
45 (a) means for detecting at least one of a plurality of actions on an object of the online service, said object being
associated with an action_,
(b) means, operative in response to detection of the action, for identifying a fee specification for the action and
the object associated with the action; and
5O (c) means for utilizing the fee specification to define the fee for the entity.
3. The system of Claim 1 or Claim 2, characterised in that the visual representation is a template.
4. The System of Claim 1 or Claim 2 or Claim 3, characterised in that the fee formula is defined using a scripting
55 language.
5. The system of any preceding claim, characterised in that the plurality of fee specifications are stored in a list.
3O
EP O 792 493 B1
6. A system for developing an online service with a computer, comprising the elements of_.
(a) a first editor for enabling a user to edit a data store that contains information comprising the online service;
(b) a second editor for enabling the user to define an interactive behaviour of said online service, said second
5 editor having a visual user interface for editing_.
(i) a format in which said information from said data store of said online service is displayed;
(ii) a set of functional features provided by said online service; and
(iii) a set of visual objects for accessing said functional features, said set of visual objects being accessed
1O by the user of the online service; and
(c) a system for specifying fees according to any one of claims 1 to 5.
7. The system of any preceding claim, characterised in that each of said fees are triggered by passage of a defined
15 amount of time.
8. The system of any preceding claim further characterised by being adapted to define a fee specification for each
fee, said fee specification comprising a first field specifying a fee action that triggers said fee.
2O 9. The system of Claim 8, characterised in that said fee specification fu_her comprises a second field specifying an
entity to whom the fee is directed.
1 O. The system of Claim 8 or Claim 9, characterised in that said fee specification further comprises a third field spec-
ifying an object associated with said triggering action.
25 11 . The system of Claim 8, 9, or 1 O, wherein said fee specification further comprises a fourth field defining a fee
computation.
12. The system of Claim 1 1 , characterised in that said fourth field comprises a script specifying said fee computation.
3O 13. The system of Claim 1 2, characterised in that said script comprises at least one fee setting script primitive.
14. The system of Claim 7, characterised in that said online service comprises a plurality of subservice programs.
35 15. The system of any preceding claim, characterised in that each of said fees are triggered by a defined user action.
16. The system of Claim 1 5, characterised in that one of said defined user actions comprises access by said user to
one of said visual objects on the online service.
4O 17. The system of Claim 1 5 or claim 1 6, characterised in that one of said defined user actions comprises submittal of
an object for inclusion in said data store of said online service.
18. The system of claim 1 5, 1 6, or 1 7, characterised in that one of said defined user actions comprises a traverse of
a hyperlink.
45 19. The system of any one of claims 1 5 to 1 8, characterised in that one of said defined user actions comprises a
connection to an online service.
2O. The system of any preceding claim, characterised in that a document object includes a Hyper Text Markup Lan-
5O guage (HTML) document.
21 . A system for developing an online service with a computer, comprising_.
(a) a first editing module for displaying and enabling editing of relationships among document objects of the
55 online service_,
(b) a second editing module for enabling editing of individual document objects of the online service;
(c) a mechanism for invoking the second editing module in response to selection of a document object in the
first editing module; 31
EP O 792 493 B1
(d) a system for specifying fees according to any one of claims 1 to 5; and
(e) means for storing a plurality of fee specifications using at least one of said first editing module and said
second editing module.
5 22. A system for developing an online service with a computer, comprising_.
(a) a viewing module for displaying relationships among and enabling selection of document objects of the
online service_,
(b) an editing module for editing individual document objects of the online service;
1O (c) a linking mechanism for invoking the editing module in response to selection of a document object in the
viewing module; and
(d) a system for specifying fees according to Claim 1 .
23. The system of any preceding claim, characterised in that if said fee is positive, a fee is charged to said entity, and
15 if said fee is negative, a payment is made to said entity.
24. The system of Claim 1 3 or Claim 1 4, further characterised by comprising_.
a script editor for editing the script specifying said fee computation.
2O 25. The system of any preceding claim, characterised in that said online service distributes information using a Hyper
Text Transport Protocol (HTTP), said information comprising a hypermedia document.
26. The system of Claim 25, characterised in that said online service distributes information on the global Internet.
25 27. The system of Claim 26, characterised in that said hypermedia document comprises a Hyper Text Markup Lan-
guage (HTML) document.
28. The system of Claim 27, characterised in that the relationships among the document objects are hyperlinks between
3O the document objects.
Patentansprü_he
35 1 . System zum Spezifizieren von Gebühren für einen Betrieb, der mit einem Online-Service verbunden ist, umfas-
send_.
(a) eine Einrichtung, die mit einem Objekt des Online-Service verbunden ist, um mindestens eine von mehreren
Auslöseaktionen für eine Gebühr zu definieren_,
4O (b) eine Einrichtung, die mit einer Auslöseaktion verknüpft ist, um eine Gebührenspezifikation für den Betrieb
zu definieren_,
(c) eine Einrichtung zum Editieren einer Mehrzahl von Gebührenspezifikationen für den Betrieb; und
45 (d) eine Einrichtung zum Speichern der Mehrzahl von Gebührenspezifikationen unter Verwendung der Edi-
tiereinrichtung, dadur_h gekennzei_hnet, daß die Editiereinrichtung umfaßt_.
(e) eine Einrichtung zum Anzeigen einer visuellen Darstellung der Gebührenspezifikation, die durch den Be-
5O nutzer modifizierbare Abschnitte enthält, wobei ein durch den Benutzer modifizierbarer Abschnitt vorgesehen
ist für den Eintrag einer Angabe eines Objekts des Online-Service, einer Angabe einer Auslöseaktion im Zu-
sammenhang mit dem Objekt, und einer Gebührenspezifikation; und
(f) eine Einrichtung zum Empfangen von Benutzereingabe zum Editieren der Gebührenspezifikation unter
55 Verwendung der visuellen Darstellung und zum Speichern editie_er Gebührenspezifikationen.
2. System zum Bestimmen einer Gebührfür einen Betrieb, der mit einem Online-Service verbünden ist, entsprechend
Anspruch 1 , weiterhin gekennzei_hnet dur_h. 32
EP O 792 493 B1
(a) eine Einrichtung zum Ermitteln mindestens einer aus einer Mehrzahl von AMionen bezüglich eines Objekts
des Online-Service, welches Objekt zu einer Aktion gehört;
(b) eine ansprechend auf das Ermitteln der Aktion wirksame Einrichtung zum Identifizieren einer Gebühren-
5 spezifikation für die Aktion und das zu der Aktion gehörige Objekt; und
(c) eine Einrichtung zum Verwenden der Gebühreuspezifikation, um die Gebühr für den Betrieb zu definieren.
3. System nach Anspruch 1 und Anspruch 2, dadur_h gekennzei_hnet, daß die visuelle Darstellung eine Schablone
1O ist.
4. System nach Anspruch 1 , 2 oder 3, dadur_h gekennzei_hnet, daß die Gebührenformel unter Verwendung einer
Schriftsprache definiert ist.
15 5. System nach einem vorhergehenden Anspruch, dadur_h gekennzei_hnet, daß die Mehrzahl von Gebührenspe-
zifikationen in einer Liste gespeichert ist.
6. System zum Entwickeln eines Online-Service mit einem Rechner, umfassend folgende Elemente_.
2O (a) einen ersten Editor, um einen Benutzer in die Lage zu versetzen, einen Datenspeicher zu editieren, der
Information über den Online-Service enthält_,
(b) einen zweiten Editor, der den Benutzer in die Lage versetzt, ein interaktives Verhalten des Online-Service
zu definieren, wobei der zweite Editor eine visuelle Benutzerschnittstelle aufweist, um zu editieren_.
25 (i) ein Format, in welchem die Information von dem Datenspeicher des Online-Service dargestellt wird;
(ii) eine Menge funktioneller Merkmale, die von dem Online-Service geliefert werden; und (iii) eine Menge
visueller Objekte für den Zugriff auf die funktionellen Merkmale, wobei auf die Menge visueller Objekte
durch den Benutzer des Online-Service zugegriffen wird; und
3O (c) ein System zum Spezifizieren von Gebühren nach einem der Ansprüche 1 bis 5.
7. System nach einem vorhergehenden Anspruch, dadur_h gekennzei_hnet, daß jede der Gebühren durch Ver-
streichen einer definierten Zeitdauer ausgelöst wird.
35 8. System nach einem vorhergehenden Anspruch, dadur_h gekennzei_hnet, daß es dazu ausgebildet ist, eine
Gebührenspezifikation für jede Gebühr zu definieren, wobei die Gebührenspezifikation ein erstes Feld zum Spe-
zifizieren einer Gebührenaktion aufweist, welche die gebühr veranlaßt.
4O 9. System nach Anspruch 8, dadur_h gekennzei_hnet, daß die Gebührenspezifikation weiterhin ein zweites Feld
aufweist, welches einen Betrieb spezifiziert, zu dem die Gebühr gelenkt wird.
1 O. System nach Anspruch 8 oder 9, dadur_h gekennzei_hnet, daß die Gebührenspezifikation außerdem ein drittes
Feld aufweist, welches ein Objekt spezifiziert, welches zu der auslösenden Aktion gehört.
45 1 1 . System nach Anspruch 8, 9 oder 1 O, bei dem die Gebührenspezifikation außerdem ein viertes Feld aufweist,
welches eine Gebührenberechnung definiert.
1 2. System nach Anspruch 1 1 , dadur_h gekennzei_hnet, daß das vierte Feld eine Schrift aufweist, die die Gebüh-
5O renberechnung spezifiziert.
1 3. System nach Anspruch 1 2, dadur_h gekennzei_hnet, daß die Schrift mindestens ein Gebühreneinstell-Schrift-
primitivelement aufweist.
55 1 4. System nach Anspruch _, dadur_h gekennzei_hnet, daß der Online-Service eine Mehrzahl von Subservicepro-
grammen aufweist.
1 5. System nach einem vorhergehenden Anspruch, dadur_h gekennzei_hnet, daß jede der Gebühren durch eine
33
EP O 792 493 B1
definierte Benutzeraktion ausgelöst wird.
1 6. System nach Anspruch 1 5, dadur_h gekennzei_hnet, daß eine der definierten Benutzeraktionen den Zugriff des
Benutzers auf eines der visuellen Objekte des Online-Service aufweist.
5 1 7. System nach Anspruch 1 5 oder 1 6, dadur_h gekennzei_hnet, daß eine der definierten Benutzeraktionen die
Vorlage eines Objekts für die Einbeziehung in den Datenspeicher des Online-Service umfaßt.
1 8. System nach Anspruch 1 5, 1 6 oder 1 7, dadur_h gekennzei_hnet, daß eine der definierten Benutzeraktionen
1O einen Hyperlink-Durchgang aufweist.
1 9. System nach einem der Ansprüche 1 5 bis 1 8, dadur_h gekennzei_hnet, daß eine der definierten Benutzeraktio-
nen eine Verbindung mit einem Online-Service aufweist.
15 2O. System nach einem vorhergehenden Anspruch, dadur_h gekennzei_hnet, daß ein Dokument-Objekt ein Hyper-
Text-Markup-Language-(HTML-)Dokument enthält.
21 . System zum Entwickeln eines Online-Service mit einem Rechner, umfassend_.
2O (a) ein erstes Editiermodul zum Anzeigen und Freigeben des Editierens von Beziehungen unter Dokument-
objekten des Online-Service;
(b) ein zweites Editiermodul zum Freigeben des Editierens individueller Dokumentobjekte des Online-Service;
25 (c) einen Mechanismus zum Anrufen des zweiten Editiermoduls ansprechend auf die Auswahl eines Doku-
mentobjekts in dem ersten Editiermodul;
(d) ein System zum Spezifizieren von Gebühren nach einem der Ansprüche 1 bis 5; und
3O (e) eine Einrichtung zum Speichern mehrerer Gebührenspezifikationen unter Verwendung mindestens eines
von dem ersten Editiermodul und dem zweiten Editiermodul.
22. System zum Entwickeln eines Online-Service mit einem Rechner, umfassend_.
35 (a) ein Ansichtsmodul zum Anzeigen von Beziehungen unter und zum Freigeben der Auswahl von Dokument-
objekten des Online-Service;
(b) ein Editiermodul zum Editieren individueller Dokumentobjekte des Online-Service;
4O (c) einen Verknüpfungsmechanismus zum Anrufen des Editiermoduls ansprechend auf die Auswahl eines
Dokumentobjekts in dem Ansichtsmodul; und
(d) ein System zum Spezifizieren von Gebühren nach Anspruch 1 .
45 23. System nach einem vorhergehenden Anspruch, dadur_h gekennzei_hnet, daß, wenn die Gebühr positiv ist, der
Betrieb mit einer Gebühr belastet wird, und falls die Gebühr negativ ist, an den Betrieb eine Zahlung erfolgt.
24. System nach Anspruch 1 3 oder Anspruch 1 4, gekennzei_hnet dur_h. einen Schrifteditor zum Editieren der die
Gebührenberechnung spezifizierenden Schrift.
5O 25. System nach einem vorhergehenden Anspruch, dadur_h gekennzei_hnet, daß der Online-Service Information
unter Verwendung eines Hyper-Text-Transportprotokolls (HTTP) verbreitet, wobei die Information ein Hypermedia-
Dokument aufweist.
55 26. System nach Anspruch 25, dadur_h gekennzei_hnet, daß der Online-Service lnformation über das globale ln-
ternet verbreitet.
27. System nach Anspruch 26, dadur_h gekennzei_hnet, daß das Hypermedia-Dokument ein Hyper-Text-Markup-
34
EP O 792 493 B1
Language-(HTML-)Dokument aufweist.
28. System nach Anspruch 27, dadur_h gekennzei_hnet, daß die Relationen unter den Dokumentobjekten Hyper-
links zwischen den Dokumentobjekten sind.
5 Revendi_ations
1 . Système pour spécifier des taxes pour une entité associée à un service en ligne, comprenant _.
1O (a) des moyens associés à un objet du service en ligne pour définir au moins une pluralité d'actions de dé-
clenchement pour une taxe ;
(b) des moyens associés à une action de déclenchement pour définir une spécification de taxe pour l'entité ;
(c) des moyens pour éditer une pluralité de spécifications de taxes pour l'entité ; et
15 (d) des moyens pour mémoriser la pluralité de spécifications de taxes en utilisant les moyens d'édition ; ca-
ractérisé en ce que les moyens d'édition comprennent _.
(e) des moyens pour afficher une représentation visuelle de la spécification de taxes en utilisant des parties
modifiables par l'utilisateur, une partie modifiable par l'utilisateur étant prévue pour l'introduction d'une indica-
tion d'un objet du service en ligne, une indication d'une action de déclenchement en liaison avec l'objet et une
2O spécification de taxes _, et
(f) des moyens pour recevoir une entrée d'utilisateur pour éditer la spécification de taxes en utilisant la repré-
sentation visuelle et pour mémoriser des spécifications de taxes éditées.
2. Système pourdéterminer une taxe pour une entité associée au service en ligne selon la revendication 1 , caractérisé
25 en ce qu'il comprend _.
(a) des moyens pour détecter au moins une pluralité d'actions sur un objet du service en ligne, ledit objet étant
associé à une action _,
(b) des moyens pouvant agir en réponse à la détection de l'action, pour identifier une spécification de taxe
3O pour l'action et l'objet associé à l'action ; et
(c) des moyens pour utiliser la spécification de taxe pour définir la taxe pour l'entité.
3. Système selon la revendication 1 ou la revendication 2, caractérisé en ce que la représentation visuelle est un
gabarit.
35 4. Système selon la revendication 1 ou la revendication 2 ou la revendication 3, caractérisé en ce que la formule de
taxe est définie en utilisant un langage de script.
5. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que la pluralité de spécifica-
4O tions de taxes sont mémorisées dans une liste.
6. Système pour développer un service en ligne avec un ordinateur, comportant _.
(a) un premier éditeur pour permettre à un utilisateur d'éditer une mémoire de données qui contient des infor-
45 mations concernant le service en ligne _,
(b) un second éditeur pour permettre à l'utilisateur de définir un comportement interactif dudit service en ligne,
Iedit second éditeur possédant une interface d'utilisateur visuelle d'utilisateur pour l'édition ;
(i) un format, dans lequel lesdites informations provenant de ladite mémoire de données et dudit service
5O en ligne sont affichées _,
(ii) un ensemble de caractéristiques fonctionnelles fournies par ledit service en ligne ; et
(iii) un ensemble d'objets visuels pour accéder auxdites caractéristiques fonctionnelles, l'utilisateur du
service en ligne accédant audit ensemble d'objets visuels ; et
55 (c) un système pour spécifier des taxes selon l'une quelconque des revendications 1 à 5.
7. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que chacune desdites taxes
sont déclenchées par un écoulement d'un intervalle de temps défini.
35
EP O 792 493 B1
8. Système selon l'une quelconque des revendications précédentes, caractérisé en outre en ce qu'il est adapté pour
définir une spécification de taxe pour chaque taxe, ladite spécification de taxe comprenant une première zone
spécifiant une action avec taxe qui déclenche ladite taxe.
5 9. Système selon la revendication 8, caractérisé en ce que ladite spécification de taxe comporte en outre une seconde
zone spécifiant une entité, que concerne la taxe.
1 O. Système selon la revendication 8 ou la revendication 9, caractérisé en ce que ladite spécification de taxe comprend
en outre une troisième zone spécifiant un objet associé à ladite action de déclenchement.
1O 1 1 . Système selon la revendication 8, 9 ou 1 O, selon lequel ladite spécification de taxe comporte en outre une quatrième
zone définissant un calcul de taxe.
1 2. Système selon la revendication 1 1 , caractérisé en ce que ladite quatrième zone comprend un script spécifiant ledit
15 calcul de taxe.
1 3. Système selon la revendication 1 2, caractérisé en ce que ledit script comprend au moins une primitive de script
de détermination de taxe.
2O 1 4. Système selon la revendication 7, caractérisé en ce que ledit service en ligne comprend une pluralité de program-
mes de services secondaires.
1 5. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que chacune desdites taxes
est déclenchée par une action définie de l'utilisateur.
25 1 6. Système selon la revendication 1 5, caractérisé en ce que l'une desdites actions définies d'utilisateur comprend
un accès, par ledit utilisateur, à l'un desdits objets visuels du service en ligne.
1 7. Système selon la revendication 1 5 ou la revendication 1 6, caractérisé en ce que l'une desdites actions définies
3O d'utilisateur comprend la soumission d'un objet pour son inclusion dans ladite mémoire de données dudit service
en ligne.
1 8. Système selon la revendication 1 5, 1 6 ou 1 7, caractérisé en ce que l'une desdites actions définies d'utilisateur
comprend un déplacement dans un hyperlien.
35 1 9. Système selon l'une quelconque des revendications 1 5 à 1 8, caractérisé en ce que l'une desdites actions définies
par l'utilisateur comprend une connexion à un service en ligne.
2O. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'un objet de document inclut
4O un langage Hyper Text Markup Language (HTML).
21 . Système pour développer un service en ligne avec un ordinateur comprenant _.
(a) un premier module d'édition pour afficher et autoriser l'édition de relations entre des objets de documents
45 du service en ligne _,
(b) un second module d'édition pour autoriser l'édition d'objets de documents individuels du service en ligne ;
(c) un mécanisme pour appeler le second module d'édition en réponse à la sélection d'un objet de document
dans le premier module d'édition ;
(d) un système pour spécifier des taxes conformément à l'une quelconque des revendications 1 à 5 ; et
5O (e) des moyens pour mémoriser des spécifications de taxes en utilisant au moins l'un dudit premier module
d'édition et dudit second module d'édition.
22. Système pour développer un service en ligne avec un ordinateur, comprenant _.
55 (a) un module d'observation pour afficher des relations entre des objets de documents du service en ligne et
autoriser la sélection de tels objets ;
(b) un module d'édition pour éditer des objets de documents individuels du service en ligne ;
(c) un mécanisme de liaison pour appeler le module d'édition en réponse à la sélection d'un objet de document
36
EP O 792 493 B1
dans le module d'observation _, et
(d) un système pour spécifier des taxes conformément à la revendication 1 .
23. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que si ladite taxe est positive,
5 la taxe est appliquée à ladite entité, et si ladite taxe est négative, un paiement est effectué à ladite entité.
24. Système selon la revendication 1 3 ou la revendication 1 4, caractérisé en outre en ce qu'il comporte _. un éditeur
de script pour éditer le script spécifiant ledit calcul de taxe.
1O 25. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit service en ligne
distribue des informations en utilisant un protocole Hyper Text Transport Protocol (HTTP), ladite information com-
prenant un document hypermedia.
26. Système selon la revendication 25, caractérisé en ce que ledit service en ligne distribue des informations dans
15 l'ensemble d'lnternet.
27. Système selon la revendication 26, caractérisé en ce que ledit document hypermedia comprend un document en
Iangage Hyper Text Markup Language (HTML).
2O 28. Système selon la revendication 2_, caractérisé en ce que la relation entre les objets de documents sont des
hyperliens entre les objets de documents.
25
3O
35
4O
45
5O
55 37
(PICTURE)
EP O 792 493 B1
38
EP O 792 493 B1
(PICTURE)
- 21O
- 22O
- 23O
_ 24O
_ 25O
Figw_e 2
39
(PICTURE)
EP O 792 493 B1
(PICTURE)_gw_e 3(PICTURE)
4O
(PICTURE)
EP O 792 493 B1
Modify a _ocument's Appearance - 3_
Figwre 3b
41
(PICTURE)
EP O 792 493 B1 _
__
_
.__
_
42
(PICTURE)
EP O 792 493 B1 __
__
___
_
__
__
_
_
_
'__
_
_
_
_
Ut_
_
__
_
_
43
(PICTURE)
EP O 792 493 B1 _
__
_
._-_
_
_
_O
U
__
__
_
_
'_
_
__
_Ol
_
4
44
(PICTURE)
EP O 792 493 B1 h
i_
_
_
_
45
(PICTURE)
EP O 792 493 B1 Oo
__ __
'Ó _
_ _h
_ i
__ h_
C '
W _'_
__
46
(PICTURE)
EP O 792 493 B1 _
__
_
_
__
47
(PICTURE)
EP O 792 493 B1 0
_
_,
__
_
__
48
(PICTURE)
EP O 792 493 B1 _
_
,__
__
_h___._
t'_
49
(PICTURE)
EP O 792 493 B1 _
_
__
_
_
__
5O
(PICTURE)
EP O 792 493 B1 M
_
__
_
__
_
51
(PICTURE)
EP O 792 493 B1 _
_
__
__
___
52
(PICTURE)
EP O 792 493 B1 _
_
__
_
.__
_
53
(PICTURE)
EP O 792 493 B1 _
_
__
_
_
__
54
(PICTURE)
EP O 792 493 B1 h
_
__
__
_
55
(PICTURE)
EP O 792 493 B1 Oo
_
i_
_
.__
_
56
(PICTURE)
EP O 792 493 B1 _
_
__
__
__
57
(PICTURE)
EP O 792 493 B1 0
_
__
_
_
__
58
(PICTURE)
EP O 792 493 B1
(PICTURE)
F_'_W_e 2l_
F__W_e 2_b
59
(PICTURE)
EP O 792 493 B1 __
__
_
_
__
6O
(PICTURE)
EP O 792 493 B1 _
_
__
_
_
__
61
(PICTURE)
EP O 792 493 B1 __
__
_
_
_
62