`
`Our Ref: 895-13
`
`OS 4L4e «3
`
`U.S. PATENT APPLICATION
`
`Invention:
`
`SYSTEMS AND METHODS FOR SECURE TRANSACTION
`MANAGEMENT AND ELECTRONIC RIGHTS PROTECTION
`
`NIXON & VANDERHYEP.C.
`ATTORNEYS AT LAW
`1100 NORTH GLEBE ROAD
`8TH FLOOR
`ARLINGTON, VIRGINIA 22201-4714
`(703) 816-4000
`Telex 200797 NIXN UR
`Telecopier (703) 816-4100
`
`SPECIFICATION
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 001
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 001
`
`
`
`In the preferred embodiment, SPU 500 uses three general
`
`kinds of memory:
`
`(1)
`
`internal ROM 532;
`
`(2)
`internal RAM 534; and
`(3) external memory (typically RAM and/or disk supplied by
`a host electronic appliance).
`
`The internal ROM 532 and RAM 534 within SPU 500
`
`provide a secure operating environment and execution space.
`
`10
`
`Because of cost limitations, chip fabrication size, complexity and
`
`other limitations, it may not be possible to provide sufficient
`
`memory within SPU500 to store all information that an SPU
`needs to process in a secure manner. Dueto the practical limits
`on the amount of ROM 532 and RAM 534 that may be included
`
`within SPU 500, SPU 500 maystore information in memory
`external to it, and move this information into and outofits secure
`internal memory space on an as needed basis.
`In these cases,
`secure processing steps performed by an SPU typically must be
`segmentedinto small, securely packaged elements that may be
`"paged in“ and "paged out* of the Limited available internal
`memory space. Memory external to an SPU 500 may not be
`secure. Since the external memory may not be secure, SPU 500
`may encrypt and cryptographically seal code and other information
`before storing it in external memory. Similarly, SPU 500 must
`typically decrypt code and other information obtained from
`external memory in encrypted form before processing(e.g.,
`
`20
`
`25
`
`_ 172 =
`
`(0061603.01)
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 002
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 002
`
`
`
`10
`
`20
`
`In the preferred embodiment, there are
`executing) based on it.
`two general approaches used to address potential memory
`limitations in a SPU 500.
`In thefirst case, the small, securely
`
`packaged elements represent information contained in secure
`
`database 610.
`
`In the second case, such elements may represent
`
`protected (e.g., encrypted) virtual memory pages. Although virtual
`
`memory pages may correspond to information elements stored in
`
`secure database 610, this is not required in this example of a SPU
`
`memory architecture.
`
`The following is a more detailed discussion of each of these
`
`three SPU memory resources.
`
`SPU Internal ROM
`
`SPU 500 read only memory (ROM) 532 or comparable
`purpose device provides secure internal non-volatile storage for
`certain programs and other information. For example, ROM 532
`may store "kernel programs such as SPU control firmware 508
`and, if desired, encryption key information and certain
`fundamental "load modules.“ The ”kernel* programs, load module
`information, and encryption key information enable the control of
`certain basic functions of the SPU 500. Those components that
`are at least in part dependent on device configuration (e.g., POST,
`memory allocation, and a dispatcher) may be loaded in ROM 532
`along with additional load modules that have been determined to
`be required for specific installations or applications.
`
`- 173 -
`
`(0061603,01)
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 003
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 003
`
`
`
`In the preferred embodiment, ROM 532 may comprise a
`combination of a masked ROM 532a and an EEPROM and/or
`
`equivalent “flash* memory 532b. EEPROMor flash memory 532b
`
`is used to store items that need to be updated and/or initialized,
`
`such as for example, certain encryption keys. An additional
`
`benefit of providing EEPROM and/or flash memory 532b is the
`
`ability to optimize any load modules and library functions
`
`persistently stored within SPU 500 based on typical usage at a
`
`specific site. Although these items could also be stored in
`
`NVRAM 534b, EEPROM and/or flash memory 532b may be more
`cost effective.
`
`Masked ROM 532a maycost less than flash and/or
`
`EEPROM 532b, and can be used to store permanentportions of
`
`SPU software/firmware. Such permanent portions may include,
`
`for example, code that interfaces to hardware elements such as the
`RTC 528, encryption/decryption engine 522, interrupt handlers,
`key generators, etc. Some of the operating system,library calls,
`libraries, and many of the core services provided by SPU 500 may
`also be in masked ROM 532a. In addition, some of the more
`commonly used executables are also good candidates for inclusion
`in masked ROM 532a. Items that need to be updatedor that need
`to disappear when poweris removed from SPU 500 should not be
`stored in masked ROM 532a.
`
`an
`
`10
`
`20
`
`25
`
`-174-
`
`(0061603.01)
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 004
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 004
`
`
`
`Under somecircumstances, RAM 534a and/or NVRAM 534b
`
`(NVRAM 534b may, for example, be constantly powered
`
`conventional RAM) mayperform at least part of the role of ROM
`532.
`
`SPU Internal RAM
`
`SPU 500 general purpose RAM 534 provides, among other
`things, secure execution space for secure processes. In the
`preferred embodiment, RAM534 is comprisedof different types of
`
`10
`
`RAM such as a combination of high-speed RAM 534a and an
`
`NVRAM ("non-volatile RAM") 534b. RAM 534a maybevolatile,
`while NVRAM 534bis preferably battery backed or otherwise
`arranged so as to be non-volatile (i.e., it does not lose its contents
`
`when poweris turned off).
`
`High-speed RAM 534a stores active code to be executed and
`associated data structures.
`
`NVRAM534b preferably contains certain keys and summary
`
`20
`
`values that are preloaded as part of an initialization process in
`which SPU 500 communicates with a VDE administrator, and may
`
`also store changeable or changing information associated with the
`operation of SPU 500. For security reasons, certain highly
`sensitive information (e.g., certain load modules and certain
`
`encryption key related information such as internally generated
`
`private keys) needs to be loaded into or generated internally by
`
`# 175-
`
`(0061603.01)
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 005
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 005
`
`
`
`SPU 500 from time to time but, once loaded or generated
`
`internally, should never leave the SPU.
`
`Inthis preferred
`
`embodiment, the SPU 500 non-volatile random access memory
`
`(NVRAM) 534b may be used for securely storing such highly
`
`sensitive information. NVRAM 534bis also used by SPU 500 to
`_ Store data that may change frequently but which preferably should
`not be lost in a power down or powerfail mode.
`
`10
`
`15
`
`20
`
`25
`
`NVRAM 534b is preferably a flash memory array, but may
`
`in addition or alternatively be electrically erasable programmable
`
`read only memory (EEPROM), static RAM (SRAM), bubble
`
`memory, three dimensional holographic or other electro-optical
`
`memory, or the like, or any other writable (e.g., randomly
`
`accessible) non-volatile memory of sufficient speed and
`cost-effectiveness.
`
`SPU External Memory
`
`The SPU 500 can store certain information on memory
`
`devices external to the SPU. If available, electronic appliance 600
`memory can also be used to support any device external portions
`of SPU 500 software. Certain advantages may be gained by
`allowing the SPU 500 to use external memory. As one example,
`memory internal to SPU 500 may be reduced in size by using
`non-volatile read/write memory in the host electronic appliance
`600 such as a non-volatile portion of RAM 656 and/or ROM 658.
`
`~ 16
`
`(0961603.01)
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 006
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 006
`
`
`
`10
`
`15
`
`20
`
`Such external memory may be used to store SPU programs,
`data and/or other information. For example, a VDE control
`program maybe, at least in part, loaded into the memory and
`communicated to and decrypted within SPU 500 prior to execution.
`Such control programs may be re-encrypted and communicated
`back to external memory where they may bestored for later
`execution by SPU 500. "Kernel“ programs and/or someorall of
`the non-kernel "load modules“ maybe stored by SPU 500 in
`memory external to it. Since a secure database 610 may be
`relatively large, SPU 500 can store someorall of secure database
`610 in external memoryandcall portions into the SPU 500 as
`needed.
`
`As mentioned above, memory external to SPU 500 may not
`be secure. Therefore, when security is required, SPU 500 must
`encrypt secure information before writing it to external memory,
`and decrypt secure information read from external memory before
`using it. Inasmuch as the encryption layer relies on secure
`processes and information (e.g., encryption algorithms and keys)
`present within SPU 500, the encryption layer effectively "extends*
`the SPUsecurity barrier 502 to protect information the SPU 500
`stores in memory external to it.
`
`SPU 500 can use a wide variety of different types of external
`memory. For example, external memory may comprise electronic
`appliance secondary storage 652 such as a disk; external EEPROM
`
`= 197 =
`
`(006 1603.01)
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 007
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 007
`
`
`
`10
`
`15
`
`20
`
`25
`
`or flash memory 658; and/or external RAM 656. External RAM
`
`656 may comprise an external nonvolatile (e.g. constantly
`
`powered) RAM and/or cache RAM.
`
`Using external RAM local to SPU 500 can significantly
`improve access times to information stored externally to an SPU.
`
`For example, external RAM maybe used:
`
`*
`
`to buffer memory image pages and data structures prior to
`
`their storage in flash memory or on an external hard disk
`
`(assuming transfer to flash or hard disk can occur in
`
`*
`
`°
`
`significant power or system failure cases);
`provide encryption and decryption buffers for data being
`released from VDE objects 300.
`to cache "swap blocks“ and VDE data structures currently in
`use as an aspect of providing a secure virtual memory
`environment for SPU 500.
`to cache other information in order to, for example, reduce
`frequency of access by an SPU to secondary storage 652
`and/orfor other reasons.
`Dual ported external RAM canbeparticularly effective in
`improving SPU 500 performance, since it can decrease the data
`movementoverhead of the SPU bus interface unit 530 and SPU
`
`*
`
`microprocessor 520.
`
`Using external flash memory local to SPU 500 can be used
`to significantly improve access timesto virtually all data
`
`~ 178 -
`
`(0061603.61)
`
`=
`
`ee
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 008
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 008
`
`
`
`structures. Since most available flash storage devices have limited
`write lifetimes, flash storage needs to take into account the
`numberof writes that will occur during thelifetime of the flash
`memory. Hence, flash storage of frequently written temporary
`items is not recommended.
`If external RAM is non-volatile, then
`transfer to flash (or hard disk) may not be necessary.
`
`External memory used by SPU 500 may include two
`categories:
`
`.
`°
`
`external memory dedicated to SPU 500, and
`memory shared with electronic appliance 600.
`
`For some VDE implementations, sharing memory (e.g.,
`electronic appliance RAM 656, ROM 658 and/or secondary storage
`652) with CPU 654 or other elements of an electronic appliance
`
`600 may be the most cost effective way to store VDE secure
`
`database management files 610 and information that needs to be
`
`stored external to SPU 500. A host system hard disk secondary
`memory 652 used for general purposefile storage can, for example,
`also be used to store VDE managementfiles 610. SPU 500 may be
`
`given exclusive access to the external memory (e.g., over a local
`
`bus high speed connection provided by BIU 530). Both dedicated
`
`and shared external memory may be provided.
`
`on
`
`10
`
`15
`
`20
`
`25
`
`- 179 -
`
`(0061603.01)
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 009
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 009
`
`
`
`The hardware configuration of an example of electronic
`
`appliance 600 has been described above. The following section
`
`describes an example of the software architecture of electronic
`
`appliance 600 provided by the preferred embodiment, including
`
`the structure and operation of preferred embodiment "Rights
`
`Operating System“ ("ROS*“) 602.
`
`Rights Operating System 602
`
`10
`
`Rights Operating System ("ROS") 602 in the preferred
`embodiment is a compact, secure, event-driven, services-based,
`
`*component* oriented, distributed multiprocessing operating
`
`system environment that integrates VDE information security
`control information, components and protocols with traditional
`operating system concepts. Like traditional operating systems,
`ROS 602 provided by the preferred embodimentis a piece of
`software that manages hardware resources of a computer system
`
`and extends management functions to input and/or output devices,
`including communications devices. Also like traditional operating
`systems, preferred embodiment ROS 602 provides a coherent set of
`basic functions and abstraction layers for hiding the differences
`between, and manyof the detailed complexities of, particular
`hardware implementations. In addition to these characteristics
`found in many or most operating systems, ROS 602 provides
`secure VDE transaction management and other advantageous
`features not found in other operating systems. The following is a
`
`20
`
`25
`
`- 180 -
`
`(0061603.01)
`
`
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 010
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 010
`
`
`
`of functionality can remain unexploited until market realities
`dictate the implementation of corresponding VDE application
`functionality. As a result, initial product implementation
`
`investment and complexity may be limited. The process of
`"surfacing the full range of capabilities provided by ROS 602 in
`terms of authoring, administrative, and artificial intelligence
`applications may take place over time. Moreover, already-
`designed functionality of ROS 602 may be changed or enhanced at
`any time to adapt to changing needs or requirements.
`
`More Detailed Discussion of Rights Operating System 602
`Architecture
`
`Figure 12 shows an example ofa detailed architecture of
`ROS 602 shown in Figure 10, ROS 602 mayincludea file system
`687 that includes a commercial database manager 730 and
`external object repositories 728. Commercial database manager
`730 may maintain secure database 610. Object repository 728 may
`store, provide access to, and/or maintain VDE objects 300.
`
`Figure 12 also shows that ROS 602 may provide one or more
`SPEs 503 and/or one or more HPEs 655. As discussed above, HPE
`655 may "emulate* an SPU 500 device, and such HPEs 655 may be
`integratedin lieu of(or in addition to) physical SPUs 500 for
`systems that need higher throughput. Some security may be lost
`since HPEs 655 are typically protected by operating system
`security and may not provide truly secure processing. Thus, in the
`
`- 221 -
`
`(0061603.01)
`
`10
`
`15
`
`20
`
`25
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 011
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 011
`
`
`
`732. All user API requests are built on top of this basic interface.
`
`The API Service Manager 742 preferably provides a service
`
`instance for each running user application 608.
`
`Most RPC calls to ROS functions supported by API Service
`Manager742 in the preferred embodiment may map directly to
`service calls with some additional parameter checking. This
`mechanism permits developers to create their own extended API
`
`libraries with additional or changed functionality.
`
`In the scenario discussed above in which ROS 602 is formed
`
`by integrating "add ons“ with a preexisting operating system, the
`
`API service 742 code may be shared (e.g., resident in a host
`
`environment like a Windows DLL), or it may be directly linked
`
`with an applications’s code— depending on an application
`
`programmer's implementation decision, and/or the type of
`
`electronic appliance 600. The Notification Service Manager 740
`
`may be implemented within API 682. These components interface
`
`with Notification Service component 686 to provide a transition
`
`between system and user space.
`
`Secure Database Service Manager ("SDSM") 744
`
`There are at least two ways that may be used for managing
`secure database 600:
`
`°
`
`°
`
`a commercial database approach, and
`
`a site record number approach.
`
`- 353 -
`
`(006 1603.01)
`
`10
`
`15
`
`20
`
`25
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 012
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 012
`
`
`
`Which way is chosen may be based on the numberof records that
`a VDE site stores in the secure database 610.
`
`The commercial database approach uses a commercial
`
`database to store securely wrappered records in a commercial
`
`database. This way may be preferred when there are a large
`numberof records that are stored in the secure database 610.
`
`This way provides high speedaccess, efficient updates, and easy
`
`integration to host systems at the cost of resource usage (most
`
`commercial database managers use many system resources).
`
`The site record number approach uses a "site record
`
`number“ ("SRN*“) to locate records in the system. This scheme is
`
`preferred when the numberof records stored in the secure
`
`database 610 is small andis not expected to change extensively
`
`over time. This way provides efficient resources use with limited
`
`update capabilities. SRNs permit further grouping of similar data
`
`records to speed access and increase performance.
`
`Since VDE 100 is highly scalable, different electronic
`
`appliances 600 may suggest one way more than the other. For
`
`example, in limited environments like a set top, PDA, or other low
`
`end electronic appliance, the SRN scheme maybe preferred
`
`because it limits the amount of resources (memory and processor)
`
`required. When VDE is deployed on more capable electronic
`
`appliances 600 such as desktop computers, servers and at
`
`- 954 -
`
`(0061603.01)
`
`10
`
`15
`
`20
`
`20
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 013
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 013
`
`
`
`clearinghouses, the commercial database scheme may be more
`
`desirable because it provides high performance in environments
`where resources are not limited.
`
`One difference between the database records in the two
`
`approaches is whetherthe records are specified using a full VDE
`
`ID or SRN. To translate between the two schemes, a SRN
`
`reference may be replaced with a VDE ID database reference
`
`wherever it occurs. Similarly, VDE IDs that are used as indices or
`
`references to other items may be replaced by the appropriate SRN
`value.
`
`In the preferred embodiment, a commercially available
`
`database manager 730 is used to maintain secure database 610.
`
`ROS 602 interacts with commercial database manager 730
`
`through a database driver 750 and a database interface 748. The
`
`database interface 748 between ROS 602 and external, third party
`
`database vendors’ commercial database manager 730 may be an
`open standard to permit any database vendor to implement a VDE
`compliant database driver 750 for their products.
`
`ROS 602 may encrypt each secure database 610 record so
`that a VDE-provided security layer is "on top of‘ the commercial
`database structure. In other words, SPE 736 may write secure
`records in sizes and formats that may be stored within a database
`
`record structure supported by commercial database manager 730.
`
`- 255 -
`
`(006 1603,01)
`
`10
`
`15
`
`20
`
`25
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 014
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 014
`
`
`
`Commercial database manager 730 may then be used to organize,
`store, and retrieve the records. In some embodiments, it may be
`
`desirable to use a proprietary and/or newly created database
`
`manager in place of commercial database manager 730. However,
`
`the use of commercial database manager 730 may provide certain
`
`advantages such as, for example, an ability to use already existing
`
`database management product(s).
`
`The Secure Database Services Manager ("SDSM"“) 744
`
`makes calls to an underlying commercial database manager 730 to
`
`obtain, modify, and store records in secure database 610.
`
`In the
`
`preferred embodiment, "SDSM“ 744 provides a layer on top of"
`
`the structure of commercial database manager 730. For example,
`
`all VDE-secure information is sent to commercial database
`
`manager 730 in encrypted form. SDSM 744 in conjunction with
`
`cache manager 746 and database interface 748 may provide record
`
`management, caching (using cache manager 746), and related
`
`services (on top of) commercial database systems 730 and/or record
`
`managers. Database Interface 748 and cache manager746 in the
`
`preferred embodiment do not present their own RSI, but rather
`
`the RPC Manager 732 communicates to them through the Secure
`
`Database Manager RSI 744a.
`
`Name Services Manager 752
`
`The Name Services Manager 752 supports three subservices:
`
`user nameservices, host name services, and services name
`
`- 256 -
`
`(0061603.01)
`
`10
`
`15
`
`20
`
`25
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 015
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 015
`
`
`
`used to check further the now-unwrapped object. Assuming this
`"checkingprocess 1054does not reveal any improprieties (and
`block 1052 also indicates that the object has not become corrupted
`or otherwise damaged), SPE 503 may then access or otherwise use
`the item (block 1058). Once use of the item is completed, SPE 503
`may need to store the item back into secure database 610 if it has
`changed. If the item has changed, SPE 503 will send the item in
`its changed form to encrypt/decrypt engine 522 for encryption
`(block 1060), providing the appropriate necessary information to
`the encrypt/decrypt engine(e.g., the appropriate same or different
`managementfile key and data) so that the object is appropriately
`encrypted. A unique, new tag and/or encryption key may be used
`at this stage to uniquely tag and/or encrypt the item security
`wrapper(block 1062; see also detailed Figure 37 discussion below).
`SPE 503 may retain a copy of the key and/or tag within a
`protected memory of SPU 500 (block 1064) so that the SPE can
`decrypt and validate the object whenit is again read from secure
`database 610.
`
`The keys to decrypt secure database 610 records are, in the
`preferred embodiment, maintained solely within the protected
`memory of an SPU 500. Each index or record update that leaves
`the SPU 500 may be time stamped, and then encrypted with a
`unique key that is determined by the SPE 503. For example, a
`key identification number may be placed "in plain view“ at the
`front of the records of secure database 610 so the SPE 503 can
`
`determine which key to use the next time the record is retrieved.
`SPE 503 can maintain the site ID of the record or index, the key
`
`identification numberassociated with it, and the actual keys in
`
`the list internal to the SPE. At some point, this internal list may
`
`410
`
`(0064091.01)
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 016
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 016
`
`
`
`fill up. At this point, SPE 503 maycall a maintenance routine
`that re-encrypts items within secure database 610 containing
`changed information. Someorall of the items within the data
`structure containing changed information may be read in,
`decrypted, and then re-encrypted with the same key. These items
`may then be issued the same key identification number. The
`items may then be written out of SPE 503 back into secure
`database 610. SPE 503 may then clear the internallist of item
`IDs and corresponding key identification numbers. It may then
`begin again the process of assigninga different key and a new key
`identification number to each new or changed item. By using this
`process, SPE 503 can protect the data structures (including the
`indexes) of secure database 610 against substitution of old items
`and against substitution of indexes for current items. This process
`also allows SPE 503 to validate retrieved item IDs against the
`
`encrypted list of expected IDs.
`
`Figure 38 is a flowchart showing this process in more detail.
`Whenevera secure database 610 item is updated or modified, a
`
`new encryption key can be generated for the updated item.
`Encryption using a new key is performed to add security and to
`
`prevent misuse of backup copies of secure database 610 records.
`
`The new encryption key for each updated secure database 610
`
`record may be stored in SPU 500 secure memory with an
`
`indication of the secure database record or record(s) to which it
`
`applies.
`
`SPE 503 may generate a new encryption/decryption key for
`
`each new item it is going to store within secure database 610
`(block 1086). SPE 503 may use this new key to encrypt the record
`
`All
`
`{0064091.01)
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 017
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 017
`
`
`
`made by end users 3310 related to transmissions and or reception
`of information related to the use of author 3306A’s content(e.g.
`end user reporting of audit information, end user requests for
`additional permissions information,etc.)
`
`Some VDE managed content provided to end users 3310
`through the repository may be stored in content storage. Other
`information may be stored elsewhere, and be referenced through
`the content references.
`In the case where content references are
`used, the repository may manage the user interactions in such a
`mannerthat all repository content, whether stored in content
`storage or elsewhere (such as at anothersite), is presented for
`selection by end users 3310 ina uniform way, such as, for
`example, a consistent or the same user interface. If an end user
`requests delivery of content that is not stored in content storage,
`the VDE repository may locate the actual storage site for the
`content using information stored in content references (e.g. the
`network address where the content may be located, a URL, a
`filesystem reference, etc.) After the contentis located, the content
`maybe transmitted across the network to the repository or it may
`be delivered directly from whereit is stored to the requesting end
`user. In some circumstances(e.g. when container modification is
`required, when encryption must be changed, if financial
`transactions are required priorto release,etc.), further processing
`may be required by the repository in order to prepare such VDE
`managed content and/or VDE content container for transmission to
`an end user.
`
`694
`
`(006409101)
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 018
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 018
`
`
`
`As
`~
`"
`py
`a er. = “a
`5
`MGS.
`7ILED
`
`~ PRINT OF DRA
`LGINA
`AS ORI,
`
`=o-
`
`egg9
`
`|
`
`daldvdvLAN
`
`YaLNIdd
`
`Wado
`
`AsSnow
`
`GuvOgAry
`
`SYAaNldd
`
`YOLINOW
`SYSOVNVWWH
`
`SWILTWa4
`
`Viva
`
`qaas
`
`
`
`(L)e809
`
`LINOLLYOMIdd
`
`(z)esos
`
`éINOLLWOIIddv
`
`NNOLLWONddv
`
`INOLLVOISLLON
`
`NOLLdSa9X4S
`
`FOVWAYSLN!
`
`iridas
`
`Y¥asn
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 019
`
`
`(0S(QUOWUOZNO)—aggg1(.AdS.)..NSWNOMIANA
`7l9HsldyVELNVLSISAY)dadWV1
`
`SUNOASii|AMAWASSV[
`
`ONISSIOOUd19069LNSA3
`
` HONISSIOONd\vivafdod||feteeter|NERSESETRett
`i!
`
`
`
`
`{__LNSWNOMIANSONISSIIOUdLNIAFLSOH_|
`JYeVMLAOS
`ANVLSISSYYadNVL
`
`ATawassv|[o:|pes<-s--------
`
`SuvMauVH\
`
`INSNOdNOO
`
`TANYSy
`
`vLvG/AGoo
`
`ONISSADONd
`
`z0SYAlNHVE
`
`OL‘SIs
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 019
`
`
`
`
`
`
`
`
`
`OF DR
`ASPRINT go
`DRs
`ORIG
`Nas
`
`Pe he
`
`Wau
`
`qgLt
`
`‘WWOO
`
`YaOVNVIN
`
`9
`
`cad
`
`WYSYLS
`
`edd
`
`YsOVNVW
`
`SSoIAdaS
`
`AWNHSLXS
`
`Bel
`
`asvaviva
`
`USOVNVIN
`
`iso
`
`YSNIWLNOD
`
`ge/|898d|gas,Pell1oarao
`
`
`
`daas6HOLIMS‘NINGLOArgo
`SNFNccpeasONINOONI
`
`YSaOVNVA99/Singrag
`
`
`|YaL1seosopelere.YALNI|WVWALs:YSLUs|
`
`
`easaat]z69
`
`2dYAQOASYHaOVNVW
`
`
`SOVSYSLNIaSa1avlONILNOY
`
`
`OFTOASAMOLISOdSY
`LOArdo
`
`YaOVNVIN
`
`TWLLUWENS
`
`FOVAYSLNI
`
`(udNdOd,)
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 020
`
`CS-1005
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 020
`
`
`
`
`
`
`
`
`
`
`
`
`