+

WO1998021671A1 - Systeme reparti de traitement de documents utilisant un intermediaire de gestion des demandes objet et un objet receptionnaire - Google Patents

Systeme reparti de traitement de documents utilisant un intermediaire de gestion des demandes objet et un objet receptionnaire Download PDF

Info

Publication number
WO1998021671A1
WO1998021671A1 PCT/US1997/020393 US9720393W WO9821671A1 WO 1998021671 A1 WO1998021671 A1 WO 1998021671A1 US 9720393 W US9720393 W US 9720393W WO 9821671 A1 WO9821671 A1 WO 9821671A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
receptionist
document
webdoc
request broker
Prior art date
Application number
PCT/US1997/020393
Other languages
English (en)
Inventor
Timothy T. Kraft
Original Assignee
Triteal Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Triteal Corporation filed Critical Triteal Corporation
Publication of WO1998021671A1 publication Critical patent/WO1998021671A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G06F16/972—Access to data in other repository systems, e.g. legacy data or dynamic Web page generation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/93—Document management systems

Definitions

  • This invention relates to network systems and object oriented software technology, and more particularly to a system and method for distributing objects and user interfaces over a network system.
  • FIGURE 1 shows a browser/server architecture.
  • a browser 1 typically on a client computer system, accesses a server 2, typically at a remote site, by using a universal resource locator (URL)
  • URL universal resource locator
  • This resource 4 is typically a hypertext markup language (HTML) file that contains URLs to other
  • the referenced resource 4 is accessed by the server 2 and transmitted to the browser 1 using a conventional network protocol such as the TCP/IP protocol.
  • the browser 1 renders the resource
  • the viewable display object 4' may contain URLs 6 to other resources 5.
  • the hypertext links (URLs) among HTML files distributed over the Internet define what is commonly called the world-wide web (WWW).
  • the browser 1 is the user's means for "navigating" the WWW through URL selection.
  • the user can "get” resources from distributed servers, and with the right permissions can "post” resources to distributed servers. This latter capability is typically reserved for one person called the "website 5 master”.
  • Another model of object interaction over the Internet involves the JAVA computer programming language. With the introduction of JAVA, it is possible now to bring small applications called “applets” from a server to a browser to "run” with information rendered from an HTML file.
  • JAVA code compiles to an intermediate host-machine independent code
  • the compiled JAVA applets can run on any host computer that is executing a JAVA virtual machine (JVM).
  • JVM JAVA virtual machine
  • entire applications can be downloaded by a user and run. (The difference between an applet and a full application is that the launcher for an applet enforces stricter security requirements that limits what the applet can access on client and host computer systems.)
  • FIGURE 1 Yet another object oriented architecture used in a network system is shown in FIGURE
  • each object is a potential Internet server object that performs a unit of work for another object that acts as a client object.
  • Client objects can likewise act as server objects to other client objects.
  • Objects are connected by means of the ORB 9, which serves as a message delivery mechanism among all objects. Objects can locate and connect to each other via services performed by the ORB 9.
  • communications between objects are abstracted by use of a proxy 10 and skeleton 11.
  • the proxy 10 appears to a client object 12 to be the actual server object 13. That is, the proxy 10 links to the client object 12 in the same manner as if the server object 13 was directly linked to the client object 12.
  • the skeleton 11 links to the server object 13 as a
  • the proxy 10 and skeleton 11 communicate via an interobject communications protocol supported by the ORB 9.
  • the client object 12 appears to communicate over a direct communications link 14 with the server object 13.
  • the proxy 10 appears to directly communicate over communications link 15 with the skeleton 11. In reality, all objects communicate through the ORB 9.
  • ORB 9 in FIGURE 2 is shown as a unified structure, conventionally, the ORB 9 is a network of ORBs executing on different computer systems but interconnected via the Internet.
  • the interconnected ORBs form a virtual software bus that allows objects to be distributed and potentially run anywhere on the Internet.
  • FIGURE 3 shows yet another diagram of a software architecture and implementation for constructing compound documents from simple parts.
  • This architecture is generally referred to as an "OpenDoc" architecture.
  • Objects called “Parts” represent the content of a document through a tree hierarchy that defines the encapsulation of the compound Parts of the document.
  • Part A is designated as the "Root” Part of the document Part tree, and defines the overall layout of the encapsulated Parts via a Frame
  • Frames represent the visual and geometry elements of the document content, and each Frame has a corresponding Part that will "render” or "paint” its content within the Frame.
  • Part B corresponds to Frame B and will paint its content into Frame B.
  • Part C corresponds to Frame C and will paint its content into Frame C.
  • the Parts 20 and Frames 21 that form a document are stored in an object called a "Bento" container 22, which allows the individual elements to be accessed and cataloged independently from the rendered document. All of the elements of a document can be accessed and rendered by various viewers and editors. Thus, the document is considered to be "open". Although a number of other elements make up the OpenDoc architecture, the Parts 20 and Frames 21 , and the interconnection among these objects, form the essential description of an arbitrary document's content.
  • the present invention provides such an architecture.
  • the invention comprises a system and method for an open GUI Framework and distributed object server architecture using a URL-based approach to designating and accessing resources over the Internet.
  • the resulting document is not only open, but also Internet distributed.
  • a document is defined as the content of one or more distributed objects, all linked to a receptionist object directly or via an object request broker, and each of which is dynamically referenced in a "WebDoc".
  • the WebDoc Upon access via a URL to a server controlling the receptionist object, the WebDoc is assembled and transferred to a client viewer, where the object content is rendered as Frames by Parts that correspond to each object type. The result is a rendered document.
  • the Parts may be linked back to corresponding objects, indirectly or via the object request broker, to maintain update information in the objects.
  • FIGURE 1 is diagram of a prior art browser/server architecture.
  • FIGURE 2 is diagram of a prior art distributed object request broker architecture.
  • FIGURE 3 is diagram of a prior art OpenDoc architecture.
  • FIGURE 4 is a diagram showing the basic WebDoc document architecture of the invention.
  • FIGURE 5 is a diagram showing the mechanism for retrieving and rendering a WebDoc using a client viewer.
  • FIGURE 6 is a diagram showing the format of a WebDoc constructed to represent the content of an object.
  • FIGURE 7 is a diagram showing an alternative format of a WebDoc constructed to represent the content of an object.
  • FIGURE 8 is a screen-shot of a example WebDoc, showing a desktop document which loads WebDocs for other universal resource locators.
  • This invention is related to the inventions entitled “Method for Displaying Multiple Visual Styles” (U.S. patent application serial no. ) and “URL Login” (U.S. patent application serial no. ), filed on the same date as the present patent application.
  • the invention comprises a system and method for an open GUI Framework and distributed object server architecture using a URL-based approach to designating and accessing resources over the Internet.
  • the resulting document is not only open, but also Internet distributed. For ease of reference, this document will be referred to as a "WebDoc".
  • WebDocs can be used to bring up a desktop session on a Network Computer and save the session initiated by a user.
  • User-constructed WebDocs can be presented on a variety of computer systems or display devices, such as pagers, personal digital assistants, Network Computers, personal computers, workstations, and mainframes.
  • the preferred embodiment of the invention incorporates current mail format standards. Accordingly, little or no modifications are necessary for current Internet content handlers. Indeed, any Multipurpose Internet Mail Extensions (MIME) compliant mailer application can handle WebDoc content at some level.
  • MIME Multipurpose Internet Mail Extensions
  • WebDocs are flat collections of "bodyparts" (as opposed to nested compound structures), WebDoc documents can be streamed and processed in parts, constructed from multiple streams, and processed in parallel.
  • a WebDoc is compliant with all current Internet standards and supports current encryption and signature methodologies.
  • a WebDoc can be routed through current MIME-compliant Internet gateways, including email applications providing multiple methods for transmitting and receiving WebDocs.
  • a WebDoc can be used to store data content, user interface descriptions, persistent states for objects, and even object code, all in one document.
  • the invention provides a standard framework for distributed object architectures to interact with a network computer desktop.
  • the supporting WebDoc system of objects can be distributed and the functions of data collection, document construction and collection, transmission, and display, can be performed anywhere on the Internet.
  • the supporting WebDoc system in the preferred embodiment can process and display current MIME-encoded messages (including MIME HTML mail messages) in a "viewer" selected and constructed by the user, as well as allow content to be incorporated into the user's own compound documents.
  • MIME-encoded messages including MIME HTML mail messages
  • FIGURE 4 is a diagram showing the basic WebDoc architecture. This general architecture allows remote location for objects comprising a WebDoc, with a robust mechanism for accessing and rendering all of such objects.
  • a final WebDoc 39 is constructed by a receptionist object 40 that communicates with other content objects 41 , 42 through an object request broker 43 that is responsible for bringing the various elements of the final WebDoc 39 together. Every object 41 , 42 that represents the content of the receptionist object 40 has a corresponding WebDoc. These other objects 41 , 42 may be internal to the receptionist object 40 (such as object C) or may be accessible to the receptionist object 40 through the ORB 43 (such as object B). In the preferred embodiment, all objects 41, 42 are linked to the receptionist object by means of URLs.
  • the receptionist object 40 provides a standard server interface that provides access to one or more services performed by other encapsulated objects.
  • the receptionist object 40 provides functions for authenticating user accesses to the service, as well as constructing the appropriate WebDoc for the requested service.
  • the content of a receptionist object 40 does not have to be physically located within the receptionist object 40, but can itself be distributed on other Internet nodes.
  • the receptionist object 40 corresponds to the Root Part 44 of the final WebDoc 39.
  • Other Parts 45, 46 contained within the Root Part 44 similarly correspond to other objects 41 , 42 encapsulated by the receptionist object 40.
  • the receptionist object 40 fetches the content (WebDocs) of all of the encapsulated objects 41 , 42, and transmits that content to the Root Part 44 and its sub-Parts 45, 46.
  • the Parts 44, 45, 46 define corresponding Frames, which together form the final WebDoc 39. That is, each Frame has a corresponding Part that will "render” or "paint" its content within the Frame.
  • the receptionist object 40 may directly get the content of object C in the form of a WebDoc which defines the content of corresponding Part C.
  • the content of object B may be fetched via the ORB 43.
  • each Part 44, 45, 46, as an object can form a direct connection through the
  • each Part can keep its content up-to-date using its own access methods.
  • the connection through the ORB 43 is only through the Root Part 44.
  • the Root Part 44 coordinates communications between its embedded Parts 45, 46 and their corresponding objects 41 , 42.
  • every Part 44, 45, 46 that makes up the final WebDoc 39 has a document unique Content Identifier (CID) and a network unique universal-object resource indicator (URI), the use of which is described below.
  • CID document unique Content Identifier
  • URI network unique universal-object resource indicator
  • FIGURE 5 is a diagram showing the mechanism for retrieving and rendering a final WebDoc 49 using a client-resident viewer 50.
  • the viewer 50 supplies a URL 51 to a launcher 52.
  • the URL 51 is used to initiate an access to a remote receptionist object 53 via a server 54.
  • the launcher 52 coordinates access to the server 54 via an Internet link 55, as well as the construction of the final WebDoc 49 on a client computer system
  • the server 54 directly accesses a WebDoc file from a receptionist object 53, or requests the WebDoc file from the receptionist object 53, depending upon the URL Internet access protocol being used over the Internet link 55. In either case, the WebDoc file is the same and is independent of the access method of the URL Internet access protocol.
  • the receptionist object 53 fetches ("gets") the content of the WebDoc file (in WebDoc format) from all encapsulated objects 56a-56d, either directly or through an ORB 57.
  • the accessed WebDoc file 55 is received by the launcher 52 and viewer 50, which select an appropriate WebDoc handler parser and initiate the various document Parts for the contents of the WebDoc file 55.
  • a Root Part 58 and sub-Parts 59a-59b correspond to each object.
  • the Parts define corresponding Frames, which together form the final WebDoc 49.
  • the Root Part 58 and its constituent sub-Parts are rendered on the viewer 50, with each Part rendering its content within a corresponding Frame.
  • each Part as an object, can form a direct connection 60 through the ORB 57 to its corresponding object in order to maintain current content.
  • each Part can keep its saved content up-to-date using its own access methods.
  • each Part handles "saving” or “maintaining" its internal content in its corresponding object.
  • the connection 60 to the ORB 57 is preferably only through the Root Part 58.
  • An alternative approach is to not directly connect Parts with their corresponding objects via a connection 60 to the ORB 57. This approach may be required for security reasons or by resource limitations on the client node.
  • An alternative mechanism can be used that omits the connection 60 to the ORB 57. In this mechanism, the viewer 50 and/or launcher 52 saves the current state of each Part of the final WebDoc 49 in a WebDoc file that has the exact same form as the WebDoc file that launched the Part (as an option, only Parts that have changed are saved). Using the original URL 51, this changed WebDoc is transferred to the remote server 54 for posting. Depending on the URL Internet access protocol being used, the changed WebDoc is saved as a file on the server 54 or is transferred to the receptionist object 53 for update processing. In the case of a file save, the server 54 determines how the updated information is merged into the original
  • the receptionist object 53 processes the changed WebDoc to either update the content of the receptionist object 53 or to distribute portions of the WebDoc to sub-objects for similar object updating.
  • the content of a WebDoc is a MIME- encoded multipart message.
  • the description above describes how these messages can be used to transport all content among distributed objects via the WWW.
  • the content of any object can be given as either parameter name/value pairs, or as internal formatted content, such as HTML, JPEG, QuickTime, binary, etc.
  • An important aspect of the WebDoc concept is the ability to format complex content from elements that can be readily understood across the Internet, as opposed to developing special proprietary content formats requiring appreciably more development and support.
  • object oriented programming OOP
  • complex objects are constructed from simpler objects so that the corresponding content of the object is a compound document comprising multiple parts.
  • FIGURE 6 is a diagram showing the format of a WebDoc constructed to represent the content of an object.
  • the document is formatted as a multipart/related "message" consisting of multiple content bodyparts.
  • a bodypart (typically the first) is designated as the root part 70.
  • the root part 70 contains a description of the layout of the other bodyparts and references these bodyparts through unique content identifiers (CIDs).
  • CIDs unique content identifiers
  • Each object generates a corresponding bodypart in the WebDoc that describes the content and location of the object, preferably using a Standard Generalized Markup Language (SGML) formatted content, such as HTML, that defines content in relation to other objects.
  • SGML Standard Generalized Markup Language
  • HTML HyperText Markup Language
  • the receptionist object describes its content as the root part 70 of the WebDoc.
  • Each corresponding Part (here, Part A) takes this description and renders the content.
  • each encapsulated object here, Objects a-d
  • Each encapsulated object generates bodyparts in the WebDoc that define the content of those objects.
  • Each corresponding part (Parts a-d) renders such content, and thus reconstructs the document from its constituent parts, gathered from across the Internet.
  • each bodypart also maintains a universal resource identifier
  • the URI to its corresponding object source, which is the "content location" for the bodypart.
  • the URI preferably takes the form of a URL.
  • Handlers for the bodyparts are selected primarily upon the content-type of each bodypart.
  • Part viewers can be considered to be part of the document viewer (e.g. , viewer 50 in FIGURE 5) and not necessarily transported as part of the WebDoc.
  • a Part ' s viewer may have configurable attributes which allows the Part to be customized to perform specific functions on behalf of the corresponding object.
  • Such configuration attributes are passed to a Part's viewer as parameter name/value pairs which are preferably incorporated as headers in the WebDoc bodypart that precedes the content of the message.
  • FIGURE 7 is a diagram showing an alternative format of a WebDoc constructed to represent the content of an object. This format can be used when the layout of the constituent parts is either implicit to a Part's viewer, or the Part's viewer can be configured through parameter name/value pairs. No special root body part is necessary because the main document header 80 provides additional content-viewer parameters and Part viewer parameters to configure the Part content from the document content.
  • the content type is multipart/related.
  • the document parts are constructed as before (FIGURE 6) from the constituent object contents. There may be additional parameters added to aid in the layout of an embedded document part in relation to the root document part and the other parts in the document.
  • An advantage of formatting WebDocs in this manner is that the parts can still be rendered even if the target viewer is not aware of all of the attributes of the document, or lacks all of the special Part viewers or viewer capabilities.
  • various classes of viewers can view the same WebDoc because the WebDoc is MIME formatted and encoded.
  • viewers and their event handlers can be exactly configured to render a WebDoc and its active elements exactly as intended with Part viewers that are WebDoc "aware".
  • FIGURE 8 is a screen-shot of a example WebDoc, showing a desktop document which loads WebDocs for other universal resource locators. More particularly, FIGURE 8 illustrates a Network Computer desktop constructed entirely from a combination of WebDoc components.
  • the desktop 100 is a WebDoc document consisting of multiple work areas, with one of the work areas shown in full frame.
  • the desktop 100 defines a framework for overlapping windows 102, 104, 106, 108, 110, each comprising a WebDoc, and icons 112, 114.
  • the icons and windows can be moved and resized using a mouse typical of other graphical desktops (e.g., X- Windows, Windows95, OS2, MacOS, etc.).
  • Window 102 is a Graphical Workspace Manager which is constructed as a "thumbnail" view of the desktop 100 Part. The same Part is used to "paint" another view of a WebDoc in a separate Frame. Any WebDoc Part can provide a thumbnail view which is a reduced image of the WebDoc Part's “full view”. Yet another view (i.e. , Frame) 116 of the desktop 100 is embedded into a "front panel" window 106. All views are coupled so that changes in one view will be reflected in all other views (frames). In the preferred embodiment, the Graphical Workspace Manager 102 is viewed within a Frame which is itself constructed from WebDoc Parts for the title bar and layout of the desktop thumbnail views.
  • Window 104 is an Internet Navigator constructed from a WebDoc document, showing the contents of a receptionist object that contains files. Changes in this view are transmitted to the receptionist object to save. The receptionist object likewise keeps this view "current" via either WebDoc messaging or an ORB connection.
  • Window 106 is a front panel of the type used in the industry standard Common Desktop Environment (CDE), but constructed and configured by a WebDoc document and Parts.
  • CDE Common Desktop Environment
  • the icons within the front panel represent services on the Internet that a user can activate by a mouse click. This action results in loading and displaying a WebDoc document within a viewer.
  • a subpanel 118 is raised from the front panel 106 when the user presses an arrow button 120.
  • the subpanel 1 18 shown contains an "icon view" of WebDoc Parts. These icons can be used to raise a full view of the corresponding WebDoc. These icons can also be active drop zones for other WebDocs or for URLs which the WebDoc Part can process.
  • Icon 114 is an "icon view" of a WebDoc. Like the thumbnail view shown in window 102, the icon view is another Frame for a Part. When a Part is depicted in an icon view, it is not necessary to retrieve the entire corresponding WebDoc contents. Typically, what is required to support a WebDoc icon view is the URL to the corresponding full view content and Part event handler for processing URLs that are dropped on the displayed icon 114.
  • Frame 116 is another thumbnail view of the desktop 100, embedded into the front panel 106.
  • thumbnail views of several workspaces 122 shown with miniature views of their backdrop patterns).
  • Each workspace 122 also depicts thumbnail views of WebDocs 124 and icons 126 contained within the workspace 122.
  • Each thumbnail view of a WebDoc has the same functionality as the corresponding full view of the WebDoc. That is, the thumbnail view can receive and respond to mouse and keyboard events in the same manner as the full view, since the exact same Part supports both views.
  • the same functionality can be implemented in a conventional architecture (e.g., CDE), the amount of code required to implement such functionality is greatly reduced and uniformity is greatly enhanced using WebDocs.
  • Window 108 shows an applet displayed without modification within an applet viewer constructed from WebDoc Parts. Because applets can be viewed as Parts, a user can incorporate applets (developed for the Internet) into the user's WebDocs. In a similar fashion, OpenDoc parts, Netscape Navigator "plugin" modules, and Microsoft ActiveX components can be incorporated into the desktop or user documents.
  • Window 1 10 shows a text editor constructed from WebDoc Parts.
  • a user can configure the editor to perform desired functions, including incorporating Parts for spell checking or text formatting.
  • the Parts for this function would describe a viewer for handling, in this case, text.
  • the WebDoc generated by the viewer/editor would be simply the text content (in this case).
  • Icon 1 12 is an icon view of an application that is not a WebDoc.
  • the application is icicrred to as a "legacy" application, which is any application developed outside of the WebDoc paradigms.
  • WebDoc references and links to legacy applications are via URLs.
  • the WebDoc-defined desktop can activate (display) legacy applications in their own window, and through the application program interface (API) for the underlying operating system (e.g. , Windows95) transfer WebDoc contents to the application.
  • API application program interface
  • "drag and drop" functionality between legacy and WebDoc components can be supported.
  • the invention may be implemented in hardware or software, or a combination of both.
  • the invention is implemented in computer programs executing on programmable computers each comprising at least one processor, at least one data storage system (including volatile and non-volatile memory and/or storage elements, any of which may be local or accessible via a network), at least one input device, and at least one output device.
  • Program code is applied to input data to perform the functions described herein and generate output information.
  • the output information is applied to one or more output devices, in known fashion.
  • Each program is preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system, although the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.
  • the invention is implemented in the JAVA programming language for use in conjunction with any host that has a JVM.
  • Each such computer program is preferably stored on a storage media or device (e.g., ROM or magnetic diskette) readable by a general or special purpose programmable computer, for configuring and operating a local or remote computer when the storage media or device is read by the computer to perform the procedures described herein.
  • a storage media or device e.g., ROM or magnetic diskette
  • the inventive system may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner to perform the functions described herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Cette invention se rapporte à un système et à un procédé destinés à un cadre ouvert d'interface utilisateur graphique (graphical user interface, GUI) et à une architecture répartie de type serveur d'objets utilisant une approche basée sur un localisateur URL aux fins de désignation et d'accès à des ressources sur le réseau Internet. Le document résultant n'est pas seulement ouvert, mais également distribué sur Internet. Un document est défini comme étant le contenu d'un ou de plusieurs objets répartis (41, 42), tous liés à un objet réceptionnaire (40) directement ou via un intermédiaire (43) gérant des demandes objet, chacun de ces objets répartis étant dynamiquement référencé dans un document du Web ('WebDoc') (39). Lors de l'accès par l'intermédiaire d'un URL à un serveur commandant l'objet réceptionnaire, le WebDoc est assemblé et transféré à un organe de visualisation client, où le contenu de l'objet est rendu sous forme d'images par morceaux qui correspondent à chaque type d'objet. Le résultat est un document rendu. Selon une réalisation, les morceaux peuvent être reliés à nouveau aux objets correspondants, indirectement ou via l'intermédiaire gérant les demandes objet, de façon à conserver des informations de mise à jour dans les objets.
