FINAL REJECTION
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 .
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 IHS invention.
Claims 6-8, 11, 12, 14, 15, and 17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 6 recites the limitation "the notification" in lines 6 and 8. There is insufficient antecedent basis for this limitation in the claim.
Claim 7 recites the limitation "the notification" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Claim 8 recites the limitation "the notification" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Claim 11 recites the limitation "the notification" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Claim 12 recites the limitation "the notification" in line 4. There is insufficient antecedent basis for this limitation in the claim.
Claim 14 recites the limitation "the notification" in line 6. There is insufficient antecedent basis for this limitation in the claim.
Claim 15 recites the limitation "the notification" in line 6. There is insufficient antecedent basis for this limitation in the claim.
Claim 17 recites the limitation "the notification" in lines 5 and 6. There is insufficient antecedent basis for this limitation in the claim.
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 (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.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Srinivas (9689887 in view of Vieira et al. (2021/0192471).
Regarding claim 1:
Srinivas teaches:
An Information Handling System (IHS), comprising:
an Embedded Controller (EC) [col. 16 lines 15-27 – includes processors with low power and high power cores that are dedicated to running the monitoring module. THIS meets the specification definition of an EC as a processing core dedicated to running IHS operations not normally handled by a host processor]; and
a memory coupled to, or integrated into, the EC, wherein the memory comprises program instructions [col 16 lines 57-59 – memory includes the monitoring module] that, upon execution by the EC, cause the EC to:
receive sensor data from a sensor [col. 3 lines 54-58, col. 7 lines 42-51, col. 10 lines 39-43 – monitoring module receives sensor data from the various sensors in the device];
determine, based at least in part on the sensor data, that an accident occurred to the IHS [col. 3 lines 54-58, col. 7 lines 42-51, col. 10 lines 35-37 – uses the sensor data to distinguish and characterize fall events. Fall events are accidents].
Srinivas does not explicitly teach that in response to the determination that the accident occurred, initiate scanning of components of the IHS; and
based on the scanning of the components, determine whether one or more of the components of the IHS are malfunctioning.
Srinivas does, however, teach recommending the device be checked for damage [col. 20 lines 11-13].
Vieira teaches in response to the determination that the accident occurred, initiate scanning of components of the IHS [par 2, 6, 7, 29, 33, 44 – when the device is subject to non-standard use, for instance falls and drops, the device runs a diagnostic on operating characteristics of multiple elements]; and
based on the scanning of the components, determine whether one or more of the components of the IHS are malfunctioning [par 2, 6, 7, 29, 33, 44 – the diagnostic is compared to a baseline and determines if there is damage].
It would have been obvious to one of ordinary skill in the art prior to the effective filing date to combine the diagnostic of Vieira with the accident detection of Srinivas.
One of ordinary skill in the art prior to the effective filing date would have been motivated to make the combination because Srinivas explicitly teaches a desire to check a device for damage after an accident. Vieira meets this desire with an automated diagnostic triggered based on non-standard use, e.g. a fall or drop similar to the accident of Srinivas, in order to avoid interference with ongoing performance, uncertainties, feelings of anxiety or worry [par 4] and further allows such diagnostic to be done free from user intervention [par 44].
Regarding claim 2:
The combination teaches:
The IHS of claim 1, wherein the sensor comprises at least one of: an accelerometer, a gyroscope, or an Inertial Measurement Unit (IMU) [Srinivas col. 3 lines 54-58, col. 5 lines 15-17 – at least accelerometers and gyroscopes].
Regarding claim 3:
The combination teaches:
The IHS of claim 1, wherein the accident comprises at least one of: a drop, a fall, a throw, a hit, a crash, an impact, or a collision involving the IHS or a component thereof [Srinivas col. 2 lines 8-9].
Regarding claim 5:
The combination teaches:
The IHS of claim 1, wherein the determining whether the one or more components of the IHS are malfunctioning includes comparing data from the initiated scanning with data from prior scans of the components [Vieira par 2, 6, 7, 29, 33, 44].
Regarding claim 6:
The combination teaches:
The IHS of claim 1, wherein the program instructions, upon execution, further cause the EC to:
receive at least one system parameter policy from a cloud service or an operating system service, wherein the at least one system parameter policy comprises at least one user notification process [Srinivas col. 14 lines 35-42, 48-54 – monitoring module is OS level service, various parameters received at the OS level such as threshold, determination of whether the module is active, possibly anonymous transmission]; and
wherein to issue the notification, the program instructions, upon execution, further cause the EC to:
issue the notification based, at least in part, on the at least one user notification process [Srinivas col. 14 lines 35-42, 48-54].
Regarding claim 7:
The combination teaches:
The IHS of claim 1, wherein to issue the notification, the program instructions, upon execution, further cause the EC to:
write an entry into an event viewer;
present an operating system level user-interface to a user [Srinivas col. 15 lines 17-21];
issue an audio or video alert; or
issue a network notification to a backend service [Srinivas col. 11 line 60-col. 12 line 14].
Regarding claim 8:
The combination teaches:
The IHS of claim 1, wherein to issue the notification, the program instructions, upon execution, further cause the EC to: transmit information to a second IHS via a personal area network (PAN) [Srinivas col. 11 line 60-col. 12 line 14 – sends the communication to external server using Bluetooth or NFC, encompasses a PAN].
Regarding claim 9:
The combination teaches:
The IHS of claim 8, wherein the sensor data comprises sensor shock event data, and wherein the information transmitted to the second IHS comprises system state information and the sensor shock event data [Srinivas col. 14 lines 66-67, col. 15 lines 8-11, col. 20 lines 6-8, col. 20 lines 13-16].
Regarding claim 10:
The combination teaches:
The IHS of claim 1, wherein the program instructions, upon execution, further cause the EC to: in response to the determination that an accident occurred, capture an image by a camera [Srinivas col. 10 lines 48-52].
Regarding claim 11:
The combination teaches:
The IHS of claim 1, wherein the notification comprises at least one of: IHS identification data, the sensor data, or accident classification data [Srinivas col. 11 line 60-col 12 line 14, col. 15 lines 7-10, col. 15 lines 14-21].
Regarding claim 12:
The combination teaches:
The IHS of claim 1, wherein the program instructions, upon execution, cause the EC to:
determine, based at least in part upon the sensor data, at least one of:
a type of the accident, or a severity of the accident [col. 15 lines 11-23],
wherein the notification comprises at least one of:
the type, or the severity [col. 15 lines 11-23].
Regarding claim 13:
The combination teaches:
The IHS of claim 1, wherein the program instructions, upon execution by the EC, further cause the EC to:
execute an Artificial Intelligence/Machine Learning (AI/ML) model configured to determine whether the sensor data is indicative of the accident [Srinivas col. 12 lines 15-30].
Regarding claim 14:
The combination teaches:
The IHS of claim 13, wherein the AI/ML model is further configured to:
identify a type of the accident comprising at least one of: an accidental fall or drop, a collision or impact with a stationary object, a collision or impact with a moving object, a collision or impact while onboard a moving vehicle, or a vandalization by a user [Srinivas col. 12 lines 15-30]; and
wherein the notification comprises information regarding the type of the accident [Srinivas col. 12 lines 15-30].
Regarding claim 15:
The combination teaches:
The IHS of claim 1, wherein the program instructions, upon execution by the EC, further cause the EC to:
identify a severity of the accident [Srinivas col. 15 lines 11-23] based, at least in part, upon the sensor data, wherein the severity of the accident comprises at least one of:
a height of a drop or fall, a duration of the drop or fall, or a force of a collision or impact [Srinivas col. 20 lines 13-16]; and
wherein the notification comprises information regarding the severity of the accident [Srinivas col. 15 lines 11-23, col. 20 lines 13-16].
Regarding claim 16:
The combination teaches:
A method, comprising:
receiving, by an Embedded Controller (EC) or Operating System (OS) service of an Information Handling System (IHS) [Srinivas col. 16 lines 15-27],
sensor data from a sensor [Srinivas col. 3 lines 54-58, col. 7 lines 42-51, col. 10 lines 39-43];
determining, based at least in part upon the sensor data, that an accident has occurred to the IHS [Srinivas col. 3 lines 54-58, col. 7 lines 42-51, col. 10 lines 35-37];
in response to the determining that the accident has occurred, scanning components of the IHS to collect diagnostic data [Vieira par 2, 6, 7, 29, 33, 44];
comparing the diagnostic data with data from prior scans of the components of the IHS [Vieira par 2, 6, 7, 29, 33, 44];
based on the comparing, determining whether one or more of the components of the IHS are damaged [Vieira par 2, 6, 7, 29, 33, 44].
Regarding claim 17:
The combination teaches:
The method of claim 16, further comprising:
receiving at least one system parameter policy from a cloud service or an OS service [Srinivas col. 14 lines 35-42, 48-54],
wherein the at least one system parameter policy comprises at least one user notification process [Srinivas col. 14 lines 35-42, 48-54; and
wherein issuing the notification further comprises:
issuing the notification based, at least in part, on the at least one user notification process [Srinivas col. 14 lines 35-42, 48-54].
Regarding claim 19:
The combination teaches:
An Information Handling System (IHS), comprising:
a processor [Srinivas col. 16 lines 15-27]; and
a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution by the processor [Srinivas col 16 lines 57-59], cause the IHS to:
receive sensor data from a sensor, wherein the sensor data indicates that an accident has occurred to the IHS [Srinivas col. 3 lines 54-58, col. 7 lines 42-51, col. 10 lines 35-43];
in response to the indication that the accident has occurred, causing an inventory service to scan components of the IHS to generate current inventory status data [Vieira par 2, 6, 7, 29, 33, 44];
based on comparing the current inventory status data to results of prior scans of the components of the IHS, determine whether the components of the IHS are damaged [Vieira par 2, 6, 7, 29, 33, 44].
Claims 21 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Srinivas-Vieira as applied to claims 16 and 19 above, and further in view of Thompson et al. (2018/0246552).
Regarding claim 21:
See the teachings above with respect to claim 16.
The Srinivas-Vieira combination further teaches wherein the accident is determined to be a collision or impact while being shipped [Srinivas col. 15 lines 5-17].
The Srinivas-Vieira combination does not explicitly teach that the shipping occurs on a moving vehicle.
Thompson teaches that shipping occurs on a moving vehicle [par 48].
It would have been obvious to one of ordinary skill in the art prior to the effective filing date to combine the shipping of Srinivas-Vieira with the shipping details of Thompson.
One of ordinary skill in the art prior to the effective filing date would have been motivated to make the combination because Srinivas-Vieira explicitly teach a fall or impact occurring while being shipped without providing any explicit details of how that shipping occurs, creating an implicit need for such details. Thompson meets that need by providing such details, i.e. that shipping occurs via moving vehicles such as trucks, ships, airplanes, etc. [par 48].
Regarding claim 23:
The combination teaches:
The IHS of claim 19, wherein the accident is determined to be at least one of: a collision or impact while onboard a moving vehicle [Srinivas col. 15 lines 5-17, Thompson par 48], or a vandalization by a user.
Claims 16, 17, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Harrington (2008/0253015) in view of Vieira.
Regarding clam 16:
Harrington teaches:
A method [par 11 – teaches a method], comprising:
receiving, by an Embedded Controller (EC) or Operating System (OS) service of an Information Handling System (IHS), [par 27 – part of the Linux kernel, thus teaches an OS service of an IHS]
sensor data from a sensor [par 4, 26, 27, 32, 33 – receives data from an accelerometer];
determining, based at least in part upon the sensor data, a type of accident that has occurred to the IHS [par 4, 26, 27, 32, 33 – receives data from an accelerometer and detects if a user shake, keyboard bash or display case smack, among other things, have occurred]; and
Harrington does not explicitly teach:
in response to the determining that the accident has occurred, scanning components of the IHS to collect diagnostic data;
comparing the diagnostic data with data from prior scans of the components of the IHS;
based on the comparing, determining whether one or more of the components of the IHS are damaged.
Vieira teaches:
in response to the determining that the accident has occurred, scanning components of the IHS to collect diagnostic data [Vieira par 2, 6, 7, 29, 33, 44];
comparing the diagnostic data with data from prior scans of the components of the IHS [Vieira par 2, 6, 7, 29, 33, 44];
based on the comparing, determining whether one or more of the components of the IHS are damaged [Vieira par 2, 6, 7, 29, 33, 44].
It would have been obvious to one of ordinary skill in the art prior to the effective filing date to combine the diagnostic of Vieira with the accident detection of Harrington.
One of ordinary skill in the art prior to the effective filing date would have been motivated to make the combination because Vieira teaches that performing automated diagnostics after detecting non-standard use avoids interference with ongoing performance, uncertainties, feelings of anxiety or worry [par 4] and further allows such diagnostic to be done free from user intervention [par 44].
Regarding claim 17:
The combination teaches:
The method of claim 16, further comprising:
receiving at least one system parameter policy from a cloud service or an OS service, wherein the at least one system parameter policy comprises at least one user notification process; and wherein issuing the notification further comprises [Harrington par 31-36 – policy is set in OS service to both detect the type of accident and to notify the user and administrator]:
issuing the notification based, at least in part, on the at least one user notification process [Harrington par 35, 36].
Regarding claim 22:
The combination teaches:
The method of claim 16, wherein the type of accident is a vandalization by a user [Harrington par 14, 27, 33, 36 – as explained above, shakes, bashed, smacks or abuse meet the BRI of vandalization by a user].
Response to Arguments
Applicant’s arguments with respect to the claims have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The arguments rest entirely on allegations that the previous rejection does not address the newly recited limitations. The newly recited limitations are rejected according to the new grounds of rejection as cited and explained above. Additionally, applicant’s amendment has created new antecedent basis with a plurality of dependent claims as indicated above.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARC M DUNCAN whose telephone number is (571)272-3646. The examiner can normally be reached M-F: 730am-9am, 10am-4:30pm.
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, Bryce Bonzo can be reached at 571-272-3655. 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.
/MARC DUNCAN/Primary Examiner, Art Unit 2113
Prosecution Insights