DETAILED ACTION
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 .
Claims 21-24, 26-34 and 36-42 are pending in this office action.
Claims 21, 34, 40 are amended.
Claims 41-42 are new added claims.
Claims 25 and 35 are cancelled.
Terminal Disclaimer
The terminal disclaimer filed on 01/30/2026 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of 12,026, 244 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Response to Arguments
Applicant's arguments filed 01/29/2026 have been fully considered but they are not persuasive
Applicant’s arguments:
Applicant submits that the cited references do not disclose or suggest at least the above- emphasized features of claim 21 as amended. Therefore, claim 21 is believed to be allowable over the cited references. Independent claims 34 and 40 are amended to include one or more elements that are the same as or similar to those elements amended into claim 21. Accordingly, Applicant submits that claims 34 and 40 are allowable over the cited references for reasons similar to those discussed above with respect to claim 21.
Examiner’s response:
The issue in the argument is that Chen do not discloses that : client package do not include executable files nor the client package use references of a host to execute the application.
Chen discloses that the untrusted client package use only references to the secure runtime environment for accessing executable of the host:
[0125] “The secure runtime environment moderates both which resources can be accessed (and communicated with) by the native code module, as well as how such resources are accessed, thereby ensuring that the native code module relies entirely on the secure runtime environment to access system services and cannot perform sensitive operations without explicit mediation”
While Bood man disclose that the client package: browser extension downloaded from the server store includes manifest file :
Col5 lines 37-43 “ In one embodiment, the browser extension 132 may include a metadata file or manifest 136 which includes information detailing or dictating how the web browser 124 should process or manage the browser extension and/or what the contents of the installable browser extension 132 are. A portion of a manifest 132 is described in more detail in reference to FIG. 6.”.
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.
Claim 26 is 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 26 recites in lines 1-2:
“Wherein the application does not include or reference an executable included in the client package.”
Claim 26 depends of claim 21 and claim 21 recites in line 6 :
“a client package not comprising executable files;”
Claim 21 explicitly recites that client package does not include executable file, and claim 26 explicitly recites that the same client package includes executable files. It’s ambiguous and not clear if the client package include or does not include those executable files.
Claim Rejections - 35 USC § 103
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.
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.
Claims 21-24, 26-27, 32-34,37-38, 40-42 are rejected under 35 U.S.C. 103 as being un-patentable over Chen et al (US20090282477A1) in view of Dwivedi et al US 20130031642A1 and Boodman et al US8,200,962A1.
As per claim 21, Chen discloses system comprising:
a processor; and memory comprising computer executable instructions that, when executed:[0047] and [0029]
perform operations comprising: generating, during execution of a host runtime of a host package, a client package:
[0045]”FIG. 2 illustrates the execution of an untrusted native code module in one embodiment of the present invention. During operation, a user performing operations in web browser 202 on computing device 200 accesses a web page, and invokes browser-based client application 204. Browser-based client application 204 causes browser plug-in 206 to download untrusted native code module 208 from network server 210”;
[0082]“For instance, a native code module cannot read or change file system state, initiate network (or inter-module and/or inter-process) communications, or launch computations outside of an isolated "sandbox," and instead must rely on the secure runtime environment to perform such interactions (if allowed) on its behalf.”;
declaring, in the client package, a dependency on the host package:
[0044] “The untrusted module can only access common system resources (e.g., communications with other local processes, durable storage, etc.) via the secure runtime environment.”;
[0048] “The untrusted module relies entirely on the secure runtime environment for access to system services, with the secure runtime environment taking full responsibility for the safety of the services provided.”
Defining, in the client package, an application with an application identity and a reference to the host runtime:
Fig. 2 and [0048] “Furthermore, untrusted modules cannot communicate directly with the network. The system prevents untrusted modules from making unmediated system calls, thereby preventing such untrusted modules from using such system calls to exploit system vulnerabilities by directly creating or modifying files in the file system, starting processes, engaging in clandestine network communications, etc. The untrusted module relies entirely on the secure runtime environment for access to system services, with the secure runtime environment taking full responsibility for the safety of the services provided “;
[0076] “This native code module is comprised of untrusted native program code expressed in the instruction set architecture associated with the computing device.”;
wherein the reference to the host runtime is usable by the client package for execution of the application:
[0125] “The secure runtime environment moderates both which resources can be accessed (and communicated with) by the native code module, as well as how such resources are accessed, thereby ensuring that the native code module relies entirely on the secure runtime environment to access system services and cannot perform sensitive operations without explicit mediation”
and providing, upon activation of the application, access to the host runtime under the application identity:
[0055] “a loader/validator that loads the module into memory and confirms that the untrusted module is compliant with a set of code- and control-flow integrity requirements; and a runtime environment that provides data integrity and moderates both the module’s ability to access resources and how the module accesses such resources. The compilation and validation processes ensure that unwanted side effects and communications are disabled for the untrusted module, while the secure runtime environment provides a moderated facility through which a limited set of desirable communications and resource accesses can safely occur. “;
But not explicitly:
Not comprising executables files:
specifying, in the client package, an unsigned marker;
wherein the dependency includes at least one of a name of the host package or a version of the host package
Dwivedi discloses:
specifying, in the client package, an unsigned marker:
[0037]“A digital signature can be used to enable a recipient to recognize the source of received digital information, but can be used in accordance with the disclosure. An application can be configured for use by not digitally signing it, removing a digital signature, or otherwise.”;
[0056] “ Verification information 800 may be encrypted with a key that is known to both the client device and the licensing server, resulting in an encrypted blob 802. In the illustrated embodiment, the encrypted information includes the identification of the unsigned applications at the client device, the timestamp, and the machine ID.”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Dwevedi into teachings of Chen to detect unauthorized application installed or subject to installation in a client device. Furthermore, to detect of misuse of digital licenses pertaining to application use and present new security holes that can adversely affect application distribution centers, and the developers, authors and owners of distributed applications.[Dwivedi 003].
But not explicitly:
Not comprising executables files:
wherein the dependency includes at least one of a name of the host package or a version of the host package;
Boodman discloses
Not comprising executables files:
Col5 lines 37-43 “ In one embodiment, the browser extension 132 may include a metadata file or manifest 136 which includes information detailing or dictating how the web browser 124 should process or manage the browser extension and/or what the contents of the installable browser extension 132 are. A portion of a manifest 132 is described in more detail in reference to FIG. 6.”.
wherein the dependency includes at least one of a name of the host package or a version of the host package:
Col 6 lines 30-50 “ Further, in various embodiments, the manifest 136 may include various fields or values indicating how the web browser 124 is to process or execute the browser extension 132. In some embodiments, these various fields may include (but are not limited to): ……."key" a public key associated with the browser extension (described below in reference to keys 152 and 162), "minimum/maximum_browser_version" an indication of the version(s) of the web browser 124 this browser extension 132 is configured to be executed by,;……..”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Boodman into teachings of Chen and Dwevedi for managing a web browser extension hosted via a web store e.g. collective web browser extension store or self-hosted web store, using a web-enabled computing device. Furthermore, to dynamically re-loading or unloading the web browser extension via the web browser without restarting the web browser so as to change the functionality of the web browser user's interest, thus enabling the user to effectively create a custom browser that includes functionality of the customized extensions.[Boodman Col 2 lines 5-17] .
As per claim 22, the rejection of claim 21 is incorporated and furthermore Chen discloses:
wherein the host package includes a first collection of data created for distribution to and installation on a computing device:
[0045] FIG. 2 illustrates the execution of an untrusted native code module in one embodiment of the present invention. During operation, a user performing operations in web browser 202 on computing device 200 accesses a web page, and invokes browser-based client application 204. Browser-based client application 204 causes browser plug-in 206 to download untrusted native code module 208 from network server 210”;
As per claim 23, the rejection of claim 22 is incorporated and furthermore Chen discloses:
wherein the client package includes a second collection of data created for installation on the computing device, the client package being generated by the host package:
[0039]”For instance, a user may download and run an arbitrary executable file over the Internet from a trusted application provider. Alternatively, Microsoft ActiveX.TM. controls allow executable content to be loaded and executed by a web browser”;
As per claim 24, the rejection of claim 21 is incorporated and furthermore Chen discloses:
wherein the client package includes: a client manifest comprising the dependency and metadata describing the application:
[0048]”The untrusted module relies entirely on the secure runtime environment for access to system services, with the secure runtime environment taking full responsibility for the safety of the services provided.”;
[0076] “…During operation, the system receives an untrusted native code module to be executed on a computing device (operation 500). This native code module is comprised of untrusted native program code expressed in the instruction set architecture associated with the computing device. Next, the system validates the native code module to confirm that the module will execute safely (operation 510). In doing so, the system first determines whether the set of instructions in the native code module includes any restricted instructions and/or accesses restricted features of the computing device (operation 520).”
And content files used during runtime of the application:
[0121]” Then, the system proceeds to execute instructions from the native code module in the secure runtime environment (operation 720). During execution, the secure runtime environment moderates which resources can be accessed by the native code module as well as how these resources are accessed”;
As per claim 26, the rejection of claim 21 is incorporated and furthermore Chen discloses:
wherein the application does not include or reference an executable included in the client package.
[0120]“Finally, note that untrusted native code modules 612 cannot interact with each other directly, but can only interact by permission of and via service runtime 608.”;
As per claim 27, the rejection of claim 21 is incorporated and furthermore Chen discloses:
wherein the host runtime includes activation information referencing an executable used to activate the application:
[0045]“Browser-based client application 204 causes browser plug-in 206 to download untrusted native code module 208 from network server 210. Note that untrusted native code module 208 is validated by validator 212 as it is loaded into secure runtime environment 214”;
As per claim 32, the rejection of claim 21 is incorporated and furthermore Chen discloses:
receiving, from the application, a request to access a function of the system; and enabling the application to access the function using the host runtime:
[0044] “The untrusted module can only access common system resources (e.g., communications with other local processes, durable storage, etc.) via the secure runtime environment.”;
[0082]“The secure runtime environment moderates both which resources can be accessed (and communicated with) by the native code module, as well as how such resources are accessed, thereby ensuring that the native code module relies entirely on the secure runtime environment to access system services and cannot perform sensitive operations without explicit mediation.”;
As per claim 33, the rejection of claim 32 is incorporated and furthermore Chen discloses:
evaluating, by an operating system executing the host runtime, a rule indicating that at least one of the client package or the host package include a capability for the function; and determining the rule is satisfied.
[0081] As described above, the compilation and validation processes ensure that native code modules are compliant with system requirements, and hence do not have any unwanted side effects that affect system security.
[0130] “Safe execution of the native code module is achieved via load-time validation and a secure runtime environment, where the validator ensures that a native code module is compliant with a set of instruction restrictions and alignment requirements and the secure runtime environment moderates both which resources can be accessed (and communicated with) by the native code module as well as how such resources are accessed. In one application of these techniques, web-based applications using the described techniques can execute with
As per claim 41, the rejection of claim 21 is incorporated and furthermore Chen discloses:
wherein generating the client package comprises: generating, by a host application included in the host package, the client package during a runtime of the host application:
[0118] “During operation, a client application 610 (e.g., a JavaScript.TM. application) in web browser 600 sends a request to client runtime 606 to download several native code modules. Client runtime 606 forwards this request to service runtime 608, which downloads and loads the untrusted native code modules 612 into memory”;
As per claim 42, the rejection of claim 21 is incorporated and furthermore Chen discloses:
wherein the client package does not comprise references to binaries or classes other than the host package.
[0082]“For instance, a native code module cannot read or change file system state, initiate network (or inter-module and/or inter-process) communications, or launch computations outside of an isolated "sandbox," and instead must rely on the secure runtime environment to perform such interactions (if allowed) on its behalf.”;
Claims 34 are the method claim corresponding to system claims 1 and rejected under the same rational set forth in connection with the rejection of claims 1 above.
Claims 40 are the device claim corresponding to system claims 1 and rejected under the same rational set forth in connection with the rejection of claims 1 above.
As per claim 37, the rejection of claim 34 is incorporated and furthermore Chen does not disclose:
wherein the client package does not include an object that allows the operating system to authenticate the client package.
Dwivedi discloses:
wherein the client package does not include an object that allows the operating system to authenticate the client package.
[0037]“A digital signature can be used to enable a recipient to recognize the source of received digital information, but can be used in accordance with the disclosure. An application can be configured for use by not digitally signing it, removing a digital signature, or otherwise.”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Dwivedi into teachings of Chen to detect unauthorized application installed or subject to installation in a client device. Furthermore, to detect of misuse of digital licenses pertaining to application use and present new security holes that can adversely affect application distribution centers, and the developers, authors and owners of distributed applications.[Dwivedi 003].
As per claim 38, the rejection of claim 34 is incorporated and furthermore Chen discloses:
wherein the host package includes a trust level with respect to the operating system, the trust level indicating a level of access the host package possesses to functionality of the operating system.
[0082] “ The secure runtime environment moderates both which resources can be accessed (and communicated with) by the native code module, as well as how such resources are accessed, thereby ensuring that the native code module relies entirely on the secure runtime environment to access system services and cannot perform sensitive operations without explicit mediation. For instance, a native code module cannot read or change file system state, initiate network (or inter-module and/or inter-process) communications, or launch computations outside of an isolated "sandbox," and instead must rely on the secure runtime environment to perform such interactions (if allowed) on its behalf.”;
[0057] “Additionally, static binary analysis facilitates implementing the validator and runtime environment in a small trusted code base, thereby facilitating security verification for the code base and reducing the likelihood of bugs and/or vulnerabilities. In some embodiments, however, the system may also use dynamic analysis and code-rewriting techniques.
Claims 28, 30 , 39 are rejected under 35 U.S.C. 103 as being un-patentable over Chen et al (US20090282477A1) in view of Dwivedi et al US20130031642A1 and furthermore in view of Boodman et al US8,200,962A1 and Thomas et al US8230415B1.
As per claim 28, the rejection of claim 21 is incorporated and furthermore Chen does not disclose:
wherein the host package includes a verifiable signature and the host package is registered with an operating system based on verification of the verifiable signature.
Thomas discloses:
wherein the host package includes a verifiable signature and the host package is registered with an operating system based on verification of the verifiable signature:
Col 5 lines 44-50 “For example, client device 12A may verify a digital signature of the software update package. Based on the outcome of the software update package authentication, client device 12A then advertises the software update package by registering the software update package with the operating system.”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Thomas into teachings of Chen Dwivedi and Boodman to advertise the software update package, or inform client devices of the software update package, prior to client devices installing each software update package. In this manner, the techniques of the invention may facilitate installation of software update packages across a VPN through on-demand advertising of software update packages without requiring further administrative action. Moreover, in this way the on-demand installation techniques are not restricted to known and previously registered software packages, but instead allow for on-demand advertisement and installation of future software packages when published by a trusted source. [Thomas Col 6 lines 15-30].
As per claim 30, the rejection of claim 28 is incorporated and furthermore Chen does not explicitly disclose:
wherein the activation of the application comprises: registering the client package with the operating system based on the verification of the verifiable signature.
Thomas discloses:
registering the client package with the operating system based on the verification of the verifiable signature
Col 5 lines44-50 “For example, client device 12A may verify a digital signature of the software update package. Based on the outcome of the software update package authentication, client device 12A then advertises the software update package by registering the software update package with the operating system.”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Thomas into teachings of Chen Dwivedi and Boodman to advertise the software update package, or inform client devices of the software update package, prior to client devices installing each software update package. In this manner, the techniques of the invention may facilitate installation of software update packages across a VPN through on-demand advertising of software update packages without requiring further administrative action. Moreover, in this way the on-demand installation techniques are not restricted to known and previously registered software packages, but instead allow for on-demand advertisement and installation of future software packages when published by a trusted source. [Thomas Col 6 lines 15-30].
As per claim 39, the rejection of claim 34 is incorporated and furthermore Chen discloses:
wherein the host package includes at least two of:a name of the host package;
[0045] “During operation, a user performing operations in web browser 202 on computing device 200 accesses a web page, and invokes browser-based client application 204.”;
But not explicitly:
The host package include a version of the host package; a publisher of the host package; or an author of the host package.
Thomas discloses:
The package include a version of the host package; a publisher of the host package; or an author of the host package.
Col 7 lines 47-53 “Once the remote user is authenticated, setup module 36 may retrieve software package parameters 38, (e.g., a product name parameter 38A and version parameter 38B) from access control device 16 and determine whether installation of one or more software update packages, such as MSI package 30A, are required to access LAN 18 via the VPN”;
Col 9 lines44-47” check on MSI package 30B to authenticate the package and verify whether MSI package 30B was published by a trusted source ‘
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Thomas into teachings of Chen, Dwivedi and Boodman to advertise the software update package, or inform client devices of the software update package, prior to client devices installing each software update package. In this manner, the techniques of the invention may facilitate installation of software update packages across a VPN through on-demand advertising of software update packages without requiring further administrative action. Moreover, in this way the on-demand installation techniques are not restricted to known and previously registered software packages, but instead allow for on-demand advertisement and installation of future software packages when published by a trusted source. [Thomas Col 6 lines 15-30].
Claims 29 are rejected under 35 U.S.C. 103 as being un-patentable over Chen et al (US20090282477A1) in view of Dwivedi et al US20130031642A1 and furthermore in view of Boodman et al US8,200,962A1, Thomas et al US8230415B1 and Devarajan et al US20140259004A1.
As per claim 29, the rejection of claim 28 is incorporated and furthermore Chen does not explicitly disclose:
wherein the verifiable signature: is generated using a private key this is not included in the host package; and is verified using a public key corresponding to the private key prior to or as part of initiating the host runtime.
Devarajan discloses:
wherein the verifiable signature: is generated using a private key this is not included in the host package:
[0044] When the vetting process is complete, the lab/assessor 216 signs the application 402 with its private key (note, the private key may correspond to the public key in the lab/assessor certificate 316) and sends the encrypted/signed package to the vendor 404.”;
and is verified using a public key corresponding to the private key prior to or as part of initiating the host runtime.
[0048]“With the application available to a deployed device, referring to FIG. 5, a validation process may be followed before the application is executed or installed on a given deployed device”.
[0051]“With respect to the first half 600, at process block 508, the deployed device 406 decrypts the encrypted manifest 424 using the approver's public key, which is present in the approver's certificate 212, to extract the hash values for both the signed application 604, the unsigned application 606, and the application name and version identification 608. Thereafter, at process block 510, the deployed device 406 generates a hash of the signed application from the second part of the blob”.
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Devarajan into teachings of Chen, Dwivedi, Boodman and Thomas to provide a distributed authority system for distributing verifiable content/software over a communications network, for rigorous validation by a number of trusted third parties before source code is signed by those trusted third parties and forwarded to a target device and user[Devarajan 0025].
Claims 31 are rejected under 35 U.S.C. 103 as being un-patentable over Chen et al (US20090282477A1) in view of Dwivedi et al US20130031642A1 and furthermore in view of Boodman et al US8,200,962A1, Thomas et al US8230415B1 and Khalid et al US11210390B1.
As per claim 31, the rejection of claim 30 is incorporated and furthermore Chen does not explicitly disclose:
wherein registering the client package with the operating system comprises: determining that an identity of the client package does not conflict with an identity of the host package.
Khalid discloses:
Installing and registering different software under the operating system registry with different identities:
Col 6 lines60-65 “Alternatively, the SSI 115 may automatically establish the different directories and/or different names in response to user input of the identity of the operating system version and software application version, e.g., using the GUI as described above. Alternatively, multiple versions of a SW application may be installed within the same directory, but registered under different identifiers or names within the operating system. For example, the executables of multiple versions of a SW application and/or their associated libraries can coexist within the same directory with different filenames. The corresponding operating system registry entries would have different links that reference to different filenames”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of khalid into teachings of Chen, Dwivedi, Boodman and Thomas to track and detect behaviors of the potentially malicious content suspect during processing by the one or more software application. Thereafter, information associated with the detected behaviors pertaining to a malicious attack is stored, and an alert with respect to the malicious attack is issued.(Khalid abstract].
Claim 36 is rejected under 35 U.S.C. 103 as being un-patentable over Chen et al (US20090282477A1) in view of Dwivedi et al US20130031642A1 and furthermore in view of Boodman et al US8,200,962A1and Khalid et al US112310390B1.
As per claim 36, the rejection of claim 34 is incorporated and furthermore Chen does not explicitly disclose:
wherein the application identity enables the operating system to track activity of the host runtime and executables referenced in the host runtime as activity of the application.
Khalid discloses:
wherein the application identity enables the operating system to track activity of the host runtime and executables referenced in the host runtime as activity of the application.
Col 8 lines 1-5 “ At block 206, the processing logic stores information describing any detected anomalous behaviors, and, associated therewith, the version identifier (e.g., version number and, where applicable, service pack number) corresponding to each of the versions of the software application and the operating system whose execution resulted in the anomalous behavior. At block 208, processing logic declares any identified attack incident and may issue an alert, which in some embodiments, contains or references threat data, including, for example, the version number or numbers of the SW application having a potential security vulnerability so that remedial action may be taken.
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of khalid into teachings of Chen, Dwivedi and Boodman to track and detect behaviors of the potentially malicious content suspect during processing by the one or more software application. Thereafter, information associated with the detected behaviors pertaining to a malicious attack is stored, and an alert with respect to the malicious attack is issued.(Khalid abstract].
Pertinent arts
US20120005480A1
The method includes associating the one or more digital certificate instances with the one or more firmware file instances to facilitate updating signature-unaware modules with signature-aware firmware or to facilitate updating signature-aware modules with signature-unaware firmware.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRAHIM BOURZIK whose telephone number is (571)270-7155. The examiner can normally be reached Monday-Friday (8-4: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, Wei Y Mui can be reached on 571-270-2738. 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.
/BRAHIM BOURZIK/ Examiner, Art Unit 2191
/WEI Y MUI/ Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights