I ||l|| llllllll Ill IIHI llfll Illll Illll lllll lllll lllll lllll Ilflll III II!!! llll
`USUUSfiBEflMA
`
`United States Patent
`
`:19}
`
`{'5 :1 Patent Number:
`
`5,530,235
`
`St_efik_et a].
`
`
`
`{54]
`
`[751
`
`INTERACTIVE CONTENTS REVEALIM}
`STDRAGE DEVICE
`
`SJSEfiU-t'
`
`3.“!993 Airinm {3:1}.
`
`--
`
`OTHER PUBLICATIONS
`
`invcmors: Mark J. Slefik, Woodside; Danie! (3:.
`Hebrew. Pals Alto; Stuart K. (hard,
`L95 Aims; Michaiem: M. Casey.
`Morgan 113.13.; Richard .I. Gaidstein,
`Sim Francism. :11} of Caiifi; Micbaei G.
`Lamina, Cambridge. England: Jack
`I). Mackiniag. San Jess. Calif; Roy
`Wani, Monnmn View, Calitl: Gum-go
`G. Robertsnm F0330! Ciiy. Calif;
`Mark D. Weiser; Danie} M. Russell.
`[:1th of Pale Alto. Cam.
`
`Assignce: Xerox Corporatiml. Sulmiorri. Conn.
`
`App}. No: 389,670
`
`Filed:
`
`Feb. 16, 1995
`
`Int. CL"
`601% 19x06
`. .........
`(LS. Ci.
`.. 235M932; 235:380, HEX-18?
`
`Field of Search ..................................... 235880. 487.
`13512193
`
`References Cited
`
`US. PATENT DOCUMENTS
`
`Robinsen. 15.1., ”Redefining Mobitc Cornpu1ing,"PC €0va
`paging, m. 1993. pp. 233~240. 247-243. and 252.
`Abadi, M Burrow. M.. Kaufmam C. and Lamgamn. 1:}.
`“Authentication
`and Deiegafion with
`Sirimmcards.“
`Research Regan DEC Sysiams Researrh Gamer. 1990.
`
`Primary Examw--------Harold Pm.»-
`Arming}: Agent. w FEm--——Richzard B. Domingn
`
`5?}
`
`A BSTRACT
`
`A Document. Card {I'Xicquai} for staring decmmnm and
`which is samurai mvealing. The Ducqui is :2 trampcnabie
`unit having a mmvalatiic storage means I'm storing infer
`makion in a digita} farm, a centre! pmmssm it}? maessmg
`use: initialed funcljonsz an 1/0 pan fer ixlzcri’acing £0 mum'-
`raal devices Fur reading and wriling digit/1} ini‘ormaiéon. am!
`a user interfau: {hr a‘niuwing :1 user to fiia‘ccziy imam with
`me. DracuCarrl. Tm. usar huerfacc an the DocuCard inckudcs.
`a display for dismayiug lists 0f functions and documents. and
`informant-n responsive: L0 use: invoked i'ufictifims em} :1 user
`inpua portim‘.
`fur ramming a user E0 {ravei'sc the lists of
`funci'tuns and ducumems. as wcfé as information generated
`rcspnnstvc m an invoked finwtican The comm} pmccswr of
`m: prcsEnL invention 1' ncludc features {Or cummiling access
`10 dacumems stored therein.
`
`fifriflifil
`93,863.}?6
`
`.................................... 23:3!33U
`9:19:56 Pauim'
`9"1959 Lessin ma]
`.. 2353-193
`
`23 Claims“, 10 Drawing Sheets
`
`
`
`SAMSUNG-1054
`
`SAMSUNG-1054
`
`

`

`US. Patent
`
`Jun. 25, 1996
`
`Sheet 1 of 10
`
`5,530,235
`
`203
`
`Storage
`Subsystem
`
`External
`Interface
`202
`
`Controller
`Module
`201
`
`Fig. 2
`
`2
`
`

`

`US. Patent
`
`Jun. 25, 1996
`
`Sheet 2 of 10
`
`5,530,235
`
`301
`
`302
`
`303
`
`304
`
`305
`
`306
`
`307
`
`Docucard and Repository
`initiate Registration
`Transactions
`
`
`
`Docucard I User
`Perform Login
`Transactions
`
`User Assi ns Payment
`0 Fees
`
`User Selects Desired
`Function
`
`User Selects Desired
`Document
`
`
`
`User Indicates
`Destination for
`Desired Document
`
`Confirmation
`
`Transaction
`
`Fig. 3
`
`3
`
`

`

`US. Patent
`
`Jun. 25, 1996
`
`Sheet 3 of 10
`
`5,530,235
`
`0
`
`20.000
`
`40.000
`
`60.000
`
`80.000
`
`
`
`Fig. 4
`
`Identifier 501
`
`Starting Address 502
`
`K500
`
`Rights Portion 504
`
`Parent Pointer 505
`
`
`
`
`Child Pointer 506
`
`I'll
`
`Child Pointer 506
`
`Fig. 5a
`
`4
`
`

`

`US. Patent
`
`Jun. 25,1996
`
`Sheet 4 of 10
`
`5,530,235
`
`
`
`Fig. 5b
`
`611
`
`601
`
`5
`
`

`

`US. Patent
`
`Jun. 25, 1996
`
`Sheet 5 of 10
`
`5,530,235
`
`701
`
`702
`
`703
`
`E Home Files
`
`D 0p Plan 1994
`
`$
`
`.
`Hugh Fee
`
`Usin a segmented
`
`disp ay to show a
`
`folder.
`
`U_sin a segmented
`dlsp any to show a
`
`document.
`
`Usin a segmented
`disp any to show a
`-Warning about a
`high fee.
`
`Fig. 7
`
`
`
`6
`
`

`

`US. Patent
`
`Jun. 25, 1996
`
`Sheet 6 of 10
`
`5,530,235
`
` 9
`
`Fig.
`
`
`
`.109Fl
`
`7
`
`

`

`US. Patent
`
`Jun. 25, 1996
`
`Sheet 7 of 10
`
`5,530,235
`
`D4”FILE
`
`COPY LOAN
`
`[> CREDIT
`
`
`
`D OTHER D HELP
`
`Fig. 12
`
`9411/15/14];1/1/1111]!
`
`
` /'//4r///////,y/////
`Delete
`New Directory
`
`
`DOTHER D HELP
`
`Fig. 13
`
`8
`
`

`

`US. Patent
`
`Jun. 25, 1996
`
`Sheet 8 of 10
`
`5,530,235
`
`SELECT REPOSITORY
`CONTAINING DOCUMENT
`
`1401
`
`
`
`
`1402
` FIND DIRECTORY
`
`CONTAINING DOCUMENT
`
`
`
`1403
`
`
`
`SEARCH DIRECTORY
`FOR DOCUMENT
`
`
`
`1404
`
`
`
`DOCUMENT
`
`FOUND?
`
`
`
`
`PRESS "SELECT" KEY TO
`VERIFY SELECTION
`
`1405
`
`Fig. 14
`
`9
`
`

`

`US. Patent
`
`Jun. 25, 1996
`
`Sheet 9 of 10
`
`5,530,235
`
`COPY FROM
`
`I THERE (MaryP. Smith)
`
`Vii/3575?
`am” (John 5. Brown)
`
`Fig. 15
`
`if BCDEFGHIJKLMNO
`
`. Hamlet Essay
`
`Aaron's Work
`
`Fig. 1 6
`
`3;: BCDEFGHIJKLMNO
`I] Annual Plan
`
`6/6/94 530K
`
`Fig. 1 7
`
`:3 BCDEFGHIJKLMNO
`
`Text so Fa {g
`
`PQRSTUVWXYZ_ D
`
`Fig. 18
`
`10
`10
`
`

`

`US. Patent
`
`Jun. 25, 1996
`
`Sheet 10 of 10
`
`5,530,235
`
`JKLNEOPQRSTUV
`E Nighttlime Reading
`
`Select FOLDER
`
`Fig. 1 9
`
`
`I I Ill/I
`
`
` CANCEL |>INFo
`4/, -”
`$1
`0/11},ng
`
`IE Atlantic June 1994
`
`
`E Nighttime Reading
`
`
`
`Fig.20
`
`”,2?
`
`$1
`
`CANCEL [>INFo
`
`Nighttime Reading
`
`Atlantic June 1994
`
`Fig.21
`
`11
`11
`
`

