CTFR 18/381,393 CTFR 95789 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 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, 2, 9, 10, 17 have been amended. Claim Rejections - 35 USC § 112 07-30-01 AIA The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. 07-31-01 Claims 1-16 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 1 “ wherein the abstracting information is further comprising: abstracting the information on the mobility device based on whether provision of a controller area network (CAN) message of the information on the mobility device is available”) is not in the specification slightly different than the written description. The written description shows something different in page 5 of the specification “dividing the information on the mobility device into data for which provision of the CAN message is available and data for which provision of the CAN message is not available, and abstracting the data for which the provision of the CAN message is available” where the information is first divided whether is available and not available into data . It is unclear on what applicant is trying to do since the new amendment slightly differs from the written description and claim 3. Applicant creates a difference in meaning on what information and data. Based on the way applicant amended the independent claims it seems like the mobility service is abstracting the information based on availability however is missing the descript step shown in written descriptions how information becomes data in the claim. In addition, with the inclusion of claim 3 further divided the information into data based on availability and further abstract the data based on availability now creates a situation where multiple abstraction based on availability is made which is not shown in the written description. Claims 9 are rejected for similar reasons. Claims 2-8, 10-16 are rejected for being dependent on claims 1, 9. 07-30-02 AIA 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. 07-34-01 Claim 1-16 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 1 is unclear thus indefinite because claim limitation claims “ wherein the abstracting information is further comprising: abstracting the information on the mobility device based on whether provision of a controller area network (CAN) message of the information on the mobility device is available”) is not in the specification. The written description shows something different in page 5 of the specification “dividing the information on the mobility device into data for which provision of the CAN message is available and data for which provision of the CAN message is not available, and abstracting the data for which the provision of the CAN message is available” where the information is first divided whether is available and not available into data . It is unclear on what applicant is trying to do since the new amendment slightly differs from the written description and claim 3. Applicant creates a difference in meaning on what information and data is. Based on the way applicant amended the independent claims it seems like the mobility service is abstracting the information based on availability however is missing the descript step shown in written descriptions how information becomes data in the claim. In addition, with the inclusion of claim 3 further divided the information into data based on availability and further abstract the data based on availability now creates a situation where multiple abstraction based on availability is made which is not shown in the written description. Claims 9 are rejected for similar reasons. Claims 2-8, 10-16 are rejected for being dependent on claims 1, 9. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-23-aia AIA 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. 07-21-aia AIA Claim (s) 1-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu et al. (US20180293811) in view of Johnston (US20230073618) . Regarding claim 1, Liu teaches A method of supporting mobility service, the method comprising: receiving, by a mobility data development platform, a request for providing information on a mobility device from a mobility service provider ( [0046] “Step S 10 , receiving a diagnosis instruction sent by the remote server and acquiring real-time vehicle data according to the diagnosis instruction”) ; abstracting, by the mobility data development platform, information on the mobility device in response to receiving the request for providing information; and providing, by the mobility data development platform, the abstracted information to the mobility device, wherein the abstracting information is further comprising: abstracting the information on the mobility device based on whether provision of a controller area network (CAN) message of the information on the mobility device is available . Liu does not explicitly teach abstracting, by the mobility data development platform, information on the mobility device in response to receiving the request for providing information; abstracted information, and providing, by the mobility data development platform, the abstracted information to the mobility device, wherein the abstracting information is further comprising: abstracting the information on the mobility device based on whether provision of a controller area network (CAN) message of the information on the mobility device is available. Johnston teaches abstracting, by the mobility data development platform, information on the mobility device in response to receiving the request for providing information ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value. For example, for one type of pump brake, a change in 5 degrees indicates a desired decrease of 5 MPH, and for another type of pump brake change in 5 degrees indicated a desired decrease of 7 MPH”, [0129] “The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”) ; and providing, by the mobility data development platform, the abstracted information to the mobility device ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value. For example, for one type of pump brake, a change in 5 degrees indicates a desired decrease of 5 MPH, and for another type of pump brake change in 5 degrees indicated a desired decrease of 7 MPH”) . wherein the abstracting information is further comprising: abstracting the information on the mobility device based on whether provision of a controller area network (CAN) message of the information on the mobility device is available ([0090] “The code in ASIL D 702 partition similarly may unpack the message and write signal data and the E2E state. These two values may then be accessed by an application in synchronized manner. In addition, code in ASIL D 702 may perform safety tasks. The code in QM partition 703 may only make signal data available to the application and not the E2E data”, ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value. For example, for one type of pump brake, a change in 5 degrees indicates a desired decrease of 5 MPH, and for another type of pump brake change in 5 degrees indicated a desired decrease of 7 MPH”, [0129] “The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”, (Examiner’s Note: based on [0090] QM partition 703 controls whether data signal are available to application, then [0128] describes an abstraction layer between the hardware components and application that abstract the data that is allowed) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Johnston. One of ordinary skill in the art would have been motivated to increase optimization of the system. Regarding claim 2, Liu teaches wherein the information on the mobility device includes the CAN message of the mobility device ([0074] “ For example, the vehicle may communicate information, such as diagnostics or fault codes, between external test equipment and automotive control units (ECU) (using ECU peripheral Driver 326 ) over DoIP 323 . This allows a vehicle system to, for example, track and analyze diagnostic information to improve failure detection. The core may also receive and send files to outside systems such as cloud servers via Controller Area Network (CAN) …. installed in the vehicle directly to connected with the vehicle bus as an independent device, wherein the type of the bus could be CANBUS”) . Regarding claim 3, Liu does not explicitly teach wherein further comprising: dividing the information on the mobility device into data for which provision of the CAN message of the mobility device is available and data for which provision of the CAN message of the mobility device is not available; and abstracting the data for which the provision of the CAN message of the mobility device is available and providing the abstracted data to the mobility device. Johnston teaches wherein further comprising: dividing the information on the mobility device into data for which provision of the CAN message of the mobility device is available and data for which provision of the CAN message of the mobility device is not available ([0090] “The code in ASIL D 702 partition similarly may unpack the message and write signal data and the E2E state. These two values may then be accessed by an application in synchronized manner. In addition, code in ASIL D 702 may perform safety tasks. The code in QM partition 703 may only make signal data available to the application and not the E2E data”) ; and abstracting the data for which the provision of the CAN message of the mobility device is available and providing the abstracted data to the mobility device ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value. For example, for one type of pump brake, a change in 5 degrees indicates a desired decrease of 5 MPH, and for another type of pump brake change in 5 degrees indicated a desired decrease of 7 MPH”, [0129] “The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Johnston. One of ordinary skill in the art would have been motivated to increase optimization of the system. Regarding claim 4, Liu does not teach wherein the abstracting of the information on the mobility device is performed based on filtering information for the abstracting of the information on the mobility device. Johnston teaches wherein the abstracting of the information on the mobility device is performed based on filtering information for the abstracting of the information on the mobility device ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value, (Examiner’s Note: abstracting is equivalent to filtering) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Johnston. One of ordinary skill in the art would have been motivated to increase optimization of the system. Regarding claim 5, Liu does not teach further comprising: generating a library to be ported directly to the mobility device from the information on the mobility device through the abstraction based on the filtering information. Johnston teaches further comprising: generating a library to be ported directly to the mobility device from the information on the mobility device through the abstraction based on the filtering information ([0129] “The encoded runtime configuration file 1503 may be sent to the UDS server 1501 which then may write it to the variant library 1504 in the memory of the vehicle. The vehicle may use non-volatile memory, and optionally one or more additional libraries such as Power-loss resilience application to decode the runtime configuration file 1503 . As a result, an additional decoded runtime configuration 1505 may be added to the variant library storage. The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Johnston. One of ordinary skill in the art would have been motivated to increase optimization of the system. Regarding claim 6, Liu teaches wherein the request for providing information on the mobility device is transmitted from the mobility service provider to the mobility data development platform ( [0046] “Step S 10 , receiving a diagnosis instruction sent by the remote server and acquiring real-time vehicle data according to the diagnosis instruction”, ( [0047] “Specifically, the diagnosis equipment is connected to the vehicle as an on-board equipment for a long time through the OBD diagnosis pedestal of the vehicle, wherein the OBD diagnosis pedestal can be an ordinary OBD … wherein the type of the bus could be CANBUS”) through a developer dashboard ( [0047] “Specifically, the diagnosis equipment is connected to the vehicle as an on-board equipment for a long time through the OBD diagnosis pedestal of the vehicle, wherein the OBD diagnosis pedestal can be an ordinary OBD … wherein the type of the bus could be CANBUS”) . Regarding claim 7, Liu does not explicitly teach wherein the developer dashboard includes a consistency checking module configured to perform a consistency check of the library, wherein the consistency checking module stored in a memory of the developer dashboard. Johnston teaches wherein the developer dashboard includes a consistency checking module configured to perform a consistency check of the library, wherein the consistency checking module stored in a memory of the developer dashboard ([0083] “E2E checking modules may be configured to validate a single message given a running state of past messages. E2E libraries may be written per the Automotive Open System architecture (AUTOSAR) specification. E2E checking may provide one of “error,” “OK,” “repeated,” “no new data” or “wrong sequence” values needed to validate the signal message”) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Johnston. One of ordinary skill in the art would have been motivated to increase optimization of the system. Regarding claim 8, Liu teaches wherein the information related to the mobility device includes driving data or state data of the mobility device ([0073] “the data acquisition module 10 configured to receive a diagnosis instruction sent by the remote server and acquiring real-time vehicle data according to the diagnosis instruction”) . Regarding claim 9, Liu teaches A system for supporting mobility service, the system comprising: a developer dashboard configured to receive a request for providing information on a mobility device from a mobility service provider ( [0046] “Step S 10 , receiving a diagnosis instruction sent by the remote server and acquiring real-time vehicle data according to the diagnosis instruction”, ( [0047] “Specifically, the diagnosis equipment is connected to the vehicle as an on-board equipment for a long time through the OBD diagnosis pedestal of the vehicle, wherein the OBD diagnosis pedestal can be an ordinary OBD … wherein the type of the bus could be CANBUS”) ; and a mobility data development platform, communicably connected to the developer dashboard ( [0047] “Specifically, the diagnosis equipment is connected to the vehicle as an on-board equipment for a long time through the OBD diagnosis pedestal of the vehicle, wherein the OBD diagnosis pedestal can be an ordinary OBD … wherein the type of the bus could be CANBUS”) , configured to: abstract information on the mobility device in response to receiving the request for providing information, and provide the abstracted information to the mobility device , wherein the abstracting information is further comprising: abstracting the information on the mobility device based on whether provision of a controller area network (CAN) message of the information on the mobility device is available. Liu does not explicitly teach configured to: abstract information on the mobility device in response to receiving the request for providing information, and provide the abstracted information to the mobility device, wherein the abstracting information is further comprising: abstracting the information on the mobility device based on whether provision of a controller area network (CAN) message of the information on the mobility device is available. Johnston teaches configured to: abstract information on the mobility device in response to receiving the request for providing information ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value. For example, for one type of pump brake, a change in 5 degrees indicates a desired decrease of 5 MPH, and for another type of pump brake change in 5 degrees indicated a desired decrease of 7 MPH”, [0129] “The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”) , and provide the abstracted information to the mobility device ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value. For example, for one type of pump brake, a change in 5 degrees indicates a desired decrease of 5 MPH, and for another type of pump brake change in 5 degrees indicated a desired decrease of 7 MPH”, [0129] “The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”) , wherein the abstracting information is further comprising: abstracting the information on the mobility device based on whether provision of a controller area network (CAN) message of the information on the mobility device is available ([0090] “The code in ASIL D 702 partition similarly may unpack the message and write signal data and the E2E state. These two values may then be accessed by an application in synchronized manner. In addition, code in ASIL D 702 may perform safety tasks. The code in QM partition 703 may only make signal data available to the application and not the E2E data”, ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value. For example, for one type of pump brake, a change in 5 degrees indicates a desired decrease of 5 MPH, and for another type of pump brake change in 5 degrees indicated a desired decrease of 7 MPH”, [0129] “The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”, (Examiner’s Note: based on [0090] QM partition 703 controls whether data signal are available to application, then [0128] describes an abstraction layer between the hardware components and application that abstract the data that is allowed) .. It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Johnston. One of ordinary skill in the art would have been motivated to increase optimization of the system. Regarding claim 10. Liu teaches wherein the information on the mobility device includes CAN message of the mobility device ([0074] “ installed in the vehicle directly to connected with the vehicle bus as an independent device, wherein the type of the bus could be CANBUS”) . Regarding claim 11, Liu does not teach wherein the mobility data development platform is further configured to: divide the information on the mobility device into data for which provision of the CAN message of the mobility device is available and data for which provision of the CAN message of the mobility device is not available; and abstract the data for which the provision of the CAN message of the mobility device is available and provide the abstracted data to the mobility device. Johnston teaches wherein the mobility data development platform is further configured to: divide the information on the mobility device into data for which provision of the CAN message of the mobility device is available and data for which provision of the CAN message of the mobility device is not available ([0090] “The code in ASIL D 702 partition similarly may unpack the message and write signal data and the E2E state. These two values may then be accessed by an application in synchronized manner. In addition, code in ASIL D 702 may perform safety tasks. The code in QM partition 703 may only make signal data available to the application and not the E2E data”) ; and abstract the data for which the provision of the CAN message of the mobility device is available and provide the abstracted data to the mobility device ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value. For example, for one type of pump brake, a change in 5 degrees indicates a desired decrease of 5 MPH, and for another type of pump brake change in 5 degrees indicated a desired decrease of 7 MPH”, [0129] “The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Johnston. One of ordinary skill in the art would have been motivated to increase optimization of the system. Regarding claim 12, Liu does not teach wherein the abstraction of the information on the mobility device is performed based on filtering information for the abstraction of the information on the mobility device. Johnston teaches wherein the abstraction of the information on the mobility device is performed based on filtering information for the abstraction of the information on the mobility device ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value, (Examiner’s Note: abstracting is equivalent to filtering) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Johnston. One of ordinary skill in the art would have been motivated to increase optimization of the system. Regarding claim 13, Liu does not teach wherein the mobility data development platform is further configured to generate a library to be ported directly to the mobility device from the information on the mobility device through the abstraction based on the filtering information. Johnston teaches wherein the mobility data development platform is further configured to generate a library to be ported directly to the mobility device from the information on the mobility device through the abstraction based on the filtering information ([0129] “The encoded runtime configuration file 1503 may be sent to the UDS server 1501 which then may write it to the variant library 1504 in the memory of the vehicle. The vehicle may use non-volatile memory, and optionally one or more additional libraries such as Power-loss resilience application to decode the runtime configuration file 1503 . As a result, an additional decoded runtime configuration 1505 may be added to the variant library storage. The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Johnston. One of ordinary skill in the art would have been motivated to increase optimization of the system. Regarding claim 14, Liu teaches wherein the request for providing information on the mobility device is transmitted from the mobility service provider to the mobility data development platform ( [0047] “Specifically, the diagnosis equipment is connected to the vehicle as an on-board equipment for a long time through the OBD diagnosis pedestal of the vehicle, wherein the OBD diagnosis pedestal can be an ordinary OBD … wherein the type of the bus could be CANBUS”) through the developer dashboard ( [0047] “Specifically, the diagnosis equipment is connected to the vehicle as an on-board equipment for a long time through the OBD diagnosis pedestal of the vehicle, wherein the OBD diagnosis pedestal can be an ordinary OBD … wherein the type of the bus could be CANBUS”) . Regarding claim 15, Liu does not teach wherein the developer dashboard further includes a consistency checking module configured to perform a consistency check of the library, wherein the consistency checking module stored in a memory of the developer dashboard. Johnston teaches wherein the developer dashboard further includes a consistency checking module configured to perform a consistency check of the library, wherein the consistency checking module stored in a memory of the developer dashboard ([0083] “E2E checking modules may be configured to validate a single message given a running state of past messages. E2E libraries may be written per the Automotive Open System architecture (AUTOSAR) specification. E2E checking may provide one of “error,” “OK,” “repeated,” “no new data” or “wrong sequence” values needed to validate the signal message”) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Johnston. One of ordinary skill in the art would have been motivated to increase optimization of the system. Regarding claim 16, Liu teaches wherein the information related to the mobility device includes driving data or state data of the mobility device ([0073] “the data acquisition module 10 configured to receive a diagnosis instruction sent by the remote server and acquiring real-time vehicle data according to the diagnosis instruction”) . Regarding claim 17, Liu teaches A method of supporting mobility service, the method comprising: receiving, by a mobility data development platform, a request for providing information including a controller area network (CAN) message for a mobility device from a mobility service provider ( [0046] “Step S 10 , receiving a diagnosis instruction sent by the remote server and acquiring real-time vehicle data according to the diagnosis instruction”, [0047] “Specifically, the diagnosis equipment is connected to the vehicle as an on-board equipment … connected with the vehicle bus as an independent device, wherein the type of the bus could be CANBUS”) ; abstracting, by the mobility data development platform, information on the mobility device in response to receiving the request for providing information, dividing into data for which provision of the CAN message is available and data for which provision of the CAN message is not available, and abstracting the data for which the provision of the CAN message is available; and providing, by the mobility data development platform, the abstracted information to the mobility device . Liu does not explicitly teach abstracting, by the mobility data development platform, information on the mobility device in response to receiving the request for providing information, dividing into data for which provision of the CAN message is available and data for which provision of the CAN message is not available, and abstracting the data for which the provision of the CAN message is available, and providing, by the mobility data development platform, the abstracted information to the mobility device. Johnston teaches abstracting, by the mobility data development platform, information on the mobility device in response to receiving the request for providing information ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value. For example, for one type of pump brake, a change in 5 degrees indicates a desired decrease of 5 MPH, and for another type of pump brake change in 5 degrees indicated a desired decrease of 7 MPH”, [0129] “The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”) , dividing into data for which provision of the CAN message is available and data for which provision of the CAN message is not available ([0090] “The code in ASIL D 702 partition similarly may unpack the message and write signal data and the E2E state. These two values may then be accessed by an application in synchronized manner. In addition, code in ASIL D 702 may perform safety tasks. The code in QM partition 703 may only make signal data available to the application and not the E2E data”) , and abstracting the data for which the provision of the CAN message is available ([0090] “The code in ASIL D 702 partition similarly may unpack the message and write signal data and the E2E state. These two values may then be accessed by an application in synchronized manner. In addition, code in ASIL D 702 may perform safety tasks. The code in QM partition 703 may only make signal data available to the application and not the E2E data”, ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value. For example, for one type of pump brake, a change in 5 degrees indicates a desired decrease of 5 MPH, and for another type of pump brake change in 5 degrees indicated a desired decrease of 7 MPH”, [0129] “The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”, (Examiner’s Note: based on [0090] QM partition 703 controls whether data signal are available to application, then [0128] describes an abstraction layer between the hardware components and application that abstract the data that is allowed) . , and providing, by the mobility data development platform, the abstracted information on the mobility device to the mobility device ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value. For example, for one type of pump brake, a change in 5 degrees indicates a desired decrease of 5 MPH, and for another type of pump brake change in 5 degrees indicated a desired decrease of 7 MPH”, [0129] “The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Johnston. One of ordinary skill in the art would have been motivated to increase optimization of the system . Response to Arguments 07-37 AIA Applicant's arguments filed 1/20/2026 have been fully considered but they are not persuasive. Applicant’s Argument Applicant remarks Thus, Johnston classifies the type of data that is accessible or written based on the partition in which a code agent resides. In other words, Johnston merely distinguishes whether signal data or E2E state data is handled, depending on the partition of the code agent, and does not teach or suggest classifying data based on whether provision of a controller area network (CAN) message of the information on the mobility device is available. Moreover, Johnston does not teach or suggest abstracting the data for which the provision of the CAN message is available as recited in claim 17. Examiner’s Response Examiner respectfully disagrees. Claims 1, 9 are different from claim 17. Claims 17 is more narrow and contains several more limitations than claims 1, 9. Applicant argues classifying data which is not in the claims. Claim 17 “A method of supporting mobility service, the method comprising: receiving, by a mobility data development platform, a request for providing information including a controller area network (CAN) message for a mobility device from a mobility service provider; abstracting, by the mobility data development platform, information on the mobility device in response to receiving the request for providing information, dividing into data for which provision of the CAN message is available and data for which provision of the CAN message is not available, and abstracting the data for which the provision of the CAN message is available; and providing, by the mobility data development platform, the abstracted information to the mobility device. Furthermore in regards to what applicant argue Johnston does not teach or suggest abstracting the data for which the provision of the CAN message is available is shown in ([0090] “The code in ASIL D 702 partition similarly may unpack the message and write signal data and the E2E state. These two values may then be accessed by an application in synchronized manner. In addition, code in ASIL D 702 may perform safety tasks. The code in QM partition 703 may only make signal data available to the application and not the E2E data”, ([0128] “the pump brake module may provide a DBC file that provides an angle of depression for the brake pedal. However, since different brakes have different “give,” the same angle change in the brake depression value may be handled completely differently by other parts of the vehicle (e.g., the ECU or TCM). To solve the problem, the system may provide an abstraction layer 1506 between the DBC interpretation by an associated interface and applications executing for other modules in the system. For example, the abstraction layer may provide an “intended speed change” value into the system instead of a raw angle value. For example, for one type of pump brake, a change in 5 degrees indicates a desired decrease of 5 MPH, and for another type of pump brake change in 5 degrees indicated a desired decrease of 7 MPH”, [0129] “The application (e.g., ECM applications) may then request the needed configuration from the library during the runtime. Optionally, there may be an abstraction layer available to the application that may access abstracted data instead of raw values from DBC files”. (Examiner’s Note: based on [0090] QM partition 703 controls whether data signal are available to application, then [0128] describes an abstraction layer between the hardware components and application that abstract the data that is allowed). [0090] QM partition divides the data into available and not available as shown “The code in ASIL D 702 partition similarly may unpack the message and write signal data and the E2E state. These two values may then be accessed by an application in synchronized manner. In addition, code in ASIL D 702 may perform safety tasks. The code in QM partition 703 may only make signal data available to the application and not the E2E data”, since the E2e data is not available to the application. Furthermore, Examiner would like to note, that applicant does not describe in the claims what happens when the data is considered not available. Conclusion 07-39 AIA THIS ACTION IS MADE FINAL. 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 KEITH TRAN-DANH FOLLANSBEE whose telephone number is (571)272-3071. The examiner can normally be reached 10am -6 pm M-Th. 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, Derrick Ferris can be reached at 571-272-3123. 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. /K.T.F./Examiner, Art Unit 2411 /DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411 Application/Control Number: 18/381,393 Page 2 Art Unit: 2411 Application/Control Number: 18/381,393 Page 3 Art Unit: 2411 Application/Control Number: 18/381,393 Page 5 Art Unit: 2411 Application/Control Number: 18/381,393 Page 6 Art Unit: 2411 Application/Control Number: 18/381,393 Page 7 Art Unit: 2411 Application/Control Number: 18/381,393 Page 8 Art Unit: 2411 Application/Control Number: 18/381,393 Page 9 Art Unit: 2411 Application/Control Number: 18/381,393 Page 10 Art Unit: 2411 Application/Control Number: 18/381,393 Page 11 Art Unit: 2411 Application/Control Number: 18/381,393 Page 12 Art Unit: 2411 Application/Control Number: 18/381,393 Page 13 Art Unit: 2411 Application/Control Number: 18/381,393 Page 14 Art Unit: 2411 Application/Control Number: 18/381,393 Page 15 Art Unit: 2411 Application/Control Number: 18/381,393 Page 16 Art Unit: 2411 Application/Control Number: 18/381,393 Page 17 Art Unit: 2411 Application/Control Number: 18/381,393 Page 18 Art Unit: 2411 Application/Control Number: 18/381,393 Page 19 Art Unit: 2411 Application/Control Number: 18/381,393 Page 20 Art Unit: 2411 Application/Control Number: 18/381,393 Page 21 Art Unit: 2411 Application/Control Number: 18/381,393 Page 22 Art Unit: 2411 Application/Control Number: 18/381,393 Page 23 Art Unit: 2411 Application/Control Number: 18/381,393 Page 24 Art Unit: 2411 Application/Control Number: 18/381,393 Page 25 Art Unit: 2411 Application/Control Number: 18/381,393 Page 26 Art Unit: 2411 Application/Control Number: 18/381,393 Page 27 Art Unit: 2411 Application/Control Number: 18/381,393 Page 28 Art Unit: 2411 Application/Control Number: 18/381,393 Page 29 Art Unit: 2411 Application/Control Number: 18/381,393 Page 30 Art Unit: 2411
Prosecution Insights