|||||||||||||||||||||||||||||||||||||||||I
`||||||||||||l||||||||||||||||||
`U300586487IIA
`
`United States Patent
`Guck
`
`[19]
`
`[11] Patent Number:
`
`5,364,870
`
`[45] Date of Patent:
`
`Jan. 26, 1999
`
`I54I
`
`METHOD FOR STORINGI’RETRIEVING
`FILES OF VARIOUS FORMATS IN AN
`OBJECT DATABASE USING A VIRTUAL
`MULTIMEDIA FILE SYSTEM
`
`Primary Exmuirter~Thomas G. Black
`Assistant Exmttiner—Donald Min
`Attorney; Agent, or i‘Irttt—J. Ronald Richebourg; Steven R.
`Petersen; Mark T. Starr
`
`I751
`
`Inventor: Randal Lee Guck. Dana Point, Calif.
`
`[57]
`
`ABSTRACT
`
`[731
`
`Assignee: Unisys Corp., Bluebell, Pa.
`
`[311
`
`|22
`
`[511
`I52!
`
`[531
`
`[56I
`
`Appl. No; 769,199
`
`Filed:
`
`Dec. 18, 1996
`
`
`Int. CL"
`............................... GflfiF 17ft]!
`
`"
`.. 707.1104; 707/100; 707/101;
`707r'1[l3
`7071100, 101,
`TONIC-4, 103
`
`Field of Search
`
`References Clted
`
`U.S. I’KI‘EN'I' DOCUMENTS
`
`lacquit ct a1.
`9.91996
`5,557,?85
`5.557.790 W199!) Bingham cl a1.
`55841106 1211906 Reher et al.
`5,659,742
`SI1997 Beanie et al.
`5,729,741
`331998 Linguno at al.
`
`.
`
`..
`
`TIFIIIH
`
`V 707mm
`395F127
`707nm
`
`.. TUWIEM
`
`A method is provided in a server for storing and retrieving
`files of various formats in an object database coupled to a
`network including a multiplicity ol‘clients also coupled to
`the network. The server includes a storage device for storing
`objects of the database. The method begins by determining
`the type and content of files received by the server from the
`clients coupled. Each file received by the server is trans-
`formed into an object. 'Ihc transformed objects are stored in
`a hierarchy in accordance with the type and content thereof.
`The retrieving part of the process includes transmitting a
`"get" request to the server; searching a Virtual File class for
`an object whose name matches the file name; and examining
`corresponding properties of the matching object for com-
`patibility with the first parameter. If compatible, a next
`parameter
`is examined for corresponding properties for
`compatibility. when all parameters have been examined, the
`content is enveloped and returned to the client that origi-
`nated the “get" request.
`
`16 Claims, III DrawingI Sheets
`
`
`'I'
`
`1“3|
`
`: MIMESUBTYPECLASS ]
`[SSEARCHED FOR
`.
`OBJECT WHOSE LABEL
`MATCHES EXTRACTED
`MIME SUHTYPF
`
`121
`
`
`
`MIME TYPE IS
`EXTRACTED FROM
`CONTENTiTYPE
`
`
`EXTRACTED MIME TYPE
`
`MIME TYPE CLASS
`IS SEARCHED FOR
`03.1 E CT THAT
`R E PR E SE NTS
`
`
`WAS
`MATCHING
`
`MIME SUBTYPE
`FOUND'3
`
`
`
`
`I24
`——- — -—-
`
`NEW MIME
`SUBTYPE
`OBJECT
`CREATED
`MD
`CONNECTED
`
`I
`MIME SUBTYPE
`IS EXTRACTED
`k 120
`FROM THE
`CONTENT-TYPE ‘
`—-————-
`MIME SUBTYPE FOUND
`on CREATEDIS CHOSEN
`As FILE'S CONTENT-TYPE
`
`(I?
`
`p-i
`II
`
`_ _.__
`
`NEW MIME FILEOBJECT IS CREATED
`
`l‘
`MIME FILE OBJECT
`CONNECTED TO MIME
`SUBTYPE OBJECT CHOSEN
`
`
`
`125
`
`E126
`
`““H— 12?
`
`FILE'S CONTENT TRANSMH'I'ED
`TO THE SERVER IS STORED
`IN THE DATABASE AND
`ATTACHED TO MIME FILE OBJECT
`A5 A PROPERTY OF THAT OBJECT
`
`
`—L
`‘
`SERVER RETURNSAPPRDPRMTE a 123
`RESULT CODE BACK TO CLIENT
`_
`.—'7lr
`
`{/ STOP jf‘H 129
`
`UA-1010.001
`
`UA-1010.001
`
`

`

`U.S. Patent
`
`Jan. 26, 1999
`
`Sheet 1 of 10
`
`5,864,870
`
`nE..ZZ
`
`n_._._>_w
`
`0—,
`
`mesEz
`
`szmmpz:
`
`525.2
`
`n_._.n_
`
`nCIrI
`
`
`
`omzotimOsman.
`
`mzoImmdF
`
`25$xmoEmz
`
`.3,9.
`
`N_.
`
`I,
`
`FijOPZm—UQ
`
`Fzmjo
`
`FZMEO
`
`m>>mZ42.2
`
`
`
`”mm:mmmD
`
`mm?»
`
`mm>>
`
`mmmgomm
`
`mmmaomm
`
`MZOIaw._m_._.
`
`_.N
`
`/
`
`_..OE
`
`m:m/E,
`
`r
`
`
`
`#10;.200
`
`EMFw>w
`
`>N_O_>_m__>_
`
`Duo
`
`
`
`NN
`
`om
`
`”Exam—mm
`
`m_.
`
`0:
`
`mm<m<H<D
`
`UA-1010.002
`
`UA-1010.002
`
`
`
`
`

`

`US. Patent
`
`Jan. 26, 1999
`
`Sheet 2 of 10
`
`5,864,870
`
`._mzz<_._oO:
`
`mméfié-
`
`ON
`
`
`
`SEEM“:wwfifiwflmmmwmoomn.
`8:52«mama
`828mm
`
`on
`
`(Em—Low
`
`
`
`.EOn.5.5.00
`
`:MNFN
`
`
`
`N.OE
`
`
`
`>mOEm—E55.55%2.
`
`UA-1010.003
`
`UA-1010.003
`
`
`
`
`

`

`U.S. Patent
`
`Jan. 26, 1999
`
`Sheet 3 of 10
`
`5,864,870
`
`
`
`
`
`.MPG
`
`—‘
`.MPEG
`
`54
`
`55
`
`
`
`MESSAGE
`
`POST-
`
`52 / SCRIPT
`— 43
`
`
`
`
`
`
`
`
`47
`
`RFcazz
`
`IMAGE
`
`53/
`
`\44
`
`.DOC
`
`MM
`
`
`
`APPLN \45
`
`MULTI-
`
`PART
`
`46
`
`FIG. 3
`
`VIDEO
`
`UA-1010.004
`
`UA-1010.004
`
`

`

`U.S. Patent
`
`Jan. 26, 1999
`
`Sheet 4 of 10
`
`5,864,870
`
`FIG. 4B
`
`UA-1010.005
`
`UA-1010.005
`
`

`

`U.S. Patent
`
`Jan. 26, 1999
`
`Sheet 5 of 10
`
`5,864,870
`
`92
`
`9‘\
`
` MSG
`
`PARTIAL
`
`FILE
`
`
` MSG
`EXT. BODY
`FILE
`
`
`
`FROM
`FIG. 4A
`
`/
`
`MIXED
`FILE
`
`95
`
`Q7
`
`
`
`ALTERNATE
`
`FILE
`
`POST
`SCRIPT
`FILE
`
`102
`
`
`
`OCTET—
`
`
`STREAM
`FILE
`
`
`
`
`
`PARALLEL
`FILE
`
`96
`
`101
`
`FIG. 4B
`
`UA-1010.006
`
`UA-1010.006
`
`

`

`U.S. Patent
`
`Jan. 26, 1999
`
`Sheet 6 of 10
`
`5,864,870
`
`START
`
`1 10
`
`
`
`FILE RECEIVED BY THE SERVER,
`INCLUDING FILE NAME. CONTENT,
`AND OPTIONAL PROPERTIES
`
`111
`
`FILE ACCOMPANIED BY
`
`
`AN EXPLICIT CO NTENT—TYPE
`?
`
`
`
`NO
`
`a
`
`SEARCH PERFORMED ON FILE
`EXTENSION CLASS TO FIND
`
`114
`
`OBJECT THAT MATCHES EXTENSION
`
`
`OBJECT WHICH REPRESENTS CONTENT-TYPE
`
`"APPLICATIONIOCTET-STREAM': AND THIS
`
`OBJECT IS CHOSEN AS THE FILE'S CONTENT
`
`
`_
`
`FIG. 5A
`
`o
`
`UA-1010.007
`
`116
`CONTENT TYPE
`
`115
`
`WAS
`
`
`MATCHING FILE
`
`
`EXTENSION OBJECT
`
`
`FOUND
`
`YES
`
`
`NO/
`MIME SUBTYPE CLASS SEARCHED FOR
`
`RELATIONSHIP TO
`MIME SUBTYPE CLASS
`
`TRAVERSED; FIRST
`MIME SUBTYPE OBJECT
`FOUND IS CHOSEN TO
`REPRESENT FILE'S
`
`UA-1010.007
`
`

`

`U.S. Patent
`
`Jan. 26, 1999
`
`Sheet 7 of 10
`
`5,864,870
`
`MIME TYPE IS
`EXTRACTED FROM
`CONTENT-TYPE
`
`
`MIME SUBWPE CLASS
`
`
`ISSEARCHED FOR
`OBJECT WHOSE LABEL
`MATCHES EXTRACTED
`
`MIME SUBTYPE
`
`
`
`
`
`
`
`/122
`
`WAS
`
`MATCHING
`N0
`
`
`
`MIME SUBTYPE
`FOUND
`
`?
`
`MIME TYPE CLASS
`IS SEARCHED FOR
`OBJECT THAT
`REPRESENTS
`EXTRACTED MIME TYPE
`
`119
`
`MIME SUBTYPE
`
`IS EXTRACTED
`
`FROM THE
`
`CONTENT-TYPE
`
`NEW MIME
`
`
`MIME SUBTYPE FOUND
`SgngE‘EPTE
`
`
`
`
`0R CREATEDIS CHOSEN
`CREATED
`
`
`AND
`AS FILE'S CONTENT-TYPE
`CONNECTED
`
`
`
`
`
`
`125
`
`NEW MIME FILE
`
`
`OBJECT IS CREATED
`
`
`
` MIME FILE OBJECT
`CONNECTED TO MIME
`
`
`SUBTYPE OBJECT CHOSEN
`‘26
`
`
`FILE‘S CONTENT TRANSMITTED
`TO THE SERVER IS STORED
`IN THE DATABASE AND
`ATTACHED TO MIME FILE OBJECT
`AS A PROPERTY OF THAT OBJECT
`
`
`
`
`
`
`SERVER RETURNS APPROPRIATE
`RESULT CODE BACK TO CLIENT
`
`-ng
`
`127
`
`128
`
`FIG. 5B
`
`UA-1010.008
`
`UA-1010.008
`
`

`

`US. Patent
`
`Jan. 26, 1999
`
`Sheet 8 of 10
`
`5,864,870
`
`/134
`
`
`
`
`
`
`CLIENT CONNECTS TO SERVER
`USING A PROTOCOL
`
`
`135
`
`I
`[ CLIENT TRANSMITS A ”GET" REQUEST / 136
`
`
`
`
`
`T0 SERVER VIA PROTOCOL
`
`’GET" REQUES
`INCLUDE A
`FILE NAME
`?
`
`RETURN AN
`ERROR
`
`YES / 139
`____7.__
`SEARCH VIRTUAL FILE CLASS
`FOR AN OBJECT WHOSE NAME
`MATCHES THE GIVEN FILE NAME
`
`
`
`
`
`
`
`
`A MATCHING
`
`OBJECT FOUND
`
`
`"GET" REQUEST
`INCLUDE
`
`PARAMETERS
`?
`
`
`
`FIG. 6A
`
`UA-1010.009
`
`UA-1010.009
`
`

`

`U.S. Patent
`
`Jan. 26, 1999
`
`Sheet 9 of 10
`
`5,864,870
`
`143
`
`SEARCH CORRESPONDING PROPERTIES OF
`
`
`VIRTUAL FILE OBJECT FOR COMPATIBILITY
`WITH THE PARAMETER
`
`
`
`IS
`
`
`VIRTUAL FILE
`
`NO
`OBJECT‘S
`PROPERTIES COMPATIBLE
`
`WITH THE
`
`PARAMETER
`
`?
`
`ATTEMPT TO DYNAMICALLY
`CREATE A TEMPORARY
`VERSION OF THE OBJECT
`WHICH IS COMPATIBLE
`
`WITH THE PARAMETER
`
`
`
`
`
`
`PARAMETERS
`147
`
` ATTEMPT
`SUCCESSFU
`
`?
`
`RETURN
`”0
`AN ERROR
`
`
`
`USE TEMPORARY
`VERSION OF THE
`OBJECT FOR NEXT
`PARAMETER
`
`
`
`FIG. GB
`
`UA-1010.010
`
`UA-1010.010
`
`

`

`US. Patent
`
`Jan. 26, 1999
`
`Sheet 10 0f 10
`
`5,864,870
`
`REQUEST VIRTUAL FILE
`OBJECT‘S "GET CONTENT"
`
`FUNCTION
`
`150
`
`
`
`CONTENT RETURNED
`FROM ”GET
`CONTENT" FUNCTION
`
`
`
`151
`
`
`
`
`
`
`ENVELOPE THE CONTENT
`RETURNED FOR THE
`PROTOCOL BEING USED
`
`
`
`152
`
`RETURN ENVELOPED CONTENT
`TO THE CLIENT
`
`
`
`
`153
`
`/ 154
`
`STOP
`
`FIG. 6C
`
`UA-1010.011
`
`UA-1010.011
`
`

`

`5,864,870
`
`1
`METHOD FOR STORINGJ'RETRIEVING
`FILES OF VARIOUS FORMATS IN AN
`OBJECT DA" ’ABASE USING A VIRTUAL
`MULTIMEDIA FILE SYSTEM
`
`FIELD OF THE INVENTION
`
`The present invention relates to a computer-implemented
`method for determining the type and content of incoming
`files, transforming such files into objects, and storing them
`in an object database for later retrieval, which database is
`part of a specialized server coupled to a network.
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`
`in
`
`15
`
`This application relates to the following applications,
`assigned to the same assignee hereof, which are incorporated
`herein by reference.
`US. Ser. No. 081768387, now entitled AUTOMATIC
`FORMAT CONVERSION SYSTEM AND PUBLISHING -
`METHODOLOGY FOR MUlTl-USER NETWORK;
`Us. Set No. flSl768,386. now US. Pat. No. 5,848,415
`entitled SELECTIVE MULTIPLE PROTOCOL ‘I‘RANS-
`PORT AND DYNAMIC FORMAT CONVERSION IN
`MUL’I‘l-USER NETWORK; and,
`US. Ser. No. 08/769,200, entitled METHOD FOR
`MiST‘RACFING MESSAGES OI’ VARIOUS PROTO-
`COLS INTO OBJECTS FOR STORAGE IN A
`DATABASE, now U.S. Pat. No. 5,794,039.
`
`3f]
`
`BACKGROUND OF THE INVENTION
`
`In the rapidly developing area of computer interconnect-
`ing technology and the Internet there is a need to provide
`systems and methodology that enable clients using one type
`of specialized protocol to communicate with other clients
`having ditIerent protocols. Earlier network technologies and
`even the majority of present network technologies involve
`slow and complex software systems and methods in order to
`enable a client with one type of protocol to communicate
`with another client having a different type of protocol, or
`with terminals having other protocols such as that used for
`FAX machines or still other protocols used for telephones.
`These software systems and methods often involve long,
`drawn-out translation procedures which are slow, cumber-
`some and subject to reliability problems.
`It would be desirable to provide a network system where
`any client, no matter what
`type of format
`is being used,
`could create, originate or author a document and enable this
`document to be transmitted and received by clients having
`different types of formats, and, also to have such a document
`receivable by appliances such as FAX machines or tele—
`phones. Heretofore. this has not been done with any great
`degree of efiEcicncy. That is, an originator or author could
`not create a text or message in his own personal computer
`format and send it
`to multiple receiver users, or multiple
`receiver appliances without any Further complications. Such
`a system and methodology is now possible with the use of
`the tnethod of the present invention.
`Thus. it is an object of the present invention to provide a
`method for driving a database that solves the problem of
`transforming incoming files into objects for storage in the
`database and organizing the transformed files into a hierar—
`chy of objects in accordance with the type and content of
`such incoming files for storage in the database.
`Another object of the present
`invention is to use the
`MIME (Mold-Purpose Internet Mail Extension) standard for
`
`35
`
`40
`
`45
`
`5f]
`
`55
`
`60
`
`05
`
`2
`a tile system by employing such standard as the basis for an
`object database schema.
`Yet another object of the present invention is to provide an
`object database schema that mimics a lite system, thereby
`creating a virtual file system that employs the full catego-
`rization technique used by the MIME standard.
`A feature of the present
`invention is that by using an
`object database system,
`the object paradigm can be
`exploited to create a highly modular and extensible system.
`Extensions can easily be made after system deployment to
`track changes in standards (e.g., new MIME types and
`subtypes). Moreover. additional modules can easily be
`developed and integrated with the virtual multi-media file
`system to address new content management requirements.
`Another feature of the present invention is that by fol—
`lowing the MIME standard,
`the virtual multi-mcdia file
`system allows content to be represented in a way that allows
`easy communication across the Internet. That
`is, even
`though the MIME standard is not intended for classifying
`files, doing so makes it easy for files to be sent/received over
`message-oriented protocols on the interact. Consequently,
`using the MIME standard for virtual files makes it easy to
`send and receive data using message-oriented protocols even
`though the content
`is obtained from or stored into files,
`which can be subsequently accessed via file-oriented proto-
`cols.
`Still another Feature of the present invention resides in the
`provision of accurate identification of a file’s content type
`(i.e., a virtual file object possesses more and better infor-
`mation about
`its content than a ”real" file);
`the ability to
`verify that a file’s content conforms to its labeling; is, each
`virtual file class can have a method which verifies that a
`given file’s content is correct according to its MIME type!
`subtype (if a file’s content is incorrect, a list ol‘errors can be
`returned to the author); and, the ability to intelligently search
`a file for specific content (cg, text, image, etc.) regardless
`of its format (i.e., methods can be defined which allow all
`files to be searched for text—image files can be searched
`within their narrative text or in text boxes—audio tiles can
`be searched for the “speech equivalent" of the given text
`—video files can be searched both in the audio track and
`within subtitles, etc.).
`An advantage of the present invention is that by the use
`of "virtual" files instead of real files (Le,
`the operating
`system files}, the user is not hou nd to the operating systems’
`inherent limitations. For example, system files cannot be
`assigned a MIME type and subtype, which is a permanent
`record of the file, By using database objects as "virtual” files,
`we can assign them all of the properties ofa system file plus.
`whatever extra properties the user wishes them to have.
`Another advantage of the present
`invention is that by
`using an object database, virtual file objects can be inter-
`connected with [ii—directional references based on actual
`content
`interdependencies (cg, sub-documents,
`linked
`documents. etc). These interconnections can be exploited in
`several ways, including but not limited to:
`the deletion oi'a file that is referenced by another file can
`he disallowed;
`a file’s dependency graph can be determined and reported
`on—a file's dependency graph is the file and the set of
`all
`files that
`it uses (or are otherwise required to
`“render" the file);
`virtual file objects can be interconnected to create version
`trees, which represent "original” files and various ver-
`sions of each file, each of which represent updates;
`a virtual file can be extracted along with the set of files on
`which it is dependent (in, the files in its dependency
`
`UA-1010.012
`
`UA-1010.012
`
`

`

`5,864,870
`
`3
`grathhis allows a file to be easily distributed along
`with the set of files which are required to render or
`otherwise use it;
`a virtual file can be converted from one file format to
`another (cg, RTF to PostScript) or even into non-file
`oriented formats (e.g., mail messages); and,
`a virtual file can be made available via a wide range of
`protocols (F'l'l’, I-l’l'l‘l’, mail, news, etc), allowing the
`same information to be disseminated in multiple ways
`without replication or manual conversion.
`Yet another advantage of the present invention is that by
`using a portable (i.c., multi-platform) database system, vir—
`tual
`files can have the same interface regardless of the
`operating system used. For example, file name length and
`maximum file size can be consistent despite different con—
`ventions and limitations between the operating systems
`used.
`Still another advantage of the present invention is that by
`the use of an object database management system greater
`security, integrity and recoverability is accomplished than
`would normally be received in a “real" file system.
`SUMMARY OF THE INVENTION
`
`ill
`
`3f]
`
`40
`
`In accordance with the above and other objects, features
`and advantages of the invention, there is provided a method ‘
`in a system server for storing files of various formats in an
`object database coupled to a network including a multiplic-
`ity of clients also coupled to the network. The server
`includes a CPU and at
`least one storage device coupled
`thereto for storing objects of the database. The method
`comprises the steps of determining the type and content of
`files received by the system server from the clients coupled
`to thc netwurk; transforming each of the files received by the
`system server into an object; storing each of the transformed
`objects into a hierarchy in accordance with the type and ‘
`content thereof; and, returning a code back to the client that
`transmitter] the file to the server indicating receipt of the file.
`The present invention also includes a method for retriev-
`ing files of various formats stored in the database in accor-
`dance with the MIME standard. This method comprises the
`steps of connecting one of the clients to the server using a
`protocol, and transmitting thereto a "get" request and deter-
`mining if the “gel" request includes a file name. If it does,
`a Virtual File class is searched for an object whose name
`matches the file name. If a matching object is found, then it
`is necessary to delen'nine if the "gel” request includes a
`parameter. If it does, corresponding properties of the match-
`ing object are examined for compatibility with the param-
`eter. If it is compatible, a next parameter is examined for
`corresponding properties for compatibility with the next
`parameter. When all parameters have been examined, the
`matching object‘s "get content“ function is requested, and
`the content
`is enveloped and relumed to the client
`that
`originated the “get" request.
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a generalized block diagram showing network
`system connections to clients and the server.
`including
`details of the server that executes the method of the present
`invention.
`
`1’10. 2 is a block diagram showing the server (including
`software modules stored therein for
`implementing the
`method of the present invention), and a database storage
`mechanism coupled to the server.
`FIG. 3 is a diagram of a look-up table used in determining
`the type and content of incoming files.
`
`60
`
`65
`
`4
`FIGS. 4A and 43 combined form a taxonomy diagram
`illustrating the complete set of lile types and subtypes for
`establishing a hierarchy of the various files that are to be
`stored in the database.
`
`FIGS. 5A and 5B combined form a flow chart illustrating
`the process for storing a file in the database as a virtual file.
`FIGS. 6A, GB and 6C combined form a
`flow chart
`illustrating the process for retrieving a file from the database.
`DETAILED DESCRIPTION
`
`Before proceeding with a description of the system and
`method ofthe present invention. a summary ochrminology
`used herein is provided, which may be helpful
`in under-
`standing the disclosed embodiment.
`An object
`is an abstract representation of a real—world
`concept or thing. For example, an object can be used to
`represent a customer account in a banking application. Ari
`object has features. which can be either an operation or a
`property. An operation defines an action that an object can
`perform, or an action that can be performed on the object.
`For example, "make withdrawal" could be defined as an
`operation on a customer account object. Properties indicate
`the state of an object. Every property of an object has a
`value, and it is the property values that delinc the state of the
`object. A property can be either an attribute or a reference.
`An attribute defines a value that is stored within the object.
`For example. “current account balance" could be an attribute
`of the customer account object. The numeric value for the
`customer’s account balance would be stored in the customer
`
`account object. A reference is a link or pointer to another
`object, and implies a relationship to that other object. A
`reference is typically used when it is desired not to duplicate
`data. For example, the customer account object could store
`the customer’s name and address as attributes. However, if
`the customer opened multiple accounts,
`the customer’s
`name and address would appear in multiple account objects.
`Therefore, it is desirable to define a separate customer object
`and place the name and address as attributes of the customer
`object. The customer aceou nt object would then contain a
`reference to the customer object.
`A normal object program stores objects in a computer
`system’s memory. When the program terminates,
`the
`memory used by those objects is freed and reused by other
`programs, making the objects that the program stored tran-
`sient. An object database stores objects in a non-volatile
`memory, such as a computer disk. Since the information on
`a computer disk remains in existence, even when the com-
`puter is turned 03', an object database provides the ability to
`persistently store objects. An object program that uses an
`object database thus has the option of storing objects tran-
`siently or persistently.
`The term format as used herein refers to the specific
`arrangement of data on a disk drive to meet established
`requirements for storage and retrieval
`thereof. The term
`protocol as used herein refers to a set of formal rules
`describing how to transmit data, especially across a network.
`Low-level protocols define the electrical and physical stan-
`dards to be observed, hit- and byte-ordering and the trans-
`mission and error detection as well as correction of the bit
`stream. High—level protocols deal with message formatting,
`including the syntax of messages, the terminal to computer
`dialogue. character sets, sequencing of messages, etc. The
`term schema as used herein refers to the logical description
`of data in a database, including definitions and relationships
`of data.
`Referring now to FIG. 1, an overall block diagram of a
`network system that may employ the method ofthc present
`
`UA-1010.013
`
`UA-1010.013
`
`

`

`5,864,870
`
`in
`
`15
`
`3f]
`
`35
`
`40
`
`5
`invention is illustrated. A llexible multi-user network system
`10, which for purposes of this disclosure represents the
`Internet (or perhaps an Intranet} is shown coupled between
`clients 11 through 14 on one side of the network system and
`a server 15 on the other side. By way of illustration. the
`client 11 is shown coupled to the network 10 by way of a
`protocol referred to as I-l'l'l‘P {Hyper Text Transport
`Protocol). This is a client-server protocol used for informa-
`tion sharing on the Internet and is the basis of use for the
`World Wide Web (WWW). Client 12 is shown coupled to the
`network 10 by way of a File Transfer Protocol (FTP). This
`Is a set of Transmission Fontrol Protocol over Internet
`Protocol ('l'CP/lP] commands used to log onto a network, to
`list directories and to copy files.
`Client 13 is shown coupled to the network 10 by way of
`the SM'I'P protocol, which denotes Simple Mail Transfer
`Protocol. This is a messaging protocol used by software
`applications to send and receive e-mail. The client 14,
`labeled Newn User, is shown coupled to the network 10 by
`way of a Network News Transfer Protocol (“NNTP”). The '
`NNTP is a protocol used for distribution, inquiry, retrieval
`and posting of News articles over the Internet.
`The server 15 includes a CPU 16, a communication port
`17, a system memory 18, and an [/0 channel 19. Astorage
`media suitable for storing a large database, such as a disk ‘
`drive system 20, is coupled to the server 15 by means of an
`l/O channel 19. The server 15 is coupled to the network 10
`by means of a cable 21 connected to the communication port
`17.
`In a similar manner, a Public Switched Telephone
`Network 22 (PSTN) is coupled to a telephone 24 using an
`lnteractive Voice Response protocol (IVR). This involves
`the generation of voice output by a computer. It provides
`pro-recorded information either with or without selection by
`the caller. Interactive Voice Response (NR) also allows
`interactive manipulation of a database.
`The facsimile or FAX machine 24 is coupled to the PS‘l'N
`22 by way of a special protocol such as the Group 3
`Facsimile Protocol (“GBFP”), which is widely used [or
`facsimile transmissions.
`The server 15 operates as a computer in a network shared
`by multiple users. It can act as a file server whereby it uses.
`a high-speed computer to store the programs and tiles that
`are shared by the various users on the network 10. Some—
`times this is called a “network server“, since it acts like a
`remote disk drive. "The server 15 can also act as a database
`server in that it is dedicated to database storage and retrieval.
`Among the problems characteristic of earlier networks
`was the lack ofcnntinuity ot'service. Thus, in many cases the
`user had to perform additional operations in order to make
`use of voice and FAX transmissions. The method of the
`present invention eliminates any such need for delay coma
`plications in order to handle telephone and FAX transmis-
`sion. Further, the present
`invention provides a means for
`communication between multi-users, together with a simpler
`and more expanded method for sending data to different
`types of appliances operating under different protocols. This
`is handled by the server 15, which provides specialized
`techniques, as will be discussed hereinafter.
`Referring now to FIG. 2, a block diagram shows typical
`components of the server 15 and the software modules
`stored therein for implementing the method of the present
`invention, with the database 20 coupled to the server by
`means of the lit) channel 19. The server 15 includes the
`following software modules: a database manager 26, which
`is controlled by a schema 27 and a method libraries 28;. and,
`a set ofserver processes 30 that service the various protocols
`
`45
`
`5f]
`
`55
`
`60
`
`65
`
`6
`on the network system 10. Each of these software modules
`will normally be loaded into the memory 18 from disk
`storage, or portions will remain on disk until required. Data
`is transferred from the network II] or the PSTN 22 via the
`cable 21 or 23. respectively, through the communication port
`17 and server process software 30 to the OSMOS database
`manager 26, and from there to the database 20 via the NO
`channel 19. The CPU 16 executes instructions from the
`software modules using data from the communication port
`17 or the database 20 for storing or retrieving the virtual files
`in accordance with the method of the present invention as
`described in greater detail hereinbelow.
`The database 20 provides an electronically stored collec-
`tion of objects, such as document components (text, inter—
`document links, acees»; rules), IVR components (call flows,
`voice prompts), multimedia components (audio, graphics,
`video) and message components (folders, news-groups,
`articles, e-mail messages). The database 20 is managed by
`the database manager 26, which comprises software that
`allows a user to manage multiple data files. In the present
`embodiment, the manager 26 is an object-relational database
`management system referred to herein sometimes as
`()SMOS, which is a software product available from the
`assignee hereof. OSMOS uses an object-relational model to
`provide its services and interfaces. Object~relational data
`base systems combine the advantages of compatibility with
`the standard relational database model with the productivity
`advantages of object technology. It is noted, however, that
`other object databases will work satisfactorily with the
`present invention.
`The OSMDS database manager 26 software enables data—
`base management capability for traditional programming
`languages, such as COBOL, BASIC, C and C++, and
`enables the storage and retrieval of data from the database 2|]
`as will be described further hereinafter. The operational
`functioning of the OSMOS database manager 26 is handled
`by a schema 27 and a set of method libraries 28. More
`particularly, as will be amplified further hereinbelow the
`schema 27 mimics a file system so as to create a Virtual File
`system that employs the categoriration established by the
`MIME standard. The term Virtual File as used herein refers
`to the fact that files stored in the database 2|] are an image
`of real files stored in one of the clients ll-14 coupled to the
`network system 10. Virtual Files are stored in the database
`as one or more objects with the attributes (creation date,
`security, etc.) and contents (a stream of bytes) supported by
`operations within the database, which allows them to be
`manipulated in a variety of ways.
`There are several advantages of the Virtual Iiile abstrac-
`tion. For example, as a series of database objects, a Virtual
`File can possess additional information that a system—level
`file cannot. That is, the database can record more detailed
`information on the file’s type, enforce greater security
`control and automatically manage versions. As an abstract
`object, a Virtual liile’s content can be represented in a large
`number of ways. Content can be stored as a stream of bytes,
`just
`like that for normal
`files; modeled as a network of
`semantic objects; synthesized on the fly from dynamic
`parameters, and so forth. As a database object a Virtual File
`can possess encapsulated behavior which is used to process
`the file {update it, retrieve it, display it, delete it, etc.) As a
`resident on the database 20, a Virtual File can be backed-up,
`recovered and otherwise administered with content objects
`using a common set of tools and procedures. Although
`Virtual Files are stored as abstract objects, their basis on the
`well-known lile paradigm allows them to be easily acces-
`sible via fileoriented protocols, such as FTP and HTTP, etc.
`
`UA-1010.014
`
`UA-1010.014
`
`

`

