Detailed Action
Claims 1-9 and 11-34 are pending.
Claims 1-9 and 11-34 are rejected.
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.
Claims 1-2, 4, 9, 11-22, 24 and 26-34 are rejected under 35 U.S.C. 103 as being unpatentable over Castaneda et al (Pub. No.: US 2017/0017392 A1) in view of HAGA et al (Pub. No.: US 2019/0069407 A1) and Ashton et al (Pub. No.: US 2018/0211451 A1).
As per claim 1, Castaneda discloses an apparatus comprising:- a vehicle communication circuit structured to interpret vehicle communications data associated with a vehicle (Castaneda, Fig 1-2, paragraph 0034, 0038, wherein the industrial vehicles 108 can wirelessly communicate through one or more access points 110 to a corresponding networking component 106. Also, the industrial vehicles 108 can be equipped with WiFi, cellular or other suitable technology that allows the processing device 102 on the industrial vehicle 108 to communicate directly with a remote device (e.g., over the networks 104). The illustrated processing device 202 is implemented as an information linking device that comprises the necessary circuitry to implement communication with a remote server, data and information processing for processing vehicle data, and wired (and optionally wireless) communication to components of the corresponding industrial vehicle 108 to which the processing device 202 is mounted); - a visualization circuit structured to generate visualization data in response to the vehicle communications data (Castaneda, Fig 2, 4, 6 paragraph 0087, 0089, 0092-0094 wherein in an example implementation, widgets are used to represent the current state of the vehicle speed, fork height, load weight, battery charge, clock, stop watch, odometer, trip meter, hour meter, time, date, etc. In this regard, the widgets represent “live” data. The current state of data values can be obtained for instance, by the processor of the controller 216 communicating with either a master state data repository on the industrial vehicle 108 (e.g., where the current state of monitored functions is aggregated into a common location), or by communicating (e.g., querying, polling, reading from, etc.) with specific vehicle control modules, sensors, etc., across the vehicle network system 226, via the monitoring I/O 220, or a combination thereof. Also, the current state data can be ascertained by polling or otherwise querying a remote server, e.g., the server 112 described with reference to FIG. 1, which extracts relevant data from the industrial vehicle data repository 116 and communicates that relevant data back to the controller 216); and - a display interface circuit structured to transmit the visualization data (Castaneda, Fig 6, paragraph 0122, 0139, wherein a graphical user interface 1102 is analogous to the graphical user interface component 206 (FIG. 2) and graphical user interface 302 (FIG. 3). The graphical user interface 1102 includes a housing 1104 having a front face 1106 defining a display section 1108 and a vehicle operator control section 1110. A display 1108A within the display section 1108 (e.g., touch screen) illustrates the display of two widgets, as described with reference to FIGS. 5-10). Castaneda already discloses a first network onboard the vehicle that is a controller area network (CAN) based protocol network (Castaneda, paragraph 0056, wherein “As an example, the industrial vehicle network system 226 may comprise a controller area network (CAN) bus, ZigBee, Bluetooth, Local Interconnect Network (LIN), time-triggered data-bus protocol (TTP), RS422 bus, Ethernet, universal serial bus (USB), other suitable communication strategy, or combinations thereof”), and an external communications portal or an external device (Castaneda, paragraph 0034, wherein “Also, the industrial vehicles 108 can be equipped with WiFi, cellular or other suitable technology that allows the processing device 102 on the industrial vehicle 108 to communicate directly with a remote device (e.g., over the networks 104)”’ Paragraph 0093, wherein “Also, the current state data can be ascertained by polling or otherwise querying a remote server, e.g., the server 112 described with reference to FIG. 1, which extracts relevant data from the industrial vehicle data repository 116 and communicates that relevant data back to the controller 216” ). In addition, Castaneda already disclose displayable widgets that display different kind of information related to the vehicle. Thus, even though Castaneda does not explicitly disclose that the visualization data having a first network identifier identifying a first network onboard a vehicle and a second network identifier identifying at least one of: an external communications portal structured to facilitate electronic communications between devices disposed onboard the vehicle and devices disposed offboard the vehicle; or an external device disposed offload the vehicle wherein the first network identifier identifies that the first network onboard the vehicle is a controller area network (CAN) based protocol network, the structure of the visualization circuit and the function of displaying does not depend on the content of the data to be displayed/visualized and thus, Castaneda display (the visualization circuit) is able to display any information including a first network identifier identifying a first network onboard a vehicle and a second network identifier as claimed. In addition, displaying state information of a vehicle including a first network identifier identifying a first network onboard a vehicle and a second network identifier identifying at least one of: an external communications portal structured to facilitate electronic communications between devices disposed onboard the vehicle and devices disposed offboard the vehicle; or an external device disposed offload the vehicle wherein the first network identifier identifies that the first network onboard the vehicle is a controller area network (CAN) based protocol network is well known in the art. To make the record clear, the examiner introduces HAGA to disclose wherein the visualization data having a first network identifier identifying a first network onboard a vehicle and a second network identifier wherein the first network identifier identifies that the first network onboard the vehicle is at least one of a controller area network (CAN) based protocol network (HAGA, Fig 9, paragraph 0077, wherein “More specifically, the transfer control unit 140 determines whether a bus that has received the CAN frame is the first CAN bus (bus 30a) or the second CAN bus (bus 30b). The transfer control unit 140 then compares the bus with sources in the priority transfer list and a CAN-ID of the CAN frame with CAN-IDs having priority in transfer in the priority transfer list. If an applicable combination of a source and a CAN-ID having priority in transfer is found as a result of the comparison, the transfer control unit 140 identifies destination identification information corresponding to the combination to select a destination of an E frame based on the received CAN frame. A CAN-ID having priority in transfer (i.e., a particular ID) in the priority transfer list is, for example, a predetermined CAN-ID (error notification ID) for a CAN frame indicating an abnormality in driving control of the vehicle. When the gateway 100 promptly transmits, to the E-ECU 200a or the like, a CAN frame having the error notification ID transmitted from a C-ECU, for example, a display of the IVI 300a connected to the E-ECU 200a can promptly display a warning screen based on information regarding an error notification. An accident, therefore, can be effectively prevented. If CAN-IDs of CAN frames relating to the driving control of the vehicle such as driving, turning, and stopping are set as particular IDs in addition to the error notification ID, E-ECUs can promptly display information relating to the driving control, and safe driving of the vehicle can be effectively achieved”; Thus, the CAN-ID can be the first network identifier identifying a first network onboard a vehicle as a controller area network (CAN) based protocol network and the destination identification information can be the second network identifier identifying at least one of an external communications portal or an external device).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing of the invention to modify Castaneda in view of HAGA to achieve the claimed limitation because this would have provided an easy way to promptly display a warning screen based on information regarding an error notification. An accident, therefore, can be effectively prevented (see HAGA paragraph 0077). HAGA destination identification information seems to identify a first network onboard but not identifying at least one of: an external communications portal structured to facilitate electronic communications between devices disposed onboard the vehicle and devices disposed offboard the vehicle; or an external device disposed offload the vehicle. However, Ashton discloses identifying at least one of: an external communications portal structured to facilitate electronic communications between devices disposed onboard the vehicle and devices disposed offboard the vehicle; or an external device disposed offload the vehicle (Ashton, Fig 4, paragraph 0039-0040, wherein “one or more techniques and methodologies may be implemented to present the distributions, performance metrics, etc. For example, graphical representations, such as one or more histograms, may be used to present data distributions. Other types of graphical representations may also be used to assist a viewer in identifying particular performance features of a vehicle (e.g., for visually comparing with similar information from two or more other vehicles). Along with presenting this information (e.g., on a display device connected to the server 218, a vehicle display, a display located remote from the vehicle information provider), the information may also be stored (e.g., on the storage device 220) at the vehicle information provider 202, at one or more remote locations, etc.”; Thus, as shown in Fig 4, the graphical representation, which is displayed in a vehicle display, includes information about a second vehicle and thus identifying at least an external device disposed offload the vehicle (the second vehicle or a component within the second vehicle) ; wherein the second vehicle is external device with respect to the first vehicle).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing of the invention to modify Castaneda and HAGA in view of Ashton to achieve the claimed limitation because this would have provided an easy way to visually comparing the current car performance information with similar information of a different car which may be used to identify which vehicle is appropriate for the environment (see Ashton paragraph 0023).
As pre claim 2, claim 1 is incorporated and Castaneda discloses an electronic display structured to interpret and display the visualization data (Castaneda, Fig 6, paragraph 0122, 0139, wherein a graphical user interface 1102 is analogous to the graphical user interface component 206 (FIG. 2) and graphical user interface 302 (FIG. 3). The graphical user interface 1102 includes a housing 1104 having a front face 1106 defining a display section 1108 and a vehicle operator control section 1110. A display 1108A within the display section 1108 (e.g., touch screen) illustrates the display of two widgets, as described with reference to FIGS. 5-10I).
As pre claim 4, claim 1 is incorporated and Castaneda discloses wherein the visualization circuit is further structured to include portions of meta-data of the vehicle communications data in the visualization data (Castaneda, Fig 2, 4, 6 paragraph 0087, 0089, 0092-0094 wherein n an example implementation, widgets are used to represent the current state of the vehicle speed, fork height, load weight, battery charge, clock, stop watch, odometer, trip meter, hour meter, time, date, etc. In this regard, the widgets represent “live” data)
As pre claim 9, claim 1 is incorporated and Castaneda discloses wherein the first network identifier identifies that the first network onboard the vehicle is an Ethernet based protocol (Castaneda, paragraph 0034, 0052, wherein the industrial vehicles 108 can be equipped with WiFi, cellular or other suitable technology that allows the processing device 102 on the industrial vehicle 108 to communicate directly with a remote device (e.g., over the networks 104). Although a single transceiver 212 is illustrated for convenience, in practice, one or more wireless communication technologies may be provided (e.g., WiFi, Bluetooth, and cellular). For instance, the transceiver 212 may be able to communicate with a remote server, e.g., server 112 of FIG. 1 via 802.11 across the access points 110 of FIG. 1. The transceiver 212 may also optionally support other wireless communication, such as cellular, Bluetooth, radio frequency (RF), infrared (IR) or any other technology or combination of technologies. For instance, using a cellular to IP bridge, the transceiver 212 may be able to use a cellular signal to communicate directly with a remote server, e.g., a manufacturer server. The transceiver 212 connects to the processing device 202 via a suitable electrical connection 214, e.g., an Ethernet connection. However, the transceiver 212 can connect to the processing device 202 using other connections).
As pre claim 11, claim 1 is incorporated and Castaneda and HAGA further disclose wherein the visualization data has a third network identifier identifying second network on board the vehicle, wherein the second network is of a different type than the first network and the third identifier identifies the type of the second network (HAGA, Fig 8-9, paragraph 0069, wherein “As illustrated in the figure, the transfer rule information is information in which, for example, sources, CAN-IDs to be transferred, destination network types, and destination identification information are associated with one another. As the destination network types, E indicates the second network (E network), and CAN indicates the first network. The E network is the second network through which communication is performed in accordance with the Ethernet (registered trademark) protocol. When the destination network type is the E network, the destination identification information is a MAC address, and when the destination network type is CAN, the destination identification information is information for identifying a bus”).
As pre claim 12, claim 11 is incorporated and Castaneda and HAGA further disclose wherein the third network identifier identifies that the type of the second network is at least one of: a cellular based protocol; a WiFi based protocol; and/or a Bluetooth based protocol (Castaneda, paragraph 0056, wherein “As an example, the industrial vehicle network system 226 may comprise a controller area network (CAN) bus, ZigBee, Bluetooth, Local Interconnect Network (LIN), time-triggered data-bus protocol (TTP), RS422 bus, Ethernet, universal serial bus (USB), other suitable communication strategy, or combinations thereof”) (HAGA, Fig 8-9, paragraph 0069, wherein “As illustrated in the figure, the transfer rule information is information in which, for example, sources, CAN-IDs to be transferred, destination network types, and destination identification information are associated with one another. As the destination network types, E indicates the second network (E network), and CAN indicates the first network. The E network is the second network through which communication is performed in accordance with the Ethernet (registered trademark) protocol. When the destination network type is the E network, the destination identification information is a MAC address, and when the destination network type is CAN, the destination identification information is information for identifying a bus”)
As pre claim 13, claim 1 is incorporated and Castaneda discloses wherein the visualization data comprises a traffic monitoring visualization depicting network traffic (Castaneda, paragraph 0055, wherein the processing device 202 includes a monitoring input/output (I/O) component 220 to communicate via wired or wireless connection between peripheral devices mounted to or otherwise on the industrial vehicle, such as cameras, sensors, meters, encoders, switches, etc. (collectively represented by reference numeral 222) and the controller 216. The monitoring input/output (I/O) component 220 may also be connected to other devices, e.g., third party devices 224 such as RFID scanners, displays, meters, bar code scanners, cameras, or other devices to convey information to the controller 216).
As pre claim 14, claim 13 is incorporated and Castaneda discloses wherein the traffic monitoring visualization corresponds to depicting network traffic for at least one of: an end point on the first network; a vehicle system; an application; a flow; a service group; a vehicle controller; a vehicle function; the first network; a port of the first network; the external communications portal; or the external device (Castaneda, paragraph 0055, wherein the processing device 202 includes a monitoring input/output (I/O) component 220 to communicate via wired or wireless connection between peripheral devices mounted to or otherwise on the industrial vehicle, such as cameras, sensors, meters, encoders, switches, etc. (collectively represented by reference numeral 222) and the controller 216. The monitoring input/output (I/O) component 220 may also be connected to other devices, e.g., third party devices 224 such as RFID scanners, displays, meters, bar code scanners, cameras, or other devices to convey information to the controller 216)
As pre claim 15, claim 1 is incorporated and HAGA discloses wherein the visualization data comprises a port counter visualization (HAGA, Fig 8-9, paragraph 0055, wherein “The E-hub 400 also selects a destination port on the basis of a destination MAC address in a header of the received E frame in accordance with the MAC address table and outputs the E frame to a cable connected to the destination port to transfer the E frame”)
As pre claim 16, claim 1 is incorporated and Castaneda discloses wherein the visualization data comprises an end point data flow monitoring visualization (Castaneda, paragraph 0055, wherein the processing device 202 includes a monitoring input/output (I/O) component 220 to communicate via wired or wireless connection between peripheral devices mounted to or otherwise on the industrial vehicle, such as cameras, sensors, meters, encoders, switches, etc. (collectively represented by reference numeral 222) and the controller 216. The monitoring input/output (I/O) component 220 may also be connected to other devices, e.g., third party devices 224 such as RFID scanners, displays, meters, bar code scanners, cameras, or other devices to convey information to the controller 216).
As pre claim 17, claim 1 is incorporated and Castaneda discloses wherein the visualization data comprises a network activity profile for an end point of the first network (Castaneda, Fig 2, 4, 6 paragraph 0087, 0089, 0092-0094 wherein n an example implementation, widgets are used to represent the current state of the vehicle speed, fork height, load weight, battery charge, clock, stop watch, odometer, trip meter, hour meter, time, date, etc. In this regard, the widgets represent “live” data. The current state of data values can be obtained for instance, by the processor of the controller 216 communicating with either a master state data repository on the industrial vehicle 108 (e.g., where the current state of monitored functions is aggregated into a common location), or by communicating (e.g., querying, polling, reading from, etc.) with specific vehicle control modules, sensors, etc., across the vehicle network system 226, via the monitoring I/O 220, or a combination thereof. Also, the current state data can be ascertained by polling or otherwise querying a remote server, e.g., the server 112 described with reference to FIG. 1, which extracts relevant data from the industrial vehicle data repository 116 and communicates that relevant data back to the controller 216).
As pre claim 18, claim 1 is incorporated and Castaneda discloses wherein the visualization data comprises an external communications portal flow monitoring visualization (Castaneda, Fig 2, 4, 6 paragraph 0087, 0089, 0092-0094 wherein n an example implementation, widgets are used to represent the current state of the vehicle speed, fork height, load weight, battery charge, clock, stop watch, odometer, trip meter, hour meter, time, date, etc. In this regard, the widgets represent “live” data. The current state of data values can be obtained for instance, by the processor of the controller 216 communicating with either a master state data repository on the industrial vehicle 108 (e.g., where the current state of monitored functions is aggregated into a common location), or by communicating (e.g., querying, polling, reading from, etc.) with specific vehicle control modules, sensors, etc., across the vehicle network system 226, via the monitoring I/O 220, or a combination thereof. Also, the current state data can be ascertained by polling or otherwise querying a remote server, e.g., the server 112 described with reference to FIG. 1, which extracts relevant data from the industrial vehicle data repository 116 and communicates that relevant data back to the controller 216).
As pre claim 19, claim 1 is incorporated and Castaneda discloses wherein the visualization data comprises a network activity profile for at least one of: an end point on the first network; a vehicle system; an application; a flow; a service group; a vehicle controller; a vehicle function; the first network; a port of the first network; the external communications portal; or the external device (Castaneda, Fig 2, 4, 6 paragraph 0087, 0089, 0092-0094 wherein n an example implementation, widgets are used to represent the current state of the vehicle speed, fork height, load weight, battery charge, clock, stop watch, odometer, trip meter, hour meter, time, date, etc. In this regard, the widgets represent “live” data. The current state of data values can be obtained for instance, by the processor of the controller 216 communicating with either a master state data repository on the industrial vehicle 108 (e.g., where the current state of monitored functions is aggregated into a common location), or by communicating (e.g., querying, polling, reading from, etc.) with specific vehicle control modules, sensors, etc., across the vehicle network system 226, via the monitoring I/O 220, or a combination thereof. Also, the current state data can be ascertained by polling or otherwise querying a remote server, e.g., the server 112 described with reference to FIG. 1, which extracts relevant data from the industrial vehicle data repository 116 and communicates that relevant data back to the controller 216);
As pre claim 20, claim 1 is incorporated and Castaneda discloses wherein the display interface circuit is further structured to transmit the visualization data by performing at least one operation selected from the operations consisting of: storing the visualization data on a shared storage of the vehicle; storing the visualization data on a shared storage of the vehicle, and selectively transmitting the stored visualization data to a second external device; transmitting the visualization data to a secured cloud storage; and transmitting the visualization data to a secured cloud storage, and providing selected access to the stored visualization data to at least one of: a monitoring tool, an external application, a service tool, or a user device (Castaneda, paragraph 0053, wherein the memory can include memory that stores processing instructions, as well as memory for data storage, e.g., to implement one or more databases, data stores, registers, arrays, etc.)
As pre claim 21, claim 1 is incorporated and Castaneda discloses wherein the vehicle communication circuit is further structured to interpret vehicle communications data by performing at least one operation selected from the operations consisting of: interpreting the vehicle communications data from a policy stored on a memory positioned on the vehicle and communicatively coupled to the vehicle communication circuit; receiving the vehicle communications data from a service tool communicatively coupled to vehicle communication circuit; receiving the vehicle communications data from an application communicatively coupled to the vehicle communication circuit; or receiving the vehicle communications data from a monitoring tool communicatively coupled to the vehicle communication circuit (Castaneda, Fig 2, 4, 6 paragraph 0087, 0089, 0092-0094 wherein n an example implementation, widgets are used to represent the current state of the vehicle speed, fork height, load weight, battery charge, clock, stop watch, odometer, trip meter, hour meter, time, date, etc. In this regard, the widgets represent “live” data. The current state of data values can be obtained for instance, by the processor of the controller 216 communicating with either a master state data repository on the industrial vehicle 108 (e.g., where the current state of monitored functions is aggregated into a common location), or by communicating (e.g., querying, polling, reading from, etc.) with specific vehicle control modules, sensors, etc., across the vehicle network system 226, via the monitoring I/O 220, or a combination thereof. Also, the current state data can be ascertained by polling or otherwise querying a remote server, e.g., the server 112 described with reference to FIG. 1, which extracts relevant data from the industrial vehicle data repository 116 and communicates that relevant data back to the controller 216).
Claims 22, 24 and 26-34 are rejected under the same rationale as claim 1-4 and 9-21.
Claims 3 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Castaneda et al (Pub. No.: US 2017/0017392 A1) in view of HAGA et al (Pub. No.: US 2019/0069407 A1), Ashton et al (Pub. No.: US 2018/0211451 A1) and KIM (Pub. No.: US 2019/0366956 A1).
As pre claim 3, claim 1 is incorporated and Castaneda, Ashton and HAGA do not explicitly disclose wherein the visualization data includes visualization of a network topology of the first network. However, KIM discloses wherein the visualization data includes visualization of a network topology of the first network (KIM, paragraph 0074, wherein “The display 36 may be installed at a center fascia inside the vehicle 1 to provide the driver with various information and entertainment through a screen. For example, the display 36 may replay a video file stored in internal storage medium or external storage medium according to the driver's command, and may output images included in the video file. In addition, the display 36 may display information about a topology of a power network (PNT) of the vehicle 1”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing of the invention to modify Castaneda in view of HAGA, Ashton with KIM to achieve the claimed limitation because this would have provided a way to display to the user the network topology information allowing the user to easily identify the components and connections between them which help better locate any component that requires attention and/or fix.
Claim 23 is rejected under the same rationale as claim 3.
Claims 5-8 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Castaneda et al (Pub. No.: US 2017/0017392 A1) in view of HAGA et al (Pub. No.: US 2019/0069407 A1), Ashton et al (Pub. No.: US 2018/0211451 A1) and Argenti et al (Patent. No.: US 10,893,010 B1).
As pre claim 5, claim 1 is incorporated and Castaneda, Ashton and HAGA do not explicitly disclose a monitoring input circuit structured to interpret a data filtering value; wherein the visualization circuit is further structured to filter, based at least in part on the data filtering value, portions of the vehicle communications data used to generate the visualization data. However, Argenti discloses a monitoring input circuit structured to interpret a data filtering value; wherein the visualization circuit is further structured to filter, based at least in part on the data filtering value, portions of the vehicle communications data used to generate the visualization data (Argenti, col 11 lines: 24-34, wherein the spare attention capacity of the occupant is determined by a local filtering application, the filtering application may provide the determined spare attention capacity information to a message filtering module of the filtering application in order to apply the determined spare attention capacity to filtering incoming messages or other information directed to the occupant of the vehicle).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing of the invention to modify Castaneda in view of HAGA, Ashton with Argenti to achieve the claimed limitation because this would have provided a way to filter displayed information based on driver’s attention capacity to receive the information which improves user’s satisfaction without compromising the user safety (see Argenti col 1, lines: 44-62).
As pre claim 6, claim 5 is incorporated and Argenti further discloses wherein the data filtering value comprises at least one value selected from the values consisting of: a network address association; a vehicle control device association; a vehicle system association; a network protocol type; an end point identifier; a data type; an application association; an external device identifier; an external communications portal identifier; a flow association; and/or a service group association (Argenti, col 10 lines: 44-67, wherein one or more computing devices implementing a dynamic attention capacity monitoring service receive information related to operation of a vehicle or conditions in which the vehicle is operating. In some embodiments, a service interface of a dynamic attention capacity monitoring service may include one or more application programmatic interfaces (APIs) or other interfaces that enable the dynamic attention capacity monitoring service to receive information from a filtering application downloaded onto a local device, local to the vehicle. The filtering application may collect information about a vehicle from one or more vehicle systems, such as a GPS system, speedometer, etc. The filtering application may send the vehicle information to a dynamic attention capacity monitoring service. Additionally, one or more other devices local to a vehicle, such as a mobile device (e.g. phone, tablet, etc.) comprising an inertial measurement unit (IMU) may further generate information about operation of the vehicle, such as speed, direction, etc. and a filtering application downloaded to the local device may send the information to a dynamic attention capacity monitoring service).
As pre claim 7, claim 6 is incorporated and Argenti discloses wherein the data filtering value references at least one system selected from the systems consisting of: an engine system; a steering system; a braking system; a fuel system; a prime mover system; an anti-lock braking system; a traction control system; and/or a drivetrain control system (Argenti, col 10 lines: 44-67, wherein one or more computing devices implementing a dynamic attention capacity monitoring service receive information related to operation of a vehicle or conditions in which the vehicle is operating. In some embodiments, a service interface of a dynamic attention capacity monitoring service may include one or more application programmatic interfaces (APIs) or other interfaces that enable the dynamic attention capacity monitoring service to receive information from a filtering application downloaded onto a local device, local to the vehicle. The filtering application may collect information about a vehicle from one or more vehicle systems, such as a GPS system, speedometer, etc. The filtering application may send the vehicle information to a dynamic attention capacity monitoring service. Additionally, one or more other devices local to a vehicle, such as a mobile device (e.g. phone, tablet, etc.) comprising an inertial measurement unit (IMU) may further generate information about operation of the vehicle, such as speed, direction, etc. and a filtering application downloaded to the local device may send the information to a dynamic attention capacity monitoring service).
As pre claim 8, claim 6 is incorporated and Argenti discloses wherein the data filtering value references at least one system selected from the systems consisting of: a security system; a lighting system; a safety system; an environmental control system; an advanced driver-assistance system; and/or an infotainment system (Argenti, col 10 lines: 44-67, wherein one or more computing devices implementing a dynamic attention capacity monitoring service receive information related to operation of a vehicle or conditions in which the vehicle is operating. In some embodiments, a service interface of a dynamic attention capacity monitoring service may include one or more application programmatic interfaces (APIs) or other interfaces that enable the dynamic attention capacity monitoring service to receive information from a filtering application downloaded onto a local device, local to the vehicle. The filtering application may collect information about a vehicle from one or more vehicle systems, such as a GPS system, speedometer, etc. The filtering application may send the vehicle information to a dynamic attention capacity monitoring service. Additionally, one or more other devices local to a vehicle, such as a mobile device (e.g. phone, tablet, etc.) comprising an inertial measurement unit (IMU) may further generate information about operation of the vehicle, such as speed, direction, etc. and a filtering application downloaded to the local device may send the information to a dynamic attention capacity monitoring service).
Claim 25 is rejected under the same rationale as claim 5-8.
Response to Arguments
Applicant's arguments filed 03/02/2026 have been fully considered but they are moot in lights of the new grounds of rejection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAMZA N ALGIBHAH whose telephone number is (571)270-7212. The examiner can normally be reached 7:30 am - 3:30 pm.
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, Wing Chan can be reached at (571) 272-7493. 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.
/HAMZA N ALGIBHAH/Primary Examiner, Art Unit 2441