PCT/US1997/020393 1996-11-14 1997-11-07 Systeme reparti de traitement de documents utilisant un intermediaire de gestion des demandes objet et un objet receptionnaire WO1998021671A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US74779396A 1996-11-14 1996-11-14
US08/747,793 1996-11-14

Publications (1)

Publication Number Publication Date
WO1998021671A1 true WO1998021671A1 (fr) 1998-05-22

Family

ID=25006665

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1997/020393 WO1998021671A1 (fr) 1996-11-14 1997-11-07 Systeme reparti de traitement de documents utilisant un intermediaire de gestion des demandes objet et un objet receptionnaire

Country Status (1)

Country Link
WO (1) WO1998021671A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2808348A1 (fr) * 2000-04-28 2001-11-02 Noheto S A S Procede pour la preparation dynamique de fichiers numeriques correspondant a des moyens d'information tels que des pages au format html
NL1015094C2 (nl) * 2000-05-02 2001-11-05 Blue Polar B V Communicatiesysteem en een informatiesysteem.
EP1260902A3 (fr) * 2001-05-14 2003-11-12 K-Plex Inc. Procédé et appareil utilisant la technologie orientée objet pour le partage d'informations
WO2001075673A3 (fr) * 2000-03-31 2003-12-04 Mypoints Com Inc Procede permettant de concevoir et de preserver le contenu de sites web
US6782536B2 (en) * 1999-06-08 2004-08-24 Unisys Corporation System and method for discovering host-based application assets for the development of business-centric software components
US7178129B2 (en) * 2001-12-07 2007-02-13 Dbase, Inc. Drag-and drop dynamic distributed object model
US7356570B1 (en) * 2000-08-29 2008-04-08 Raja Tuli Portable high speed communication device

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5481715A (en) * 1993-12-15 1996-01-02 Sun Microsystems, Inc. Method and apparatus for delegated communications in a computer system using trusted deputies
US5491820A (en) * 1994-11-10 1996-02-13 At&T Corporation Distributed, intermittently connected, object-oriented database and management system
US5664208A (en) * 1995-05-16 1997-09-02 Apple Computer, Inc. Methods and apparatuses for seamless compound document processing
US5689664A (en) * 1995-04-14 1997-11-18 Microsoft Corporation Interface sharing between objects
US5701484A (en) * 1990-05-18 1997-12-23 Digital Equipment Corporation Routing objects on action paths in a distributed computing system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5701484A (en) * 1990-05-18 1997-12-23 Digital Equipment Corporation Routing objects on action paths in a distributed computing system
US5481715A (en) * 1993-12-15 1996-01-02 Sun Microsystems, Inc. Method and apparatus for delegated communications in a computer system using trusted deputies
US5491820A (en) * 1994-11-10 1996-02-13 At&T Corporation Distributed, intermittently connected, object-oriented database and management system
US5689664A (en) * 1995-04-14 1997-11-18 Microsoft Corporation Interface sharing between objects
US5664208A (en) * 1995-05-16 1997-09-02 Apple Computer, Inc. Methods and apparatuses for seamless compound document processing

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6782536B2 (en) * 1999-06-08 2004-08-24 Unisys Corporation System and method for discovering host-based application assets for the development of business-centric software components
WO2001075673A3 (fr) * 2000-03-31 2003-12-04 Mypoints Com Inc Procede permettant de concevoir et de preserver le contenu de sites web
FR2808348A1 (fr) * 2000-04-28 2001-11-02 Noheto S A S Procede pour la preparation dynamique de fichiers numeriques correspondant a des moyens d'information tels que des pages au format html
WO2001084362A1 (fr) * 2000-04-28 2001-11-08 Noheto S.A.S Procede pour la preparation dynamique de fichiers numeriques correspondant a des moyens d'information tels que des pages au format html
NL1015094C2 (nl) * 2000-05-02 2001-11-05 Blue Polar B V Communicatiesysteem en een informatiesysteem.
US7356570B1 (en) * 2000-08-29 2008-04-08 Raja Tuli Portable high speed communication device
EP1260902A3 (fr) * 2001-05-14 2003-11-12 K-Plex Inc. Procédé et appareil utilisant la technologie orientée objet pour le partage d'informations
US7099919B2 (en) 2001-05-14 2006-08-29 K-Plex Inc. Information sharing method and apparatus using object oriented technology
US7178129B2 (en) * 2001-12-07 2007-02-13 Dbase, Inc. Drag-and drop dynamic distributed object model
USRE44327E1 (en) 2001-12-07 2013-06-25 Amstr. Investments 9 K.G., Llc Drag-and-drop dynamic distributed object model

