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.
DETAILED ACTION
Remarks
This action is in response to communications filed on 05/28/2026, claim(s) 1-30 is/are cancelled, claim(s) 31-60 is/are added per Applicant's request. Therefore, claims 31-60 are presently pending in the application and have been considered as follows.
Election/Restrictions
Applicant's election with traverse of Group I, claims 31-39 and 51-55 in the reply filed on 05/28/2026 is acknowledged. The traversal is on the ground(s) that the Restriction Requirement on the basis that this application entered the national stage under 35 U.S.C. § 371 and is therefore subject to the unity of invention standard under 37 CFR 1.475, not the domestic restriction practice under 35 U.S.C. § 121 applied in the Office Action and is found persuasive therefore the examiner withdraws the pervious restriction requirement.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/16/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 49 and 50 are rejected under 35 U.S.C. 101 because the claim fails to fall into any of the four enumerated categories of 35 USC 101 as set forth above.
Regarding claims 49 and 50, these claims recites a “license container” and an “extension container”. The claims define the containers based on the information contained therein and the cryptographic treatment of the information but do not require the containers to be embodied in a memory, storage device, computer-readable storage medium, machine or other tangible article. As such the broadest reasonable interpretation of claims 49 and 50 encompasses data per se which do no falls within one of the statutory categories of invention.
As such, the claims are directed towards software per se. Software per se does not fall within any one of the statutory category.
See Gottschalk v. Benson, 409 U.S. at 72 and MPEP 2106.
Claims 31-33, 37, 39-43, 47, 48, 51, 52 and 56 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without significantly more.
Step 1: This part of the eligibility analysis evaluates whether the claim falls within any statutory category. See MPEP 2106.03. Regarding claims 31-48 and 51-60, these claims recites apparatuses, devices, systems and methods. These are directed to machines, a series of steps or acts, and, and falls within one of the statutory categories of invention. (Step 1: YES).
Regarding claims 49 and 50, these claims recites a “license container” and an “extension container”. The claims define the containers based on the information contained therein and the cryptographic treatment of the information but do not require the containers to be embodied in a memory, storage device, computer-readable storage medium, machine or other tangible article. As such the broadest reasonable interpretation of claims 49 and 50 encompasses data per se which do no falls within one of the statutory categories of invention. (Step 1: NO).
Step 2A, Prong One: This part of the eligibility analysis evaluates whether the claim as a whole integrates the recited judicial exception into a practical application of the exception or whether the claim is “directed to” the judicial exception. This evaluation is performed by (1) identifying whether there are any additional elements recited in the claim beyond the judicial exception, and (2) evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. See MPEP 2106.04(d).
Claims 31 and 51
Claims 31 and 51 are directed to an abstract idea because the following claim limitations recite an abstract idea:
An apparatus and method comprising :
generate a globally unique identifier, so-called device unique identity data, D-UID, based on the specific data of the device and optionally random data; (mental process/mathematical concept: a human-being assigning or calculating an identifier based on collected information.)
utilize an L-UID as unique identity data of the licensor of the application to be licensed; (mental process/certain method of organizing human activity: a human-being identifying the party granting permission to use a resource.)
create a license container containing at least the D-UID, the L-UID and a link value based on the application to be licensed; (certain methods of organizing human activity: a human-being creates a licensing record including the information listed);
Claims 31 and 51 recites the following additional elements:
a license agent apparatus;
a device;
a device interface;
a processing unit;
determine specific data of the device connected via the device interface
determining a private device key, priv-D-key of the device based on the specific data of the device, on a D-RND random number, and optionally on the L-UID
encrypt the license container using a public licensor key, pub-L-key;;
optionally provide the license container.
optionally providing the encrypted license container;
optionally storing the L-UID and/or the D-RND on the device for later use.
Claims 32 and 52
Claims 32 and 52 include the abstract idea of the base claim the they depend from and further recites:
identifying the device connected to the device interface (mental process: a human being recognizes the device based on identifying information)
Claims 32 and 52 recites the following additional elements:
loading a communication protocol corresponding to the identified device;
using the communication protocol for communication and data exchange with the device;
a generic API.
Claims 33
Claims 33 include the abstract idea of the base claim the they depend from.
Claims 33 recites the following additional elements:
determine a private device key, priv-D-key of the device based on the specific data of the device, on a D-RND random number, and optionally on the L-UID;
optionally store the L-UID and/or the D-RND for later use;
create the public device key, pub-D-key based on the private device key, priv-D-key.
Claims 37
Claims 37 include the abstract idea of the base claim the they depend from.
Claims 37 recites the following additional elements:
receive a license container containing a license for the application,
store the license container on the device connected to the device interface.
Claims 39
Claims 39 include the abstract idea of the base claim the they depend from :
verify the license container (mental process: a human being reviewing and verifying the licensing information satisfies the requirements.)
Claims 39 recites the following additional elements:
receive a license container containing a license for the application.
Claims 40
Claims 40 include the abstract idea of the base claim the they depend from and further recites :
the device being configured to be bound to a license container, which is suitable to contain at least a license for an application (certain method of organizing human activity: a human being conditioning authorizations to use an application after association of the license with a particular device.)
Claims 40 recites the following additional elements:
a device;
specific data characterizing the device;
communicating with a license agent or license agent apparatus
providing the specific data for identifying the device and for creating a device unique identity data, D-UID.
Claims 41
Claims 41 include the abstract idea of the base claim the they depend from.
Claims 41 recites the following additional elements:
a storage medium;
storage of data and/or a license container;
specific data of the device comprise at least one member selected from the group comprising at least serial number, chip identification data, bad sector information, type of device, production data, production batch, safety information stored in the device.
Claims 42
Claims 42 include the abstract idea of the base claim the they depend from.
Claims 42 recites the following additional elements:
communication with the device takes place using a generic API.
Claims 43
Claims 43 include the abstract idea of the base claim the they depend from.
Claims 43 recites the following additional elements:
password protected storage area;
self-encrypting region of the device and/or a cryptographic controller having a storage capacity;
the license container and/or the D-RND and/or the L-UID is stored in the password protected storage area or in the storage capacity of the controller.
Claims 47
Claims 47 include the abstract idea of the base claim the they depend from and further recites :
license being contained in a license container and being bound to a device (certain method of organizing human activity: a human being associating permission to use an application with a particular identified device.)
the application can only be executed if the license is valid and the device is present. (certain method of organizing human activity: a human being permitting use of the licensed application only when the user satisfies the licensing conditions..)
Claims 47 recites the following additional elements:
A system
device;
device specific data
a license container
a license agent apparatus
communications between the license agent apparatus and device;
obtaining device specific data.
Claims 48
Claims 48 include the abstract idea of the base claim the they depend from.
Claims 48 recites the following additional elements:
a storage medium on which the application is stored;;
a processor unit for executing the application;
an application interface;
a bidirectional interface;
communicating between the license agent apparatus and the processor unit for executing the application;
exchange at least the license container between the license agent apparatus and a licensor device;
enter a license in a license container;
communicate with the application requiring the license;
optionally to communicate with the device to exchange data with the device for storing data in the device;
communicate with the licensor at least for receiving the license container filled with the license created by the licensor.
Step 2A, Prong Two: This part of the eligibility analysis evaluates whether the claim as a whole integrates the recited judicial exception into a practical application of the exception or whether the claim is “directed to” the judicial exception. This evaluation is performed by (1) identifying whether there are any additional elements recited in the claim beyond the judicial exception, and (2) evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application.
Claims 31 and 51
The claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with creating a license container containing information identifying the device, licensor and application and encrypting the license container. Claim 51 additionally generates cryptographic keys used in connection with the license container but does not require the generated device keys to authenticate the device, verify or decrypt a returned license or control execution of the application. See MPEP 2106.04(d)(1) and 2106.05(a). Determining specific data of the device is merely data gathering used to perform the abstract licensing process. See MPEP 2106.05(g). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to integrate the abstract idea into a practical application.
Claims 32 and 52
The claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate identifying the connected device and using a corresponding communication protocol to exchange information with the device. Claim 52 additionally requires use of a generic API. The claims do not improve the communication protocol, API, driver or operation of the device but merely use these components to communicate the information used in the licensing process. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to integrate the abstract idea into a practical application.
Claims 33
The claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with generating a private device key from the recited information and creating a corresponding public device key. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to integrate the abstract idea into a practical application.
Claims 37
The claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with receiving a license container containing the license and storing the license container on the device. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to integrate the abstract idea into a practical application.
Claims 39
The claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with verifying the received license container without requiring a particular technological mechanism for performing the verification. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to integrate the abstract idea into a practical application.
Claims 40
The claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with associating a license container with an identified device based on device specific information. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to integrate the abstract idea into a practical application.
Claims 41
The claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with storing data and/or the license container and specifying particular types of device identifying information used in the licensing relationship. . See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to integrate the abstract idea into a practical application.
Claims 42
The claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with communicating with the device using a generic API. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to integrate the abstract idea into a practical application.
Claims 43
The claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with storing licensing information in a password protected, self-encrypting and/or cryptographically controlled storage area.. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to integrate the abstract idea into a practical application.
Claims 47
The claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with permitting execution of the application only when the license is valid and the identified device is present. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to integrate the abstract idea into a practical application.
Claims 48
The claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with exchanging the licensing information among the application, license agent apparatus, device and licensor. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to integrate the abstract idea into a practical application.
Step 2B:
This part of the eligibility analysis evaluates whether the claim as a whole amounts to significantly more than the recited exception i.e., whether any additional element, or combination of additional elements, adds an inventive concept to the claim. See MPEP 2106.05.
One way to determine integration into a practical application is when the claimed invention improves the functioning of a computer or improves another technology or technical field. To evaluate an improvement to a computer or technical field, the specification must set forth an improvement in technology and the claim itself must reflect the disclosed improvement. See MPEP 2106.04(d)(1) and 2106.05(a).
Claims 31 and 51
Likewise to step 2A prong 2, the claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with creating a license container containing information identifying the device, licensor and application and encrypting the license container. Claim 51 additionally generates cryptographic keys used in connection with the license container but does not require the generated device keys to authenticate the device, verify or decrypt a returned license or control execution of the application. See MPEP 2106.04(d)(1) and 2106.05(a). Determining specific data of the device is merely data gathering used to perform the abstract licensing process. See MPEP 2106.05(g). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to amount to significantly more than the abstract idea itself, even when the additional elements are considered alone and in combination with the abstract idea. (Step 2B: NO).
Therefore, the claims are directed to an abstract idea without significantly more and are unpatentable.
Claims 32 and 52
Likewise to step 2A prong 2, the claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate identifying the connected device and using a corresponding communication protocol to exchange information with the device. Claim 52 additionally requires use of a generic API. The claims do not improve the communication protocol, API, driver or operation of the device but merely use these components to communicate the information used in the licensing process. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to amount to significantly more than the abstract idea itself, even when the additional elements are considered alone and in combination with the abstract idea. (Step 2B: NO).
Therefore, the claims are directed to an abstract idea without significantly more and are unpatentable.
Claims 33
Likewise to step 2A prong 2, the claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with generating a private device key from the recited information and creating a corresponding public device key. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to amount to significantly more than the abstract idea itself, even when the additional elements are considered alone and in combination with the abstract idea. (Step 2B: NO).
Therefore, the claims are directed to an abstract idea without significantly more and are unpatentable.
Claims 37
Likewise to step 2A prong 2, the claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself The claim culminate with receiving a license container containing the license and storing the license container on the device. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to amount to significantly more than the abstract idea itself, even when the additional elements are considered alone and in combination with the abstract idea. (Step 2B: NO).
Therefore, the claims are directed to an abstract idea without significantly more and are unpatentable.
Claims 39
Likewise to step 2A prong 2, the claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself . The claim culminate with verifying the received license container without requiring a particular technological mechanism for performing the verification. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to amount to significantly more than the abstract idea itself, even when the additional elements are considered alone and in combination with the abstract idea. (Step 2B: NO).
Therefore, the claims are directed to an abstract idea without significantly more and are unpatentable.
Claims 40
Likewise to step 2A prong 2, the claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself . The claim culminate with associating a license container with an identified device based on device specific information. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to amount to significantly more than the abstract idea itself, even when the additional elements are considered alone and in combination with the abstract idea. (Step 2B: NO).
Therefore, the claims are directed to an abstract idea without significantly more and are unpatentable.
Claims 41
Likewise to step 2A prong 2, the claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with storing data and/or the license container and specifying particular types of device identifying information used in the licensing relationship. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to amount to significantly more than the abstract idea itself, even when the additional elements are considered alone and in combination with the abstract idea. (Step 2B: NO).
Therefore, the claims are directed to an abstract idea without significantly more and are unpatentable.
Claims 42
Likewise to step 2A prong 2, the claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with communicating with the device using a generic API. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to amount to significantly more than the abstract idea itself, even when the additional elements are considered alone and in combination with the abstract idea. (Step 2B: NO).
Therefore, the claims are directed to an abstract idea without significantly more and are unpatentable.
Claims 43
Likewise to step 2A prong 2, the claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with storing licensing information in a password protected, self-encrypting and/or cryptographically controlled storage area. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to amount to significantly more than the abstract idea itself, even when the additional elements are considered alone and in combination with the abstract idea. (Step 2B: NO).
Therefore, the claims are directed to an abstract idea without significantly more and are unpatentable.
Claims 47
Likewise to step 2A prong 2, the claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with permitting execution of the application only when the license is valid and the identified device is present. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to amount to significantly more than the abstract idea itself, even when the additional elements are considered alone and in combination with the abstract idea. (Step 2B: NO).
Therefore, the claims are directed to an abstract idea without significantly more and are unpatentable.
Claims 48
Likewise to step 2A prong 2, the claims fails to achieve a technical solution to a technical problem. Thus the claim fail to provide an improvement to the function of a computer or to a technology itself. The claim culminate with exchanging the licensing information among the application, license agent apparatus, device and licensor. See MPEP 2106.04(d)(1) and 2106.05(a). The additional elements are recited at a high level of generality and amount to merely using computers as a tool to implement the abstract idea. Thus the additional elements are considered mere instruction to apply the abstract idea See MPEP 2106.05(f). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application (Step 2A, Prong Two: NO), and the claim is directed to the judicial exception. (Step 2A: YES).Therefore, the examiner must find that the claims fail to amount to significantly more than the abstract idea itself, even when the additional elements are considered alone and in combination with the abstract idea. (Step 2B: NO).
Therefore, the claims are directed to an abstract idea without significantly more and are unpatentable.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 36, 38, 41, 42, 43, 45, 46, 47, 49, 50, 52, 56, 57, 58, 59 and 60 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 36 recites “the D-RND” and “the priv-D-key”. However, these terms lack an antecedent basis as claim 31 never introduces these terms and it’s unclear at the scope of these terms as they are not ordinary terms.
In regards to claim 38, the limitation “ allow the application to use the license contained in the license container after decrypting the license container” renders the claim indefinite as it’s unclear if the license container of claim 31 and the subsequently filled license container containing the license are the same or different container as the relationship has never been established between the two.
In regards to claim 41, the limitation “the specific data of the device comprise at least one member selected from the group comprising at least serial number, chip identification data, bad sector information, type of device, production data, production batch, safety information stored in the device” renders the claim indefinite. Specifically, the claim uses the phrases “comprising” which is an open ended phrase that may also include elements not listed and makes the claim unclear as to what other alternatives are intended to be encompassed by the claim. See MPEP 2173.05(h). he examiner recommends to amended “comprising” to “consisting of” or any other phrase that closes the Markush group.
In regard to claim 42 and 52 the limitation “wherein the communication with the device takes place using a generic API” renders the claim indefinite because the claims and specification fail to provide an objective boundary for determining whether an API is “generic” as oppose to non-generic or device specific. Accordingly it is unclear as to what falls inside and outside the scope of this limitation.
In regards to claims 43, 45, 46, 49, 50, 56-58 and 60 the following terms lack an antecedent basis
Claim 43 “the D-RND” and “the L-UID”
Claim 45 “the priv-D-key”
Claim 46 “the private licensor key” and “the public device key”
Claim 49 “the application”, “the public licensor key , and “the pub-D-key”
Claim 50 “the priv-D-key”, “the device”
Claim 56 “the application”, “the priv-D-key” “the device”
Claim 57 “the priv-L-key” “the application” “the pub-D-key” “the licensor”
Claim 58 “the licensor” “the pub-L-key”
Claim 60 “the pub-D-key”
In regards to claim 46, 49 and 57 , the limitation “one data of the group comprising at least a D-UID, a link value based on the application to be licensed, license parameters, and license keys of the application; encrypt the filled license container with the public device key” , “one data of the group comprising a D-UID, a D-UID-cert, a link value based on the application to be licensed, license parameters, license specifications, and a license key for executing the application” and “at least one data of the group comprising at least a D-UID of the device to which the license should be bound, a D-UID-cert, a link value based on the application to be licensed, a license parameter, license specifications, and a license key of the application” renders the claim indefinite. Specifically, the claim uses the phrases “comprising” which is an open ended phrase that may also include elements not listed and makes the claim unclear as to what other alternatives are intended to be encompassed by the claim. See MPEP 2173.05(h). he examiner recommends to amended “comprising” to “consisting of” or any other phrase that closes the Markush group.
In regards to claim 47 the limitation “a license agent apparatus configured to handle a license container” renders the claim indefinite because the term “handle” does not identify the operation that the license agent apparatus is required to perform on the license container. Furthermore, the claims and specification fail to provide an objective boundary for what the operation of “handle” is. Accordingly it is unclear as to what falls inside and outside the scope of this limitation.
Claim 50 recites “the device” and “the priv-D-key”. However, these terms lack an antecedent basis as claim 49 never introduces these terms and it’s unclear as to the scope of at least “priv-D-key” is as this is not an ordinary term.
Claim 56 recites “the application”, “the priv-D-key” and “the device.” However, these terms lack an antecedent basis as the claim never introduces these terms and it’s unclear as to the scope of at least “priv-D-key” is as this is not an ordinary term.
Furthermore, claim 56 recites decrypting the license container and storing “the encrypted license container” on the device. After the recited decryption, it is unclear whether “the encrypted license container” refers to the originally received encrypted container, the decrypted container after being re-encrypted or another encrypted version of the container. Accordingly, this relationship between the decrypted license container and the subsequent stored encrypted license container is unclear.
In regards to claim 59, the claim recites checking the counter against “a start value and/or a limit value of the license usage which is stored in the license container and/or may be stored additionally in a restricted area of the device..” The phrase “which is stored” has an unclear grammatical meaning. It is unclear whether only the limit value is required to be stored, both the state value and limit value are required to be stored or the storage requirement varies depending on the selected alternative. Additionally, the repeated use of “and/or” further obscures which value or values must be present and where the required value or values must be stored.
Claim 60 recites “the pub-D-key”.” However, this terms lack an antecedent basis as the claim nor do the base claims of 58 or 59 ever introduces the term and it’s unclear as to the scope of at least “pub-D-key” is as this is not an ordinary term.
Furthermore, with regards to claim 60, the claim further recites an extension container “comprising the following steps”. A container is an article or data structure whereas the subsequent recited limitations are method operations that include at least retrieving, comparing, allowing use, changing the counter and updating a backup value. Thus it is unclear whether the recite steps define operations performed by the extension container, information or instructions contained in the extension container or additional steps of the claimed method.
Additionally, claims 60 recites allowing use “if the current value of the counter and the backup values are equal.” The claim does not clearly establish whether the subsequent steps of changing the counter and updating the backup value are also condition upon the equality determination.
Finally , claim 60 recites “overriding the backup value with the changed current value.” It is unclear whether “overriding” requires overwriting or replacing the stored backup values, temporarily superseding the value or some other operations. As such, the metes and bounds of claim 60 cannot be determined with reasonable certainty.
Claim Rejections - 35 USC § 102
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 40, 41 and 47 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by US 20190026442 A1 to Pearlman et al. (hereinafter “Pearlman”)
Claim 40
Pearlman teaches a device having specific data characterizing the device and being configured to be bound to a license container, which is suitable to contain at least a license for an application, and being configured to communicate with a license agent or a license agent apparatus to provide the specific data for identifying the device and for creating a device unique identity data, D-UID. [e.g. Perlman; Abstract, Claims 15-20, Para. 0031-0033, 0048-0052 – Perlman discloses a computing device having hardware components identified by serial numbers, media access control (hereinafter “MAC”) numbers, device identifiers, and/or any identifier that uniquely identifies such hardware components (e.g. specific data characterizing the device), licensing data containing binding and grant information for authorized software (e.g. license container suitable to contain a license for an application) and device management agent 304 reading the hardware identifiers and generating hardware binding data identifying device (e.g. communicating with a license agent apparatus to provide specific data for identifying the device and creating D-UID). ]
Claim 41
Pearlman teaches the device according to claim 40, wherein the device is configured to store data and to comprise a storage medium and is configured to store a license container; wherein the specific data of the device comprise at least one member selected from the group comprising at least serial number, chip identification data, bad sector information, type of device, production data, production batch, safety information stored in the device. [e.g. Perlman; Abstract, Claims 15-20, Para. 0031-0033, 0048-0052 – Perlman discloses memories and firmware storing the device bound licensing data (e.g. storage medium configured to store a license container) and hardware component serial numbers, MAC numbers and device identifiers used to generate the hardware binding data (e.g. serial number or chip/device identification data)]
Claim 47
Pearlman teaches a system for handling a license of an application of a licensor, the license being contained in a license container and being bound to a device, comprising
a device having specific data characterizing the device and being linked to the license in the license container and being configured to provide the specific data for identifying the device; [e.g. Perlman; Abstract, Para. 0031-0033, 0048-0050 – Perlman discloses a computing device having hardware identifiers and licensing data containing binding data identifying the hardware configuration and grant information identifying the authorized software rights (e.g. a device having specific data and being linked to a license contained in the license container). Pearlman further discloses device management agent 204 reading the serial numbers, MAC numbers and other hardware identifiers of the computing device and generating hardware binding data from those values (e.g. providing the specific data for identifying the device) ]
a license agent apparatus configured to handle a license container containing the license to execute the application, and to communicate with the device so that device specific data can be read out from the device; [e.g. Perlman; Abstract, Para. 0032, 0033, 0048-0052 – Perlman discloses device management agent 304 obtaining the device hardware identifiers, obtaining and validating licensing data containing binding and grant information and managing activation of the licensed application (e.g. license agent apparatus handling a license container containing the license and reading device specific data.)]
wherein the binding between the license in the license container and the device is based on the specific data, so that the application can only be executed if the license is valid and the device is present. [e.g. Perlman; Abstract, Claims 19, 20, Para. 0050-0052 – Perlman discloses generating current hardware binding data, comparing the current binding data with the binding data stored in the licensing data, verifying the license data signature and grant information, refusing activation when the values do not correspond and activating the software when the binding and license information are valid (e.g. execution only when the license is valid and the bound device is present)]
Claim(s) 49 and 56 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by US 20120131345 A1 to Dadu
Claim 49
Dadu teaches a license container containing at least one data of the group comprising a D-UID, a D-UID-cert, a link value based on the application to be licensed, license parameters, license specifications, and a license key for executing the application, wherein the license container is encrypted with the public licensor key and/or with the pub-D-key. [e.g. Dadu; Claims 13, 15 Para. 0012-0014, 0020, 0022-0024 – Dadu discloses a software license containing a unique identifier of the restricted application (e.g. link value based on the application), a lease period (e.g. license parameter/specification) and a License Encryption Key (LEK) (e.g. license key for executing/accessing the application). Dadu further discloses SLM Service 112 implemented in a hardware security engine within a chipset of computing platform 102, the computing platform supplying the SLM Service public key to License Server 120, the License Server encrypting the software license using the public key and the SLM Service 112 decrypting the license using the corresponding private key (e.g. license container encrypted using pub-D-key).]
Claim 56
Dadu teaches a method for handling a license container containing a license, comprising the following steps:
receiving a license container containing a license for the application, [e.g. Dadu; Para. 0022, 0023 – Dadu discloses License Server 120 creating a license (e.g. a license for the application) containing a unique identifier for the requested restricted software, user information, a lease period and License Encryption Key (LEK), encrypting and signing the license to form the protected license object (e.g. license container) and sending the protected license to Host Application 116 on the computing platform 102 (e.g. receiving the license container).]
decrypting the license container using the priv-D-key, [e.g. Dadu; Para. 0024 – Dadu discloses Secure License Management (SLM) Service 112 within the hardware security engine decrypting the encrypted license using the SLM service private key corresponding to the public key used to encrypt the license (e.g. decrypting the license container using priv-D-key).]
optionally verifying the license container, [e.g. Dadu; Para. 0024 – Dadu discloses verifying the License Server signature on the encrypted license using the License server public key and checking the lease time condition (e.g. verifying the license container).]
storing the encrypted license container on the device for later use with the application, and[e.g. Dadu; Para. 0023 – Dadu discloses Host Application 116 storing the signed license in memory of computing platform 102 or in secure storage 109 (e.g. storing the encrypted license container on the device).]
optionally allowing the application to use the license contained in the license container after decrypting the license container. [e.g. Dadu; Para. 0024 – Dadu discloses extracting the LEK from the decrypted license, sending the LEK to the host application, decrypting the restricted software and allowing access to the software (e.g. allowing the application to the use the license after decryption).]
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 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.
Claim(s) 31 and 39 are rejected under 35 U.S.C. 103 as being unpatentable over US 20030156719 to Cronce
Claim 31
Cronce teaches a license agent apparatus for handling a license of an application of a licensor, comprising
a device interface to communicate with a device having specific data; a processing unit to generate a license container configured to maintain a license for the application; [e.g. Cronce; Para. 0027- 0031 – Cronce discloses computer system 101 having CPU 113, memory 114, I/O circuitry 112, interface cards 126 and authorization program 214 responsible for requesting, validating and managing a license for software product 215 (e.g. license agent apparatus, device interface, processing unit and application).]
the processing unit being configured to:
determine specific data of the device connected via the device interface; [e.g. Cronce; Para. 0062 – Cronce discloses extracting computer configuration information including CPU serial number, hard drive serial number, network card MAC address from computer system 101 (e.g. determining specific data of the connected device).]
generate a globally unique identifier, so-called device unique identity data, D-UID, based on the specific data of the device and optionally random data; [e.g. Cronce; Para. 0062 – Cronce discloses digesting the collected machine information to generate a unique machine fingerprint that prevents the licensed program from being used on a different machine. (e.g. generating D-UID based on device specific data).]
utilize an L-UID as unique identity data of the licensor of the application to be licensed; [e.g. Cronce; Para. 0051, 0056, 0062 – Cronce discloses publisher certificate 502, publisher ID 504 and the software publisher name identifying the publisher of software product 215 (e.g. L-UID identifying the licensor).]
create a license container containing at least the D-UID, the L-UID and a link value based on the application to be licensed; [e.g. Cronce; Para. 0063, 0065, 0066, 0082-0086 – Cronce discloses XML request document 700 containing the machine fingerprint in CustomerInfo 753 (e.g. D-UID), publisher ID and publisher information (e.g. L-UID) and ProductInfo 754 containing product ID 506, product name and product version formation product 215 (e.g. link value based on the application to be licensed).]
optionally provide the license container. [e.g. Cronce; Para. 0064 – Cronce discloses transmitting license request document 700 to license server 102 through a network, email, disk or other delivery option. (e.g. providing the license container).]
Cronce teaches encrypting license request document 700 using the product public key so license server 102 can decrypt the request using the corresponding product private key [e.g. Cronce; Para. 0033, 0036 – Cronce discloses encrypting the license request using the product public key and decrypting the request at license server 102 using the product private key.] Cronce does not explicitly teach that the public key used for this encryption is the public licensor key as Cronce identifies the encryption key as the public key associated with the software product.
However, Cronce separately discloses a publisher and licensor public and private key pair including a publisher certificate 502 containing the publisher public key and teaches that license server 102 is operated by or on behalf of a key authority for the publisher and has access to the corresponding publisher private key. [e.g. Cronce; Para. 00521, 0062, 0094, 0108, 0111 – Cronce discloses the publisher certificate and publisher key pair and the publisher private key being available to the back-end server 192 for handling license request.]
Therefore, it would have been obvious to encrypt Cronce’s license request using the publisher/licensor public key as opposed to the product public key because Cronce already encrypts the request with a public key such that the license server possessing the corresponding private key can recover the request and also Cronce teaches that the same back-end license server has access to the publisher/licensor private key; see Cronce Para. 0033, 0064 and 0094. Thus using the disclosed publisher public key for the same encryption operation would have predictably protected the request for receipt and decryption by the publisher’s license server using the corresponding publisher private key (e.g. encrypting the license container using pub-L-key).
Claim 39
Cronce teaches the license agent apparatus according to claim 31, wherein the processing unit is further configured to receive a license container containing a license for the application, to verify the license container. [e.g. Cronce; Para. 0038-0041, 0093-0102 – Cronce discloses transferring singed XML license response document 900 to authorization program 214 (e.g. receiving a license container), . (e.g. storing the license container on the device), response document 900 being the actual software license document containing the LicenseTerms 964 for software product 215 (e.g. containing a license for the application) and authorization program 214 validating the publisher certificate, document signature, message digest, publisher ID, product ID and license terms before authorizing user of software product 215 (e.g. verifying the license container)]
Claim(s) 32 is rejected under 35 U.S.C. 103 as being unpatentable over US 20030156719 to Cronce in view of US 20090024757 to Proctor et al. (hereinafter “Proctor”)
Claim 32
While Cronce teaches the License agent apparatus according to claim 31 and teaches obtaining identifying information from hardware of computer system 101, Cronce fails to explicitly teach identifying an arbitrary connected device, loading a communication protocol corresponding to the identified device and using the loaded protocol for communication and data exchange.
However, Proctor teaches: identify the device connected to the device interface and to load a communication protocol corresponding to the identified device and to use the communication protocol for communication and data exchange with the device. [e.g. Proctor; Para. 0065-0074 – Proctor discloses receiving class and operating system descriptors from portable device 102 and searching portable device database 176 for a descriptor matching the received descriptor (e.g. identifying the connected device). Proctor further discloses installing the driver associated with the matching descriptor and using the enhanced or base functionality protocol supported by the installed derived for subsequent communications between host device 104 and portable device 102 (e.g. loading the communication protocol corresponding to the identified device and using the protocol for communication and data exchange).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to configure Cronce’s authorization program to identify an attached device and load the corresponding driver and protocol as taught Proctor as the combined references teach obtaining hardware identifying data for creation of machine fingerprints and automatically matching a connected device’s descriptors to an available driver and using the protocol supported by the driver. This would allow Cronce’s authorization program to obtain device identifying data from different connected devices without requiring manual device or protocol configuration as Proctor states in paragraph 0083 that the host automatically determines the supported device functionality, selects the driver and protocol and doe no require the user to change configuration settings or manually provide a driver.
Claim(s) 33 and 51 are rejected under 35 U.S.C. 103 as being unpatentable over US 20030156719 to Cronce in view of US 20140082359 to Nakhjiri et al. (hereinafter “Nakhjiri”)
Claim 33
While Cronce teaches the License agent apparatus according to claim 31, Cronce fails to explicitly teach deriving a private device key from device specific data, a random value and licensor identity information or creating the corresponding pubic device key.
However, Nakhjiri teaches: determine a private device key, priv-D-key of the device based on the specific data of the device, on a D-RND random number, and optionally on the L-UID; optionally store the L-UID and/or the D-RND for later use; and create the public device key, pub-D-key based on the private device key, priv-D-key. [e.g. Nakhjiri; Claims 17, 19, 21, 22 Para. 0025-0029, 0034-0037, 0040 – Nakhjiri discloses a private seed that may be randomly generated and maintained in a target device secure element (e.g. D-RND), using the UICC of manufacture or vendor identifier (e.g. device specific data) and MNO/service provider identifier (e.g. L-UID) as inputs to a key generation function to derive the device private key (e.g. priv-D-key). Nakhjiri further discloses maintaining the private seed in the secure element of the target device and later retrieving or using the seed to regenerate the device private key (e.g. storing D-RND for later user) and generating the corresponding ECC public device key from the device private key and elliptic curve base point (e.g. creating pub-D-key based on priv-D-key).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to derive a device key pair for Cronce’s license bound machine using Nakhjiri device seed and identifier processor because Cronce already uses machine specific data and publisher identity to bind a license request to a particular machine and Nakhjiri teaches deriving provider specific device private key from a device held seed, device ID and service provider ID. This would allow for the derivation of key from a seed that avoids storing numerous private keys from multiple providers and permits a device to generate the provider specific key when needed as disclosed in paragraphs 0024-0029 and 0035 of Nakhjiri.
Regarding claim 51 it is a method claim essentially corresponding to the above recitations, and they are rejected, at least, for the same reasons.
Claim(s) 34 and 53 are rejected under 35 U.S.C. 103 as being unpatentable over US 20030156719 to Cronce in view of US 20140082359 to Nakhjiri et al. (hereinafter “Nakhjiri”) and further in view of US 20060080528 to Ellison et al (hereinafter “Ellison)
Claim 31
While Cronce and Nakhjiri teaches the License agent apparatus according to claim 33, and teaches a device bound license request containing and corresponding device key pair the combination fails to explicitly teach signing the license container using the priv-D-key and including the corresponding pub-D-key with the container before encryption using pub-L-key.
However, Ellison teaches signing a request using the private key of the requesting platform, accompanying the signed request with a certificate containing the corresponding first platform public key and encrypting the signed request and accompanying public key certificate using the public key of the receiving platform. [e.g. Ellison; Para. 0024, 0025 – Ellison discloses a first platform creates a certification request and signs the request using private key PRKP1 (e.g. signing using priv-D-key) accompanying the request with a first platform certificate containing public key PUKP1 (e.g. including pub-D-key) and encrypting the signed request and certificate using receiving platform public key PUKP2 (e.g. encryption using pub-L-key).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above features in order to authenticate senders and protect signed information against illicit modification as disclosed by Ellision in paragraphs 0013-0014 allowing the licensor to authenticate the requesting device and public key association and verify the integrity of the request while preserving confidentiality during transfer.
Regarding claim 53 it is a method claim essentially corresponding to the above recitations, and they are rejected, at least, for the same reasons.
Claim(s) 35 is rejected under 35 U.S.C. 103 as being unpatentable over US 20030156719 to Cronce in view of US 20140082359 to Nakhjiri et al. (hereinafter “Nakhjiri”) and US 20060080528 to Ellison et al (hereinafter “Ellison) and further in view of US 20190052622 to Karroumi et al. (hereinafter “Karroumi”)
Claim 35
While Cronce, Nakhjiri and Ellison teaches the License agent apparatus according to claim 34, the combination fails to explicitly teach creating a self-signed certificate that bind D-UID to pub-D-key.
However, Karroumi teaches obtaining a unique identifier and public key, generating a certificate containing the unique identifier and public key and signing the certificate using the private key corresponding to the contained public key to create a self-signed certificate. [e.g. Karroumi; Claims 1-4, Abstract, Para. 0012-0023 – Karroumi discloses a certificate contains a unique identifier and public key and is signed using the corresponding private key (e.g. creating a self-signed D0UID -cert using D-UID, pub-D-key and priv-D-key and binding D-UID to pub-D-key).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above features in order to protect against impersonation and man-in-the-middle attacks and avoids the complexity of a centralized certificate management infrastructure as disclosed by Karroumi in paragraphs 0008-0016 and 0037, 0038.
Claim(s) 36, 38, 55 and 57 is rejected under 35 U.S.C. 103 as being unpatentable over US 20030156719 to Cronce in view of US 20140082359 to Nakhjiri et al. (hereinafter “Nakhjiri”) and further in view of US 20120131345 A1 to Dadu
Claim 36
While Cronce teaches the License agent apparatus according to claim 31, and teaches generating a license specifically for the machine identified by machine specific information and returning the resulting software license to that computer in the form of the license response document 900 Cronce fails to explicitly retrieving device specific data, D-RND, and L-UID to recreate a private device key.
However, Nakhjiri teaches: retrieving or using device specific information, a securely maintained device specific seed and a service provider identifier to regenerate a target device private key [e.g. Nakhjiri; Claims 17, 19, 22 Para. 0025-0029, 0034, 0037, 0040 – Nakhjiri discloses using the private seed (e.g. D-RND), UICC/device ID(e.g. specific device data) and MMO/service provider ID (e.g. L-UID) are to regenerate the provider specific device private key (e.g. restoring priv-D-key).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above features in order to allow for the recovery of the returned license to the intended device possessing the required seed and identifying information when needed as disclosed in paragraphs 0024-0029 and 0035 of Nakhjiri.
While Cronce and Nakhjiri teaches the License agent apparatus according to claim 31 Nakhjiri uses its recreated private key in key agreement to derive a separate profile encryption key, thus the combination fails to explicitly teach decrypting the returned software license container using the created private device key.
However, Dadu teaches encryption and decryption of licenses with the device key. [e.g. Dadu; Claim 1, Para. 0022-0024 – Dadu discloses a License Server encrypting the software license using the public key of SLM Service 112 and the SLM Service 112 decrypting the license using the corresponding private key. Dadu further discloses SLM Service 112 implemented in a hardware security engine within a chipset of computing platform 102(e.g. license container encrypted using pub-D-key and decrypted using corresponding priv-D-key)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature as OS managed licensing keys and policies are vulnerable to viruses, hackers and malicious users and to overcome this by implementing the protection by encrypting the license with key pair secured by the hardware based security engine, See Dadu Para. 001, 0002, 0009-0014, 0022-0024. This would allow the returned license of Cronce recovery to be restricted to the intended device possessing the information necessary to recreate the corresponding private key.
Claim 38
Cronce teaches the license agent apparatus according to claim 36, wherein the processing unit is further configured to allow the application to use the license contained in the license container after decrypting the license container. [e.g. Cronce; Para. 0099-0102 – Cronce discloses validated license terms control authorization of software product 215. Dadu; Claim 15, Para. 0024 – Dadu discloses after decrypting and validating the license, SLM Service 112 extracts the LEK and supplies it to Host Application 116, which uses the LEK to decrypt and access the restricted application (e.g. allowing the application to use the license after decryption)]
Regarding claim 55 it is a method claim essentially corresponding to the above recitations, and they are rejected, at least, for the same reasons.
Claim 57
Cronce teaches a method for filling an empty license container bound to a device with license relevant data, [e.g. Cronce; Para. 0062-0064, 0082-0086, 0092-0098 – Cronce request document 700 containing machine fingerprint, CustomerInfo and ProductInfo is processed by license server 102 to generate license response document 900 containing the software license and LicenseTerms 964 (e.g. an empty license container bound to the identified device and subsequently filled with license relevant data).] comprising the following steps:
decrypting the empty license container using the priv-L-key; [e.g. Cronce; Para. 0033, 0036,– Cronce discloses license request 700 is encrypted using the product public key and decrypted at license server 102 using the corresponding product private key (e.g. decrypting the empty license container using a corresponding private key).]
Cronce does not explicitly teach that the public key used for this encryption is the public licensor key as Cronce identifies the encryption key as the public key associated with the software product.
However, Cronce separately discloses a publisher and licensor public and private key pair including a publisher certificate 502 containing the publisher public key and teaches that license server 102 is operated by or on behalf of a key authority for the publisher and has access to the corresponding publisher private key. [e.g. Cronce; Para. 00521, 0062, 0094, 0108, 0111 – Cronce discloses the publisher certificate and publisher key pair and the publisher private key being available to the back-end server 192 for handling license request.]
Therefore, it would have been obvious to encrypt Cronce’s license request using the publisher/licensor public key as opposed to the product public key because Cronce already encrypts the request with a public key such that the license server possessing the corresponding private key can recover the request and also Cronce teaches that the same back-end license server has access to the publisher/licensor private key; see Cronce Para. 0033, 0064 and 0094. Thus using the disclosed publisher public key for the same encryption operation would have predictably protected the request for receipt and decryption by the publisher’s license server
Cronce further teaches:
filling the license container with at least one data of the group comprising at least a D-UID of the device to which the license should be bound, a D-UID-cert, a link value based on the application to be licensed, a license parameter, license specifications, and a license key of the application; [e.g. Cronce; Para. 0092-0098 – Cronce discloses license server 102 extracts CustomerInfo and ProductInfo from request document 700, creates License Terms 964 and generates license response document 900 containing licensed features, start date, expiration date and node lock conditions (e.g. filing the license container with at least a license parameter and/or license specification).]
While Cronce teaches the method according to claim 57, Cronce fails to explicitly teaches encrypting the filled license container with the pub-D-key.
However, Dadu teaches encrypting a completed software license using the public key associated with the licensing service of the target computing platform. [e.g. Dadu; Claim 15, Para. 0022-0024 – Dadu discloses a License Server creates the completed software licenses and encrypts the software license using the public key of SLM Service 112 supplied from the hardware security engine of computing platform 102(e.g. encrypting the filled license container with pub-D-key)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature as OS managed licensing keys and policies are vulnerable to viruses, hackers and malicious users and to overcome this by implementing the protection by encrypting the license with key pair secured by the hardware based security engine, See Dadu Para. 001, 0002, 0009-0014, 0022-0024. This would allow the returned license of Cronce recovery to be restricted to the intended device possessing the corresponding private key.
While Cronce and Dadu teaches the method according to claim 57 the combination fails to explicitly using, D-RND, and L-UID as inputs to generate D-UID.
However, Nakhjiri teaches: using a device held private seed, device identifying information and provider identifying value as inputs to generate a reproducible provider specific device value. [e.g. Nakhjiri; Para. 0025-0029, 0034, 0037, 0040 – Nakhjiri discloses using the private seed (e.g. D-RND), UICC/device ID(e.g. specific device data) and MMO/service provider ID (e.g. L-UID) are to are provided jointly to a key derivation function.]
While Nakhjiri is not relied upon for explicitly teaching a D-UID, Nakhjiri does teach that a device held random seed and provider identity were known additional inputs for generating a reproducible value specific to the relationship between a device and provider.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above features as the retained input approach permits the provider specific value to be regenerated when needed as disclosed in paragraphs 0024-0029 and 0035 of Nakhjiri.
Claim(s) 37 and 46 are rejected under 35 U.S.C. 103 as being unpatentable over US 20030156719 to Cronce in view of in view of US 20120131345 A1 to Dadu
Claim 37
Cronce teaches the license agent apparatus according to claim 31, wherein the processing unit is further configured to receive a license container containing a license for the application. [e.g. Cronce; Para. 0038-0040, 0093-0099 – Cronce discloses transferring license response document 900 to authorization program 214 on computer system 101 (e.g. receiving a license container), response document 900 being the actual software license document containing the LicenseTerms 964 for software product 215 (e.g. containing a license for the application).]
While Cronce teaches the License agent apparatus according to claim 31 Cronce fails to explicitly teach storing the received protected license container on the connected device.
However, Dadu teaches storing a received protected software license on the target computing platform. [e.g. Dadu; Claim 15, Para. 0023– Dadu discloses the signed and encrypted software license is received and stored in memory of computing platform 102 or secure storage 109 (e.g. storing the license container on the device)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature as OS managed licensing keys and policies are vulnerable to viruses, hackers and malicious users and to overcome this by implementing the protection by encrypting the license with key pair secured by the hardware based security engine, See Dadu Para. 001, 0002, 0009-0014, 0022-0024. This would allow the returned license of Cronce recovery to be restricted to the intended device possessing the information necessary and ensure the license is locally stored and protected.
Claim 46
Cronce teaches a licensor device comprising
a processor unit being configured to receive a license container; [e.g. Cronce; Para. 0028, 0036. 0047 – Cronce discloses back end license server 102 controlled by a key authority and configured to receive and process XML license request document 700 (e.g. licensor device comprising a processor unit configured to receive a license container)]
decrypt the license container using a private key; [e.g. Cronce; Para. 0033, 0036 – Cronce discloses encrypting license request document 700 using the product public key and upon receipt by license server 102, decrypting the request using the corresponding product private key (e.g. decrypting the received license container using a corresponding private key).]
Cronce does not explicitly teach that the private key used for this decryption is the private licensor key as Cronce identifies the decryption key as the private key associated with the software product.
However, Cronce separately discloses a publisher and licensor public and private key pair including a publisher certificate 502 containing the publisher public key and teaches that license server 102 is operated by or on behalf of a key authority for the publisher and has access to the corresponding publisher private key. [e.g. Cronce; Para. 00521, 0062, 0094, 0108, 0111 – Cronce discloses the publisher certificate and publisher key pair and the publisher private key being available to the back-end server 192 for handling license request.]
Therefore, it would have been obvious to encrypt Cronce’s license request using the publisher/licensor public key as opposed to the product public key because Cronce already encrypts the request with a public key such that the license server possessing the corresponding private key can recover the request and also Cronce teaches that the same back-end license server has access to the publisher/licensor private key; see Cronce Para. 0033, 0064 and 0094. Thus using the disclosed publisher private key for the same decryption operation would have predictably protected the request for receipt and decryption by the publisher’s license server
Cronce further teaches:
fill the license container with at least one data of the group comprising at least a D-UID, a link value based on the application to be licensed, license parameters, and license keys of the application; [e.g. Cronce; Para. 0092-0098 – Cronce discloses license server 102 extracts CustomerInfo and ProductInfo from request document 700, creates License Terms 964 and generates license response document 900 containing licensed features, start date, expiration date and node lock conditions (e.g. filing the license container with at least a license parameter and/or license specification).]
While Cronce teaches the Licensor device of claim 46 Cronce fails to explicitly teach encrypt the filled license container with the public device key.
However, Dadu teaches a License Server creating a completed software license for a particular computing platform and encrypting the license using the public key of the SLM Service of the target computing platform. [e.g. Dadu; Claim 15, Para. 0022– Dadu discloses the License Server creates a license containing a unique application identifier, user information, lease period and LEK and encrypts the license using the SLM Service public key supplied by the Host Application of the computing platform (e.g. encrypting the filled license container with the public device key)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature as OS managed licensing keys and policies are vulnerable to viruses, hackers and malicious users and to overcome this by implementing the protection by encrypting the license with key pair secured by the hardware based security engine, See Dadu Para. 001, 0002, 0009-0014, 0022-0024. This would allow the returned license of Cronce recovery to be restricted to the intended device possessing the information necessary and ensure the license is locally stored and protected.
Claim(s) 42 is rejected under 35 U.S.C. 103 as being unpatentable over US 20190026442 A1 to Pearlman et al. (hereinafter “Pearlman”) in view of US 20040177361 to Bernhard et al. (hereinafter “Bernhard”)
Claim 42
While Perlman teaches the device according to claim 40, Perlman fails to explicitly teach carrying out communication using a generic API
However, Bernhard teaches: a generic API providing device independent access and communication with different peripheral devices through corresponding native device drivers [e.g. Bernhard; Para. 0014-0021 – Bernhard discloses generic API 230 receives an application request, identifies the requested peripheral device, invokes the native driver corresponding to that device and permits data to be sent to or received from the peripheral device (e.g. communication using a generic API).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above features in order to allow additional devices types to be supported without requiring the application to implement a different interface for every native driver as disclosed in paragraphs 0021 of Bernhard.
Claim(s) 43 and 48 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190026442 A1 to Pearlman et al. (hereinafter “Pearlman”) in view of US 20120131345 A1 to Dadu
Claim 43
While Perlman teaches the device according to claim 40 and teaches storing device bound licensing data in persistent device firmware, Perlman fails to explicitly teach storing the license container in storage capacity of a cryptographic controller
However, Dadu teaches a hardware implemented security engine containing protected secure storage and storing software license information in that secure environment. [e.g. Dadu; Para. 0009, 0012-0014, 0020, 0023 – Dadu discloses Security Engine 108 is implemented in the platform chipset independently of ordinary host software and includes secure storage 109 for cryptographic keys and software licensing information with the protected software license capable of being stored in secure storage 109 (e.g. cryptographic controller having storage capacity containing the license container)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature as OS managed licensing keys and policies are vulnerable to viruses, hackers and malicious users and to overcome this by implementing the protection by encrypting the license with key pair secured by the hardware based security engine, See Dadu Para. 001, 0002, 0009-0014, 0022-0024.
Claim 48
While Perlman teaches the system according to claim 47, Perlman fails to explicitly teach the claimed hardware and interfaces for communication among the application, license agent and licensor device.
However, Dadu teaches a storage medium containing the application and a processor for executing the application, an application interface between the application and licensing apparatus and bidirectional communication between platform licensing components and license server.. [e.g. Dadu; Para. 0011-0024 – Dadu discloses computing platform 102 includes memory and a processor executing Host Application 116, protected software, Security Engine Interface 114 communicates between Host Application 116 and SLM Service 112 and request, permits, licenses and keys are transferred among License Server 120, Host Application 116 and SLM Service 112 (e.g. claimed storage, processor, application interface and bidirectional licensor communications.)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature as OS managed licensing keys and policies are vulnerable to viruses, hackers and malicious users and to overcome this by implementing the protection by encrypting the license with key pair secured by the hardware based security engine, See Dadu Para. 001, 0002, 0009-0014, 0022-0024.
Claim(s) 44 is rejected under 35 U.S.C. 103 as being unpatentable over US 20190026442 A1 to Pearlman et al. (hereinafter “Pearlman”) in view of US 20090063756 to Asipov
Claim 44
While Perlman teaches the device according to claim 40, Perlman fails to explicitly teach a non-resettable counter restricted to a start or limit value contained with a license container.
However, Asipov teaches a device counter used to track a predetermined number of authorized software uses, changing the counter through use of the application, preventing effective resetting of counted uses through irreversible exhaustion of flash sectors and storing the licensed use limit in protected license information. [e.g. Asipov; Para. 0015, 0030, 0035, 0036, 0040-0045 – Asipov discloses license information contains a predetermined number of permitted executions, flash counter vectors record consumed application uses, the counter state changes as the software is used and application use is limited or disabled once the licensed number of uses has been consumed (e.g. cryptographic controller having storage capacity containing the license container)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature in order to avoid the costly and problematic issues with conventional special licensing devices for electronically distributed software by using a flash storage device to prevent unauthorized software uses, See Asipov Para. 0001-0004, 0040-0045, 0063-0065.
Claim(s) 45 is rejected under 35 U.S.C. 103 as being unpatentable over US 20190026442 A1 to Pearlman et al. (hereinafter “Pearlman”) in view of US 20090063756 to Asipov and further in view of US 20080282088 to Rudelic et al. (hereinafter “Rudelic”)
Claim 45
While Perlman and Asipov teaches the device according to claim 44, the combination fails to explicitly teach locating the counter in a restricted area accessible using a private device key.
However, Rudelic teaches a protected range of nonvolatile and flash memory and use of an internally maintained private key to authorize access to and authenticate operations directed to the protected range. [e.g. Rudelic; Claims 1 and 3, Para. 0018 – Rudelic discloses a private key retained internally by the nonvolatile memory is used to authorize access to a range of data and authenticate commands directed to a protected flash memory range (e.g. restricted area accessible using priv-D-key)].
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature in order to authorize access to a protected range and to authenticate memory commands before protected data are accessed, See Rudelic Para. 0018.
Claim(s) 50 is rejected under 35 U.S.C. 103 as being unpatentable over US 20120131345 A1 to Dadu in view of US 20070172065 to Lee et al. (hereinafter “Lee”)
Claim 50
While Dadu teaches the license container according to claim 49 and teaches a software license encrypted using the public key of the licensing service of the target computing platform and recoverable using the corresponding private device key, Dadu fails to explicitly teach a separate extension container linked to the license container and containing a current value of a counter stored in the device.
However, Lee teaches a rights object corresponding to licensed digital content and a separate state information object corresponding to the rights object wherein the state information object comprises the current value of a usage counter and protecting the rights objected and associated state information object using the public key of the receiving device. [e.g. Lee; Para. 0006, 0030, 0035, 0046– Lee discloses a stateful rights object, a state information object containing state corresponding to the RO is maintained and transferred separately from the RO with the date information containing the current state of constraints explicitly including count and time-count (e.g. extension container linked to the license container and comprising a current counter value.) Lee further discloses the server encodes the RO corresponding to the received RO identifier and the state information object using the public key of the second device before transfer to that device. (e.g. linked extension container protected for access by the corresponding private device key)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature as when a license is subject to usage restrictions such as a permitted number of uses it is necessary to inspect and record how many of those rights have already been used, See Lee Para. 0006.
Claim(s) 52 is rejected under 35 U.S.C. 103 as being unpatentable over US 20030156719 to Cronce in view of US 20140082359 to Nakhjiri et al. (hereinafter “Nakhjiri”) and US 20090024757 to Proctor et al. (hereinafter “Proctor”) and further in view of US 20040177361 to Bernhard et al. (hereinafter “Bernhard”)
Claim 52
While Cronce and Nakhjiri teaches the method according to claim 51, the combination fails to explicitly teach identifying an arbitrary connected device, loading a communication protocol corresponding to the identified device and using the loaded protocol for communication and data exchange.
However, Proctor teaches: identify the device connected to the device interface and to load a communication protocol corresponding to the identified device and to use the communication protocol for communication and data exchange with the device. [e.g. Proctor; Para. 0065-0074 – Proctor discloses receiving class and operating system descriptors from portable device 102 and searching portable device database 176 for a descriptor matching the received descriptor (e.g. identifying the connected device). Proctor further discloses installing the driver associated with the matching descriptor and using the enhanced or base functionality protocol supported by the installed derived for subsequent communications between host device 104 and portable device 102 (e.g. loading the communication protocol corresponding to the identified device and using the protocol for communication and data exchange).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to configure Cronce’s authorization program to identify an attached device and load the corresponding driver and protocol as taught Proctor as the combined references teach obtaining hardware identifying data for creation of machine fingerprints and automatically matching a connected device’s descriptors to an available driver and using the protocol supported by the driver. This would allow Cronce’s authorization program to obtain device identifying data from different connected devices without requiring manual device or protocol configuration as Proctor states in paragraph 0083 that the host automatically determines the supported device functionality, selects the driver and protocol and doe no require the user to change configuration settings or manually provide a driver.
While Cronce, Nakhjiri and Proctor teaches the method according to claim 51, Perlman fails to explicitly teach carrying out communication using a generic API
However, Bernhard teaches: a generic API providing device independent access and communication with different peripheral devices through corresponding native device drivers [e.g. Bernhard; Para. 0014-0021 – Bernhard discloses generic API 230 receives an application request, identifies the requested peripheral device, invokes the native driver corresponding to that device and permits data to be sent to or received from the peripheral device (e.g. communication using a generic AP).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above features in order to allow additional devices types to be supported without requiring the application to implement a different interface for every native driver as disclosed in paragraphs 0021 of Bernhard.
Claim(s) 54 are rejected under 35 U.S.C. 103 as being unpatentable over US 20030156719 to Cronce in view of US 20140082359 to Nakhjiri et al. in view of (hereinafter “Nakhjiri”) and further in view of US 20190052622 to Karroumi et al. (hereinafter “Karroumi”)
Claim 54
While Cronce and Nakhjiri teaches the method according to claim 51 including generation of the device identity and the device public and private key pair and the license request document includes the product certificate, the combination fails to explicitly teach creating a self-signed certificate that bind D-UID to pub-D-key.
However, Karroumi teaches obtaining a unique identifier and public key, generating a certificate containing the unique identifier and public key and signing the certificate using the private key corresponding to the contained public key to create a self-signed certificate. [e.g. Karroumi; Claims 1-4, Abstract, Para. 0012-0023 – Karroumi discloses a certificate contains a unique identifier and public key and is signed using the corresponding private key (e.g. creating a self-signed D0UID -cert using D-UID, pub-D-key and priv-D-key and binding D-UID to pub-D-key).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above features in order to protect against impersonation and man-in-the-middle attacks and avoids the complexity of a centralized certificate management infrastructure as disclosed by Karroumi in paragraphs 0008-0016 and 0037, 0038.
Claim(s) 36, 38, 55 and 57 is rejected under 35 U.S.C. 103 as being unpatentable over US 20030156719 to Cronce in view of US 20120131345 A1 to Dadu and further in view of US 20140082359 to Nakhjiri et al. (hereinafter “Nakhjiri”)
Claim 36
While Cronce teaches the License agent apparatus according to claim 31, and teaches generating a license specifically for the machine identified by machine specific information and returning the resulting software license to that computer in the form of the license response document 900 er Cronce fails to explicitly retrieving device specific data, D-RND, and L-UID to recreate a private device key.
However, Nakhjiri teaches: retrieving or using device specific information, a securely maintained device specific seed and a service provider identifier to regenerate a target device private key [e.g. Nakhjiri; Claims 17, 19, 22 Para. 0025-0029, 0034, 0037, 0040 – Nakhjiri discloses using the private seed (e.g. D-RND), UICC/device ID(e.g. specific device data) and MMO/service provider ID (e.g. L-UID) are to regenerate the provider specific device private key (e.g. restoring priv-D-key).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above features in order to allow for the recovery of the returned license to the intended device possessing the required seed and identifying information when needed as disclosed in paragraphs 0024-0029 and 0035 of Nakhjiri.
While Cronce and Nakhjiri teaches the License agent apparatus according to claim 31 Nakhjiri uses its recreated private key in key agreement to derive a separate profile encryption key, thus the combination fails to explicitly teach decrypting the returned software license container using the created private device key.
However, Dadu teaches encryption and decryption of licenses with the device key. [e.g. Dadu; Claim 1, Para. 0022-0024 – Dadu discloses a License Server encrypting the software license using the public key of SLM Service 112 and the SLM Service 112 decrypting the license using the corresponding private key. Dadu further discloses SLM Service 112 implemented in a hardware security engine within a chipset of computing platform 102(e.g. license container encrypted using pub-D-key and decrypted using corresponding priv-D-key)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature as OS managed licensing keys and policies are vulnerable to viruses, hackers and malicious users and to overcome this by implementing the protection by encrypting the license with key pair secured by the hardware based security engine, See Dadu Para. 001, 0002, 0009-0014, 0022-0024. This would allow the returned license of Cronce recovery to be restricted to the intended device possessing the information necessary to recreate the corresponding private key.
Claim 38
Cronce and Dadu teaches the license agent apparatus according to claim 36, wherein the processing unit is further configured to allow the application to use the license contained in the license container after decrypting the license container. [e.g. Cronce; Para. 0099-0102 – Cronce discloses validated license terms control authorization of software product 215. Dadu; Claim 15, Para. 0024 – Dadu discloses after decrypting and validating the license, SLM Service 112 extracts the LEK and supplies it to Host Application 116, which uses the LEK to decrypt and access the restricted application (e.g. allowing the application to use the license after decryption)]
Regarding claim 55 it is a method claim essentially corresponding to the above recitations, and they are rejected, at least, for the same reasons.
Claim 57
Cronce teaches a method for filling an empty license container bound to a device with license relevant data, [e.g. Cronce; Para. 0062-0064, 0082-0086, 0092-0098 – Cronce request document 700 containing machine fingerprint, CustomerInfo and ProductInfo is processed by license server 102 to generate license response document 900 containing the software license and LicenseTerms 964 (e.g. an empty license container bound to the identified device and subsequently filled with license relevant data).] comprising the following steps:
decrypting the empty license container using the priv-L-key; [e.g. Cronce; Para. 0033, 0036,– Cronce discloses license request 700 is encrypted using the product public key and decrypted at license server 102 using the corresponding product private key (e.g. decrypting the empty license container using a corresponding private key).]
Cronce does not explicitly teach that the public key used for this encryption is the public licensor key as Cronce identifies the encryption key as the public key associated with the software product.
However, Cronce separately discloses a publisher and licensor public and private key pair including a publisher certificate 502 containing the publisher public key and teaches that license server 102 is operated by or on behalf of a key authority for the publisher and has access to the corresponding publisher private key. [e.g. Cronce; Para. 00521, 0062, 0094, 0108, 0111 – Cronce discloses the publisher certificate and publisher key pair and the publisher private key being available to the back-end server 192 for handling license request.]
Therefore, it would have been obvious to encrypt Cronce’s license request using the publisher/licensor public key as opposed to the product public key because Cronce already encrypts the request with a public key such that the license server possessing the corresponding private key can recover the request and also Cronce teaches that the same back-end license server has access to the publisher/licensor private key; see Cronce Para. 0033, 0064 and 0094. Thus using the disclosed publisher public key for the same encryption operation would have predictably protected the request for receipt and decryption by the publisher’s license server
filling the license container with at least one data of the group comprising at least a D-UID of the device to which the license should be bound, a D-UID-cert, a link value based on the application to be licensed, a license parameter, license specifications, and a license key of the application; [e.g. Cronce; Para. 0092-0098 – Cronce discloses license server 102 extracts CustomerInfo and ProductInfo from request document 700, creates License Terms 964 and generates license response document 900 containing licensed features, start date, expiration date and node lock conditions (e.g. filing the license container with at least a license parameter and/or license specification).]
While Cronce teaches the method according to claim 57, Cronce fails to explicitly teach encrypting the filled license container with the pub-D-key.
However, Dadu teaches encrypting a completed software license using the public key associated with the licensing service of the target computing platform. [e.g. Dadu; Claim 15, Para. 0022-0024 – Dadu discloses a License Server creates the completed software licenses and encrypts the software license using the public key of SLM Service 112 supplied from the hardware security engine of computing platform 102(e.g. encrypting the filled license container with pub-D-key)].
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature as OS managed licensing keys and policies are vulnerable to viruses, hackers and malicious users and to overcome this by implementing the protection by encrypting the license with key pair secured by the hardware based security engine, See Dadu Para. 001, 0002, 0009-0014, 0022-0024. This would allow the returned license of Cronce recovery to be restricted to the intended device possessing the corresponding private key.
While Cronce and Dadu teaches the method according to claim 57 the combination fails to explicitly using, D-RND, and L-UID as inputs to generate D-UID.
However, Nakhjiri teaches: using a device held private seed, device identifying information and provider identifying value as inputs to generate a reproducible provider specific device value. [e.g. Nakhjiri; Para. 0025-0029, 0034, 0037, 0040 – Nakhjiri discloses using the private seed (e.g. D-RND), UICC/device ID(e.g. specific device data) and MMO/service provider ID (e.g. L-UID) are to are provided jointly to a key derivation function.]
While Nakhjiri is not relied upon for explicitly teaching a D-UID, Nakhjiri does teach that a device held random seed and provider identity were known additional inputs for generating a reproducible value specific to the relationship between a device and provider.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above features as the retained input approach permits the provider specific value to be regenerated when needed as disclosed in paragraphs 0024-0029 and 0035 of Nakhjiri.
Claim(s) 58 is rejected under 35 U.S.C. 103 as being unpatentable US 20120131345 A1 to Dadu in view of US 20140082359 to Nakhjiri et al. (hereinafter “Nakhjiri”)
Claim 58
Dadu teaches a method for using a license contained in an encrypted license container for an application, comprising the following steps:
receiving a request for a license by an application; determining a license container containing the license for the application; decrypting the license container using the priv-D-key of the device; verifying the license container using the pub-L-key; allowing the use of the license for the application requested the license use; providing a license key contained in the license container to the application. [e.g. Dadu; Claims 15 Para. 0012-0022-0024 – Dadu discloses that Host Application 116 initiates processing of the encrypted license associated with the requested restricted software, SLM Service 112 decrypts the license using a SLM Service private key, verifying the License Server signature using the License Server public key, extracting LEK and supplying the LEK to the Host Application 116 for accessing the restricted software (e.g. request, license determination, priv-D-key decryption, pub-L-key verification, allowing use and providing the license key).]
While Dadu teaches the method according to claim 58, Dadu fails to explicitly teach recreating the SLM Service private key from device specific data, L-UID, and D-RND.
However, Nakhjiri teaches: using a securely maintained private seed, target device identifier and provider identifier to create a provider specific private device key when the key is required. [e.g. Nakhjiri; Claims 17, 19, 21, 22 Para. 0025-0029, 0034-0037, 0040 – Nakhjiri discloses a private seed that may be randomly generated and maintained in a target device secure element (e.g. D-RND), using the UICC of manufacture or vendor identifier (e.g. device specific data) and MNO/service provider identifier (e.g. L-UID) as inputs to a key generation function to derive the device private key (e.g. priv-D-key).]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the features above in order to allow for the derivation of key from a seed that avoids storing numerous private keys from multiple providers and permits a device to generate the provider specific key when needed as disclosed in paragraphs 0024-0029 and 0035 of Nakhjiri.
Claim(s) 59 is rejected under 35 U.S.C. 103 as being unpatentable US 20120131345 A1 to Dadu in view of US 20140082359 to Nakhjiri et al. (hereinafter “Nakhjiri”) and further in view of US 20090063756 to Asipov
Claim 59
While Dadu and Nakhjiri teaches the method according to claim 58, the combination fails to explicitly teach a non-resettable counter restricted to a start or limit value contained with a license container.
However, Asipov teaches a device counter used to track a predetermined number of authorized software uses, changing the counter through use of the application, preventing effective resetting of counted uses through irreversible exhaustion of flash sectors and storing the licensed use limit in protected license information. [e.g. Asipov; Para. 0015, 0030, 0035, 0036, 0040-0045 – Asipov discloses license information contains a predetermined number of permitted executions, flash counter vectors record consumed application uses, the counter state changes as the software is used and application use is limited or disabled once the licensed number of uses has been consumed (e.g. device counter changed through application use and checked against a limit value stored in the license container)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature in order to avoid the costly and problematic issues with conventional special licensing devices for electronically distributed software by using a flash storage device to prevent unauthorized software uses, See Asipov Para. 0001-0004, 0040-0045, 0063-0065.
Claim(s) 60 is rejected under 35 U.S.C. 103 as being unpatentable US 20120131345 A1 to Dadu in view of US 20140082359 to Nakhjiri et al. (hereinafter “Nakhjiri”) and US 20090063756 to Asipov and further in view of US 20090006868 to Alkove et al. (hereinafter “Alkove”)
Claim 60
While Dadu, Nakhjiri and Asipov teaches the method according to claim 59 including device bound license, protecting software licensing information intended for a particular computing platform using the public key of the licensing service in that platform hardware Security engine, recreated private device key, device resident licensed use counter and license use limits, the combination fails to explicitly teach maintaining a backup value of the current use counter in an extension container, comparing the current use counter value with the stored backup before allowing use and overriding the backup value with the new current use counter version.
However, Alkove teaches maintaining DRM state information in local storage in association with the corresponding license and including a stored counter value corresponding to a secure hardware counter, retrieving and comparing the secure counter and stored counter value, permitting the protected DRM operations when the values correspond, chaining the secure counter and storing the changed counter value with the updated DRM state. [e.g. Alkove; Para. 0091-0101, 0117-0125 – Alkove discloses license associated DRM state includes a counter value corresponding to a secure hardware counter, the secure counter and stored counter value are read and compared, the protected operation is permitted when the match and the secure counter and corresponding stored counter value are subsequently updated (e.g. retrieving a counter and backup, comparing the values, allowing use when equal, changing the counter and overriding/updating the backup value)]
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to include the above feature in order to protect DRM state again manipulation in an open computing environment as hostile modifications of DRM software and state are threats to DRM enforcement and the solution provides tamper resistant and robust secure storage techniques to address such threat while providing cryptographic verification that fails on manipulation of locally stored DRM data that disallows operations, See Alkove Para. 0001-0004, 0025, 0107.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER C HARRIS whose telephone number is (571)270-7841. The examiner can normally be reached Monday through Friday between 8:00 AM to 4:00 PM CST.
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, Jeffrey L Nickerson can be reached on (469) 295-9235. 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.
/CHRISTOPHER C HARRIS/Primary Examiner, Art Unit 2432
Prosecution Insights