throbber
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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket