United States Patent
`Stefik et al.
`
`[19]
`
`[11] Patent Number:
`[45] Date of Patent:
`
`5,530,235
`Jun. 25, 1996
`
`IlllllllllllllIllIlllllllllllllllllllllllllllllllllllllllllllllllllllllllll
`USO05530235A
`
`INTERACTIVE CONTENTS REVEALING
`STORAGE DEVICE
`
`5,183,404
`
`2/1993 Aldous et al.
`............................ 439/55
`OTHER PUBLICATIONS
`
`[54]
`
`[75]
`
`Inventors: Mark J. Stefik, Woodside; Daniel G.
`B0br0w,Pa10 Alto; Stuart K- Card,
`Los A1tos;Michalene M- Casey,
`Mmgan Ht“; Richard -1- Goldstetttv
`St’-It Fr3nCt5C°v 311 0f Calif-9 Michael G-
`Lamming, Cambridge, England; Jock
`D. Mackinlay, San Jose, Calif.; Roy
`want, Mountajn View, Cajifi; George
`G. Robertson, Foster Cit , Ca1if.;
`Mark D. Weiser; DanielyM. Russell,
`both Of P810 Alto, Calif.
`
`.
`[73] Asstgfleei Xerox C01'P01‘3ti011a Stamford: C0Y1n-
`
`[21] Appl. No.2 389,670
`
`Feb’ 16’ 1995
`[22] Filed:
`[51]
`Int. c1.s ..................................................... coax 19/06
`[52] U.S. Cl. ........................... 235/492; 235/330; 235/487
`[58] Field of Search ............................ 235/380 487
`235/492
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`9/1986 Paulov .................................... 235/380
`9/1989 Lessin et al.
`......................... .. 235/492
`
`4,614,861
`4,868,376
`
`Robinson, E. J., “Redefining Mobile Computing,” PC Cam-
`puting, Jul., 1993, pp. 233-240, 247-248, and 252.
`Abadi, M., Burrows, M., Kaufman, c., and Lampson, 13.,
`“Authentication
`and Delegation with
`Smart—cards,”
`Research Report DEC Systems Research Center, 1990.
`
`Primary Ex“mt”9""HaT0td Pitts
`Attorney, Agent, or Firm—Richard B. Domingo
`[57]
`ABSTRACT
`A Document Card (DocuCard) for storing documents and
`which is content revealing. The DocuCard is a transportable
`unit having a nonvolatile storage means for storing infor-
`mation in a digital form, a control processor for processing
`user initiated functions; an I/O port for interfacing to exter-
`nal devices for reading and writing digital information, and
`a user interface for allowing a user to directly interact with
`the DocuCard- The user interface on the Docucard includes
`3 display fsr displaying lists of funstisns and documents and
`i“t°”“ati°“ ‘eSP°“SiV‘* t” “S” i“V°k“d t““°“°“5 and a “S”
`input portion for allowing a user to traverse the lists of
`functions and documents, as well as information generated
`responsive to an invoked function. The control processor of
`the present invention include features for controlling access
`to documents stored therein.
`
`23 Claims, 10 Drawing Sheets
`
`Apple Exhibit 1012
`
`Page 00001
`
`9 o
`
`rator):
`
`o~r‘o‘a‘I‘o‘o‘o‘I‘a‘I‘I‘I~o‘I\I‘I
`ssssssssssss‘35‘5*3‘?:‘:‘:‘:‘3‘$‘:‘$‘:‘3‘os\\s\\s\s\sss\\u
`sss\s\s~ssss:\:\:\:\:s:\'u's’s’\'9's'ssssusssssssssssss“‘I‘l‘lOPOlf0‘o‘o‘o‘¢vIoI1r11o ‘gar;‘:‘3‘$‘opasssss\s"s"’
`Aoootooooaooaoarooro‘o‘o‘r‘o‘o‘o‘o‘o‘p‘o‘:‘o‘:‘o‘o‘o‘r‘o
`o
`c\‘I
`t
`l‘I‘0.59.:I4‘I‘o‘r‘I~o‘r‘orrIs,\,s,\,ssss
`0‘: \:\'\'s,5‘;c-5\s s\
`\ s s ‘o
`sI
`a 4 o I5
`o
`'5
`
`K;ss‘ss
`‘I
`\'\’«gs,\\
`
`9,5ss\ssus
`‘sI'\\
`‘s’-’\
`\:\"5us
`
`unanno-u
`
`oooouooou
`
`nnonoocoo
`
`anon-c-an
`
`
`
`Apple Exhibit 1012
`Page 00001
`
`

`
`U.S Patent
`
`Jun. 25, 1996
`
`Sheet 1 of 10
`
`5,530,235
`
`101
`
`\s\\\\\sssI\I\OII\l|t\I\d\l\l\l
`
`External
`Interface
`202
`
`Controller
`Module
`201
`
`Storage
`Subsystem
`203
`
`Fig. 2
`
`Page 00002
`
`Page 00002
`
`
`

`
`U.S. Patent
`
`Jun. 25, 1996
`
`Sheet 2 of 10
`
`5,530,235
`
`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
`
`301
`
`302
`
`303
`
`304
`
`305
`
`306
`
`307
`
`Confirmation
`
`Transaction
`
`Fig. 3
`
`Page 00003
`
`Page 00003
`
`

`
`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
`
`500
`
`Child Pointer 506
`
`Starting Address 502
`
`Length 503
`
`Rights Portion 504
`
`Parent Pointer 505
`
`Child Pointer 506
`
`Fig. 5a
`
`Page 00004
`
`Page 00004
`
`

`
`U.S. Patent
`
`Jun. 25, 1996
`
`Sheet 4 of 10
`
`5,530,235
`
`Fig. 5b
`
`604:
`
`61 1
`
`60
`
`1
`
`\\\s\\\\\\\\\\I\\sl\\\
`\su\\\s\\\\\u\\\s\\\
`\\\§\\\\\\\\\\\§\\\\
`s\\\\\\u\\\\
`\\\x\\\\\u\ssssssss
`
`
`
`saslsos\\\\\\\\Iso\o\I\Isossoulsstsasl
`\t\l\I\l\I|I\lsI\4\I\I\IsIcI\I\I\lsO\I\I
`OIIIIIIOIIIIOIIOIIOI
`ooooloooalootoltoaoo
`
`
`raotoals\I\I\l\IIIIll
`covcoottaoooooorarvv
`
`Fig. 6
`
`Page 00005
`
`Page 00005
`
`
`

`
`U.S. Patent
`
`Jun. 25, 1996
`
`Sheet 5 of 10
`
`5,530,235
`
`701
`
`702
`
`
`
`703
`
`E Home Files
`
`[3
`
`Op Plan 1994
`
`$
`
`“Wee
`
`Fig. 7
`
`Using a segmented
`
`display to show a
`
`folder.
`
`Usin a segmented
`
`disp ay to show a
`
`document.
`
`hisinlg a segmented
`.v\'«‘..'3.f‘ai’.g‘,°ai,o‘2.‘£"a“‘
`high fee.
`
`Page 00006
`
`Page 00006
`
`

`
`U.S. Patent
`
`Jun. 25, 1996
`
`Sheet 6 of 10
`
`5,530,235
`
`««¢¢««««««saQ«¢
`
`«««««««aa««¢¢9v««««««Aae«aayyu»¢......c.......¢
`\\\s\s\\\\§\\\sl
`
`4slutsoscslsosososono\t\oso\o\o
`
`IAft0\O§7\UQO\I\I\O§l§lCI$I\l§O
`..,.¢a.o...:oo..
`\....\.....‘...
`
`Fig.
`
`.««««««..
`
`Fig. 1 0
`
`Page 00007
`
`Page 00007
`
`

`
`U.S. Patent
`
`MTW.u.u.u‘u.u.u.u.u.u.n.u.u.u.u\u.u.NMf--\\\\§\\\\\\\§\\P0....7.D...H_I.ACI.uHME%MEmmM1LHmyDHS..C.../,3UUnv2/.2wDNW1.W1.W/Mm1.HU9oR99%mNHcEim._H9HHnwwwwwwwHFflm/IE1..TWu.”eH5,HHO7/”4.TJHHDOnH”.m_HNVD
`
`595
`
`sM%0I»e0M.3P
`
`00
`
`Page 00008
`
`
`
`

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

`
`U.S. Patent
`
`Jun. 25, 1996
`
`Sheet 9 of 10
`
`5,530,235
`
`COPY FROM
`7 xx! 1/11
`//.;.,.I
`
`I TH ERE (Mary P. Smith)
`
`Fig. 15
`
`
`BCDEFGHIJKLMNO
`E Aaron's Work
`0 Hamlet Essay
`
`
`
`Fig. 1 6
`
`BCDEFGHIJKLMNO
`D Annual Plan
`
`6/6/94 530K
`
`Fig. 1 7
`
`
`
`
`
`BCDEFGHIJKLMNO
`
`PQRSTUVWXYZ_ D
`Text so Fa
`
`Fig. 18
`
`Page 00010
`
`Page 00010
`
`

`
`U.S. Patent
`
`Jun. 25, 1996
`
`Sheet 10 of 10
`
`5,530,235
`
`
`
`JI<LN@oPQRsTuv
`E Nighttlime Reading
`
`Select FOLDER
`
`Fig. 19
`
`$1
`
`CANCEL DINFO
`
`Nighttime Reading
`
`Atlantic June 1994
`
`Fig.20
`
`$1
`
`CANCEL Dmro
`
`Nighttime Reading
`
`Atlantic June 1994
`
`Fig.21
`
`Page 00011
`
`Page 00011
`
`

`
`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 playing/render-
`ing device, e.g. a computer system or a Compact Disc
`Player. While such distribution of digital works is common,
`it is not ideal. A deficiency of transportable 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 way of identifying the contents of storage
`mediums, e.g. an optical or magnetic disk,
`is to affix a
`written label to the medium. Unfortunately, every time the
`disk is reused, the label must be updated or a new label
`created and and attached. It requires diligence to relabel
`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, writeable 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 playing/rendering
`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
`playing/rendering 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 performing 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 ATMS 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
`smartcard having an alphanumeric keypad for user input, an
`alphanumeric display for displaying the results of various
`commands, a microprocessor, an operating system for con-
`trolling the smartcard, storage for storing one or more
`
`5,530,235
`
`2
`
`application programs and an Input/Output port for sending
`and receiving information. The smartcard described in
`Lessin et al. can be programmed for specific applications.
`As noted above, smartcards have a focus that is primarily
`on enabling and/or 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) PDA, available
`from Apple Computer, Inc. of Cupertino, 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 (e.g. calendering, address book) and commu-
`nication (e. g. 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 “permanent” 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 DocuCard 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 I/O port for
`interfacing to external devices for reading and writing digital
`information, and a user interface for allowing a user to
`directly interact with the DocuCard. 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 be 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
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Page 00012
`
`Page 00012
`
`

`
`3
`
`4
`
`5,530,235
`
`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 attached 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 sub-lists 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 repository 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 Document 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 DocuCard.
`
`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 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. 5a and 5b illustrates 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 preferred embodiment of the
`present invention.
`FIG. 7 illustrates different 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 currently
`preferred embodiment of the present invention.
`
`10
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`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 a
`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
`contents 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-
`ligent 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 DocuCard. 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 PCMCIA standard without departing from
`the spirit and scope of the present invention. In any event,
`the PCMCIA 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
`
`Page 00013
`
`Page 00013
`
`

`
`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 Input/Output 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 PCMCIA Headquarters,
`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 II or III standards. The
`physical dimensions of PCMCIA Type II or III compliant
`cards are 85.6 millimeters long, 54 millimeters wide with a
`thickness of 5.0 or 10.5 millimeters, respectively. The choice
`of Type II or III will depend on the desired storage capacity.
`The length and width are roughly the size 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 user interaction
`area 103 is defined. The user interaction is comprised of a
`display, a plurality of buttons for scrolling, selection and
`entry of alphanumeric 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
`The operational components of
`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, 111.) 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 further
`detail below. The controller module 201 may also be used to
`perform additional functions as needed, such as data encryp-
`tionldecryption,
`or
`data
`compression/decompression.
`Finally,
`the controller module 201 enforces usage rights
`attached to 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 DocuCard may look to the coupled computer
`system as if it were networked attached via a TCP/JP session
`while the actual exchange of documents may be enabled
`using a higher level protocol.
`
`10
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`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 functions
`under battery power of a DocuCard 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 DocuCard. 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
`preferred 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 exhaustive. 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 mentioned above, a DocuCard 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 anti a repository in the course of accessing a
`document stored in the repository. Referring to FIG. 3, the
`DocuCard 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 bona fide (i.e. not an intruder). The registration
`process is automatic and is triggered by the establishment of
`the 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 transaction, 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 DocuCard. This logging
`in process may also activate credit accounts.
`The user on the DocuCard now uses the user interface to
`assign payment of any fees associated with the transaction to
`
`Page 00014
`
`Page 00014
`
`

`
`7
`
`8
`
`5,530,235
`
`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 and/or 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 art to store digital data in
`other types of organizational structures, e.g. hyper-linked or
`as a fiat 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-
`tion 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
`0—30,000,
`advertisement 411
`at
`addresses
`30,00l—40,000, story B 412 at addresses 40,00l—60,000 and
`story C 413 at addresses 60,001—85 K. 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 parts 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
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`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-blocks 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 a textual description. In
`other instances the document thumbnail is pictorial repre-
`sentation (for documents comprised of video data,
`the
`thumbnail could be 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 document. I