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 1-12 are presented for Examination.
DETAILED ACTION
Claim Rejections - 35 USC § 102
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 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.
Claim(s) 1, 6, 7, 12 is/are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Koshy et.al. (U.S Patent Application Publication 2021/0049280; hereinafter “Koshy”].
Regarding claims 1, 7, Koshy discloses , A boot control method, adapted to an electronic device, wherein the electronic device has a wireless communication circuit, and the boot control method comprises: [“FIG. 1 illustrates an information handling system 100 similar to information handling systems according to several aspects of the present disclosure. In embodiments presented herein, the information handling system 100 may include the information handling system 100 forming part of a wireless network and communicatively coupled to a plurality of access points 138-1, 138-2, 138-N.”, 0019; Fig.1; “the instructions 124 may be transmitted or received over the network 128 via the network interface device or wireless adapter 120.”, 0030];
activating a boot procedure of the electronic device [ “At block 602, a boot up process for a mobile information handling system may be initiated in an embodiment. The mobile information handling system in an embodiment may operate a portion of the wireless signal based location security system during the boot up process, prior to the user gaining access to the operating system of the mobile information handling system. The boot up process may be initiated and handed off to the wireless signal based location security system at block 602..”, 0076];
during an execution of the boot procedure, receiving a wireless verification signal through a wireless communication circuit, wherein the wireless verification signal carries verification information [“, the location fingerprint system 136 may measure a power present in a received wireless signal such as a signal received by the information handling system 100 from a plurality of access points 138-1, 138-2, 138-N. The location fingerprint system 136 may be in the form of an application specific integrated circuit (ASIC) that receives signal strength data (e.g., RSSI values) from the network interface device 120….”, 0039; “The network interface device of the mobile information handling system in an embodiment may receive wireless signals from one or more in-range access points (APs) at block 604. the mobile client information handling system in an embodiment may receive a broadcast message from one or more APs.”, 0078; “At block 606, the RSSI values and time of flight (TOF) for communications between the mobile information handling system and two or more APs may be determined..”, 0079; “The location fingerprint system operating at the mobile information handling system may also measure RSSI values for the wireless links established between the mobile information handling system and the one or more APs in an embodiment.. , the location fingerprint system 136 may measure a power present in a received wireless signal such as a signal received by the information handling system 100 from a plurality of access points 138-1, 138-2, 138-N. The location fingerprint system 136 may be in the form of an application specific integrated circuit (ASIC) that receives signal strength data (e.g., RSSI values) from the network interface device 120. ”, 0080; ( i.e verifying the signal strength data (e.g., RSSI ) and the TOF values carried by the wireless signal .Therefore the wireless signal carries the RSSI and TOF information ) ] ;
determining whether the verification information passes verification [ “At block 608, the location fingerprint system operating at the mobile information handling system in an embodiment may determine a current location fingerprint for the mobile information handling system. A location fingerprint in an embodiment may comprise a single record for each of a plurality of APs with which the mobile information handling system has established a wireless link. Each of these records in an embodiment may include the MAC address of one of the plurality of in-range, address-identified APs, the TOF for the wireless link established with the AP having that MAC address, and the measured RSSI values for that wireless link. ..”, 0081;” The location fingerprint system operating at one or more APs in an embodiment may determine at block 610 whether the current location fingerprint for the mobile information handling system matches any previously determined location fingerprints. Location fingerprints for a plurality of mobile information handling systems determined over time may be stored at the one or more APs in an embodiment, or at a remote storage module accessible by one or more of the APs with which the mobile information handling system has established a wireless link. Stored location fingerprints in an embodiment may include previously measured RSSI and TOF values for information handling systems known to be located within the preset, secured perimeter. As such, the location fingerprint determined at block 610 may only match or be clustered with existing location fingerprints if the mobile information handling system associated with the location fingerprint is also located within the preset, secured perimeter. In some embodiments, the stored location fingerprints may be seeded by an information technology (IT) specialist to include RSSI/TOF/MAC address combinations measured by an information handling system as the IT specialist moves about an area the IT specialist wishes to define as secured.”, 0082; ( i.e verifying the RSSI & TOF measurements with preset values)] ;
in response to the verification information passing the verification, continuing executing the boot procedure [“Because the current location fingerprint includes both TOF and RSSI measurements, it may only match or be clustered with previously recorded location fingerprints taken by an information handling system having the same physical location with respect to the one or more secure, a.. the location fingerprint will only match or be clustered with previous location fingerprints having similar TOF and RSSI values associated with a given address-identified AP. … For example, a “spoofed” location fingerprint may provide accurate TOF measurements to describe the relative position of the mobile information handling system with respect to the one or more APs, but it cannot provide accurate RSSI measurements unless it is actively located within the same physical and architectural layout that describes the area within the secured perimeter. “..If the location fingerprint matches previous location fingerprints, the method may proceed to block 612”, 0083; “The wireless signal based location security system in an embodiment may determine at block 612 whether the mobile information handling system is authorized to access the secure network,. ..”, 0084; ( i.e continuing to execute the boot procedure if the TOF & RSSI values matches with the previously recorded location fingerprint)] ; and
in response to the verification information not passing the verification, stopping the boot procedure [“If the location fingerprint does not match any previous location fingerprints, this may indicate a spoofing attempt or an attempt to access the network from outside the secured perimeter, and the method may proceed to block 614 for termination of the boot process. “, 0083].
Koshy further discloses a processor, connected to the wireless communication circuit [ “..a processor 102 ..”, 0024; “The wireless network interface device 120”, 0026; “ the processor 102, the video display 110, the alpha-numeric input device 112, and the network interface device 120 via bus 108..”, 0040; Fig.1] ( as recited in Claim 7).
Regarding claims 6, 12, Koshy discloses, wherein determining whether the verification information passes the verification comprises[0061; 0081-0082]:
determining whether a signal strength of the wireless verification signal is higher than a critical value [“..receives signal strength data (e.g., received signal strength indicator (RSSI)..”, 0039;” 0018;” the location fingerprint system 136 may compare the RSSI to the TOF signal received from any of the access points 138-1, 138-2, 138-N at the information handling system in order to determine whether a reduction in power of the RSSI exceeds a threshold reduction value. This threshold reduction value may be set to any sensitivity level that represents a reduction in power of the RSSI the location fingerprint system 136 is capable of detecting. In an embodiment, the location fingerprint system 136 may set the threshold reduction value between 6 and 10 decibels (dB). …boundaries such as walls and doors can be determined for a layout of a secured space without the need for GPS. Similarly, one or more security perimeters may be determined relative to the secured, address identified APs within a secured facility.”, 0042;” Stored location fingerprints in an embodiment may include previously measured RSSI and TOF values for information handling systems known to be located within the preset, secured perimeter…”, 0082; ( i.e. Determining whether the power of the signal strength data RSSI) is reduced with respect to a threshold reduction value and indicating the location fingerprint system that the location of the mobile information handling system with respect to secured APs is in a security perimeter of a facility ) ; and
in response to the signal strength of the wireless verification signal not being higher than the critical value [ 0042; 0082;( i.e. determining reduction in power of the RSSI signal with respect to a threshold value stored RSSI values are within a preset range indicating a secured perimeter ) determining that the verification information does not pass the verification [“Because the current location fingerprint includes both TOF and RSSI measurements, it may only match or be clustered with previously recorded location fingerprints .. For example, a “spoofed” location fingerprint may provide accurate TOF measurements to describe the relative position of the mobile information handling system with respect to the one or more APs, but it cannot provide accurate RSSI measurements unless it is actively located within the same physical and architectural layout that describes the area within the secured perimeter. If the location fingerprint does not match any previous location fingerprints, this may indicate a spoofing attempt or an attempt to access the network from outside the secured perimeter, and the method may proceed to block 614 for termination of the boot process. If the location fingerprint matches previous location fingerprints, the method may proceed to block 612.”, 0083;” ..Movement of such a door in an embodiment, as detected by the wireless signal based location security system, may prompt a warning that the security perimeter 400 has been breached. That movement may be detected by smart sensors transmitting at the doors or by changes in RSSI values among location fingerprints”, 0096-0097;( i.e. in response to the reduction in power of the signal strength /RSSI value not matching the stored values boot procedure is aborted or the network access is denied. Hence the verification information does not pass the verification)].
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 of this title, 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 2-5, 8-11 are rejected under 35 U.S.C. 103 as being unpatentable over Koshy in view of Khatri et.al. (U.S Patent Application Publication 2019/0018966; hereinafter “Khatri”)
1
Regarding Claims 2, 8, Koshy discloses wherein determining whether the verification information passes the verification [0061; 0081-0082] and other limitations as outlined in Claim1.
However, Koshy does not expressly disclose , detecting whether a verification point of the boot procedure has been reached ,in response to having reached the verification point, determining whether the verification information passes the verification, in response to not having reached the verification point, continuing executing the boot procedure.
In the same field of endeavor ( e.g. verifying and authenticating the firmware images of the associated hardware devices and to initiate the operating system (OS) during system boot-up), Khatri teaches,
detecting whether a verification point of the boot procedure has been reached [ “.. a timeline 400 of a boot operation (or boot process) 405 for IHS 100, which includes a security phase, pre-EFI initialization (PEI) phase, driver execution environment (DXE) phase, boot device select (BDS) phase, transient system load (TSL) phase, and a run time (RT) phase. At the DXE phase, EFI driver dispatcher 432 retrieves device, bus or service images or drivers 430, depending upon the architectural protocols 434 associated with IHS 100. During the DXE phase, if a secure boot process or mode is enabled, an authentication check of UEFI images 430 occurs.”, 0044;(i.e. detecting whether the DXE phase has been reached to verify the image and authenticate. Hence the DXE phase corresponds to the verification point)];
in response to having reached the verification point, determining whether the verification information passes the verification [ 0044; “ verification F/W 326 executes on processor 102 during the DXE phase. ..During the DXE phase, BMC 144 identifies a request to authenticate a particular UEFI image from among a plurality of UEFI images. BMC 144 identifies the type of the UEFI image based on the storage location of the UEFI image. … In response to determining the type of the image, BMC 144 retrieves, from an entry within a UEFI signature database (Db 336 or Dbx 338), a certificate utilized to sign the UEFI image. BMC 144 then determines a verification entry (e.g., verification entry 346b) within a corresponding verification database (e.g., verification Db 340) and identifies, from the verification entry, a particular type of image that the certificate may be used to authenticate. BMC 144 determines whether the type of the UEFI image matches the particular type identified within the verification entry. In response to determining the type of the UEFI image matches the particular type, the UEFI image is authenticated using the certificate..”, 0045;(i.e verifying the UEFI image )] ; and
in response to not having reached the verification point, continuing executing the boot procedure[ “.. At PEI phase, a PEI core operation 420 is performed. During the PEI core operation 420, memory is initialized and firmware volume locations are described in hand off blocks. Next, a processor initialization 422 of processor 102 occurs, followed by chipset initialization 424 and then motherboard initialization 426. Next, a processor initialization 422 of processor 102 occurs, followed by chipset initialization 424 and then motherboard initialization 426”, 0044].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Koshy with Khatri. Khatri’s teaching of implementing a Unified extensible firmware interface (UEFI) that defines a software interface between an operating system and platform firmware to manage initialization and configuration of devices and authenticating UEFI images based on the plurality of entries in the UEFI signature database will substantially increase the security to access Koshy’s system by verifying the information with an associated certificate during the driver execution environment (DXE) phase to prevent the loading of drivers or images that are not signed with an acceptable digital signature.
Regarding Claims 3, 9, Khatri teaches , wherein the boot procedure comprises a boot procedure of a Universal Extensible Firmware Interface (UEFI) [ 0007; 0031-0032]
Regarding Claims 4, 10 Khatri teaches , wherein the verification point corresponds to at least one of a Pre-EFI initialization (PEI) phase in the boot procedure, a Driver Execution Environment (DXE) phase in the boot procedure, and the Boot Device Selection (BDS) phase in the boot procedure [ 0044-0045].
Regarding claims 5,11, Koshy discloses, wherein determining whether the verification information passes the verification[0061; 0081-0082] and other limitations as outlined in Claim1.
Khatri teaches , decrypting the verification information to obtain a verification code[0043;”.. BMC 144 may determine the type of the UEFI image by reading metadata associated with the UEFI image. In response to determining the type of the image, BMC 144 retrieves, from an entry within a UEFI signature database (Db 336 or Dbx 338), a certificate utilized to sign the UEFI image...”, 0045; “determining the type of UEFI image 522a, verification F/W 326 sequentially checks, starting at first Db entry 508a, each entry of Db entries 508a-n in Db 336 until at least one Db certificate 508a-n is identified that was used to sign UEFI image 522a, ..”, 0051;( i.e. decrypting the image to obtain the signature / code to identify the certificate that was used to sign the image )
determining whether the verification code complies with specifications [ “The UEFI specifications define four public key databases. Those databases include: (1) an authorization signature database (Db) that contains certificates that authorize particular images for execution, . The UEFI specification provides that any pre-boot image may be authorized by any entry in Db or forbidden by any certificate in Dbx. Thus, an industry-wide certificate may authorize a pre-boot image”, 0004; 0051]
in response to the verification code complying with the specifications, determining that the verification information passes the verification [0004; 0045;0051-0052; “In response to determining the image type identified in verification entry 346b matches the identified image type of UEFI image 522a, verification F/W 326 authenticates UEFI image 522a using Db certificate 508b. The authentication of Db certificate 508b authorizes UEFI image 522a to execute. “, 0053] and
in response to the verification code not complying with the specifications, determining that the verification information does not pass the verification [ “If the type of the UEFI image does not match the particular type, BMC 144 sequentially checks each entry in the UEFI signature database for a subsequent certificate that was used to sign the image. In response to determining no other certificates in the UEFI signature database were used to sign the image, BMC 144 issues a notification, such as an error message that indicates that the UEFI image was not able to be authenticated, to an error log and/or at least one output device (e.g., a monitor). In one embodiment, the detected failure may also be recorded to memory (e.g., NV Memory 139) for future reference/access.0045].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Halibard, U.S Patent Application Publication 2015/0143508, authenticating access to an operating system by a user before the operating system is booted. Such authentication may be performed by processing information received from a wireless communication token via Near Field Communication (NFC). The received information may be processed to determine credentials for accessing the operating system, which if validated, may be sent to a Basic Input Output System (BIOS) which may boot the operating system in response.
Cha et al., U.S Patent Application Publication 2011/0302638, teaches a network device comprising a secure hardware module, may receive a root key. The secure hardware module may also receive a first code measurement. The secure hardware module may provide a first key based on the root key and the first code measurement. The secure hardware module may receive a second code measurement and provide a second key based on the first key and the second code measurement. The release of keys based on code measurements may provide authentication in stages.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GAYATHRI SAMPATH whose telephone number is (571)272-5489. The examiner can normally be reached on 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, Jaweed Abbaszadeh can be reached on 5712701640. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/GAYATHRI SAMPATH/ Examiner, Art Unit 2176
/JAWEED A ABBASZADEH/ Supervisory Patent Examiner, Art Unit 2176
Prosecution Insights