DETAILED ACTION
Office Action Summary
Claims 21-40 are pending in the instant application.
Claims 21-40 are rejected under Double Patenting.
Claims 21-40 are rejected under 35 USC § 103.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 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.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 21-40 of this application is patentably indistinct from claims 1-20 of patent no. 11586710. Pursuant to 37 CFR 1.78(f), when two or more applications filed by the same applicant or assignee contain patentably indistinct claims, elimination of such claims from all but one application may be required in the absence of good and sufficient reason for their retention during pendency in more than one application. Applicant is required to either cancel the patentably indistinct claims from all but one application or maintain a clear line of demarcation between the applications. See MPEP § 822.
Claims 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of patent no. 11586710. Although the claims at issue are not identical, they are not patentably distinct from each other because they recite substantially the same limitations and are anticipated by claims of patents 12111893 and 11586710 . (See table below for the independent claims).
Instant Application
18825532
Patent No.
12111893
Patent No.
11586710
21. (New) A system comprising: a processor; and
memory comprising computer executable instructions that, when executed, perform operations comprising:
receiving, by a license manager, a request to generate a license for a software application, wherein the request includes a license file specific to the software application; generating a command that is provided to a trusted platform module (TPM) responsive to the request, wherein the command specifies a license generation action, the license file, and an identifier of the software application; and
receiving, by the license manager from the TPM, the license.
21. (New) A system comprising: a processing unit;
and a memory coupled to the processing unit and storing instructions that, when executed, perform operations comprising:
receiving a command at a trusted security mechanism of a client device, the command specifying an identifier of a software component of the client device, the software component providing a request to determine whether a license for the software component is valid;
retrieving, by the trusted security mechanism, a key mapped to the identifier, wherein the key is used to sign and verify the license; …
and providing, by the trusted security mechanism, a validation response to the command.
8. (Currently Amended) A system, comprising: … a processing system comprising one or more processors;
and a memory configured to store program code to be executed by the processing system to perform a method, the program code comprising:
… generate a first command that is sent to the TPM responsive to the first request, the first command specifying a license verification action and an identifier of the software application; determine that the license is not present for the software application responsive to the first command; and …
and provide the license to the first program code.
32. (New) A method comprising: receiving, by a license manager, a request to generate a license for a software application, wherein the request includes a license file specific to the software application;
generating, by the license manager, a set of commands specifying a license generation action and the license file; providing, by the license manager, the set of commands to a trusted platform module (TPM) responsive to the request; receiving, by the license manager from the TPM, the license;
and storing, by the license manager, the license among a set of license files stored by the license manager.
31. (New) A method comprising: receiving a command at a trusted security mechanism of a computing device, the command specifying a software identifier of a software component of the client device, the software component providing a request to determine whether a license for the software component is valid;
retrieving, by the trusted security mechanism, a key associated with the software identifier and a license identifier for the license;
validating, by the trusted security mechanism, the license based on the key; and providing, by the trusted security mechanism, a validation response that is responsive to the request.
1. (Previously Presented) A method performed by a client device, the method comprising: in response to a request from a software application of the client device to determine whether a license for the software application is valid, receiving a command at a trusted platform module (TPM) of the client device, the command specifying an identifier of the software application and including a license information file corresponding to the license;
retrieving, by the TPM, a key from a mapping data structure, the mapping data structure comprising a mapping of the identifier to the key, wherein the identifier is used to identity the mapping and the key is used to sign and verify the license;
validating the license at the TPM using a secure register of the TPM based on the key and the license information file; and providing by the TPM a validation indication response to the command.
40. (New) A device comprising: a processor;
and memory comprising computer executable instructions that, when executed, perform operations comprising:
receiving, by a license manager, a request to generate a license for a software application, wherein the request includes a license file specific to the software application;
generating, by the license manager, a command specifying a license generation action; providing, by the license manager, the command to a trusted platform module (TPM); and
receiving, by the license manager from the TPM, the license.
36. (New) A system comprising: a processing unit;
and a memory coupled to the processing unit and storing instructions that, when executed, perform operations comprising:
receiving, at a license manager of a computing device, a request to generate a license for a software component of the computing device, wherein the request is based on a license verification request from the software component and includes a license information file specific to the software component;
sending a command to a trusted security mechanism of the computing device responsive to the request, the command specifying the license information file and an identifier of the software component;
receiving the license from the trusted security mechanism;
receiving, from the trusted security mechanism, a validation response that is responsive to the command; and
and providing the validation response to the software component.
8. (Currently Amended) A system, comprising: … a processing system comprising one or more processors;
and a memory configured to store program code to be executed by the processing system to perform a method, the program code comprising:
first program code implemented by the first device, the first program code configured to: determine that a software application lacks access to a license; provide a first request, to determine whether a license is present for the software application, based at least on the software application lacking the license;
… generate a first command that is sent to the TPM responsive to the first request, the first command specifying a license verification action and an identifier of the software application; determine that the license is not present for the software application responsive to the first command;
and generate a second command that is sent to the TPM responsive to the second request, the second command specifying a license generation action and information including a license information file and an identifier of the software application;
…generate the license via the secure register, responsive to the second command and based on the key;
and provide the license to the first program code.
Claim Rejections - 35 USC § 103
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 may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 21-40 are rejected under 35 U.S.C. 103 as being unpatentable over Young et al. (US Pre-Grant Publication No: 2019/0042707) hereinafter referred to as Young.
As per claim 21, Young teaches … receiving, by a license manager, a request to generate a license for a software application, wherein the request includes a license file specific to the software application; (Young, 632 in figure 6B; paragraphs [0060; 0051]) [" ... processor 102 transmits license data 410 and the key name to HSM 240 (block 632). "; "License data 410 contains information about the hardware and/or software that is being licensed to a customer.”])
generating a command that is provided to a trusted platform module (TPM) responsive to the request, wherein the command specifies a license generation action, the license file, and an identifier of the software application; and (Young, 636 in figure 6; paragraph [0061]) ["Processor 102 triggers HSM 240 to generate a fingerprint or encrypted hash 434 of the license data 410 (block 636).”])
receiving, by the license manager from the TPM, the license. (Young, see, e.g., paragraph [0051]; 636 in figure 68)
however Young does not teach that the trusted security mechanism of a client device.
However, Young [0036]-0040], along with figures 2-5 teaches having the HSM and the HSM where [0040] states “HSM 296 is a physical computing device that safeguards and manages digital keys for strong authentication and cryptographic processing. HSM 296 is communicatively coupled to the other components of root IHS 290. HSM 296 can generate and store certificates 297, private keys 298 and public keys 299. In an embodiment, HSM 296 can be a root certificate authority (CA) that generates certificates 297, private keys 298 and public keys” and [0036] teaches that the HIS has the RAC and it is not clear whether the RAC is part of the computing device along with the HSM or separate. Although it would be obvious variants to have the computing device have the RAC and the HSM coupled with it or separate.
It would have been obvious to one having ordinary skill in the art, before the effective filing of the claimed invention to modify the invention of Young to have the HSM, RAC to be parts of one device or separate it is a design choice and each has benefits/drawbacks. The RAC/HSM/device processors by design choice can work together as one device or as separate. When they are one device they perform the steps of: “receiving a request from a software application to determine whether a license is valid for the software application at least in response to determining that a license is not issued therefor; generating a command that is sent to a trusted platform module (TPM) of the computing device responsive to the request, the command specifying an identifier of the software application and including a license information file corresponding to the license; retrieving a key by the TPM based on a mapping for the identifier in a mapping data structure subsequent to receiving the command; validating the license at the TPM using a secure register of the TPM based on the key and the license information file; and providing by the TPM a validation indication response to the command.”
As per claim 22, Young teaches … wherein the operations further comprise: prior to receiving the request to generate the license, determining, by the license manager, that the software lacks the license. ; (Young, 632 in figure 6B; paragraphs [0060; 0051], teaches retrieving previous certificate)
As per claim 23, Young teaches … wherein determining that the software lacks the license comprises determining that the license manager is not storing the license among a set of one or more license files stored by the license manager. (Young, 632 in figure 6B; paragraphs [0060; 0051], teaches generating new certificate)
As per claim 24, Young teaches … wherein determining that the software lacks the license comprises: determining that the license manager is storing the license; and determining that the license stored by the license manager is invalid. (Young, [0043], teaches validity period)
As per claim 25, Young teaches … wherein determining that the software lacks the license comprises determining that a license server that is remote to a user device comprising the license manager is unreachable over a network. (Young, 632 in figure 68; paragraphs [0060; 0051]) [" ... processor 102 transmits license data 410 and the key name to HSM 240 (block 632). "; "License data 410 contains information about the hardware and/or software that is being licensed to a customer.”])
As per claim 26, Young teaches …wherein the license manager exposes a license installation application programming interface (API) to service calls from the software application, and wherein the license manager sends license generation requests to the TPM using the license installation API. (Young, [0045] and [0046])
As per claim 27, Young teaches …wherein the license manager exposes a license verification application programming interface (API) to service calls from the software application, and wherein the license manager sends license verification requests to the TPM using the license verification API. (Young, [0045] and [0046])
As per claim 28, Young teaches … wherein the license manager stores one or more license files for one or more software applications of the system, and wherein at least one of the one or more license files is generated by the license manager. (Young [0036]-0040], along with figures 2-5 teaches having the HSM and the HSM where [0040] states “HSM 296 is a physical computing device that safeguards and manages digital keys for strong authentication and cryptographic processing.”)
As per claim 29, D1 teaches … wherein the request further includes the identifier of the software application and permission to be associated with the license. (Young, 632 in figure 68; paragraphs [0060; 0051]) [" ... processor 102 transmits license data 410 and the key name to HSM 240 (block 632). "; "License data 410 contains information about the hardware and/or software that is being licensed to a customer.”])
As per claim 30, D1 teaches … wherein, in response to receiving the license from the TPM, the license manager stores the license as a license file of the license manager. (Young [0036]-0040], along with figures 2-5 teaches having the HSM and the HSM where [0040] states “HSM 296 is a physical computing device that safeguards and manages digital keys for strong authentication and cryptographic processing.”)
As per claim 31, D1 teaches … wherein the operations further comprise: after receiving the license from the TPM, providing an indication of the license to the software application. (Young [0036]-0040], along with figures 2-5 teaches having the HSM and the HSM where [0040] states “HSM 296 is a physical computing device that safeguards and manages digital keys for strong authentication and cryptographic processing. HSM 296 is communicatively coupled to the other components of root IHS 290. HSM 296 can generate and store certificates 297)
As per claims 32 and 40, D1 teaches … receiving, by a license manager, a request to generate a license for a software application, wherein the request includes a license file specific to the software application; (Young, 632 in figure 68; paragraphs [0060; 0051]) [" ... processor 102 transmits license data 410 and the key name to HSM 240 (block 632). "; "License data 410 contains information about the hardware and/or software that is being licensed to a customer.”])
generating, by the license manager, a set of commands specifying a license generation action and the license file; (Young, 636 in figure 6; paragraph [0061]) ["Processor 102 triggers HSM 240 to generate a fingerprint or encrypted hash 434 of the license data 410 (block 636).”])
providing, by the license manager, the set of commands to a trusted platform module (TPM) responsive to the request; (Young, 632 in figure 68; paragraphs [0060; 0051]) [" ... processor 102 transmits license data 410 and the key name to HSM 240 (block 632). "; "License data 410 contains information about the hardware and/or software that is being licensed to a customer.”])
receiving, by the license manager from the TPM, the license; and (Young, see, e.g., paragraph [0051]; 636 in figure 68)
storing, by the license manager, the license among a set of license files stored by the license manager. (Young [0036]-0040], along with figures 2-5 teaches having the HSM and the HSM where [0040] states “HSM 296 is a physical computing device that safeguards and manages digital keys for strong authentication and cryptographic processing. HSM 296 is communicatively coupled to the other components of root IHS 290. HSM 296 can generate and store certificates 297)
however Young does not teach that the trusted security mechanism of a client device.
However, Young [0036]-0040], along with figures 2-5 teaches having the HSM and the HSM where [0040] states “HSM 296 is a physical computing device that safeguards and manages digital keys for strong authentication and cryptographic processing. HSM 296 is communicatively coupled to the other components of root IHS 290. HSM 296 can generate and store certificates 297, private keys 298 and public keys 299. In an embodiment, HSM 296 can be a root certificate authority (CA) that generates certificates 297, private keys 298 and public keys” and [0036] teaches that the HIS has the RAC and it is not clear whether the RAC is part of the computing device along with the HSM or separate. Although it would be obvious variants to have the computing device have the RAC and the HSM coupled with it or separate.
It would have been obvious to one having ordinary skill in the art, before the effective filing of the claimed invention to modify the invention of Young to have the HSM, RAC to be parts of one device or separate it is a design choice and each has benefits/drawbacks. The RAC/HSM/device processors by design choice can work together as one device or as separate. When they are one device they perform the steps of: “receiving a request from a software application to determine whether a license is valid for the software application at least in response to determining that a license is not issued therefor; generating a command that is sent to a trusted platform module (TPM) of the computing device responsive to the request, the command specifying an identifier of the software application and including a license information file corresponding to the license; retrieving a key by the TPM based on a mapping for the identifier in a mapping data structure subsequent to receiving the command; validating the license at the TPM using a secure register of the TPM based on the key and the license information file; and providing by the TPM a validation indication response to the command.”
As per claim 33, D1 teaches … wherein the request further includes at least one of: a validity period for the license file; or an authorization relating to the license file. (Young, 632 in figure 68; paragraphs [0060; 0051]) [" ... processor 102 transmits license data 410 and the key name to HSM 240 (block 632). "; "License data 410 contains information about the hardware and/or software that is being licensed to a customer.”])
As per claim 34, D1 teaches … wherein the license file includes the at least one of: the validity period for the license file; or the authorization relating to the license file. (Young, 632 in figure 68; paragraphs [0060; 0051]) [" ... processor 102 transmits license data 410 and the key name to HSM 240 (block 632). "; "License data 410 contains information about the hardware and/or software that is being licensed to a customer.”])
As per claim 35, D1 teaches … the method further comprising: prior to receiving the request to generate the license, determining that a license server is unreachable over a network. (Young, 636 in figure 6; paragraph [0061] and Young, 632 in figure 68; paragraphs [0060; 0051]) [" ... processor 102 transmits license data 410 and the key name to HSM 240 (block 632). "; "License data 410 contains information about the hardware and/or software that is being licensed to a customer.”])
As per claim 36, D1 teaches … the method further comprising: prior to receiving the request to generate the license, determining that the software application lacks a valid license. (Young, 624-632 in figures 6A-B AND 710➔712➔714 in figure 7 AND paragraph [0064])
As per claim 37, D1 teaches … wherein the license is generated by a secure register of the TPM responsive to the command. (Young, 632 in figure 68; paragraphs [0060; 0051]) [" ... processor 102 transmits license data 410 and the key name to HSM 240 (block 632). "; "License data 410 contains information about the hardware and/or software that is being licensed to a customer.”])
As per claim 38, D1 teaches … wherein the software application, the license manager, and the TPM are implemented a common computing device. (Young [0036]-0040], along with figures 2-5 teaches having the HSM and the HSM where [0040] states “HSM 296 is a physical computing device that safeguards and manages digital keys for strong authentication and cryptographic processing. HSM 296 is communicatively coupled to the other components of root IHS 290. HSM 296 can generate and store certificates 297, private keys 298 and public keys 299. In an embodiment, HSM 296 can be a root certificate authority (CA) that generates certificates 297, private keys 298 and public keys” and [0036] teaches that the HIS has the RAC and it is not clear whether the RAC is part of the computing device along with the HSM or separate. Although it would be obvious variants to have the computing device have the RAC and the HSM coupled with it or separate.)
As per claim 39, D1 teaches … wherein the license provide by the TPM is a temporary license. (Young, [0043], teaches validity period, since it has a period it is temporary and not for ever)
Other Art of Record
Smith et al. (US 9,800,911) teaches “Technologies for selectively licensing segments of source content are described. In some embodiments the technologies enable a user of a client device to select, license, and use one or more segments of source content, without the need to obtain a license to the source content as a whole. Systems, methods, and computer readable media utilizing such technologies are also described. In some embodiments, the technologies can enable digital rights management or other restrictions imposed on a content segment to be enforced, even when the content segment is incorporated into diverse content such as a content mashup. The technologies may also enable independent tracking of information regarding the use and/or payback of content segments, even when such segments are included in diverse content”
Ganesan (US 9,246,916) teaches “A digital license specifies rights with regard to corresponding digital content, and in particular specifies at least one event and for the at least one event at least one of a condition precedent to allowing the event to proceed and an action to be taken once the event has occurred. To respond to a request for an event from a rendering application with regard to the content, event code corresponding to the event is located in the license, and the condition within the event code is evaluated. If evaluated as true, the requested event is allowed to proceed, whereby the rendering application performs the event, and the action within the event code is executed. If evaluated as false, the requested event is denied.”
Solow et al. (US Pre-Grant Puiblication 2018/0322259) teaches “In one embodiment, an instruction is received at a blockchain server from a first digital rights management (DRM) client, the instruction including an instruction to transfer a DRM license to an encrypted content item to a second DRM client. A block to be recorded in a blockchain, is created, the block including a content item ID of said encrypted content item, one of a device ID of a device including the second DRM client or a user ID of a user of the second DRM client, DRM license information for said DRM license, and a DRM decryption key for decrypting said encrypted content item. The block is recorded in the blockchain. A confirmation message is sent to the second DRM client confirming that the block was written to the blockchain. Related systems, methods, and apparatuses are also described.”
Ishimi et al. (US Pre-Grant Puiblication 2018/0181726 A1) teaches “A license managing method including an execution device that executes software and a software storage device coupled to the execution device further includes a license storage device that stores license information indicating the number of licenses for permitting a license of the software, and the license managing method includes the step of license-managing of controlling storage of the software to be downloaded into the software storage device or execution of the software by the execution device based on the license information stored in the license storage device when the software whose license permission is required is downloaded.”
Hughes et al. (US Pre-Grant Publication No. 2008/0319779) teaches “Techniques are described for generating a license for software installed on a device. An entitlement certificate is generated including one or more entitlements describing license characteristics of the software. The one or more entitlements are determined in accordance with first information about the software. The first information includes at least one of a purchase token and package information. A binding certificate in accordance with a binding type for the software is generated. A license in accordance with said binding certificate and said entitlement certificate is generated. The binding certificate identifies an entity to which the license is bound.”
Bhandaru et al. (US Pre-Grant Publication No. 2020/0074047) teaches “At least one machine readable medium comprising a plurality of instructions that in response to being executed by a system cause the system to send a unique identifier to a license server, establish a secure channel based on the unique identifier, request a license for activating an appliance from a license server over the secure channel, receive license data from the license server over the secure channel; determine whether the license is valid, and activate the appliance in response to a determination that the license data is valid.”
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SIMON P KANAAN whose telephone number is (571)270-3906. The examiner can normally be reached on M-F (7AM-4PM).
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, Catherine Thiaw can be reached on (571) 272-1183. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SIMON P KANAAN/Primary Examiner, Art Unit 2407
Prosecution Insights