`

`1
`INTERACTIVE CONTENTS REVEALING
`STORAGE DEVICE
`
`FIELD OF THE INVENTION
`
`The present invention relates generally to the field of
`storage mediums, and in particular to transportable storage
`mediums for storing and retrieving documents.
`
`BACKGROUND OF THE INVENTION
`
`Digitally created works. for example music or software,
`are commonly distributed on a transportable storage medium
`such as an optically or magnetically encoded disk. Means for
`retrieving and interpreting the contents of the transportable
`storage medium are typically embodied in a playingfrcnder-
`ing device, c.g. a computer system or a Compact Disc
`Player. While such distribution of digital works is common,
`it is not idea]. A deficiency oftransportablc storage mediums
`is that they are not contents revealing. That is, the contents
`of the storage medium cannot be determined by merely
`looking at the storage medium. An example of a contents
`revealing storage medium is paper. Absent any encoding. by
`simply looking at the paper, its contents can be determined.
`A simple wayr of identifying the contents of storage
`mediums, e.g. an cptical or magnetic disk,
`is to sflix a
`written label to the medium. Unfornmately, every time the
`disk is reused, the label must be updated or a new label
`created and and attached. It requires diligence to relahel
`floppy disks as they are used. Moreover. as storage capacity
`increases, a label big enough to list the entire contents may
`become impractical. In the case of optical disk medium,
`content information is typically printed onto the medium
`itself. This is satisfactory for the current state of optical disk
`technology since such disks typically cannot be reused.
`However, writeahle optical disk products are now available.
`Such products will cause optical disks to have the same
`deficiencies as other storage mediums. Absent a label, the
`only way of verifying the contents of a transportable storage
`medium is to insert it into a suitable playingl'rendcring
`device and invoke commands to list the contents.
`
`It is anticipated that the distribution of works in digital
`form will increase dramatically. For conservation and con-
`venience reasons, it would be desirable to collect desired
`works on a personal transportable storage medium which is
`inherently contents revealing. Further, it would be desirable
`to perform basic storage management functions. such as
`deleting a file or organizing the content of the storage
`medium, without having to insert the storage medium into a
`playinglrendering device. This would enable a user to “make
`room” or organize the contents of the storage medium when
`necessary.
`
`A technology which is related to the present invention is
`in the area of "smartcards". Smartcards are generally imple—
`mented to increase the convenience of perforating various
`transactions, e.g. financial transactions. An example appli-
`cation of a smartcard would be as a smart financial services
`card. In such an application, the smartcard could provide
`Automatic Teller Machine (ATM) access as well as perform
`functions such as limiting the AWS at which the card could
`be used and maintaining a record of ATM transactions. U.S.
`Pat No. 4,868,376 to Lessin et al. entitled “Intelligent
`Portable Interactive Personal Data System" describes a
`smartch having an alphanumeric keypad for uscriuput, an
`alphanumeric display for displaying the results of various
`commands. a microprocessor, an operating system for con-
`trolling tlre smartcard. storage for storing one or more
`
`5,530,235
`
`2
`
`application programs and an Inputl'Output port for sending
`and receiving information. The smartcard described in
`Lessin et a]. can be programmed for specific applications.
`As noted above, smancards have a focus that is primarily
`on enabling andlor recording certain transactions. As a
`result, their storage requirements are fairly modest. KnoWn
`smartcard implementations are inadequate for use as a
`transportable storage medium due to their limited storage
`capacities.
`
`A further related technology is for Personal Digital Assis-
`tants (PDAs), such as the Newton (TM) FDA, available
`from Apple Computer, Inc. of Copertino, Calif. PDAs are
`typically portable computer systems, often characterized as
`having a “pen“ based input device. PDAs are typically
`distributed with packages which perform various personal
`organization (cg. calendaring, address book) and commu-
`nication (cg. messaging) functions. Alternatively. PDAs can
`be programmed to perform desired applications.
`Another related technology area is hardcards. Hardcards
`are storage medium such as a hard disk which is coupled to
`and packaged with a storage controller (rather than having
`separate controller and hard disk devices)- The hardcard is
`then coupled to the computer system. Hardcards are typi-
`cally used as a ‘pcmanent" storage medium which remains
`coupled to the computer system and are not meant to be
`transportable Further, hardcards are not contents revealing.
`SUMMARY OF THE INVENTION
`
`A Document Card (hereinafter referred to as DocuCard) is
`disclosed. The DecuCard performs the function of a storage
`medium whose contents can be viewed and managed
`autonomously from a computer based system. In the cur-
`rently preferred embodiment of the present invention, the
`DocuCard is a transportable unit having a nonvolatile stor-
`age means for storing information in a digital form; a control
`processor
`for processing user
`initiated functions and
`requests to access documents stored therein; an U0 port for
`interfacing to external devices for reading and writing digital
`information. and a user interface for allowing a user to
`direclly interact with the DoeuCar-d. The user interface
`comprising a plurality of traversal keys for allowing a user
`to traverse lists of functions and documents, a select key to
`allow a user to select highlighted functions or documents, a
`processing means for processing user invoked functions. and
`a display for displaying lists of functions and documents and
`information responsive to user invoked functions.
`The currently preferred embodiment of a DocuCard is an
`instance of a repository. as defined in co-pending application
`entitled “System for Controlling the Distribution and Use of
`Digital Works". serial number not yet assigned. which is
`assigned to the assignee of the present invention and which
`is herein incorporated by reference. A repository is a device
`which enables access to documents through enforcement of
`usage rights which are attached to the documents. Usage
`rights define how and under what conditions a stored docu-
`ment may he used or distributed. For example, a user may
`request that a particular document be printed The document
`cannot be printed unless it has an attached print right. A
`condition associated with the right may be that the document
`can only be printed once.
`The user interface of the present invention enables a user
`to interact with a DocuCard to manage the contents con-
`tained therein. as well as to obtain Documents stored in other
`repositories.
`The general steps for accessing a document stored in
`another repository comprising the steps of: coupling the
`
`5
`
`It!
`
`15
`
`20
`
`30
`
`35
`
`4D
`
`45
`
`SD
`
`55
`
`65
`
`12
`12
`
`

`

