DETAILED ACTION
Claims 1-15 are cancelled. Claims 16-28 are new. Claims 16-28 are pending in the application.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Should applicant desire to obtain the benefit of foreign priority under 35 U.S.C. 119(a)-(d) prior to declaration of an interference, a certified English translation of the foreign application must be submitted in reply to this action. 37 CFR 41.154(b) and 41.202(e).
Failure to provide a certified translation may result in no benefit being accorded for the non-English application.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“a computer configured to operating a control unit” and “computer configured to:” in claim 27.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 16-22 and 24-28 are rejected under 35 U.S.C. 103 as being unpatentable over Fanton et al. (US 2015/0193614 A1; hereinafter Fanton) in view of Campagna et al. (US 2018/0183774 A1; hereinafter Campagna).
With respect to claim 16, Fanton teaches: A method for operating a control unit on which multiple applications are executed (see e.g. Fanton, Fig. 1-2; paragraph 33), the method comprising the following steps:
obtaining, using a reference (see e.g. Fanton, paragraph 19: “hooks”) stored [permanently] in the control unit (see e.g. Fanton, paragraph 49: “multi-level whitelist authentication system 100 includes… a kernel mode driver 160”; and paragraph 19: “a kernel-level driver, which intercepts or "hooks"”), a first code block (see e.g. Fanton, paragraph 36: “code module”; paragraph 19: “a kernel-level driver, which intercepts or "hooks" certain system Application Programming Interface (API) calls in order to monitor the creation of processes prior to code execution. The kernel-level driver may also intercept and monitor the loading of code modules by running processes”; and paragraph 52: “kernel mode driver 115 hooks low level operating system APIs to intercept various OS operations, such as process creation, module loading, and file system input/output (I/O) activity”) of a first application (see e.g. Fanton, paragraph 36: “code modules include executable objects… code module objects, such as visual basic scripts, JavaScript, Windows-based scripts, Java applets, and/or the like, are intended to be encompassed by the phrase "code module." Common file extensions of executable objects include, but are not limited to, .exe, .com, .sys, .dll, .scr, .cpl, .api, .drv, .bpl and/or the like”), the first code block containing executable program code of the first application (see e.g. Fanton, paragraph 36: “"code module" generally refers to any file that contains information that may be interpreted by a computer system. Examples of code modules include executable objects”);
checking, using verification information (see e.g. Fanton, paragraph 48: “whitelist" generally refers to an access control mechanism that may identify a set of one or more code modules approved for execution on one or more computer systems”; and paragraph 52: “multi-level whitelist authentication system 100 first attempts to authenticate the code module with reference to the local whitelist 135”) stored [permanently] in the control unit (see e.g. Fanton, paragraph 48: “whitelist may be stored in a memory store or a data store resident in local memory”), whether the first code block is in a version corresponding to the verification information stored [permanently] in the control unit (see e.g. Fanton, paragraph 52: “authenticate the code module with reference to the local whitelist 135 (e.g., calculate a content authenticator value associated with the code module and compare the calculated value to the expected value stored in the local whitelist 135)”; and paragraph 75: “At decision block 320, a determination may then be made as to whether the code module is authorized to execute. According to one embodiment, a multi-level whitelisting approach may be used”);
approving, in response to a result of the check of the first code block being positive (see e.g. Fanton, paragraph 76: “If the request is granted, control flow continues along the "Yes" path exiting decision block 320 to block 345”), the program code in the first code block for execution (see e.g. Fanton, paragraph 77: “At block 345, a decision has previously been made that the code module in question may continue to load and execute in the normal fashion. In one embodiment, this means that the code module is granted access to system resources such as memory, processors, and/or the like”);
obtaining, at least using a reference in the first code block (see e.g. Fanton, paragraph 20: “a kernel mode driver intercepts and monitors the loading of dependent code modules by running processes”), a transfer block (see e.g. Fanton, paragraph 20: “attempt by the running process to load and execute the dependent code module”) which contains a reference to a further code block (see e.g. Fanton, paragraph 20: “dependent code modules… an attempt by the running process to load and execute the dependent code module within the address space of the running process… Dependent code modules may include code modules that can be loaded and executed from within an existing process (e.g., modules with a .dll extension)”) of a further application (see e.g. Fanton, paragraph 36: “code modules include executable objects… code module objects, such as visual basic scripts, JavaScript, Windows-based scripts, Java applets, and/or the like, are intended to be encompassed by the phrase "code module." Common file extensions of executable objects include, but are not limited to, .exe, .com, .sys, .dll, .scr, .cpl, .api, .drv, .bpl and/or the like”), the further code block containing executable program code of the further application (see e.g. Fanton, paragraph 20: “Dependent code modules may include code modules that can be loaded and executed from within an existing process (e.g., modules with a .dll extension)”);
Note that, the attempt by the running process to load and execute the dependent code module (see e.g. Fanton, paragraph 20) is an attempt to transfer execution flow to the dependent code module (i.e. a “transfer block” within the execution flow).
checking, at least using verification information stored in the first code block (see e.g. Fanton, paragraph 20: “identity or type of the code module or running process that initiated the load request at issue”), whether the transfer block is in a version corresponding to the verification information stored in the first code block (see e.g. Fanton, paragraph 20: “kernel mode driver may take into consideration in connection with allowing or denying the loading of the dependent code module, the identity or type of the code module or running process that initiated the load request at issue… the dependent code module may be authenticated with reference to a multilevel whitelist architecture”; paragraph 48: “The term "whitelist" generally refers to an access control mechanism that may identify a set of one or more code modules approved for execution on one or more computer systems. In some embodiments, a whitelist may also include information identifying a set of one or more code modules that are not approved for execution”; and paragraph 52: “authenticate the code module with reference to the local whitelist 135 (e.g., calculate a content authenticator value associated with the code module and compare the calculated value to the expected value stored in the local whitelist 135)”); and
obtaining, in response to a result of the check of the transfer block being positive (see e.g. Fanton, paragraph 20: “allowing or denying the loading of the dependent code module… dependent code module may be authenticated with reference to a multilevel whitelist architecture”; and paragraph 76: “If the request is granted, control flow continues along the "Yes" path exiting decision block 320 to block 345”), the further code block of the further application using the reference in the transfer block (see e.g. Fanton, paragraph 20: “loading of a dependent code module by a running process represents an attempt by the running process to load and execute the dependent code module within the address space of the running process”; and paragraph 77: “At block 345, a decision has previously been made that the code module in question may continue to load and execute in the normal fashion”).
Even though Fanton discloses storing references and information used for verification purposes in a control unit (see e.g. Fanton, paragraphs 66-70; Fig. 2), Fanton does not explicitly disclose such storage being “permanent”.
However, Campagna teaches storing such information permanently (see e.g. Campagna, paragraph 62: “Each tree-node record includes one or more pointers that reference child nodes”; paragraph 70: “The one-time-use keys may be used to generate digital signatures, and the digital signatures may be verified using the Merkle tree by confirming the hashes of the public key pairs against the root of the Merkle tree which is owned by the signature authority”; and paragraph 101: “permanently containing, storing, transmitting, and retrieving computer-readable information”).
Fanton and Campagna are analogous art because they are in the same field of endeavor: code verification associated with dependent code execution. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Fanton with the teachings of Campagna. The motivation/suggestion would be to improve data retention and processing efficiency.
With respect to claim 17, Fanton as modified teaches: The method according to claim 16, further comprising:
checking, using verification information in the transfer block (see e.g. Fanton, paragraph 20: “identity or type of the code module or running process that initiated the load request at issue”), whether the further code block is in a version corresponding to the verification information in the transfer block (see e.g. Fanton, paragraph 20: “kernel mode driver may take into consideration in connection with allowing or denying the loading of the dependent code module, the identity or type of the code module or running process that initiated the load request at issue… the dependent code module may be authenticated with reference to a multilevel whitelist architecture”); and
approving, in response to a result of the check of the further code block being positive, the program code in the further code block for execution (see e.g. Fanton, paragraph 20: “allowing or denying the loading of the dependent code module… dependent code module may be authenticated with reference to a multilevel whitelist architecture”; paragraph 76: “If the request is granted, control flow continues along the "Yes" path exiting decision block 320 to block 345”; and paragraph 77: “At block 345, a decision has previously been made that the code module in question may continue to load and execute in the normal fashion”).
With respect to claim 18, Fanton as modified teaches: The method according to claim 16, further comprising:
obtaining, using the reference in the first code block (see e.g. Fanton, paragraph 20: “a kernel mode driver intercepts and monitors the loading of dependent code modules by running processes”), a reference block (see e.g. Fanton, paragraph 20: “attempt by the running process to load and execute the dependent code module”);
Note that, the attempt by the running process to load and execute the dependent code module (see e.g. Fanton, paragraph 20) is a reference in the execution flow to the dependent code module (i.e. a “reference block” within the execution flow).
checking, using the verification information stored in the first code block (see e.g. Fanton, paragraph 20: “identity or type of the code module or running process that initiated the load request at issue”), whether the reference block is in a version corresponding to the verification information stored in the first code block (see e.g. Fanton, paragraph 20: “kernel mode driver may take into consideration in connection with allowing or denying the loading of the dependent code module, the identity or type of the code module or running process that initiated the load request at issue… the dependent code module may be authenticated with reference to a multilevel whitelist architecture”; paragraph 48: “The term "whitelist" generally refers to an access control mechanism that may identify a set of one or more code modules approved for execution on one or more computer systems. In some embodiments, a whitelist may also include information identifying a set of one or more code modules that are not approved for execution”; and paragraph 52: “authenticate the code module with reference to the local whitelist 135 (e.g., calculate a content authenticator value associated with the code module and compare the calculated value to the expected value stored in the local whitelist 135)”); and
obtaining, in response to a result of the check of the reference block being positive (see e.g. Fanton, paragraph 20: “allowing or denying the loading of the dependent code module… dependent code module may be authenticated with reference to a multilevel whitelist architecture”; and paragraph 76: “If the request is granted, control flow continues along the "Yes" path exiting decision block 320 to block 345”), the transfer block using a reference in the reference block (see e.g. Fanton, paragraph 20: “loading of a dependent code module by a running process represents an attempt by the running process to load and execute the dependent code module within the address space of the running process”; and paragraph 77: “At block 345, a decision has previously been made that the code module in question may continue to load and execute in the normal fashion”).
With respect to claim 19, Fanton as modified teaches: The method according to claim 16, wherein the verification information permanently stored in the control unit and the verification stored in the first code block each includes at least one hash value (see e.g. Fanton, paragraph 38: “"content authenticator" generally refers to a result of a method for generating an authenticating mark which may be used in verifying digital information, files, code and/or data segments of code modules… a digital signature is employed as the content authenticator. A digital signature or cryptographic digital signature denotes the result of computing a cryptographic hash value, such as a Secure Hash Algorithm (e.g., SHA-1, SHA-256), Message Digest #5 (MD-5)”), and wherein in response to the hash value stored in the control unit matching a hash value formed via the first code block, it is determined that the first code block is in a version corresponding to the verification information permanently stored in the control unit (see e.g. Fanton, paragraph 38: “content authenticators may be generated and validated for only the code segment of a code module representing an executable”; and paragraph 110: “After the content authenticator for the code module is determined, at block 620, the next whitelist is checked for a matching entry”), and wherein in response to the hash valued stored in the first code block matching a hash value formed via the transfer block, it is determined that the transfer bock is in a version corresponding to the verification information stored in the first code block (see e.g. Fanton, paragraph 38: “content authenticators may be generated and validated for only the code segment of a code module representing an executable”; paragraph 110: “After the content authenticator for the code module is determined, at block 620, the next whitelist is checked for a matching entry”; and paragraph 113: “at block 665, the multi-level code module authorization is performed on the script file. Advantageously, this allows script files to be selectively authorized for execution on a computer system in a manner similar to executable files”).
With respect to claim 20, Fanton as modified teaches: The method according to claim 16, wherein the verification information permanently stored in the control unit and the verification information stored in the first code block each includes at least one public key (see e.g. Fanton, paragraph 38: “"content authenticator" generally refers to a result of a method for generating an authenticating mark which may be used in verifying digital information, files, code and/or data segments of code modules… a digital signature is employed as the content authenticator. A digital signature or cryptographic digital signature denotes the result of computing a cryptographic hash value, such as a Secure Hash Algorithm (e.g., SHA-1, SHA-256), Message Digest #5 (MD-5)”; and paragraph 26: “RSS may be used to encrypt hash values of the whitelists using Public Key Infrastructure (PKI) encryption”) of an [asymmetric] cryptosystem (see e.g. Fanton, paragraph 25: “digital signature may be based in part upon a hash value for the data in the whitelist. This signature may then be encrypted remotely by a Remote Signing Server (RSS) using public key cryptography”), and wherein in response to the first code block being validly signed with a secret key associated with the public key in the control unit (see e.g. Fanton, paragraph 26: “RSS may host a secret (private) encryption key that it uses to encrypt values”; paragraph 38: “"content authenticator" generally refers to a result of a method for generating an authenticating mark which may be used in verifying digital information, files, code and/or data segments of code modules… a digital signature is employed as the content authenticator. A digital signature or cryptographic digital signature denotes the result of computing a cryptographic hash value, such as a Secure Hash Algorithm (e.g., SHA-1, SHA-256), Message Digest #5 (MD-5), and the like, over a specific body of encoded data, then encrypting the hash value using a private key”; and paragraph 62: “The digital signature may be based in part upon a hash value for the data in the corresponding whitelist. This signature may then be encrypted remotely by a Remote Signing Server (RSS) using private key encryption”), it is determined that the first code block is in a version corresponding to the verification information permanently stored in the control unit (see e.g. Fanton, paragraph 62: “each time one or more of the whitelists are read into memory to look up a value during normal operation, the hash value may be recalculated by the authentication system software, and compared to the unencrypted stored value (unencrypted using the public key)”), and wherein in response to the transfer block being validly signed with a secret key associated the public key in the first code block, it is determined that the transfer block is in a version corresponding to the verification information stored in the first code block (see e.g. Fanton, paragraph 38: “content authenticators may be generated and validated for only the code segment of a code module representing an executable… encrypting the hash value using a private key. Given the same body of encoded data, re-computing the hash value, and decrypting the digital signature using the corresponding public key, will produce the identical value if the encoded data remains the same”; paragraph 62: “signature may then be encrypted remotely by a Remote Signing Server (RSS) using private key encryption. Then, each time one or more of the whitelists are read into memory to look up a value during normal operation, the hash value may be recalculated by the authentication system software, and compared to the unencrypted stored value (unencrypted using the public key)”; paragraph 110: “After the content authenticator for the code module is determined, at block 620, the next whitelist is checked for a matching entry”; and paragraph 113: “at block 665, the multi-level code module authorization is performed on the script file. Advantageously, this allows script files to be selectively authorized for execution on a computer system in a manner similar to executable files”).
Fanton does not but Campagna teaches:
asymmetric (see e.g. Campagna, paragraph 104: “Asymmetric key algorithms may also include various schemes for performing cryptographic operations on data”)
Fanton and Campagna are analogous art because they are in the same field of endeavor: code verification associated with dependent code execution. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Fanton with the teachings of Campagna. The motivation/suggestion would be to improve data access security.
With respect to claim 21, Fanton as modified teaches: The method according to claim 16, wherein the first code block and/or the transfer block additionally include a specification of authorizations (see e.g. Fanton, paragraph 41: “local whitelist" generally refers to a whitelist which identifies code modules which have been locally approved for execution on one or more computer systems or a whitelist that has otherwise been customized for use by one or more particular computer systems”) for accessing system resources of the control unit and/or for performing actions in or with the control unit (see e.g. Fanton, paragraph 41: “whitelist which identifies code modules which have been locally approved for execution on one or more computer systems”; and paragraph 77: “a decision has previously been made that the code module in question may continue to load and execute in the normal fashion. In one embodiment, this means that the code module is granted access to system resources such as memory, processors, and/or the like”), and wherein the access of the further application to system resources and/or the performance of actions by the further application is limited according to these authorizations (see e.g. Fanton, paragraph 20: “If the running process is a script interpreter, for example, then the dependent code module may be authenticated with reference to a multilevel whitelist architecture”; and paragraph 77: “a decision has previously been made that the code module in question may continue to load and execute in the normal fashion. In one embodiment, this means that the code module is granted access to system resources such as memory, processors, and/or the like”).
With respect to claim 22, Fanton as modified teaches: The method according to claim 21, wherein a specification of authorizations in the context of a predecessor application (see e.g. Fanton, paragraph 20: “attempt by the running process to load and execute the dependent code module”) in each case grants authorizations to a successor application to be executed (see e.g. Fanton, paragraph 20: “ Dependent code modules may include code modules that can be loaded and executed from within an existing process… the dependent code module may be authenticated with reference to a multilevel whitelist architecture”) only at most to the extent to which the predecessor application also has the authorizations (see e.g. Fanton, paragraph 20: “monitors the loading of dependent code modules by running processes… kernel mode driver may take into consideration in connection with allowing or denying the loading of the dependent code module, the identity or type of the code module or running process that initiated the load request at issue”).
With respect to claim 24, Fanton as modified teaches: The method according to claim 16, wherein at least one of the applications causes the control unit to provide one or more services that remain active even after a switch to execution of the further application (see e.g. Fanton, paragraph 20: “loading of a dependent code module by a running process represents an attempt by the running process to load and execute the dependent code module within the address space of the running process”).
With respect to claim 25, Fanton as modified teaches: The method according to claim 16, wherein in addition to the checking of whether the first code block is in a version corresponding to the verification information permanently stored in the control unit, a check is also carried out as to whether a data block required during the execution of the first code block is in a version corresponding to verification information permanently stored in the control unit (see e.g. Fanton, paragraph 36: “code modules include executable objects, file system objects, data files, text files, script files and/or the like”; paragraph 52: “authenticate the code module with reference to the local whitelist 135 (e.g., calculate a content authenticator value associated with the code module and compare the calculated value to the expected value stored in the local whitelist 135)”), and wherein the program code in the first code block is approved for execution only when the result of the check of the data block is also positive (see e.g. Fanton, paragraph 75: “At decision block 320, a determination may then be made as to whether the code module is authorized to execute. According to one embodiment, a multi-level whitelisting approach may be used”; paragraph 76: “If the request is granted, control flow continues along the "Yes" path exiting decision block 320 to block 345”; and paragraph 77: “At block 345, a decision has previously been made that the code module in question may continue to load and execute in the normal fashion. In one embodiment, this means that the code module is granted access to system resources such as memory, processors, and/or the like”).
With respect to claim 26: Claim 26 is directed to a non-transitory machine-readable storage medium on which is stored a computer program for operating a control unit on which multiple applications are executed, the computer program, when executed by one or more computers, causing the one or more computers to perform steps corresponding to the method disclosed in claim 16; please see the rejection directed to claim 16 above which covers the limitations recited in claim 26. Note that, Fanton also discloses a machine-readable medium storing instructions to implement the method disclosed in claim 16 (see e.g. Fanton, paragraph 32).
With respect to claim 27: Claim 27 is directed to a control unit comprising a computer configured to operating a control unit on which multiple applications are executed to implement active steps corresponding to the method disclosed in claim 16; please see the rejection directed to claim 16 above which covers the limitations recited in claim 27. Note that, Fanton also discloses a control unit with a computer configured to implement the method disclosed in claim 16 (see e.g. Fanton, Fig. 1-2).
With respect to claim 28, Fanton as modified teaches: The control unit according to claim 27, further comprising a hardware safety module (HSM) and/or a trusted platform module (see e.g. Fanton, paragraph 4: “securing computer systems of subscribers to a cloud-based whitelist of a trusted service provider”), which includes the reference stored permanently in the control unit, to the first code block of the first application and the permanently stored verification information for the first code block (see e.g. Fanton, paragraph 39: “a trusted service provider may maintain a global whitelist and allow local copies of the global whitelist to be stored on computer systems associated with a registered user of the trusted service provider”; paragraph 48: “whitelist" generally refers to an access control mechanism that may identify a set of one or more code modules approved for execution on one or more computer systems”; and paragraph 52: “multi-level whitelist authentication system 100 first attempts to authenticate the code module with reference to the local whitelist 135”).
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Fanton in view of Campagna as applied to claim 21 above, and further in view of Zhang et al. (US 2020/0213287 A1; hereinafter Zhang).
With respect to claim 23, Fanton as modified teaches: The method according to claim 21, wherein, by the specification of authorizations, the further application or successor application is excluded from accessing specifically such system resources or from performing specifically such actions (see e.g. Fanton, paragraph 20: “denying the loading of the dependent code module”; and paragraph 51: “kernel mode driver 115 can make a determination as to… deny the request (e.g., by propagating an error code to the user mode service layer 110)”)
Fanton does not but Zhang teaches:
that may affect the driving safety and/or a granted type approval of a vehicle (see e.g. Zhang, paragraph 38: “techniques disclosed herein may use multiple secure measures to authenticate both the hardware and software components in a vehicle and enforce secure communication between ECUs, thereby improving the safety and security of both the autonomous vehicle and the passenger”; and paragraph 49: “code authentication may be needed for the autonomous driving system”).
Fanton and Zhang are analogous art because they are in the same field of endeavor: managing trusted platform functions for operational processing. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Fanton with the teachings of Zhang. The motivation/suggestion would be to extend compatibility with different platforms; thus improving the overall user satisfaction.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Toyama (US 2008/0184258 A1) discloses an invocation authorization management program (TCACNT) that utilizes an invocation authorization database (TCADB) to decide whether to allow a data reference or a function invocation of an application on a certain operating system from an application of another operating system (see paragraph 34).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
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, Kevin L Young can be reached at (571) 270-3180. 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.
/UMUT ONAT/Primary Examiner, Art Unit 2194