`5,864,870
`
`7
`It is noted that a specific protocol is used as a means for
`accessing the server 15‘, and, theoretically any format can be
`transmitted by use of any protocol. The server process
`software 30 performs the function of servicing the various
`protocols received by, or transmitted from, the server. This
`technique is well known in the art and will not be amplified
`further.
`Referring now to FIG. 3, an illustration of a look-up table
`for deciphering files that are to be loaded into the database
`in accordance with the MIME standard is shown. Each tile
`received by the server is accompanied by a designation of
`the MIME type of its content, which describes the data
`contained in the body of the file. This description of the data
`is sufficient enough for the receiver to process or store the
`data in an appropriate manner. The table of FIG. 3 represents
`the result of an initialization process of the database 20 in
`accordance with the present invention. That is, the disk is
`pre-populaled with objects for
`the MIME types and
`subtypes, as well as for file extensions, with known stan-
`dards {both de-facto and dejure). It is noted that the terms
`type and class are used interchangeably to mean the same
`thing, and in a like manner the corresponding terms subtype
`and subclass are used interchangeably.
`In general, a MIME file 37 points to a MIME subtype 38,
`and MIME subtype is linked to one or more file extensions
`39. Also, the MIME subtype is linked to a MIME type 40.
`Aconvenrion used in the drawings is a double headed arrow
`for denoting the pointing to a multiplicity of objects. It is
`noted that every object stored in the database 20 that has
`content will include an identification of its particular MIME
`subtype.
`The MIME standard defines seven MIME types and at
`least twenty-om: MIME-subtypes. As shown in FIG. 3, the
`seven content types are illustrated in the right—hand column
`by blocks 41—47. A ponion of the content subtypes are
`illustrated in the center column by blocks 59—NN. 'lhc file
`name also includes a file extension. which is set oif by a
`period (.) and a partial listing thereof is illustrated in the
`left-hand column by blocks till—MM.
`The block 41 represents Text, which covers a stream of
`"printable" characters, usually in the ASCII format. A pri-
`mary subtype is Plain Text, which is represented by block
`51, and is shown linked to the Text block 41. That is, in the
`vernacular of Object Technology, the Plain Text 51 subtype
`has a relationship with the Text
`type 41. The block 42.
`represents Audio covering audio data, which requires an
`audio device to "display” the contents thereof. The block 43
`represents a Message category, which covers an encapsu-
`lated message. The primary subtype for Message is RFC 822
`(block 53), which is a Request For Comment defining the
`Internet standard format for electronic mail message head-
`ers.
`
`The block 44 represents an Image category, which covers
`image data. Image data requires a display device (such as a
`graphical display, a printer, or a FAX machine) to View the
`information. The subtypes for this type are GIF (block 54),
`an XBM category (block 55) and a JPEG category (block
`NN). The GIF category covers graphics stored in the GIF
`format. The XBM category covers an X BitMap format,
`which is a common format used for storing graphical
`information. The JPEG category is a common format for
`storing compressed graphical files. The block 45 represents
`an Application category, which covers some other type of
`data, typically either uninterrupted binary data or informa-
`tion to be processed by a mail-based application. A primary
`subtype, "octet-stream", is to be used in the case of unin-
`terrupted binary data.
`
`it]
`
`15
`
`3f]
`
`35
`
`40
`
`45
`
`5f]
`
`55
`
`60
`
`05
`
`8
`The block 46 represents the Mulli-Fart c