`5,530,235
`
`3
`
`DocuCard to said repository; displaying on the display of the
`DocuCard a list of functions for accessing a document stored
`in the repository. each of said functions representing an
`instance of how a selected document is used, each of said
`functions corresponding to an instance of a usage right;
`selecting a function from said displayed list of functions;
`displaying on the display of said DocuCard a list of the
`contents of the repository; selecting a desired document
`from the list of contents of the repository; the repository
`determining if the desired document has said instance of a
`usage right corresponding to the selected function; if the
`desired document has altached thereto the usage right cor-
`responding to the selected function, the repository granting
`access to said document; and if the desired document does
`not have attached thereto the usage right corresponding to
`the selected function, the repository denying access to said
`document
`
`Because of the transportable nature of the DocuCard. it’s
`size will be relatively small. Accordingly, the display size
`will be limited. It is typical that all of the functions for
`accessing a document cannot be present on the display at one
`time. The present invention provides a means for traversing
`the list of available functions. What will initially be dis-
`played is a list of commonly used functions and one or more
`indicators to sub-lists of less frequently used functions. To
`find the desired function the user will: determine if the
`desired function is displayed;
`if the desired function is
`displayed, highlighting the function and selecting it: and if
`the desired function is not displayed, highlighting an indi-
`cator to subwlists of less frequently used functions, selecting
`it and repeating until the function is displayed.
`Similarly, it may not be possible to list all of the docu-
`ments stored in a repository. Documents are stored in a
`hierarchical file system and in a lexical ordering. What is
`initially displayed is an indicator of lexical position within
`the repoaitory at a current directory level and a list of
`documents. A user traverses the list using the traversal keys
`on the DocuCard until the desired Doeuruent is highlighted,
`wherein the select key is depressed.
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a perspective view of the currently preferred
`embodiment of a Document Card (DocuCard).
`FIG. 2 is a block diagram of the operational components
`of a DocuCatd.
`
`FIG. 3 is a flowchart describing the interaction betwuen a
`DocuCard and a repository in the course of accessing a
`document stored in the repository as may be performed in
`the currently preferred embodiment of the present invention.
`FIG. 4 illustrates a contents file portion of a document
`representation for a document stored on a DocuCard of the
`currently preferred embodiment of the present invention.
`FIGS. 5;: and 5b illusu'ates a description block and a
`description tree portion for the document representation of
`the contents file illustrated in FIG. 4.
`FIG. 6 is a detailed illustration of the user interaction area
`of a DocuCard in the currently prefcrred embodiment of the
`present invention.
`FIG. 7 illustrates did‘erent forms of information provided
`on a DocuCard display in the currently preferred embodi-
`ment of the present invention.
`FIGS. 8—11 illustrate various alternative embodiments of
`a user interaction area having different key arrangements.
`FIG. 12 is an illustration of the display area displaying a
`function selection interface as may be used in the murently
`preferred embodiment of the present invention.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`rs
`
`50
`
`55
`
`60
`
`65
`
`4
`FIG. 13 is an illustration of the display area when a
`function group has been selected and the user is presented
`with the particular functions within the group.
`FIG. 14 is a flowchart illustrating the steps performed for
`selection of a document or directory in the currently pre-
`ferred embodiment of the present invention.
`FIGS. 15—17 are illustrations of the display area for
`document or directory selection in the currently preferred
`embodiment of the present invention.
`FIG. 18 is an illustration of the display area for entering
`text in the currently preferred embodiment of the present
`invention.
`
`FIGS. 19—21 are illustrations of the display area for 3
`COPY function transaction as may be performed in the
`currently preferred embodiment of the present invention.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`A Document Card (hereinafter referred to as DocuCard]
`for storing digital information (documents) and which is
`mutants revealing is disclosed. A DocuCard is used for
`storing digital information which may be accessed by a
`system that is capable of playing or rendering the digital
`information, such as a computer system. digital copier, audio
`CD player and the like. Such systems are referred to herein
`collectively as rendering systems. A DocuCard is also used
`for obtaining documents from a repository of documents. An
`example of such a repository is a kiosk which is used for the
`secure distribution of documents.
`
`The utility of a DocuCard can be viewed from varied
`perspectives. From one perspective. a DocuCard is an intel-
`Iigent storage medium which enables a user to manage and
`view its contents in a standalone fashion. From a second
`perspective, the DocuCard is a secure repository of docu-
`ments. A DocuCard implements the functionality of a
`repository as defined in the co-pending application entitled
`“System For Controlling the Distribution and Use of Digital
`Works", serial no. not yet assigned. Usage rights are
`attached to digital works and control how the digital work
`can be used or distributed. and are further used to specify
`any fees associated with use or distribution of digital works.
`When a. repository receives a request to access a digital
`work. the repository examines the usage rights attached to
`the digital works to determine if access may be granted.
`As used herein, the terms digital work and document are
`used interchangeably and refer to a work that has been
`reduced to a digital form. This would include any textual,
`audio or visual work, as well as to software programs.
`
`Overview of a Physical Design of a DocuCard
`
`FIG. 1 is a perspective view of the currently preferred
`embodiment of a DoeuCard. The DocuCard of the present
`invention is preferably implemented in accordance with
`standards promulgated by the Personal Computer Memory
`Card International Association (PCMCIA) of Sunnyvale,
`Calif. However. it would be apparent to one of skill in the
`art to implement the present invention having features
`different from the PCMCM standard without departing from
`the spirit and scope of the present invention. In any event,
`the PCMCLA has defined an open standard for personal
`computer cards intended for use with portable computer
`systems. The standard can be used on any personal computer
`system supporting bus structures such as the Industry Stan-
`dard Architecture (ISA) or Extended Industry Standard
`
`13
`13
`
`

`

`5.530.235
`
`5
`Architecture (EISA). PCMCIA cards are desirable because
`of their small size and support for plug and play applications
`(which means that the computer system will automatically
`recognize insertion of a card in a slot and enable its use).
`Utilization of such plug and play applications does require
`Basic InputIOutput System (BIOS) and operating system
`level software coding. Specifications for designing products
`for support of PCMCIA cards and creating the requisite
`BIOS and operating system level software is available from
`the PCMCIAHeadquarters. located in Sunnyvale Calif.
`Thus. no further discussion of PCMCIA and the attendant
`standards is deemed necessary.
`Physically, the DocuCard is included in a housing 101 that
`is compliant with PCMCIA Type I] or III standards. The
`physical dimensions of PCMCIA Type II or 111 compliant
`cards are 85.6 millimeters long. 54 millimeters wide with a
`thickness of 5.0 or 10.5 millimeters, respond vely. The choice
`of Type II or 111 will depend on the desired storage capacity.
`The length and width are roughly the sire of a credit card
`which makes it easily transportable. The PCMCIA standard
`further defines a signal protocol for communication between
`a PCMCIA device and a computer based system Such
`communication is carried out through pins 102. On a “top"
`side of the currently preferred embodiment a usur interaction
`area 103 is defined. The user interaction is comprised of a
`display. a plurality of buttons for scrolling. selection and
`entry of alphanumta-ic data and speaker for output of audio
`information. The user interaction area 103 of the currently
`preferred embodiment is described below with reference to
`FIG. 6.
`
`the DocuCard are
`components of
`The operational
`described with reference to FIG. 2. Referring to FIG. 2. a
`controller module 201 provides the overall control function
`for the DocuCard. The controller module 201 may be
`implemented using a suitable controller integrated circuit
`chip (or chipset) such as a Motorola 6808 {available from
`Motorola Corporation of Chicago. Ill.) or an Intel 8051
`(available from Intel Corporation of Santa Clara. Calif). The
`controller module 201 may also be implemented using a
`general purpose microprocessor such as one of the members
`of the Intel X86 family of microprocessors. The controller
`module 201 further comprises a time keeping means or
`clock for maintaining a timebase for documents stored
`therein and an internal memory means (e.g. a Read Only
`Memory or ROM}. The internal memory means contains
`programming instructions needed for carrying out the vari-
`ous DocuCard functions that are described herein.
`
`The controller module 201 performs traditional disk con-
`troller functions (e.g. storage management, formatting. etc.)
`as well as processing in response to user initiated functions.
`Such user initiated functions will be described in fiirther
`detail below. The controller module 201 may also beused to
`perform additional functions as needed. such as data encryp
`tionldeeryption.
`or
`data
`compressionldecompression.
`Finally. the controller module 201 enforces usage tights
`attached lo documents. initiation of usage fee transactions,
`and controls the DocuCard User Interface.
`An external interface 202 enables the DocuCard to be in
`communications with another repository or to a rendering
`system. Communications to external system in the currently
`preferred embodiment is through well known networking
`protocols. However, the protocol by which documents are
`stored and accessed are transport layer independent. So for
`example. the Docch may look to the coupled computer
`system as if it were networked attached via aTCPlIP session
`while the actual exchange of documents may be enabled
`using a higher level protocol.
`
`10
`
`15
`
`2t]
`
`30
`
`35
`
`45
`
`50
`
`55
`
`65
`
`14
`14
`
`6
`
`The controller 201 manages access to storage subsystem
`203. The storage subsystem 203 is comprised of two distinct
`parts. A first part residing on a low power nonvolatile solid
`state memory will contain the directory structure for the
`storage system. Use of a low power solid state memory in
`part enables the performance of the standalone finrctions
`under battery power of a DocuCai'd that are described
`herein. The directory structure would include the description
`file. which is described in greater detail below, for each of
`the documents stored in the DoctrCard. The first part is
`readily accessible to the controller 201 to facilitate quick
`display of the DocuCard directory on the DocuCard display.
`A second part resides on a high capacity storage medium and
`will contain the digitally encoded contents of each of the
`documents. Suitable high capacity storage mediums would
`be magnetic or optical disks or a nonvolatile solid state
`memory. Partitioning of the data in this manner reduces
`memory and power requirements for viewing the contents of
`the DocuCard when operating in standalone mode. The
`manner in which documents are organized in the currently
`prefen'ed embodiment is described in more detail below.
`Although not illustrated, a DocuCard may also have
`stored within it a credit server for reporting usage fees that
`are associated with the access to a document.
`
`The list of operational components described herein is not
`meant to be exhauslive. DocuCards will typically be imple-
`mented in accordance with the desired functionality and the
`type of documents that it will support.
`
`DocuCard Coupling
`
`The repositories and rendering systems to which a Docu-
`Card may interface would fulfill the functional requirements
`as defined in the aforementioned “System For Controlling
`The Distribution and Use of Digital Works" application. For
`a direct coupling, the repository or rendering system would
`typically have at least one PCMCIA compliant slot. So for
`the electrical connection to occur, the DocuCard is merely
`inserted into the PCMCIA slot.
`
`Further, as mention above. a DocuCar-d may also couple
`to another DocuCard. Such coupling would occur via a
`mating interface device which would electrically connect the
`PCMCIA external interfaces of the respective DocuCards.
`FIG. 3 is a flowchart describing the interaction between a
`DocuCard and a repository in the course of accessing a
`document stored in the repository. Refcn'ing to FIG. 3. the
`DecuCard and repository initiate registration transactions.
`step 301. Registration is a process by which two repositories
`establish a secure and trusted session. By secure and trusted
`it is meant that the session is reasonably safe from intrusion
`and that the respective repositories have established them
`selves as bone tide (is. not an intruder). The registration
`process is automatic and is triggered by the establishment of
`Ihe electrical connection between the DocuCard and reposi-
`tory. The steps performed during registration as may be used
`in the currently preferred embodiment is described in the
`aforementioned co~pending application entitled “System For
`Controlling the Distribution and Use of Digital Works."
`Following the registration oansaction. a Login transaction
`is performed. step 302. A Login transaction is the process by
`which a user logs onto a repository. typically by entering a
`Personal Identification Number (PIN). In this case, the user
`of the DocuCard is logging onto the DocttCard. This logging
`in process may also activate credit accounts.
`The user on the DocuCard new uses the user interface to
`assign payment of any fees associated with the transaction to
`
`

`

`5,530,235
`
`7
`be executed, step 303. The fees may be assigned to either the
`user of the DocuCard or to the owner of the repository. Of
`course the acceptance of fees by the repository may be a
`prerequisite to the continuation of the process.
`Now. the user of the DocuCard selects the desired func-
`tion for obtaining the document. step 304. The particular
`function will correspond to a particular usage right and
`indicates how the user wishes to use the document. A list of
`available documents on the repository is then presented
`wherein the user selects the desired document. step 305 and
`the destination where the document is to be placed, step 306.
`The DocuCard will then present the transaction for confir-
`mation. step 307 where it can be confirmed or rejected.
`The steps for selection of documents and functions is part
`of the user interface of the present invention and are
`described in greater detail below.
`
`Organization and Representation of Documents In
`A DocuCard
`
`In the currently preferred embodiment, documents are
`stored in a hierarchical file system. Organization of docu-
`ments in a hierarchical file system is well known in the art
`but is briefly described herein. Documents are stored within
`directories. Directories and subdirectories are comprised of
`a collection of documents andlor subdirectories. The con-
`tents of a directory or subdirectory are organized for display
`in alphabetical order. Documents will have types for iden-
`tifying document properties. It is worth noting that it would
`be apparent to one skilled in the an to store digital data in
`other types of organizational snucnrres, e.g. hyper-linked or
`as a flat directory.
`Implementations incorporating other
`organizational structures would not depart from the spirit
`and scope of the present invention.
`The file information for a document is comprised of a
`“contents file" and a "description file." The contents file is
`stored independently from the description file. The “con-
`tents" file is a stream of addressable bytes whose format
`depends completely on the computer based system used to
`play. display or print the document. The description file
`contains the usage rights for the document and a pointer to
`the document in the content part. For composite documents
`comprised of multiple individual digital works. the descrip-
`Lion part is an acyclic structure [e.g. a tree structure) wherein
`each node corresponds to one or more of the multiple
`individual digital works.
`FIG. 4 illustrates the layout of a contents file. Referring to
`FIG. 4, a digital work 409 is comprised of story A 410,
`advertisement 411. story B 412 and story C 413. It is
`assumed that the digital work is stored starting at a relative
`address of 0. Each of the parts of the digital work are stored
`linearly so that story A 410 is stored at approximately
`addresses
`(It—30.000,
`advertisement 411
`at
`addresses
`30301—40300. story 13 412 at addresses 40001—60000 and
`story C 413 at addresses 60.001—85 1C Note that the data in
`the contents file may be compressed (for saving storage) or
`encrypted (for security).
`From FIG. 4 it is readily observed that a digital work can
`be represented by its component pans as a hierarchy. The
`description tree for a digital work is comprised of a set of
`related descriptor blocks (d-blocks). The contents of each
`d-block is described with respect to FIG. 5a. Referring to
`FIG. 5a, a d—block 500 includes an identifier 501 which is a
`unique identifier for the work in the repository, a starting
`address 502 providing the start address of the first byte of the
`work, a length 503 giving the number of bytes in the work.
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`I15
`
`50
`
`53
`
`65
`
`a rights portion 504 wherein the granted usage rights and
`their status data are maintained, a parent pointer 505 for
`pointing to a parent d-block and child pointers 506 for
`pointing to the child d-blocks In the currently preferred
`embodiment, the identifier 501 has two parts. The first part
`is a unique number assigned to the DocuCard upon manu—
`facture. The second part is a unique number assigned to the
`work upon creation. The rights portion 504 will contain a
`data structure, such as a look-up table, wherein the various
`information associated with a right is maintained. The
`information required by the respective usage rights is
`described in more detail below. D—bloeks form a strict
`hierarchy. The top d-block of a work has no parent; all other
`d-blocks have one parent.
`Each d-block may further contain a document thumbnail
`or a pointer to a document thumbnail. The document thumb-
`nail
`is a fixed representation of the document. In some
`instances the document thumbnail is atextual description. in
`other instances the document thumbnail is pictorial repre-
`sentation (for documents comprised of video data,
`the
`thumbnail could he one or more video frames) or an audio
`clip (for documents comprised of audio information}. In any
`event, the thumbnail will convey the essence of the content
`of the corresponding doeumenL It should be noted that each
`of the subdoeuments has associated with it a thumbnail.
`However, it would be apparent to one skilled in the art to
`only provide a thumbnail for the main document. Further, it
`should be noted that visual thumbnails would preferably be
`stored in some compressed image format (e.g. MPEG. IPEG
`or run—length encoded). Accordingly,
`the display of the
`thumbnail would require that the DocuCard display have at
`least a portion of which is bit-mapped.
`FIG. 5!: illustrates a description tree for the digital work
`of FIG. 4. Referring to FIG. Sb, a top d-block 5% for the
`digital work points to the various stories and advertisements
`contained therein. Here,
`the top dblock 520 points to
`d-bloek 521 {representing story A r110), d-bloek 522 (rep-
`resenting the advertisement 411). d—bloek 523 (representing
`story B 412) and and dnblock 524 [representing story C 413).
`
`DocuCard User Interface
`
`The user interface enables a user to direct the DocuCard
`to access documents stored in a repository and to manage the
`contents of the DocuCard. The user interface is comprised of
`a plurality of switches for entering input. a display for
`presenting information and predetermined and programmed
`sequences of steps for carrying out the various operations.
`FIG. 6 illustrates in greater detail the user interaction area
`for a DocuCard in the currently preferred embodiment.
`Referring to FIG. 6, the user interaction