Similar Documents

Publication Publication Date Title
US8285807B2 (en) Method and system for remote industrial factory automation control of a local system
US5896533A (en) Accessing internets world-wide web through object linking and embedding technology
US5732219A (en) Computer system and computer-implemented process for remote editing of computer files
US6192394B1 (en) Inter-program synchronous communications using a collaboration software system
US7269664B2 (en) Network portal system and methods
US6480882B1 (en) Method for control and communication between computer systems linked through a network
US6457066B1 (en) Simple object access protocol
US6003094A (en) Generic Java Gateway for connecting a client to a transaction processing system
US7725906B2 (en) Method and device for executing a function with selection and sending of multiple results in a client-server environment
US7191450B2 (en) Data-driven application integration adapters
US7146618B1 (en) Simple object access protocol
US20020091788A1 (en) Internet web server cache storage and session management system
US20030195950A1 (en) Virtual desktop in a computer network
US10255333B2 (en) Local client database for remote support
EP1126681A2 (fr) Portique de réseau et procédé associé
US6665860B1 (en) Sever-based method and apparatus for enabling client systems on a network to present results of software execution in any of multiple selectable render modes
AU5184301A (en) Human machine interface
US20030149749A1 (en) Method of data refreshing of a mark-up- language document
EP0815518A1 (fr) Systeme d'ordinateur et processus informatise de creation et maintenance de services telematiques
CA2437273C (fr) Canal reseau permettant d'acceder a des services de transmission de donnees
WO1998021671A1 (fr) Systeme reparti de traitement de documents utilisant un intermediaire de gestion des demandes objet et un objet receptionnaire
Pierce et al. Application web services
Dale Achieving User interface heterogeneity in a distributed environment
Dönszelmann Interfacing with the WEB
Serain et al. Internet and Middleware

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
122 Ep: pct application non-entry in european phase
点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载