Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. EXAMINER’S NOTE: The claims have been reviewed and considered under the new guidance pursuant to the 2019 Revised Patent Subject Matter Eligibility Guidance (PEG 2019) issued January 7, 2019.
3. This communication is in response to Applicant’s amendment filed on 23 April 2026. Claims 1, 9, and 14 have been amended. Claims 1-20 remain pending.
Response to Arguments
4. Applicant’s arguments, see pages 7-10, filed on 23 April 2026, with respect to the 102 rejection in view of Gaidar et al. has been fully considered, but are moot in view of the new grounds of rejection. In light of the newly amended claim limitations, a new ground of rejection is hereby presented in view of Stefik et al. (Pub No. 2012/00331565) and Levine et al. (Pub No. 2010/0122349).
Claim Rejections - 35 USC § 102
5. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
6. Claims 1-8 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Stefik et al. (Pub No. 2012/0331565).
Referring to the rejection of claim 1, Stefik et al. discloses a computer-implemented method of digital rights management for content, comprising:
receiving a request from a user for copying information on a source page in a source workspace to a target page in a target workspace, wherein the source page comprises a hierarchical structure of blocks that includes at least a preset format of one or more blocks and wherein the one or more blocks include a first block of a first type rendered in a first manner and a second block of a second type different from the first type and rendered in a second manner different from the first manner; (See Stefik et al., para. 42-43, 52-59, 61-62, and 64-65, i.e., a creator creates a digital work, determine appropriate usage rights and fees, associate them with the digital work, and store them in repository 1. The request for access begins with a session initiation by repository 2. Repository 2 request access to the digital work to print the digital work or to obtain a copy of the digital work. Repository 1 checks the usage rights associated with the digital work to determine if the access to the digital work may be granted. If access is granted, repository 1 transmits the digital work to repository 2. Each of the articles and photographs may represent a node in a hierarchical structure. A d-block includes a unique identifier for the work in the repository, a starting address providing the start address of the first byte of the work, a length giving the number of bytes in the work, a rights portion wherein the granted usage rights and their status data are maintained, a parent pointer for pointing to a parent d-block and child pointers for pointing to the child d-blocks. The identifier has two parts. The first part is a unique number assigned to the repository upon manufacture. The second part is a unique number assigned to the work upon creation. D-blocks form a strict hierarchy because each part of a digital work may have its own usage rights, there will be instances where the rights of a "contained part" are different from its parent or container part. As a result, conflict rules must be established to dictate when and how a right may be exercised. The hierarchical structure of a digital work facilitates the enforcement of such rules. A "strict" rule would be as follows: a right for a part in a digital work is sanctioned if and only if it is sanctioned for the part, for ancestor d-blocks containing the part and for all descendent d-blocks. By sanctioned, it is meant that (1) each of the respective parts must have the right, and (2) any conditions for exercising the right are satisfied.)
and initiating a process to copy the information to the target page, wherein the process comprises: determining, for a block in the preset format of the one or more blocks, that the target workspace has a license for copying the block, wherein the block has a set of attributes that determines whether the block is of the first type or the second type and how the block is rendered in the source workspace and the target workspace in accordance with the first manner or the second manner; (See Stefik et al., para. 42-43, 98, 105, 111-114, 179, 192, and 247-248, i.e., Repository 2 initiates a session with Repository 1 to obtain a copy of the digital work wherein the digital work can be played, transferred, or copied. The repository identifier would be a unique number assigned to the repository at the time of manufacture. Each repository will also be classified as being in a particular security class. Certain communications and transactions may be conditioned on a repository being in a particular security class. Copies or transfers must be on repositories of security level 3 or greater. Copying requires the license. License-123-ID issued to the copying repository. Grammar element "Transport-Code:=[Copy|Transfer|Loan {Remaining-Rights: Next-Set-of-Rights}] {(Next-Copy-Rights: Next-Set of Rights)}" lists a category of rights involving the making of persistent, usable copies of the digital work on other repositories. Copy: Make a new copy of a work. Transfer: Moving a work from one repository to another. Loan: Temporarily loaning a copy to another repository for a specified period of time. A Copy transaction is a request to make one or more independent copies of the work with the same or lesser usage rights. Copy differs from the extraction right discussed later in that it refers to entire digital works or entire folders containing digital works. A copy operation cannot be used to remove a portion of a digital work. The requester sends the server a message to initiate the Copy Transaction. This message indicates the work to be copied, the version of the copy right to be used for the transaction, the destination address information (location) for placing the work, the file data for the work (size), and the number of copies requested.)
and associating a record of copying the block with the target workspace based on the determining. (See Stefik et al., para. 55, 221-226, i.e., If the digital work has been granted the requested right, the server then determines if the various conditions for exercising the right are satisfied. Time based conditions are examined. These conditions are checked by examining the time specification for the version of the right. Assuming that the time based conditions are satisfied, the server checks security and access conditions. Such security and access conditions are satisfied if: 1) the requester is at the specified security class, or a higher security class, 2) the server satisfies any specified authorization test and 3) the requester satisfies any specified authorization tests and has any required digital tickets. Assuming that the security and access conditions are all satisfied, the server checks the copy count condition, step 1808If the copy count is less than the copies in use for the transaction the transaction can continue, and the copies in use would be incremented by the number of digital works requested in the transaction. A rights portion wherein the granted usage rights and their status data are maintained, a parent pointer for pointing to a parent d-block and child pointers for pointing to the child d-blocks. In the currently preferred embodiment, the identifier has two parts. The first part is a unique number assigned to the repository upon manufacture. The second part is a unique number assigned to the work upon creation. The rights portion will contain a data structure, such as a look-up table, wherein the various information associated with a right is maintained. D-blocks form a strict hierarchy. The top d-block of a work has no parent; all other d-blocks have one parent.)
Referring to the rejection of claim 2, Stefik et al. discloses wherein the preset format of the one or more blocks comprises a template of blocks. (See Stefik et al., para. 67-68, i.e., a root d-block has child d-blocks. The root d-block represents a magazine and each of the child d-blocks represent articles in the magazine. The rights for the root d-block and child d-blocks 1102 are examined and granted PRINT rights. Child d-block 1103 has not been granted PRINT rights and child d-block 1104 has PRINT rights conditioned on payment of a usage fee. Under the strict rule the PRINT right cannot be exercised because the child d-block does not have the PRINT right. Under the lenient rule, the result would be different. The digital works represented by child d-blocks 1102 and 1105 could be printed and the digital work represented by d-block 1104 could be printed so long as the usage fee is paid. Only the digital work represented by d-block 1103 could not be printed. This same result would be accomplished under the strict rule if the requests were directed to each of the individual digital works)
Referring to the rejection of claim 3, Stefik et al. discloses wherein the copying of the information comprises copying an entirety of the source page. (See Stefik et al., para. 62-63 and 103-104 and Fig. 15, i.e., When the repository loans out a copy of the digital work, the usage rights in the loaner copy (called the next set of rights) could be set to prohibit any further rights to loan out the copy, the usage rights will be the same for an entire digital work, they could be associated when the digital work is processed for deposit in the digital work server and a set of rights will attach to the entire digital work)
Referring to the rejection of claim 4, Stefik et al. discloses wherein the preset format of the one or more blocks comprises a module of blocks that is part of a library, and wherein the source page further comprises blocks that are not part of the module or the library. (See Stefik et al., para. 65-68, i.e., Because each part of a digital work may have its own usage rights, there will be instances where the rights of a "contained part" are different from its parent or container part. As a result, conflict rules must be established to dictate when and how a right may be exercised. The hierarchical structure of a digital work facilitates the enforcement of such rules. A "strict" rule would be as follows: a right for a part in a digital work is sanctioned if and only if it is sanctioned for the part, for ancestor d-blocks containing the part and for all descendent d-blocks. By sanctioned, it is meant that (1) each of the respective parts must have the right, and (2) any conditions for exercising the right are satisfied. In the more lenient rule, access to the part may be enabled to the descendent parts which have the right, but access is denied to the descendants which do not. Root d-block 1101 and child d-blocks 1102 and 1105 have been granted PRINT rights. Child d-block 1103 has not been granted PRINT rights and child d-block 1104 has PRINT rights conditioned on payment of a usage fee. Under the strict rule the PRINT right cannot be exercised because the child d-block does not have the PRINT right. Under the lenient rule, the result would be different. The digital works represented by child d-blocks 1102 and 1105 could be printed and the digital work represented by d-block 1104 could be printed so long as the usage fee is paid)
Referring to the rejection of claim 5, Stefik et al. discloses wherein the copying of the information comprises installation or duplication of the information. (See Stefik et al., para. 127-128, 221, 356-357, i.e., Grammar element 1508 "Configuration-Code:=Install|Uninstall" lists a category of rights for installing and uninstalling software on a repository (typically a rendering repository.) Install: To install new software on a repository. An Install transaction is a request to install a digital work as runnable software on a repository. In a typical case, the requester repository is a rendering repository and the software would be a new kind or new version of a player. Also in a typical case, the software would be copied to file system of the requester repository before it is installed. The requester sends the server an Install message. This message indicates the work to be installed, the version of the Install right being invoked, and the file data for the work (including its size)
Referring to the rejection of claim 6, Stefik et al. discloses wherein the record comprises information about the copying of the block to the target workspace. (See Stefik et al., para. 267-270, i.e., The requester records the digital work contents, data, usage rights, and loan period and stores the work. The server updates the usage rights information in the digital work to reflect the number of copies loaned out. The repositories perform the common closing transaction steps. The server updates the usage rights data for the digital work. This may preclude use of the work until it is returned from the loan. The user on the requester platform can now use the transferred copies of the digital work. A user accessing the original repository cannot use the digital work, unless there are copies remaining What happens next depends on the order of events in time)
Referring to the rejection of claim 7, Stefik et al. discloses wherein the record corresponds to information about the license. (See Stefik et al., para. 178-179 and 386-388, i.e., ((Play) (Transfer (SC: 3)) (Copy Authorization: License-123-ID (SC: 3) The digital work can be played, transferred, or copied. Copies or transfers must be on repositories of security level 3 or greater. Copying requires the license License-123-ID issued to the copying repository. A creator purchases a digital distribution license that he will hand out to his distributors. He puts access requirements (such as a personal license) on the Copy and Transfer rights on the distribution license so that only he can copy or transfer it. The creator also creates a digital work. He grants an Embed right and a Copy right, both of which require the distribution license to be exercised. He grants a Play right so that the work can be played by anyone. A distributor obtains the distribution license and a number of copies of the work. He makes copies for his customers, using his distribution license)
Referring to the rejection of claim 8, Stefik et al. discloses wherein the process further comprises: determining, for a block in the hierarchical structure of blocks, whether the block requires validation for the copying. (See Stefik et al., para. 44, 55, 148, and 179, i.e., An authorization is itself a digital work that can be moved between repositories and subjected to fees and usage rights conditions. An authorization may be required by both repositories involved in an access to a digital work. D-blocks form a strict hierarchy. The top d-block of a work has no parent; all other d-blocks have one parent. In a transaction involving a repository and a document server, some usage rights may require that the repository have a particular authorization, that the server have some authorization, or that both repositories have (possibly different) authorizations. Authorizations themselves are digital works (hereinafter referred to as an authorization object) that can be moved between repositories in the same manner as other digital works. Their copying and transferring are subject to the same rights and fees as other digital works. A repository is said to have an authorization if that authorization object is contained within the repository. The digital work can be played, transferred, or copied. Copies or transfers must be on repositories of security level 3 or greater. Copying requires the license License-123-ID issued to the copying repository.)
Claim Rejections - 35 USC § 103
7. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
8. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
9. Claims 9-20 are rejected under 35 U.S.C. 103 as being unpatentable over Stefik et al. (Pub No. 2012/0331565) in view of Levine et al. (Pub No. 2010/0122349).
Referring to the rejection of claim 9, Stefik et al. discloses a computer-implemented method of digital rights management for content, comprising:
receiving a request from a user for duplicating information on a source page in a source workspace to a target page in a target workspace, wherein the source page comprises a hierarchical structure of blocks that includes at least a preset format of one or more blocks, and wherein the one or more blocks include a first block of a first type rendered in a first manner and a second block of a second type different from the first type and rendered in a second manner different from the first manner; (See Stefik et al., para. 42-43, 52-59, 61-62, and 64-65, i.e., a creator creates a digital work, determine appropriate usage rights and fees, associate them with the digital work, and store them in repository 1. The request for access begins with a session initiation by repository 2. Repository 2 request access to the Digital Work to print the digital work or to obtain a copy of the digital work. Repository 1 checks the usage rights associated with the digital work to determine if the access to the digital work may be granted. If access is granted, repository 1 transmits the digital work to repository 2. Each of the articles and photographs may represent a node in a hierarchical structure. A d-block includes a unique identifier for the work in the repository, a starting address providing the start address of the first byte of the work, a length giving the number of bytes in the work, a rights portion wherein the granted usage rights and their status data are maintained, a parent pointer for pointing to a parent d-block and child pointers for pointing to the child d-blocks. The identifier has two parts. The first part is a unique number assigned to the repository upon manufacture. The second part is a unique number assigned to the work upon creation. D-blocks form a strict hierarchy because each part of a digital work may have its own usage rights, there will be instances where the rights of a "contained part" are different from its parent or container part. As a result, conflict rules must be established to dictate when and how a right may be exercised. The hierarchical structure of a digital work facilitates the enforcement of such rules. A "strict" rule would be as follows: a right for a part in a digital work is sanctioned if and only if it is sanctioned for the part, for ancestor d-blocks containing the part and for all descendent d-blocks. By sanctioned, it is meant that (1) each of the respective parts must have the right, and (2) any conditions for exercising the right are satisfied.)
initiating a duplication process to duplicate the information to the target page, wherein the duplication process comprises: determining, for a block in the preset format of the one or more blocks, that the target workspace fails to have a license for duplicating the block, wherein the block has a set of attributes that determines whether the block is of the first type or the second type and how the block is rendered in the source workspace and the target workspace in accordance with the first manner or the second manner; (See Stefik et al., para. 42-43, 98, 105, 111-114, 179, 192, and 247-248, i.e., Repository 2 initiates a session with Repository 1 to obtain a copy of the digital work wherein the digital work can be played, transferred, or copied. The repository identifier would be a unique number assigned to the repository at the time of manufacture. Each repository will also be classified as being in a particular security class. Certain communications and transactions may be conditioned on a repository being in a particular security class. Copies or transfers must be on repositories of security level 3 or greater. Copying requires the license. License-123-ID issued to the copying repository. Grammar element "Transport-Code:=[Copy|Transfer|Loan {Remaining-Rights: Next-Set-of-Rights}] {(Next-Copy-Rights: Next-Set of Rights)}" lists a category of rights involving the making of persistent, usable copies of the digital work on other repositories. Copy: Make a new copy of a work. Transfer: Moving a work from one repository to another. Loan: Temporarily loaning a copy to another repository for a specified period of time. A Copy transaction is a request to make one or more independent copies of the work with the same or lesser usage rights. Copy differs from the extraction right discussed later in that it refers to entire digital works or entire folders containing digital works. A copy operation cannot be used to remove a portion of a digital work. The requester sends the server a message to initiate the Copy Transaction. This message indicates the work to be copied, the version of the copy right to be used for the transaction, the destination address information (location) for placing the work, the file data for the work (size), and the number of copies requested.)
Stefik et al. fails to explicitly disclose replacing the block with a dummy block on the target page.
Levine et al. discloses a system and method for preventing unauthorized use of digital content.
Levine et al. discloses and replacing the block with a dummy block on the target page. (See Levine et al., para. 15, 21-22, 28-29, 31-32, 34, 70-77, 109-111, 128 and Table 5, i.e., content can be replaced with translocated content, such that, in the example of executable content, the file a.exe is replaced with another file a.exe. The contents of a.exe are encrypted, locked, and hidden, saturation "chaff" logic to create a large amount of harmless and meaningless (yet utterly real in appearance and content, and apparently meaningful) information designed to saturate or confuse logging, reverse engineering, and debugging tools. The first data file is replaced with the second data file and upon an attempt at access by the system of the first data file, the second data file is accessed if the attempt is unauthorized by preventing unauthorized use of digital content data hosted on a system. Digital content data is modified with saturation data to generate modified data, and the modified data are stored at predetermined memory locations on the system to deter unauthorized access of the digital content data. Dummy instruction commands are received while impersonating the interface disclosed in Table 5 as If an authorized request is received, we use the saved location of the //bottom of the OS-Interface ShimList to bypass anyone who might be Attached in between //If an unauthorized request is received it is passed down the ShimList normally. //The Attach and reAttach logic keep the .sub.-- Attach at the top of the ShimList. // Install and remove a dummy SystemInterface Attach in order to get // the address of the last Attach in the OS-Interface ShimList s_pPrevAttachDummy = ANYINTERFACEMgr_InstallSystemInterfaceApiAttach(FnAttachDummy); ANYINTERFACEMgr_RemoveSystemInterfaceApiAttach(FnAttachDummy); // Keep going until we get to the OS-Interface itself apAttachs[0] = s_pPrevAttachDummy; wIdAttach = GetAttachId((BYTE *)*(apAttachs[0]), NULL); idxShimListDepth = 1; while (wIdAttach != ANYINTERFACEMGR_VXD_ID) { // Remove all of the Attachs we have found so far for// Add and remove a dummy ShimLists_pPrevAttachDummy = ANYINTERFACEMgr_InstallSystemInterfaceApiAttach(FnAttachDummy); ANYINTERFACEMgr_RemoveSystemInterfaceApiAttach(FnAttachDummy); apAttachs[idxShimListDepth] = s_pPrevAttachDummy; // Now replace all the Attachs we removed above for (ii = idxShimListDepth - 1; ii >= 0; ii--)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date the claimed invention was made to combine Stefik et al.’s system and method for enforcing utilization of content and usage rights for digitally encoded works modified with Levine et al.’s system and method for preventing unauthorized use of digital content.
Motivation for such an implementation would replacing the block with a dummy block which prevents illegal or unauthorized access to duplicate copyrighted or licensed information to digital content. (See Levine et al., para. 6)
Referring to the rejection of claim 10, (Stefik et al. modified by Levine et al.) discloses wherein the preset format of the one or more blocks comprises a template of blocks. (See Stefik et al., para. 67-68, i.e., a root d-block has child d-blocks. The root d-block represents a magazine and each of the child d-blocks represent articles in the magazine. The rights for the root d-block and child d-blocks 1102 are examined and granted PRINT rights. Child d-block 1103 has not been granted PRINT rights and child d-block 1104 has PRINT rights conditioned on payment of a usage fee. Under the strict rule the PRINT right cannot be exercised because the child d-block does not have the PRINT right. Under the lenient rule, the result would be different. The digital works represented by child d-blocks 1102 and 1105 could be printed and the digital work represented by d-block 1104 could be printed so long as the usage fee is paid. Only the digital work represented by d-block 1103 could not be printed. This same result would be accomplished under the strict rule if the requests were directed to each of the individual digital works)
Referring to the rejection of claim 11, (Stefik et al. modified by Levine et al.) discloses wherein the copying of the information comprises copying an entirety of the source page. (See Stefik et al., para. 62-63 and 103-104 and Fig. 15, i.e., When the repository loans out a copy of the digital work, the usage rights in the loaner copy (called the next set of rights) could be set to prohibit any further rights to loan out the copy, the usage rights will be the same for an entire digital work, they could be associated when the digital work is processed for deposit in the digital work server and a set of rights will attach to the entire digital work)
Referring to the rejection of claim 12, (Stefik et al. modified by Levine et al.) discloses wherein the preset format of the one or more blocks comprises a module of blocks that is part of a library, and wherein the source page further comprises blocks that are not part of the module or the library. (See Stefik et al., para. 65-68, i.e., Because each part of a digital work may have its own usage rights, there will be instances where the rights of a "contained part" are different from its parent or container part. As a result, conflict rules must be established to dictate when and how a right may be exercised. The hierarchical structure of a digital work facilitates the enforcement of such rules. A "strict" rule would be as follows: a right for a part in a digital work is sanctioned if and only if it is sanctioned for the part, for ancestor d-blocks containing the part and for all descendent d-blocks. By sanctioned, it is meant that (1) each of the respective parts must have the right, and (2) any conditions for exercising the right are satisfied. In the more lenient rule, access to the part may be enabled to the descendent parts which have the right, but access is denied to the descendants which do not. Root d-block 1101 and child d-blocks 1102 and 1105 have been granted PRINT rights. Child d-block 1103 has not been granted PRINT rights and child d-block 1104 has PRINT rights conditioned on payment of a usage fee. Under the strict rule the PRINT right cannot be exercised because the child d-block does not have the PRINT right. Under the lenient rule, the result would be different. The digital works represented by child d-blocks 1102 and 1105 could be printed and the digital work represented by d-block 1104 could be printed so long as the usage fee is paid)
Referring to the rejection of claim 13, (Stefik et al. modified by Levine et al.) discloses wherein the process further comprises: determining, for a block in the hierarchical structure of blocks, whether the block requires validation for the copying. (See Stefik et al., para. 44, 55, 148, and 179, i.e., An authorization is itself a digital work that can be moved between repositories and subjected to fees and usage rights conditions. An authorization may be required by both repositories involved in an access to a digital work. D-blocks form a strict hierarchy. The top d-block of a work has no parent; all other d-blocks have one parent. In a transaction involving a repository and a document server, some usage rights may require that the repository have a particular authorization, that the server have some authorization, or that both repositories have (possibly different) authorizations. Authorizations themselves are digital works (hereinafter referred to as an authorization object) that can be moved between repositories in the same manner as other digital works. Their copying and transferring are subject to the same rights and fees as other digital works. A repository is said to have an authorization if that authorization object is contained within the repository. The digital work can be played, transferred, or copied. Copies or transfers must be on repositories of security level 3 or greater. Copying requires the license License-123-ID issued to the copying repository.)
Referring to the rejection of claim 14, (Stefik et al. modified by Levine et al.) discloses a system of digital rights management for content, comprising at least one processor configured to cause the system to: (See Stefik, Fig. 12 and para. 16, a processor, item 1201 is disclosed for the digital work comprising digital content representing a portion of a digital work suitable for being rendered by a rendering device and usage rights associated with the digital content)
receive a request from a user for copying information on a source page in a source workspace to a target page in a target workspace, wherein the source page comprises a hierarchical structure of blocks that includes at least a preset format of one or more blocks, and wherein the one or more blocks include a first block of a first type rendered in a first manner and a second block of a second type different from the first type and rendered in a second manner different from the first manner; (See Stefik et al., para. 42-43, 52-59, 61-62, and 64-65, i.e., a creator creates a digital work, determine appropriate usage rights and fees, associate them with the digital work, and store them in repository 1. The request for access begins with a session initiation by repository 2. Repository 2 request access to the Digital Work to print the digital work or to obtain a copy of the digital work. Repository 1 checks the usage rights associated with the digital work to determine if the access to the digital work may be granted. If access is granted, repository 1 transmits the digital work to repository 2. Each of the articles and photographs may represent a node in a hierarchical structure. A d-block includes a unique identifier for the work in the repository, a starting address providing the start address of the first byte of the work, a length giving the number of bytes in the work, a rights portion wherein the granted usage rights and their status data are maintained, a parent pointer for pointing to a parent d-block and child pointers for pointing to the child d-blocks. The identifier has two parts. The first part is a unique number assigned to the repository upon manufacture. The second part is a unique number assigned to the work upon creation. D-blocks form a strict hierarchy because each part of a digital work may have its own usage rights, there will be instances where the rights of a "contained part" are different from its parent or container part. As a result, conflict rules must be established to dictate when and how a right may be exercised. The hierarchical structure of a digital work facilitates the enforcement of such rules. A "strict" rule would be as follows: a right for a part in a digital work is sanctioned if and only if it is sanctioned for the part, for ancestor d-blocks containing the part and for all descendent d-blocks. By sanctioned, it is meant that (1) each of the respective parts must have the right, and (2) any conditions for exercising the right are satisfied.)
and copy the information to the target page based on: determining, for a block in the preset format of the one or more blocks, whether the target workspace has a license for copying the block, wherein the block has a set of attributes that determines whether the block is of the first type or the second type and how the block is rendered within the source workspace and the target workspace in accordance with the first manner or the second manner; (See Stefik et al., para. 42-43, 98, 105, 111-114, 179, 192, and 247-248, i.e., Repository 2 initiates a session with Repository 1 to obtain a copy of the digital work wherein the digital work can be played, transferred, or copied. The repository identifier would be a unique number assigned to the repository at the time of manufacture. Each repository will also be classified as being in a particular security class. Certain communications and transactions may be conditioned on a repository being in a particular security class. Copies or transfers must be on repositories of security level 3 or greater. Copying requires the license. License-123-ID issued to the copying repository. Grammar element "Transport-Code:=[Copy|Transfer|Loan {Remaining-Rights: Next-Set-of-Rights}] {(Next-Copy-Rights: Next-Set of Rights)}" lists a category of rights involving the making of persistent, usable copies of the digital work on other repositories. Copy: Make a new copy of a work. Transfer: Moving a work from one repository to another. Loan: Temporarily loaning a copy to another repository for a specified period of time. A Copy transaction is a request to make one or more independent copies of the work with the same or lesser usage rights. Copy differs from the extraction right discussed later in that it refers to entire digital works or entire folders containing digital works. A copy operation cannot be used to remove a portion of a digital work. The requester sends the server a message to initiate the Copy Transaction. This message indicates the work to be copied, the version of the copy right to be used for the transaction, the destination address information (location) for placing the work, the file data for the work (size), and the number of copies requested.)
associating a record of copying the block with the target workspace upon determining that the target workspace has the license; (See Stefik et al., para. 55, 221-226, i.e., If the digital work has been granted the requested right, the server then determines if the various conditions for exercising the right are satisfied. Time based conditions are examined. These conditions are checked by examining the time specification for the version of the right. Assuming that the time based conditions are satisfied, the server checks security and access conditions. Such security and access conditions are satisfied if: 1) the requester is at the specified security class, or a higher security class, 2) the server satisfies any specified authorization test and 3) the requester satisfies any specified authorization tests and has any required digital tickets. Assuming that the security and access conditions are all satisfied, the server checks the copy count condition, step 1808If the copy count is less than the copies in use for the transaction the transaction can continue, and the copies in use would be incremented by the number of digital works requested in the transaction. A rights portion wherein the granted usage rights and their status data are maintained, a parent pointer for pointing to a parent d-block and child pointers for pointing to the child d-blocks. In the currently preferred embodiment, the identifier has two parts. The first part is a unique number assigned to the repository upon manufacture. The second part is a unique number assigned to the work upon creation. The rights portion will contain a data structure, such as a look-up table, wherein the various information associated with a right is maintained. D-blocks form a strict hierarchy. The top d-block of a work has no parent; all other d-blocks have one parent.)
Stefik et al. fails to explicitly disclose replacing the block with a dummy block on the target page.
Levine et al. discloses a system and method for preventing unauthorized use of digital content.
Levine et al. discloses and replacing the block with a dummy block on the target page upon determining that the target workspace does not have the license. (See Levine et al., para. 15, 21-22, 28-29, 31-32, 34, 70-77, 109-111, 128 and Table 5, i.e., content can be replaced with translocated content, such that, in the example of executable content, the file a.exe is replaced with another file a.exe. The contents of a.exe are encrypted, locked, and hidden, saturation "chaff" logic to create a large amount of harmless and meaningless (yet utterly real in appearance and content, and apparently meaningful) information designed to saturate or confuse logging, reverse engineering, and debugging tools. The first data file is replaced with the second data file and upon an attempt at access by the system of the first data file, the second data file is accessed if the attempt is unauthorized by preventing unauthorized use of digital content data hosted on a system. Digital content data is modified with saturation data to generate modified data, and the modified data are stored at predetermined memory locations on the system to deter unauthorized access of the digital content data. Dummy instruction commands are received while impersonating the interface disclosed in Table 5 as If an authorized request is received, we use the saved location of the //bottom of the OS-Interface ShimList to bypass anyone who might be Attached in between //If an unauthorized request is received it is passed down the ShimList normally. //The Attach and reAttach logic keep the .sub.-- Attach at the top of the ShimList. // Install and remove a dummy SystemInterface Attach in order to get // the address of the last Attach in the OS-Interface ShimList s_pPrevAttachDummy = ANYINTERFACEMgr_InstallSystemInterfaceApiAttach(FnAttachDummy); ANYINTERFACEMgr_RemoveSystemInterfaceApiAttach(FnAttachDummy); // Keep going until we get to the OS-Interface itself apAttachs[0] = s_pPrevAttachDummy; wIdAttach = GetAttachId((BYTE *)*(apAttachs[0]), NULL); idxShimListDepth = 1; while (wIdAttach != ANYINTERFACEMGR_VXD_ID) { // Remove all of the Attachs we have found so far for// Add and remove a dummy ShimLists_pPrevAttachDummy = ANYINTERFACEMgr_InstallSystemInterfaceApiAttach(FnAttachDummy); ANYINTERFACEMgr_RemoveSystemInterfaceApiAttach(FnAttachDummy); apAttachs[idxShimListDepth] = s_pPrevAttachDummy; // Now replace all the Attachs we removed above for (ii = idxShimListDepth - 1; ii >= 0; ii--))
The rationale for combining Stefik et al. in view of Levine et al. is the same as claim 9.
Referring to the rejection of claim 15, (Stefik et al. modified by Levine et al.) discloses wherein the preset format of the one or more blocks comprises a template of blocks. (See Stefik et al., para. 67-68, i.e., a root d-block has child d-blocks. The root d-block represents a magazine and each of the child d-blocks represent articles in the magazine. The rights for the root d-block and child d-blocks 1102 are examined and granted PRINT rights. Child d-block 1103 has not been granted PRINT rights and child d-block 1104 has PRINT rights conditioned on payment of a usage fee. Under the strict rule the PRINT right cannot be exercised because the child d-block does not have the PRINT right. Under the lenient rule, the result would be different. The digital works represented by child d-blocks 1102 and 1105 could be printed and the digital work represented by d-block 1104 could be printed so long as the usage fee is paid. Only the digital work represented by d-block 1103 could not be printed. This same result would be accomplished under the strict rule if the requests were directed to each of the individual digital works)
Referring to the rejection of claim 16, (Stefik et al. modified by Levine et al.) discloses wherein the copying of the information comprises copying an entirety of the source page. (See Stefik et al., para. 62-63 and 103-104 and Fig. 15, i.e., When the repository loans out a copy of the digital work, the usage rights in the loaner copy (called the next set of rights) could be set to prohibit any further rights to loan out the copy, the usage rights will be the same for an entire digital work, they could be associated when the digital work is processed for deposit in the digital work server and a set of rights will attach to the entire digital work)
Referring to the rejection of claim 17, (Stefik et al. modified by Levine et al.) discloses wherein the preset format of the one or more blocks comprises a module of blocks that is part of a library, and wherein the source page further comprises blocks that are not part of the module or the library. (See Stefik et al., para. 65-68, i.e., Because each part of a digital work may have its own usage rights, there will be instances where the rights of a "contained part" are different from its parent or container part. As a result, conflict rules must be established to dictate when and how a right may be exercised. The hierarchical structure of a digital work facilitates the enforcement of such rules. A "strict" rule would be as follows: a right for a part in a digital work is sanctioned if and only if it is sanctioned for the part, for ancestor d-blocks containing the part and for all descendent d-blocks. By sanctioned, it is meant that (1) each of the respective parts must have the right, and (2) any conditions for exercising the right are satisfied. In the more lenient rule, access to the part may be enabled to the descendent parts which have the right, but access is denied to the descendants which do not. Root d-block 1101 and child d-blocks 1102 and 1105 have been granted PRINT rights. Child d-block 1103 has not been granted PRINT rights and child d-block 1104 has PRINT rights conditioned on payment of a usage fee. Under the strict rule the PRINT right cannot be exercised because the child d-block does not have the PRINT right. Under the lenient rule, the result would be different. The digital works represented by child d-blocks 1102 and 1105 could be printed and the digital work represented by d-block 1104 could be printed so long as the usage fee is paid)
Referring to the rejection of claim 18, (Stefik et al. modified by Levine et al.) discloses wherein the copying of the information comprises installation or duplication of the information. (See Stefik et al., para. 127-128, 221, 356-357, i.e., Grammar element 1508 "Configuration-Code:=Install|Uninstall" lists a category of rights for installing and uninstalling software on a repository (typically a rendering repository.) Install: To install new software on a repository. An Install transaction is a request to install a digital work as runnable software on a repository. In a typical case, the requester repository is a rendering repository and the software would be a new kind or new version of a player. Also in a typical case, the software would be copied to file system of the requester repository before it is installed. The requester sends the server an Install message. This message indicates the work to be installed, the version of the Install right being invoked, and the file data for the work (including its size)
Referring to the rejection of claim 19, (Stefik et al. modified by Levine et al.) discloses wherein the record comprises information about the copying of the block to the target workspace. (See Stefik et al., para. 267-270, i.e., The requester records the digital work contents, data, usage rights, and loan period and stores the work. The server updates the usage rights information in the digital work to reflect the number of copies loaned out. The repositories perform the common closing transaction steps. The server updates the usage rights data for the digital work. This may preclude use of the work until it is returned from the loan. The user on the requester platform can now use the transferred copies of the digital work. A user accessing the original repository cannot use the digital work, unless there are copies remaining What happens next depends on the order of events in time)
Referring to the rejection of claim 20, (Stefik et al. modified by Levine et al.) discloses wherein the record corresponds to information about the license. (See Stefik et al., para. 178-179 and 386-388, i.e., ((Play) (Transfer (SC: 3)) (Copy Authorization: License-123-ID (SC: 3) The digital work can be played, transferred, or copied. Copies or transfers must be on repositories of security level 3 or greater. Copying requires the license License-123-ID issued to the copying repository. A creator purchases a digital distribution license that he will hand out to his distributors. He puts access requirements (such as a personal license) on the Copy and Transfer rights on the distribution license so that only he can copy or transfer it. The creator also creates a digital work. He grants an Embed right and a Copy right, both of which require the distribution license to be exercised. He grants a Play right so that the work can be played by anyone. A distributor obtains the distribution license and a number of copies of the work. He makes copies for his customers, using his distribution license)
Conclusion
10. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY D FIELDS whose telephone number is (571)272-3871. The examiner can normally be reached IFP M-F 8am-4:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SHEWAYE GELAGAY can be reached at (571)272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/COURTNEY D FIELDS/Examiner, Art Unit 2436 July 17, 2026
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights