DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 10/27/2025 have been fully considered but they are not persuasive. On Page 9 of Remarks, Applicant argues: “The Office Action therefore is equating the discussion of Collective Perception Messages (CPMs) and Collective Perception Services (CPS) with the recitation to “utilize a message broker to publish the SDSMs to topics for retrieval by the vehicles.” Significantly, however, there is no mention in the cited reference of message topics at all, let alone of a message broker that publishes messages for retrieval by vehicles. The Office Action acknowledges this deficiency by stating “Note that the CPM TxM (message broker) transmits the CPM (SDSM) for retrieval by the vehicles.)” The CPM TxM is not disclosed or suggested as being a message broker, and the transmission of CPMs is not to publish messages for retrieval. Because these details are not shown in the reference, Merwaday cannot disclose at least to “utilize a message broker to publish the SDSMs to topics for retrieval by the vehicles” as recited by claim 1. For at least these reasons, the rejection of independent claim 1 should be reconsidered and withdrawn. Independent claims 8 and 15 differ in scope from that of independent claim 1, but are patentable at least for similar reasons.”
Firstly, Applicant argues that the reference does not disclose message topics at all. Messages inherently have topics, otherwise they would be blank messages and serve no purpose, which is not the case in the cited reference. Second, Applicant argues that the cited reference does not disclose a message broker that publishes messages for retrieval by vehicles. As explained in the Non-Final rejection and referenced by the Applicant above: “Note that the CPM TxM (message broker) transmits the CPM (SDSM) for retrieval by the vehicles.)” A message broker, under broadest reasonable interpretation, is an entity that outputs messages, such as the CPM TxM. The messages are retrieved by vehicles, as disclosed by the cited reference (and previously recited in the Non-Final Office Action): (Merwaday, Paragraphs 125-126, “FIG. 15 shows an example CPS service functional architecture 1500 including various functional entities of the CPS 1521 and interfaces to other facilities and other ITS layers. The CPS 1521 may correspond to the CPS 1421 of FIG. 14 . For sending and receiving CPMs, the CPS includes a CPM transmission management function (CPM TxM) 1503, CPM reception management function (CPM RxM) 1504, an encode CPM function (E-CPM) 1505, and a decode CPM function (D-CPM) 1506. The E-CPM 1505 constructs CPMs as discussed herein and/or according to the format specified in Annex A of [TS103324]. The CPM RxM 1504 implements the protocol operation of the receiving (Rx) ITS-S 1400 such as, for example, triggering the decoding of CPMs upon receiving incoming CPMs; provisioning of the received CPMs to the LDM 1423 and/or ITS apps 1401 of the Rx ITS-S 1400; and/or checking the validity of the information of the received CPMs (see e.g., ETSI TR 103 460 V2.1.1 (2020-10) (“[TR103460]”)). The D-CPM 1506 decodes received CPMs.”) The CPM TxM is directly described here as transmitting messages (i.e. outputting/publishing) for retrieval/reception by vehicles (via CPM RxM), thus fully disclosing “utilize a message broker to publish the SDSMs to topics for retrieval by the vehicles”.
On Page 9 of Remarks, Applicant further argues: “The dependent claims are patentable at least due to their dependence on one of independent claims 1, 8, or 15. Moreover, the dependent claims recite separately patentable subject matter. In an example, new dependent claim 21 recites, in the context of the claim “wherein the message broker is implemented using message queuing telemetry transport (MQTT), and the topics are MQTT topics.” Merwaday fails to disclose at least these additional details, at least for reasons similar to those discussed above. For at least these reasons, claim 21 is separately patentable.”
Because the rejections of independent claims 1, 8, and 15, the dependent claims remain rejected. Additionally, Applicant’s arguments with respect to claim(s) 21 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.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 4, 6, 8, 11, 13, 15, 18, and 19 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Merwaday (US20230300579A1).
Regarding claim 1, Merwaday teaches “A federated object data mechanism (FODM) for multi-radio access technology (RAT) vehicle-to-everything (V2X) communication, comprising: one or more hardware components, (Merwaday, Figure 20 and Paragraph 161, “FIG. 20 illustrates an example of components that may be present in an compute node 2000 for implementing the techniques (e.g., operations, processes, methods, and methodologies) described herein. This compute node 2000 provides a closer view of the respective components of node 2000 when implemented as or as part of a computing device or system. The compute node 2000 can include any combination of the hardware or logical components referenced herein, and may include or couple with any device usable with a communication network or a combination of such networks. In particular, any combination of the components depicted by FIG. 20 can be implemented as individual ICs, discrete electronic devices, or other modules, instruction sets, programmable logic or algorithms, hardware, hardware accelerators, software, firmware, or a combination thereof adapted in the compute node 2000, or as components otherwise incorporated within a chassis of a larger system. Additionally or alternatively, any combination of the components depicted by FIG. 20 can be implemented as a system-on-chip (SoC), a single-board computer (SBC), a system-in-package (SiP), a multi-chip package (MCP), and/or the like, in which a combination of the hardware elements are formed into a single IC or a single package. Furthermore, the compute node 2000 may be or include a client device, server, appliance, network infrastructure, machine, robot, drone, and/or any other type of computing devices such as any of those discussed herein. For example, the compute node 2000 may correspond to any of the UEs 1310, NAN 1330, edge compute node 1340, NFs in network 1365, and/or application functions (AFs)/servers 1390 of FIG. 13 ; REM-RUM service 950 (or individual REM servers) of FIG. 9 ; EVSE 1011 and/or EVSE controller 1110 of FIGS. 10-12 ; ITS 1400 of FIG. 14 ; vehicle computing system 1700 of FIG. 17 ; personal computing system 1800 of FIG. 18 ; roadside infrastructure 1900 of FIG. 19 ; and/or any other computing device/system discussed herein.”)
“configured to receive connected messages from vehicles, the connected messages specifying vehicle information including vehicle locations of the vehicles;” (Merwaday, Paragraphs 27 and 31, “In various implementations, individual vehicles 1310 report their road usage information to the infrastructure (e.g., NANs 1330, edge platform 1340, DN 1365, and/or cloud 1390) by transmitting road information messages over a suitable W-V2X RAT link and/or C-V2X RAT link. As examples, the road information messages contain some or all of the following information: identity (ID) information of the vehicle 1310 (e.g., VIN, an ITS-AID, and/or any other identifier or network address, such as any of those discussed herein), start timestamp for the reported road usage data, end timestamp for the reported road usage data, and a list of geo-area IDs and the corresponding travelled distances. Additionally or alternatively, the road information messages include one or more bins 201. The road information messages can be (or are encapsulated in) any suitable message format, such as Cooperative Awareness Message (CAM), Collective Perception Message (CPM), Decentralized Environmental Notification Message (DENM), VRU Awareness Messages (VAMs), cellular network message format(s), C-V2X message formats, and/or any other message format, such as any of those discussed herein.”; “The vehicles enabled with V2X communications periodically broadcast different types of messages such as, for example, ITS-S messages (e.g., Cooperative Awareness Message (CAM), Collective Perception Message (CPM), Decentralized Environmental Notification Message (DENM), VRU Awareness Messages (VAMs)) C-V2X messages, and/or other like messages, such as any of those discussed herein. These messages contain various information about the respective Tx vehicles 1310. For example, a CAM contains basic information about the transmitting vehicle 1310 such as vehicle ID, location, heading direction, speed, and the like (see e.g., [EN302637-2]). Other ITS-S messages include the same or similar information. This information can be used to track the vehicles’ 1310 movements at the infrastructure, and estimate and/or predict the road usage of the vehicles 1310.”)
“receive perception objects from sensors of roadside infrastructure, the perception objects specifying object locations as perceived by the sensors;” (Merwaday, Paragraph 42, “These implementations can be used for tracking the road usage of vehicles 1310 that do not include V2X communications capabilities and/or when vehicles 1310 travel through areas with little or no network connectivity by utilizing roadside infrastructure 1330 and/or sensors 610 resources. In the example of FIG. 6 , each edge computing platform 1340 is connected to a set of sensors 610, via local DN 1365 (e.g., via a wired and/or wireless connection(s)), which stream sensor data (e.g., live video footage and/or other sensor data based on the type of sensors 610 being employed) of their respective coverage sectors (e.g., sectors 830 of FIG. 8 ). The edge computing platforms 1340 process received sensor data (e.g., video data and/or the like) using perception algorithms and/or object tracking techniques to detect vehicles 1310. The identity of vehicles 1310 can also be uniquely identified using, for example, license plate numbers and vehicle features (e.g., make, model, color, vehicle type, and/or the like), and/or other identification features/data. Furthermore, using the information about each sensors’ 610 deployment locations and/or field of views (FoVs), the perception algorithms can also estimate locations of the identified vehicles 1310.”)
“utilize a fusion component to combine the vehicle locations and the object locations to form a consolidated object database including data elements specifying each of the vehicles and the perception objects;” (Merwaday, Paragraphs 115 and 140, “As alluded to previously, CP involves ITS-Ss sharing information about their current environments with one another. An ITS-S participating in CP broadcasts information about its current (e.g., driving) environment rather than about itself. For this purpose, CP involves different ITS-Ss actively exchanging locally perceived objects (e.g., other road participants and VRUs 1316, obstacles, and the like) detected by local perception sensors by means of one or more V2X RATs. In some implementations, CP includes a perception chain that can be the fusion of results of several perception functions at predefined times. These perception functions may include local perception and remote perception functions. The local perception is provided by the collection of information from the environment of the considered ITS element (e.g., VRU device, vehicle, infrastructure, and/or the like).”; “The object (data) fusion system maintains one or more lists of objects that are currently perceived by the ITS-S. The object fusion mechanism performs prediction of each object to timestamps at which no measurement is available from sensors; associates objects from other potential sensors mounted to the station or received from other ITS-Ss with objects in the tracking list; and merges the prediction and an updated measurement for an object. At each point in time, the data fusion mechanism is able to provide an updated object list based on consecutive measurements from (possibly) multiple sensors containing the state spaces for all tracked objects. V2X information (e.g., CAMs, DENMs, CPMs, and/or the like) from other vehicles may additionally be fused with locally perceived information. Other approaches additionally provide alternative representations of the processed sensor data, such as an occupancy grid.”)
“utilize a sensor data sharing message (SDSM) generator to generate SDSMs describing each of the data elements of the consolidated object database;” (Merwaday, Paragraph 137, “FIG. 16 shows an example of object data extraction levels of the CP basic service 1601, which may be the same or similar as the CPS 1521 of FIG. 15 and/or CPS 1421 of FIG. 14 . Part 1600 a depicts an implementation in which sensor data from sensors 1 to n (where n is a number) is processed as part of a low-level data management entity 1610. The CP basic service 1601 then selects object candidates to be transmitted as defined in clause 4.3 of ETSI TR 103 562 V2.1.1 (2019-12) (“[TR103562]”) and/or according to section 6 of [TS103324]. Part 1600 a is more likely to avoid filter cascades, as the task of high-level fusion will be performed by the receiving ITS-S. Part 1600 b depicts an implementation in which the CP basic service 1601 selects objects to be transmitted as part of the CPM according to section 6 of [TS103324] and/or according to clause 4.3 of [TR103562] from a high-level fused object list, thereby abstracting the original sensor measurement used in the fusion process. The CPM provides data fields to indicate the source of the object. In parts 1600 a and 1600 b, the sensor data is also provided to a data fusion function 1620 for high-level object fusion, and the fused data is then provided to one or more ADAS apps 1630.” Note that the CP basic service generates CPM (Collective Perception Message), which are mapped to the SDSM generator and SDSM.)
“and utilize a message broker to publish the SDSMs to topics for retrieval by the vehicles.” (Merwaday, Paragraphs 125-126, “FIG. 15 shows an example CPS service functional architecture 1500 including various functional entities of the CPS 1521 and interfaces to other facilities and other ITS layers. The CPS 1521 may correspond to the CPS 1421 of FIG. 14 . For sending and receiving CPMs, the CPS includes a CPM transmission management function (CPM TxM) 1503, CPM reception management function (CPM RxM) 1504, an encode CPM function (E-CPM) 1505, and a decode CPM function (D-CPM) 1506. The E-CPM 1505 constructs CPMs as discussed herein and/or according to the format specified in Annex A of [TS103324]. The CPM RxM 1504 implements the protocol operation of the receiving (Rx) ITS-S 1400 such as, for example, triggering the decoding of CPMs upon receiving incoming CPMs; provisioning of the received CPMs to the LDM 1423 and/or ITS apps 1401 of the Rx ITS-S 1400; and/or checking the validity of the information of the received CPMs (see e.g., ETSI TR 103 460 V2.1.1 (2020-10) (“[TR103460]”)). The D-CPM 1506 decodes received CPMs.” Note that the CPM TxM (message broker) transmits the CPM (SDSM) for retrieval by the vehicles.)
Regarding claim 4, Merwaday teaches “The FODM of claim 1,”
“wherein the one or more hardware components include a road side unit (RSU) configured to receive raw sensor data from a sensor, and utilize a corresponding sensor client to generate the perception objects from the raw sensor data.” (Merwaday, Paragraph 42, “These implementations can be used for tracking the road usage of vehicles 1310 that do not include V2X communications capabilities and/or when vehicles 1310 travel through areas with little or no network connectivity by utilizing roadside infrastructure 1330 and/or sensors 610 resources. In the example of FIG. 6 , each edge computing platform 1340 is connected to a set of sensors 610, via local DN 1365 (e.g., via a wired and/or wireless connection(s)), which stream sensor data (e.g., live video footage and/or other sensor data based on the type of sensors 610 being employed) of their respective coverage sectors (e.g., sectors 830 of FIG. 8 ). The edge computing platforms 1340 process received sensor data (e.g., video data and/or the like) using perception algorithms and/or object tracking techniques to detect vehicles 1310. The identity of vehicles 1310 can also be uniquely identified using, for example, license plate numbers and vehicle features (e.g., make, model, color, vehicle type, and/or the like), and/or other identification features/data. Furthermore, using the information about each sensors’ 610 deployment locations and/or field of views (FoVs), the perception algorithms can also estimate locations of the identified vehicles 1310.”)
Regarding claim 6, Merwaday teaches “The FODM of claim 1,”
“wherein the SDSM generator is configured to add metadata to the SDSMs including, for each data element, a type of data source for the data element and a reference time of perception of the data element.” (Merwaday, Paragraph 99, “A CPM contains a set of detected objects and regions, along with their observed status and attribute information. The content may vary depending on the type of the road user or object and the detection capabilities of the originating ITS-S. For detected objects, the status information is expected to include at least the detection time, position, and motion state. Additional attributes such as the dimensions and object type may be provided. To support the CPM interpretation at any receiving ITS-S, the sender can also include information about its sensors, like sensor types and fields of view.” Note that according to Paragraph 137 recited above, the CP service (SDSM generator) generates the CPM (SDSM), which includes the features claimed above. )
Claims 8, 11, and 13 recite a method with steps corresponding to the elements of the system recited in Claims 1, 4, and 6. Therefore, the recited steps of this claim are mapped to the analogous elements in the corresponding system claims.
Claims 15, 18, and 19 recite a non-transitory computer-readable medium storing instructions corresponding to the elements of the system recited in Claims 1, 4, and 6. Therefore, the recited instructions of these claims are mapped to the analogous elements in the corresponding system claims. Finally, Merwaday discloses a non-transitory computer-readable medium (Merwaday, Paragraph 167, “The storage 2020 may include instructions 2021 in the form of software, firmware, or hardware commands to implement the techniques described herein. Although such instructions 2021 are shown as code blocks included in the memory 2010 and/or storage 2020, any of the code blocks may be replaced with hardwired circuits, for example, built into an ASIC, FPGA memory blocks/cells, and/or the like. In an example, the instructions 2001, 2011, 2021 provided via the memory 2010, the storage 2020, and/or the processor 2002 are embodied as a non-transitory or transitory machine-readable medium (also referred to as “computer readable medium” or “CRM”) including code (e.g., instructions 2001, 2011, 2021, accessible over the IX 2006, to direct the processor 2002 to perform various operations and/or tasks, such as a specific sequence or flow of actions as described herein and/or depicted in any of the accompanying drawings. The CRM may be embodied as any of the devices/technologies described for the memory 2010 and/or storage 2020.”)
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.
Claim(s) 2, 9, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Merwaday in view of Filippou (US 20220116755 A1).
Regarding claim 2, Merwaday teaches “The FODM of claim 1,”
While Merwaday teaches “wherein the one or more hardware components include a multi-access edge computing (MEC) device configured to implement the fusion component” (Merwaday, Paragraphs 44 and 90, “FIG. 7 shows an example process 700 of an edge processing pipeline that is operated at or by an edge platform 1340. In some examples, the process 700 may be embodied as the RUM 1305 e, which may be an edge app and/or edge service that is operated or otherwise provided by the edge platform 1340. Process 700 begins at operation 701, where the RUM 1305 e receives sensor data from one or more sensors 610. In some examples, the edge compute node 1340 obtains continuous (or nearly continuous) streams of input (sensor) data from respective sensors 610. At operation 702, the RUM 1305 e performs environment perception based on the received sensor data. In some examples, the environment perception includes methods and algorithms that collaboratively process the sensor data received from various sensors 610 (e.g., using sensor data fusion techniques, such as any of those discussed herein) to develop a contextual understanding of the environment.”; “The edge compute node 1340 includes or is part of an edge computing network (or edge cloud) that employs one or more edge computing technologies (ECTs). In one example implementation, the ECT is and/or operates according to the MEC framework, as discussed in ETSI GR MEC 001 v3.1.1 (2022-01), ETSI GS MEC 003 v3.1.1 (2022-03), ETSI GS MEC 009 v3.1.1 (2021-06), ETSI GS MEC 010-1 v1.1.1 (2017-10), ETSI GS MEC 010-2 v2.2.1 (2022-02), ETSI GS MEC 011 v2.2.1 (2020-12), ETSI GS MEC 012 V2.2.1 (2022-02), ETSI GS MEC 013 V2.2.1 (2022-01), ETSI GS MEC 014 v2.1.1 (2021-03), ETSI GS MEC 015 v2.1.1 (2020-06), ETSI GS MEC 016 v2.2.1 (2020-04), ETSI GS MEC 021 v2.2.1 (2022-02), ETSI GR MEC 024 v2.1.1 (2019-11), ETSI GS MEC 028 V2.2.1 (2021-07), ETSI GS MEC 029 v2.2.1 (2022-01), ETSI MEC GS 030 v2.1.1 (2020-04), and ETSI GR MEC 031 v2.1.1 (2020-10) (collectively referred to herein as “[MEC]”), the contents of each of which are hereby incorporated by reference in their entireties.” Accordingly, the MEC performs the fusion via process 700.), Merwaday does not expressly disclose that the edge computing device implements the SDSM generator and the message broker.
Filippou discloses an MEC for managing messaging to vehicles (Filippou, Paragraph 128, “The MEC apps 926 and 928 can be configured to provide services 930/931, which can include processing network communications traffic of different types associated with one or more wireless connections. In some embodiments, the services 930/931 include message broker services configured to support multiple application layer protocols used in the collection/distribution of data from/to multiple data sources across different MNOs. In this regard, services 930/931 provided by MEC apps can also be referred to as V2X message brokers. In other embodiments, MEC apps 926 and 928 are used for V2X message subscription (e.g., to subscribe to V2X messages distributed from V2X message brokers) and V2X message publication (e.g., to publish data to V2X message brokers which can be distributed to V2X message subscribers).”)
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to use the MEC of Merwaday for the generation (CP basic service) and brokering (CPM TxM) of messages, as taught by Filippou.
The motivation for doing so would have been to consolidate the system and expedite processing. Further, one skilled in the art could have combined the elements as described above by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results. Therefore, it would have been obvious to combine Merwaday with the above teaching of Filippou to fully disclose, “wherein the one or more hardware components include a multi-access edge computing (MEC) device configured to implement the fusion component, the SDSM generator, and the message broker.”
Claim 9 recites a method with steps corresponding to the elements of the system recited in Claim 2. Therefore, the recited steps of this claim are mapped to the analogous elements in the corresponding system claim. Additionally, the rationale and motivation to combine Merwaday and Filippou apply to this claim.
Claims 16 recites a non-transitory computer-readable medium storing instructions corresponding to the elements of the system recited in Claim 2. Therefore, the recited instructions of these claims are mapped to the analogous elements in the corresponding system claims. Additionally, the rationale and motivation to combine Merwaday and Filippou apply to this claim. Finally, Merwaday discloses a non-transitory computer-readable medium (Merwaday, Paragraph 167, “The storage 2020 may include instructions 2021 in the form of software, firmware, or hardware commands to implement the techniques described herein. Although such instructions 2021 are shown as code blocks included in the memory 2010 and/or storage 2020, any of the code blocks may be replaced with hardwired circuits, for example, built into an ASIC, FPGA memory blocks/cells, and/or the like. In an example, the instructions 2001, 2011, 2021 provided via the memory 2010, the storage 2020, and/or the processor 2002 are embodied as a non-transitory or transitory machine-readable medium (also referred to as “computer readable medium” or “CRM”) including code (e.g., instructions 2001, 2011, 2021, accessible over the IX 2006, to direct the processor 2002 to perform various operations and/or tasks, such as a specific sequence or flow of actions as described herein and/or depicted in any of the accompanying drawings. The CRM may be embodied as any of the devices/technologies described for the memory 2010 and/or storage 2020.”)
Claim(s) 3, 10, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Merwaday in view of Filippou (US 20220116755 A1) further in view of Franke (US 20230182843 A1).
Regarding claim 3, Merwaday teaches “The FODM of claim 1,”
While Merwaday teaches a cloud component (Merwaday, Figure 1), an MEC device (Merwaday, Paragraph 90), and a fusion component, SDSM generator, and message broker (see rejection of claim 1), Merwaday does not expressly disclose that the cloud implements the fusion component and the MEC implements the SDSM generator and message broker.
Filippou discloses an MEC for managing messaging to vehicles (Filippou, Paragraph 128, “The MEC apps 926 and 928 can be configured to provide services 930/931, which can include processing network communications traffic of different types associated with one or more wireless connections. In some embodiments, the services 930/931 include message broker services configured to support multiple application layer protocols used in the collection/distribution of data from/to multiple data sources across different MNOs. In this regard, services 930/931 provided by MEC apps can also be referred to as V2X message brokers. In other embodiments, MEC apps 926 and 928 are used for V2X message subscription (e.g., to subscribe to V2X messages distributed from V2X message brokers) and V2X message publication (e.g., to publish data to V2X message brokers which can be distributed to V2X message subscribers).”)
Franke discloses a cloud for performing fusion, (Franke, Paragraph 63, “In an eighth method step 208, an object 303, 304 in the vicinity of the road user is identified in the data cloud 306. For this purpose, the object list transferred to the data cloud 306 in the fifth method step 205 is used. Furthermore, additional object lists transferred to the data cloud 306 may be used in this process, for example object lists transferred to the data cloud 306 by other road users. If multiple object lists for objects 303, 304 in the environment of the road user are present in the data cloud 306, these object lists are fused in the data cloud 306, for example, to form an environment description of the environment of the road user, that is, the object lists are combined with each other to form a more comprehensive environment description. This environment description is then used in the data cloud 306 to identify an object 303, 304 in the vicinity of the road user.”)
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to use the MEC of Merwaday for the generation (CP basic service) and brokering (CPM TxM) of messages, as taught by Filippou, and use the cloud of Merwaday for the fusion component, as taught by Franke.
The motivation for doing so would have been to increase the scalability of fusion by using the cloud, and leverage the MEC for message management because the MEC is already communicatively coupled to the vehicle message recipients. Further, one skilled in the art could have combined the elements as described above by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results. Therefore, it would have been obvious to combine Merwaday with the above teachings of Filippou and Franke to fully disclose, “wherein the one or more hardware components include a cloud component configured to implement the fusion component, in communication with a MEC device configured to implement the SDSM generator and the message broker.”
Claim 10 recites a method with steps corresponding to the elements of the system recited in Claim 3. Therefore, the recited steps of this claim are mapped to the analogous elements in the corresponding system claim. Additionally, the rationale and motivation to combine Merwaday, Franke, and Filippou apply to this claim.
Claims 17 recites a non-transitory computer-readable medium storing instructions corresponding to the elements of the system recited in Claim 3. Therefore, the recited instructions of these claims are mapped to the analogous elements in the corresponding system claims. Additionally, the rationale and motivation to combine Merwaday, Franke, and Filipou apply to this claim. Finally, Merwaday discloses a non-transitory computer-readable medium (Merwaday, Paragraph 167, “The storage 2020 may include instructions 2021 in the form of software, firmware, or hardware commands to implement the techniques described herein. Although such instructions 2021 are shown as code blocks included in the memory 2010 and/or storage 2020, any of the code blocks may be replaced with hardwired circuits, for example, built into an ASIC, FPGA memory blocks/cells, and/or the like. In an example, the instructions 2001, 2011, 2021 provided via the memory 2010, the storage 2020, and/or the processor 2002 are embodied as a non-transitory or transitory machine-readable medium (also referred to as “computer readable medium” or “CRM”) including code (e.g., instructions 2001, 2011, 2021, accessible over the IX 2006, to direct the processor 2002 to perform various operations and/or tasks, such as a specific sequence or flow of actions as described herein and/or depicted in any of the accompanying drawings. The CRM may be embodied as any of the devices/technologies described for the memory 2010 and/or storage 2020.”)
Claim(s) 5 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Merwaday in view of Banjade (US20230095384A1).
Regarding claim 5, Merwaday teaches “The FODM of claim 1,”
While Merwaday discloses utilization of a plurality of RAT types (Merwaday, Paragraph 78, “The UEs 1310 also include an ITS-S 1313 that employs one or more Radio Access Technologies (RATs) to allows the UEs 1310 to communicate directly with one another and/or with infrastructure equipment (e.g., network access node (NAN) 1330). In some examples, the ITS-S 1313 corresponds to the ITS-S 1400 of FIG. 14 . The one or more RATs may refer to cellular V2X (C-V2X) RATs (e.g., V2X technologies based on 3GPP LTE, 5G/NR, and beyond), a WLAN V2X (W-V2X) RAT (e.g., V2X technologies based on DSRC in the USA and/or ITS-G5 in the EU), and/or some other RAT, such as any of those discussed herein.”), Merwaday does not expressly disclose “wherein a first vehicle of the vehicles supports a first RAT, a second vehicle of the vehicles supports a second RAT but not the first RAT, and the first and second vehicles are configured to interoperate using a logical interconnect plane of the federated object data mechanism (FODM).”
Banjade discloses “wherein a first vehicle of the vehicles supports a first RAT, a second vehicle of the vehicles supports a second RAT but not the first RAT, and the first and second vehicles are configured to interoperate using a logical interconnect plane of the federated object data mechanism (FODM).” (Banjade, Paragraph 62, “In arrangement 100, V-ITS-S 110 a may be equipped with a first V2X RAT communication system (e.g., C-V2X) whereas V-ITS-S 110 b may be equipped with a second V2X RAT communication system (e.g., W-V2X which may be DSRC, ITS-G5, or the like). In other embodiments, the V-ITS-S 110 a and/or V-ITS-S 110 b may each be employed with one or more V2X RAT communication systems. In these embodiments, the RSU 130 may provide V2X RAT translation services among one or more services/capabilities 180 so that individual V-ITS-Ss 110 may communicate with one another even when the V-ITS-Ss 110 implement different V2X RATs. According to various embodiments, the RSU 130 (or edge compute node 140) may provide VRU services among the one or more services/capabilities 180 wherein the RSU 130 shares CPMs, MCMs, VAMs DENMs, CAMs, etc., with V-ITS-Ss 110 and/or VRUs for VRU safety purposes including RSS purposes. The V-ITS-Ss 110 may also share such messages with each other, with RSU 130, and/or with VRUs. These messages may include the various data elements and/or data fields as discussed herein.”)
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to incorporate the interoperation (RAT translation) for vehicles with different RAT types of Banjade into the FODM of Merwaday.
The motivation for doing so would have been to enable communication between cars with different RAT types. Further, one skilled in the art could have combined the elements as described above by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results. Therefore, it would have been obvious to combine Merwaday with the above teaching of Banjade to fully disclose the invention of claim 5.
Claim 12 recites a method with steps corresponding to the elements of the system recited in Claim 5. Therefore, the recited steps of this claim are mapped to the analogous elements in the corresponding system claim. Additionally, the rationale and motivation to combine Merwaday and Banjade apply to this claim.
Claim(s) 7, 14, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Merwaday in view of Kwak (US20220264265A1).
Regarding claim 7, Merwaday teaches “The FODM of claim 1,”
While Merwaday discloses deduplication (Merwaday, Paragraph 101, “The CPM complements the Cooperative Awareness Message (CAM) (see e.g., ETSI EN 302 637-2 v1.4.1 (2019-04) (“[EN302637-2]”)) to establish and increase cooperative awareness. The CPM contains externally observable information about detected road users or objects and/or free space. The CP service may include methods to reduce duplication of CPMs sent by different ITS-Ss by checking for sent CPMs of other stations. On reception of a CPM, the receiving ITS-S becomes aware of the presence, type, and status of the recognized road user or object that was detected by the transmitting ITS-S. The received information can be used by the receiving ITS-S to support ITS apps to increase the safety situation and to improve traffic efficiency or travel time. For example, by comparing the status of the detected road user or received object information, the receiving ITS-S sub-system is able to estimate the collision risk with such a road user or object and may inform the user via the HMI of the receiving ITS sub-system or take corrective actions automatically. Multiple ITS apps may rely on the data provided by CPS. It is assigned to domain app support facilities in ETSI TS 102 894-1 v1.1.1 (2013-08) (“[TS102984-1]”). Additionally, CPM contents, structure, format, generation rules and processes, as well as various other aspects of CPMs are discussed in U.S. App. No. 18/079,499 filed on Dec. 12, 2022 (“[‘499]”), the contents of which are hereby incorporated by reference in its entirety and for all purposes.” Note that the fusion component is mapped to the CP service in the rejection of claim 1, therefore the fusion component of Merwaday performs the deduplication.), Merwaday does not expressly disclose that the deduplication is based on “message identifier, geolocation, and/or reference time of perception.”
Kwak teaches deduplication is based on geolocation (Kwak, Paragraph 227, “In the second and third cases {circle around (2)} and {circle around (3)}, the first ITS station may determine whether the sensing object is the duplication object identical to the recognition object recognized by the reception CAM (S304). If the sensing object is determined to be the overlapping object (S305), the first ITS station may calculate the distance to the overlapping object in the third case {circle around (3)}, and may determine whether the calculated distance is equal to or less than a threshold distance (S306). If the calculated distance is equal to or less than the threshold distance, the first ITS station may configure or generate the CPM in a manner that information about the overlapping object is not included in the CPM. Alternatively, if the calculated distance exceeds the threshold distance, the first ITS station may configure or generate the CPM in a manner that information about the overlapping object is included in the CPM (S307).”)
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to incorporate the distance-based deduplication method of Kwak into the deduplication processing of Merwaday.
The motivation for doing so would have been to leverage the location data collected to declutter the object list. Further, one skilled in the art could have combined the elements as described above by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results. Therefore, it would have been obvious to combine Merwaday with the above teaching of Kwak to fully disclose, “wherein the fusion component is configured to perform deduplication of the data elements of the consolidated object database by message identifier, geolocation, and/or reference time of perception.”
Claim 14 recites a method with steps corresponding to the elements of the system recited in Claim 7. Therefore, the recited steps of this claim are mapped to the analogous elements in the corresponding system claim. Additionally, the rationale and motivation to combine Merwaday and Kwak apply to this claim.
Claims 20 recites a non-transitory computer-readable medium storing instructions corresponding to the elements of the system recited in Claim 7. Therefore, the recited instructions of these claims are mapped to the analogous elements in the corresponding system claims. Additionally, the rationale and motivation to combine Merwaday and Kwak apply to this claim. Finally, Merwaday discloses a non-transitory computer-readable medium (Merwaday, Paragraph 167, “The storage 2020 may include instructions 2021 in the form of software, firmware, or hardware commands to implement the techniques described herein. Although such instructions 2021 are shown as code blocks included in the memory 2010 and/or storage 2020, any of the code blocks may be replaced with hardwired circuits, for example, built into an ASIC, FPGA memory blocks/cells, and/or the like. In an example, the instructions 2001, 2011, 2021 provided via the memory 2010, the storage 2020, and/or the processor 2002 are embodied as a non-transitory or transitory machine-readable medium (also referred to as “computer readable medium” or “CRM”) including code (e.g., instructions 2001, 2011, 2021, accessible over the IX 2006, to direct the processor 2002 to perform various operations and/or tasks, such as a specific sequence or flow of actions as described herein and/or depicted in any of the accompanying drawings. The CRM may be embodied as any of the devices/technologies described for the memory 2010 and/or storage 2020.”)
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Merwaday in view of Yassein (Internet of Things: Survey and open issues of MQTT protocol)
Regarding claim 21, Merwaday teaches “The FODM of claim 1,”
While Merwaday discloses a message broker and topics (see rejection of claim 1 and response to arguments), and discloses the use of MQTT (Merwaday, Paragraph 264, “The term “application layer” at least in some examples refers to an abstraction layer that specifies shared communications protocols and interfaces used by hosts in a communications network. Additionally or alternatively, the term “application layer” at least in some examples refers to an abstraction layer that interacts with software applications that implement a communicating component, and may include identifying communication partners, determining resource availability, and synchronizing communication. Examples of application layer protocols include HTTP, HTTPs, File Transfer Protocol (FTP), Dynamic Host Configuration Protocol (DHCP), Internet Message Access Protocol (IMAP), Lightweight Directory Access Protocol (LDAP), MQTT (MQ Telemetry Transport), Remote Authentication Dial-In User Service (RADIUS), Diameter protocol, Extensible Authentication Protocol (EAP), RDMA over Converged Ethernet version 2 (RoCEv2), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Real Time Streaming Protocol (RTSP), SBMV Protocol, Skinny Client Control Protocol (SCCP), Session Initiation Protocol (SIP), Session Description Protocol (SDP), Simple Mail Transfer Protocol (SMTP), Simple Network Management Protocol (SNMP), Simple Service Discovery Protocol (SSDP), Small Computer System Interface (SCSI), Internet SCSI (iSCSI), iSCSI Extensions for RDMA (iSER), Transport Layer Security (TLS), voice over IP (VoIP), Virtual Private Network (VPN), Extensible Messaging and Presence Protocol (XMPP), and/or the like.”), Merwaday does not expressly disclose “wherein the message broker is implemented using message queuing telemetry transport (MQTT), and the topics are MQTT topics.”
Yassein teaches “wherein the message broker is implemented using message queuing telemetry transport (MQTT), and the topics are MQTT topics.” (Yassein, Section III, “MQTT uses the client/server model. Every device that is connected to a server, using TCP known as (broker) message in MQTT is a discrete chunk of data and it is ambiguous for the broker. Therefore, MQTT is a message oriented protocol. The address that the message published to it is called topic. The Device may subscribe to more than one topics, and it receives all messages that are published to these topics [3]. The broker is a central device between the spoke model and the mentioned hub. The main MQTT broker responsibilities are processing the communication between MQTT clients and distributing the messages between them based on their interested topics [11]. The broker can deal with thousands of connected devices at the same time. Upon receiving the message, the broker must search and find all the devices that own a subscription to this topic [10].”)
It would have been obvious to a person having ordinary skill in the art before the time of the effective filing date of the claimed invention of the instant application to replace the broker and topic architecture of Merwaday with the MQTT broker and MQTT architecture of Yassein.
The motivation for doing so is described by Yassein, Section V: “Many applications in various fields use the MQTT. For example, it is being used in health care, Facebook notification, surveillance, and in the energy meter. Therefore, the MQTT protocol is considered the perfect messaging protocol for the M2M communications and in the IoT. The reason behind that is because of its ability to provide routing within a low power, small, low memory and cheap devices that are installed in a low bandwidth and weak networks.”. Further, one skilled in the art could have combined the elements as described above by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results. Therefore, it would have been obvious to combine Merwaday with the above teaching of Yassein to fully disclose the invention of claim 21.
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 AARON JOSEPH SORRIN whose telephone number is (703)756-1565. The examiner can normally be reached Monday - Friday 9am - 5pm.
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, Sumati Lefkowitz can be reached at (571) 272-3638. 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.
/AARON JOSEPH SORRIN/ Examiner, Art Unit 2672 /GANDHI THIRUGNANAM/Primary Examiner, Art Unit 2672