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 .
This action is in response to the application filed on 8/23/2024.
The IDS filed on 11/4/2024, 6/6/2025 and 4/10/2026 are considered.
Claims 1-20 are examined and rejected.
Allowable Subject Matter
Claims 15-19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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) 1, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bender (US 20210089026 A1, hereinafter “Bender”) in view of Lin (WO 2020150872 A1, hereinafter “Lin”).
Regarding Claim 1, Bender teaches a method of controlling an in-vehicle network (see FIG. 2), the method comprising:
determining whether a bandwidth required for transmission of an Ethernet signal is capable of being secured on a transmission path between a first node and a second node (see para 32, FIG. 2., step 204, routing program determines a bandwidth requirement of the autonomous vehicle, by utilizing data of client device to determine a bandwidth requirement of client device),
based on that the bandwidth is capable of being secured, controlling the Ethernet signal to be transmitted to the second node along the transmission path (see para 44, If routing program determines that bandwidth consumption of network along a determined route of client device is not above a defined threshold (decision step 214, “NO” branch), then routing program does not modify a determined route of client device and monitors for a priority autonomous vehicle. In one scenario, if routing program determines that a router that services a geographic area/grid of an MWN presently has available bandwidth and the bandwidth consumption will not exceed a total capacity of the router at a future defined time period when an autonomous vehicle enters the geographic area along with other registered and unregistered autonomous vehicles, then routing program does not reroute the autonomous vehicle); and
based on that the bandwidth is incapable of being secured, changing the transmission path to route through a third node and controlling the Ethernet signal to be transmitted to the second node along the changed transmission path (see para 45, If routing program determines that bandwidth consumption of network along a determined route of client device is above a defined threshold (decision step 214, “YES” branch), then routing program modifies a determined route of client device. In one scenario, if routing program determines that a router that services a geographic area/grid of an MWN presently does not has available bandwidth and/or bandwidth consumption of the router will exceed a total capacity of the router at a future defined time period when an autonomous vehicle enters the geographic area along with other registered and unregistered autonomous vehicles, then routing program transmits an updated route to a navigational application of the autonomous vehicle (i.e., traffic patterns can be adjusted based on total capacity and availability of network bandwidth)).
Bender does not teach details regarding: the Ethernet signal is converted from a controller area network (CAN) signal and is to be transmitted from the first node to the second node;
Lin teaches this limitation: see FIG. 5., page 13, para 40, an action of converting at the data link layer, is performed. The ingress CAN frame is converted into an egress Ethernet frame, based on the value of the CAN identifier such that a transmission priority is expressed in the egress Ethernet frame. The value of the obtained CAN identifier is converted into one or more header fields at the data link layer in the corresponding egress Ethernet frame.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Bender, to include details regarding a hybrid network comprising CAN and ethernet in vehicular communication and convert from one protocol to another based on the ethernet priority, as taught by Lin, the motivation being, a protocol conversion method that preserves the property of the prioritized transmission from the source network frame in the target network frame (see Lin, Summary).
Regarding Claim 20, Bender teaches an in-vehicle network comprising: a first node; a second node; a third node (see FIG. 2., client devices); and a host computer (see FIG. 2., server),
wherein the host computer is configured to: determine whether a bandwidth required for transmission of the Ethernet signal is capable of being secured on a transmission path between the first node and the second node (see para 32, FIG. 2., step 204, routing program determines a bandwidth requirement of the autonomous vehicle, by utilizing data of client device to determine a bandwidth requirement of client device),
based on that the bandwidth is capable of being secured, control the Ethernet signal to be transmitted to the second node along the transmission path (see para 44, If routing program determines that bandwidth consumption of network along a determined route of client device is not above a defined threshold (decision step 214, “NO” branch), then routing program does not modify a determined route of client device and monitors for a priority autonomous vehicle. In one scenario, if routing program determines that a router that services a geographic area/grid of an MWN presently has available bandwidth and the bandwidth consumption will not exceed a total capacity of the router at a future defined time period when an autonomous vehicle enters the geographic area along with other registered and unregistered autonomous vehicles, then routing program does not reroute the autonomous vehicle); and
based on that the bandwidth is incapable of being secured, change the transmission path to route through the third node and control the Ethernet signal to be transmitted to the second node along the changed transmission path.
Bender does not teach details regarding: the first node is configured to convert a controller area network (CAN) signal into an Ethernet signal to transmit to the second node (see para 45, If routing program determines that bandwidth consumption of network along a determined route of client device is above a defined threshold (decision step 214, “YES” branch), then routing program modifies a determined route of client device. In one scenario, if routing program determines that a router that services a geographic area/grid of an MWN presently does not has available bandwidth and/or bandwidth consumption of the router will exceed a total capacity of the router at a future defined time period when an autonomous vehicle enters the geographic area along with other registered and unregistered autonomous vehicles, then routing program transmits an updated route to a navigational application of the autonomous vehicle (i.e., traffic patterns can be adjusted based on total capacity and availability of network bandwidth)),
Lin teaches this limitation: see FIG. 5., page 13, para 40, an action of converting at the data link layer, is performed. The ingress CAN frame is converted into an egress Ethernet frame, based on the value of the CAN identifier such that a transmission priority is expressed in the egress Ethernet frame. The value of the obtained CAN identifier is converted into one or more header fields at the data link layer in the corresponding egress Ethernet frame.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Bender, to include details regarding a hybrid network comprising CAN and ethernet in vehicular communication and convert from one protocol to another based on the ethernet priority, as taught by Lin, the motivation being, a protocol conversion method that preserves the property of the prioritized transmission from the source network frame in the target network frame (see Lin, Summary).
Claim(s) 2-4, 8, 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bender in view of Lin, in view of Dasari (US 20250016066 A1, hereinafter “Dasari”).
Regarding claim 2, Bender in view of Lin do not teach: the CAN signal is transmitted based on software-defined networking (SDN) between the first node, the second node, and the third node.
Dasari teaches this limitation: see FIG. 1., paras 18-26, The communication network is a software-defined communication network (SDN) with a software-defined network architecture (SDN architecture) ... the control devices and network switches are disposed in a vehicle ... the first protocol and network type is ethernet that enables data exchange between the control devices as terminal devices... the control devices are a second type of protocol, that is the Controller Area Network protocol. The Controller Area Network protocol allows data exchange between these control devices as terminal devices according to a predetermined schema.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the combined teachings of Bender and Lin, to include details regarding a SDN in vehicular communication as taught by Dasari, the motivation being, for network and computing resource management for service-oriented communication in a software-defined network architecture (see Dasari, Field).
Regarding Claim 3, Bender does not teach: transmitting, by the first node, a control request message to secure the transmission path for the Ethernet signal.
Examiners Note: Using BRI consistent with the specification, the limitation “control request message to secure the transmission path for the Ethernet signal” has been interpreted as: the transmission path for the Ethernet signal is changed/switched according to the control request message. Based on this interpretation, Lin teaches this limitation: see FIGs. 5-6., pages 13-14, an action of converting at the data link layer, is performed. The ingress CAN frame is converted into an egress Ethernet frame, based on the value of the CAN identifier such that a transmission priority is expressed in the egress Ethernet frame (see FIG. 8). The value of the obtained CAN identifier is converted into one or more header fields at the data link layer in the corresponding egress Ethernet frame… optionally performing access control 610 for the ingress Ethernet frame/i.e., representing the control request message, the Ethernet frame is parsed according to the fields in the Ethernet header such as VLAN tag and/or source address and/or destination address, according to a white list or blacklist. If on the white list, the Ethernet frame may be converted and / or switched. If on the blacklist, the Ethernet frame is not for the target network and is not converted nor switched.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Bender, to include details regarding a hybrid network comprising CAN and ethernet in vehicular communication and convert from one protocol to another based on the ethernet priority, as taught by Lin, the motivation being, a protocol conversion method that preserves the property of the prioritized transmission from the source network frame in the target network frame (see Lin, Summary).
Regarding Claim 4, Bender teaches using a routing program determines a bandwidth requirement of the autonomous vehicle, by utilizing data of client device to determine a bandwidth requirement of client device.
Bender does not teach: based on a type of the CAN signal, a data size of the CAN signal, a priority of the CAN signal, an identifier of the first node, and an identifier of the second node included in the control request message, it is determined whether the bandwidth required for the transmission of the Ethernet signal is capable of being secured.
Lin teaches this limitation: see FIGs. 5-6., pages 13-14, The ingress CAN frame is converted into an egress Ethernet frame, based on the value of the CAN identifier such that a transmission priority is expressed in the egress Ethernet frame. The value of the obtained CAN identifier is converted into one or more header fields at the data link layer in the corresponding egress Ethernet frame/i.e., using the access control 610 for the ingress Ethernet frame or control request message. The conversion is performed according to a mapping. The CAN identifier value may be mapped to the VLAN tag, and in particular to the User priority field therein. A principle of mapping may be that a lower value of the CAN ID maps to a higher value in the User Priority tag. Many CAN IDs may be mapped to one value of the VLAN tag or User Priority field. For example, one range of CAN IDs maps to one VLAN value, one CAN ID maps to another VLAN value, and another range of CAN IDs maps to another VLAN value. Other permutations and combinations of the mapping are possible. In the converting, the payload is also converted. Figures 9a-9c depict three different ways of converting ingress CAN frames. Then, the converted Ethernet frame is output; also see page 18, lines 15-17, Status information are collected back from the multiple controllers with different CAN IDs. To further save the bandwidth in Ethernet, those CAN frames with different CAN IDs are aggregated in fewer Ethernet frames. Moreover, to provide a better response quality in terms of stability, resulting Ethernet frames are assigned the same stream ID, such that stream reservation protocol can be applied on this stream ID.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the bandwidth based routing of Bender, to include details regarding a hybrid network comprising CAN and ethernet in vehicular communication and convert from one protocol to another based on the ethernet priority and bandwidth saving, as taught by Lin, the motivation being, a protocol conversion method that preserves the property of the prioritized transmission (while saving bandwidth) from the source network frame in the target network frame (see Lin, Summary).
Regarding Claim 8, Bender teaches: based on that the bandwidth is capable of being secured, transmitting a first parameter for securing the bandwidth (see para 32, routing program determines a bandwidth requirement of the autonomous vehicle. The routing program utilizes data of client device to determine a bandwidth requirement/i.e., first parameter, of client device);
Bender in view of Lin do not teach details regarding: transmit first parameter to a first software-defined networking (SDN) switch of the first node; securing, by the first SDN switch, a queue responsible for the bandwidth among a plurality of queues managed by the first SDN switch based on the first parameter; and transmitting the Ethernet signal through the secured queue.
Dasari teaches this limitation: see FIG. 2., paras 44-47, the SDN controller determines the network and computing resource configuration/i.e., bandwidth for example, depending on a result of an evaluation of the data. The SDN controller determines an assignment of instances of services/i.e., queue, to control devices and paths for messages that the instances exchange with one another, i.e. the paths for the respective data streams. The assignment is determined depending on the computing resource availability of the control devices in such a way that no control device that offers a service is overloaded, no bottleneck occurs on the data lines or network switches in the communication network … paras 53-54, he SDN controller programs look-up tables in the network switches to route messages between the pairs of instances over the designated paths, and configures instances that are intended to communicate with one another; also see para 22, ethernet protocol is used to enable data exchange between the control devices as terminal devices.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the combined teachings of Bender and Lin, to include details regarding a SDN using computing resources such as bandwidth to evaluate the data using service instances based on bandwidth so as to enable ethernet communication path as taught by Dasari, the motivation being, for network and computing resource management for service-oriented communication in a software-defined network architecture (see Dasari, Field).
Regarding Claim 10, Bender teaches: based on that the bandwidth is incapable of being secured, transmitting a second parameter for changing the transmission path (see para 45, If routing program determines that bandwidth consumption of network along a determined route of client device is above a defined threshold (decision step 214, “YES” branch), then routing program modifies a determined route of client device. In one scenario, if routing program determines that a router that services a geographic area/grid of an MWN presently does not has available bandwidth and/or bandwidth consumption of the router will exceed a total capacity of the router at a future defined time period when an autonomous vehicle enters the geographic area along with other registered and unregistered autonomous vehicles, then routing program transmits an updated route/i.e., second parameter, to a navigational application of the autonomous vehicle (i.e., traffic patterns can be adjusted based on total capacity and availability of network bandwidth)).
Bender in view of Lin do not teach details regarding: the first node comprises a first software-defined networking (SDN) switch with a first forwarding table; wherein the second node comprises a second SDN switch with a second forwarding table, wherein the third node comprises a third SDN switch with a third forwarding table.
Dasari teaches this limitation: see FIG. 1., para 19, A message from a source is forwarded to its destination via a path in the infrastructure defined by the SDN architecture… paras 53-54, The SDN controller programs look-up tables in the network switches to route messages between the pairs of instances over the designated paths. The SDN controller configures instances that are intended to communicate with one another. In one example a protocol is provided for this purpose, with which the SDN controller informs an instance whether it should be active or deactivated.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the combined teachings of Bender and Lin, to include details regarding a SDN architecture with the controller look-up tables to route messages on designated paths based on a protocol to activate or deactivate SDN controller instances, as taught by Dasari, the motivation being, resource management for network and computing of service-oriented communication in a software-defined network architecture (see Dasari, Field).
Claim(s) 11-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bender in view of Lin, in view of Dasari, further in view of Giorgetti (US 20150372902 A1, hereinafter “Giorgetti”).
Regarding claim 11, Bender in view of Lin, in view of Dasari do not teach: transmitting a third parameter for changing the transmission path to the third SDN switch; and changing the third forwarding table to transmit the Ethernet signal to the second SDN switch based on the third parameter.
Examiners Note: Using BRI consistent with the specification, this limitation has been interpreted as “using a flow entry of a backup path (instead of a working path, to change the transmission/i.e., third parameter, path based on an association of the backup path and the working path) of a SDN switch using OpenFlow.”
Based on this interpretation, Giorgetti teaches this limitation: see para 78, FIG. 10.shows a method of supporting traffic recovery at a switching node of an OpenFlow network. Step 101 of the method comprises receiving an instruction from the controller to configure a backup path at the switching node. Step 102 comprises installing a flow entry for the backup path in the at least one flow table of the switching node. Step 104 comprises renewing/i.e., updating, the flow entry for the backup path based on an association between the flow entry for the backup path and a flow entry for a working path at the node. The flow entry for the backup path is renewed when the flow entry for the working path is used to forward a received packet. Step 105 comprises renewing the flow entry for the backup path based on receiving a flow renewal packet from another node. An optional step 103 comprises receiving an instruction to configure the working path at the switching node and installing a flow entry for the working path in the at least one flow table of the switching node… Further optional steps 106, 107, can be performed by nodes which are fork points for the working path and backup path.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the combined teachings of Bender, Lin and Dasari, to include details regarding using a flow entry of a backup path (instead of a working path to change the transmission path, based on an association of the backup path and the working path) of a SDN switch using OpenFlow, as taught by Giorgetti, the motivation being, supporting traffic recovery at a switching node of an OpenFlow network (see Giorgetti, para 5).
Regarding claim 12, Bender in view of Lin, in view of Dasari do not teach: the second parameter and the third parameter are transmitted through an OpenFlow protocol.
Examiners Note: Using BRI consistent with the specification, the limitation “second parameter” has been interpreted to mean “update route”; and the limitation “third parameter” has been interpreted to mean “change route”
Based on this interpretation, Giorgetti teaches this limitation: see para 78, FIG. 10.shows a method of supporting traffic recovery at a switching node of an OpenFlow network. Step 101 of the method comprises receiving an instruction from the controller to configure a backup path at the switching node. Step 102 comprises installing a flow entry for the backup path in the at least one flow table of the switching node. Step 104 comprises renewing/i.e., second parameter for updating route, the flow entry for the backup path based on an association between the flow entry for the backup path and a flow entry for a working path at the node. The flow entry for the backup path is renewed when the flow entry for the working path is used to forward a received packet. Step 105 comprises renewing the flow entry for the backup path based on receiving a flow renewal packet from another node. An optional step 103 comprises receiving an instruction to configure the working path at the switching node and installing a flow entry for the working path in the at least one flow table of the switching node… Step 106 comprises receiving an instruction from the controller to configure the sending of flow entry renewal packets along the backup path/i.e., third parameter to change the route
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the combined teachings of Bender, Lin and Dasari, to include details regarding using a flow entry of a backup path (instead of a working path to change the transmission path, based on an association of the backup path and the working path) of a SDN switch using OpenFlow, as taught by Giorgetti, the motivation being, supporting traffic recovery at a switching node of an OpenFlow network (see Giorgetti, para 5).
Regarding claim 13, Bender teaches the method of claim 12, wherein the first parameter, the second parameter, and the third parameter see para 45, If routing program determines that bandwidth consumption of network along a determined route of client device is above a defined threshold (decision step 214, “YES” branch), then routing program modifies a determined route of client device. In one scenario, if routing program determines that a router that services a geographic area/grid of an MWN presently does not has available bandwidth and/or bandwidth consumption of the router will exceed a total capacity of the router at a future defined time period when an autonomous vehicle enters the geographic area along with other registered and unregistered autonomous vehicles, then routing program transmits an updated route to a navigational application of the autonomous vehicle (i.e., traffic patterns can be adjusted based on total capacity and availability of network bandwidth)).
Bender does not teach the underlined limitation: network parameters to determine an updated route based on bandwidth and changing the route in a time sensitive network (TSN) standard.
Lin teaches automotive ethernet using TSN standard, it further teaches: see page 3, para 20-25, Automotive Ethernet aims at providing more accurate time synchronization and better quality of network service, such as guaranteed maximal latency and jitter. For a specified set of data streams, network resources can also be reserved in advance to ensure transmission quality. IEEE provides an additional set of standards to form Automotive Ethernet, the so-called AudioVideo Bridging (AVB). A newer version is called AVB generation 2 or Time-Sensitive Networks (TSN).
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teachings of Bender, to include details regarding network parameters to determine an updated route based on bandwidth and changing the route in a time sensitive network (TSN) standard as taught by Lin, the motivation being, for providing more accurate time synchronization and better quality of network service, such as guaranteed maximal latency and jitter (see Lin, page 3).
Regarding claim 14, Bender teaches the method of claim 11, secure the bandwidth or change the transmission path by transmitting the first parameter, the second parameter, and the third parameter.
Bender in view of Lin do not teach details regarding: the network comprises a host computer, and wherein the host computer comprises an SDN controller configured to control the first SDN switch, the second SDN switch, and the third SDN switch for the transmission path.
Dasari teaches this limitation: see FIG. 1., paras 18-26, The communication network is a software-defined communication network (SDN) with a software-defined network architecture (SDN architecture) ... the control devices and network switches are disposed in a vehicle ... the first protocol and network type is ethernet that enables data exchange between the control devices as terminal devices... the control devices are a second type of protocol, that is the Controller Area Network protocol. The Controller Area Network protocol allows data exchange between these control devices as terminal devices according to a predetermined schema.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the combined teachings of Bender and Lin, to include details regarding a SDN in vehicular communication as taught by Dasari, the motivation being, for network and computing resource management for service-oriented communication in a software-defined network architecture (see Dasari, Field).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bender in view of Lin, in view of Dasari, further in view of Li (US 20180367635 A1, hereinafter “li”).
Regarding claim 9, Bender in view of Lin, in view of Dasari teach transmitting a first parameter comprising bandwidth to the SDN controller queues for the ethernet signal path.
Bender in view of Lin, in view of Dasari do not teach: the first parameter is transmitted through a network configuration NETCONF protocol.
Li teaches this limitation: see para 32, determining the bandwidth and the bandwidth of the control channel is bandwidth for carrying a data service in the NETCONF.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the combined teachings of Bender, Lin and Dasari, to include a NETCONF protocol to transmit the bandwidth as taught by Li, the motivation being, for optimizing bandwidth usage and based on the KSR rationale F - Known work in one field of endeavor may prompt variations of it for use in either the same field or a different one based on design incentives or other market forces if the variations are predictable to one of ordinary skill in the art.
Claim(s) 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bender in view of Lin, in view of Dasari, further in view of Jung (US 20210248095 A1, hereinafter “Jung”).
Regarding Claim 5, Bender in view of Lin, in view of Dasari teach service availability of SOME/IP (see Dasari, para 40).
Bender in view of Lin, in view of Dasari do not teach: the control request message is transmitted based on that the CAN signal is not intended for Scalable Service-Oriented Middleware over IP (SOME/IP) service communication.
Examiners Note: Using BRI consistent with the specification, the above limitation is interpreted as: “if an ethernet connection is not established, a switch or conversion from CAN to Ethernet not performed, and the SOME/IP service is prevented”
Based on this interpretation, see Jung para 40: the payload type indicates that a “SOME/IP” message is transmitted in the payload. This requires the prior establishment of an Ethernet connection, i.e., payload type is “UDP” or “TCP.” If a manipulated control unit transmits a message with payload type “SOME/IP” without an Ethernet connection having previously been established, the communication module prevents this attack by not switching into configuration state 408 (for SOME/IP). The communication module identifies that a transition from configuration state “Normal CAN XL” into state “Ethernet CAN XL” has not yet taken place, and thus blocks the incoming as well as outgoing “SOME/IP” messages.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the combined teaching of Bender, Lin and Dasari, to include details regarding blocking SOME/IP service when the CAN to Ethernet conversion has not been performed, as taught by Jung, the motivation being, decreasing the risk of cyber-attack, by communicating only after a communication channel has been established to receive a certain service or to provide the service (see Jung, Background).
Regarding Claim 6, Bender in view of Lin do not teach:
Dasari teaches this limitation: see paras 39-43, the SDN controller monitors network traffic and collects data that includes, for example: Knowledge about available instances of services and the assignment thereof to the control devices. These data are available as part of the offers and/or requests that occur in the network traffic, for instance. Messages according to the Scalable Service-Oriented Middleware over Internet Protocol (SOME/IP) protocol or Data Distribution Service (DDS) are provided as offers or requests. Requirements for the communication network and computing resources. This information can be derived from a description of a service, for instance. The description includes information relating to a quality of the service, for example. The description is contained in the offer and/or in the request, for example, in particular in accordance with SOME/IP. The network topology is ascertained via a separate protocol, for example, for instance the Link Layer Discovery Protocol (LLDP). Computing resource availability at the control devices. This information is known through an internal scheduling model, for example, or is communicated by the control devices, in particular regularly or irregularly, or in response to a request from the SDN controller. It can be provided that the communication of this information by the control device is triggered by an event. For example, the event is a temporary unavailability of an instance of the service on the control device.
Bender in view of Lin in view of Dasari does not teach: based on that the CAN signal is intended for the service communication
Jung teaches this limitation: see para 40, if the CAN to Ethernet transition has been established leading to the Ethernet connection, then the CAN signal can process the SOME/IP payload.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the combined teaching of Bender, Lin and Dasari, to include details regarding allowing SOME/IP service when the CAN to Ethernet conversion has been performed, as taught by Jung, the motivation being, decreasing the risk of cyber-attack, by communicating only after a communication channel has been established to receive a certain service or to provide the service (see Jung, Background).
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bender in view of Lin, in view of Dasari, in view of Jung, and further in view of Cheng (US 20230119616 A1, hereinafter “Cheng”).
Regarding claim 7, Bender in view of Lin, in view of Dasari, in view of Jung do not teach detials regarding: the discovery message for service offering includes identification information on the service communication, a priority of the service communication, a data size of the service communication, and an identifier of the first node, and wherein the discovery message for service finding includes identification information on the service communication and an identifier of the second node.
Cheng teaches this limitation: see para 61, the first UE may transmit or receive discovery messages to establish connection with the second UE/i.e., using identifiers of the first and second node. After connection is established, the first UE may use the second configuration for data communication to communicate with the second UE… para 66, different discovery priority levels may be configured for different services. For example, a relay UE and a remote UE may obtain a service code/i.e., service identification information, from the network. The service code may indicate a quality of service (QoS) associated with a service for which discovery operations are implemented. In other words, discovery messages may have different QoS and latency specifications, and may be configured with different periodicities accordingly. For example, discovery messages configured for a service with low latency specification may be configured with a shorter periodicity/i.e., data size of the service, allowing faster discovery between UEs.
Therefore, it would have been obvious to one having ordinary skill in the art, before the effective filing date of the claimed invention, to modify the combined teaching of Bender, Lin, Dasari and Jung, to include details regarding discovery message for service offerings, as taught by Cheng, the motivation being, for further improvements in NR and LTE technology, these improvements should be applicable to other multi-access technologies and the telecommunication standards that employ these technologies (see Cheng, para 4).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Fang (US 20210234761 A1) teaches mixed network communication on a vehicle. At para 104, FIG. 1, an example system includes an application (e.g., a vehicle) having a first network and a second network … networks include a Controller Area Network (CAN), a Media Oriented Systems Transport (MOST) network, a Local Interconnect Network (LIN), a FlexRay network, a Time-Triggered Protocol (TTP) network, a Low-Voltage Differential Signaling (LVDS) network, and/or an Ethernet implemented … An example system includes the first network being an Ethernet implemented network, and the second network of a different type, such as a CAN network … The system further includes a converged network device (CND) interposed between the first network and the second network, and structured to facilitate communications between the first network and the second network.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEEPA BELUR whose telephone number is (571)270-3722. The examiner can normally be reached M-F 8 am - 4:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Bates can be reached at 571-272-3980. 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.
/DEEPA BELUR/Primary Examiner, Art Unit 2472
Prosecution Insights