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 Amendment
This is in response to Applicant’s amendment which was filed on 11/24/2025 and has been entered. Claims 1, 3-7, 10, 11, 13-20 have been amended. Claim 2 has been cancelled. Claim 21 has been added. Claims 1, 3-21 are pending in this application, with claims 1, 15, and 19 being independent.
Response to Arguments
Applicant’s arguments with respect to the claims have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim Rejections - 35 USC § 102
Claims 1, 3-5, 8, 10-12, 14-16 and 19 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US Publication No. 2015/0288636 (“Yalavarty et al.”).
Regarding claim 1, Yalavarty et al. discloses a method for distributed publisher-subscriber communications, comprising:
determining a first event (topics 208/204) published with a first service operating on a first device (fig. 2, message broker 202 described in [0036]);
determining a second device subscribing to the first event ([0041] a vehicle 31 may be a subscriber and may receive commands 302 or other information from a service delivery network 200 via the message broker 202);
unicasting the first event from the first device to the second device with a first subscription manager operating on the first device ([0036] The vehicle 31 may be in wireless communication with the network 61 by way of the VCS 1 of the vehicle 3, [0049] under the vehicle-specific nodes 402, the topic tree 208 may further include one or more vehicle topic nodes 404 for communication to the specific vehicles 31. A vehicle 31 may subscribe to the vehicle topic node 404 that correspond to the VIN or other unique identifier of the vehicle 31, so that the vehicle 31 may be able to receive messages 206 in topics 204 that specifically relate to the vehicle 31 itself);
determining a plurality of second applications operating on the second device with a second subscription manager operating on the second device, the plurality of second applications subscribing to the first event; and multicasting the first event received at the second device to each of the plurality of second applications ([0098] At block 606, the recipient of the message 206 processes the message 206. For example, the vehicle 31 or service delivery network 200 receiving the message 206 (e.g., a command 302, a command response 304, an alert 306) in any or the ways discussed in detail above with respect to those messages 206; [0052] For example, a general alert topic node 406-A may be used by a vehicle 31 to publish messages 206 (e.g., alerts 306) such as indications of low fuel, erratic driving by the vehicle 31, or periodic current vehicle 31 GPS locations).
Regarding claim 3, Yalavarty et al. discloses the method according to claim 1, further comprising: the first subscription manager including a first subscriber list for the first event; and identifying the second device from the first subscriber list ([0048] the message broker 202 is aware of the subscribers to the message 206).
Regarding claim 4, Yalavarty et al. discloses the method according to claim 3, further comprising: transmitting a first subscription request from the second subscription manager to the first subscription manager, the first subscription request requesting the first subscription manager to include the second device within the first subscriber list, the first subscription request identifying the second device without independently identifying the plurality of second applications ([0048] the service delivery network 200 may create vehicle-specific nodes 402 for vehicles 31 according to VIN or other unique identifier of vehicles 31 that register with the service delivery network 200 as belonging to the particular region).
Regarding claim 5, Yalavarty et al. discloses the method according to claim 1, further comprising: operating a first dispatcher on the first device to append a second device sink attribute to the first event when unicasting the first event from the first device to the second device, the second device sink attribute providing routing information for routing the first event to the second device ([0049] correspond to the VIN or other unique identifier of the vehicle 31, so that the vehicle 31 may be able to receive messages 206 in topics 204 that specifically relate to the vehicle 31 itself).
Regarding claim 8, Yalavarty et al. discloses the method according to claim 5, further comprising: unicasting the first event from the first device to the second device via a gateway, the gateway having a first connection with the first device and a second connection with the second device, the gateway processing the routing information to route the first event from the first connection to the second connection ([0036] FIG. 2 illustrates an exemplary service delivery network 200 in communication over the network 61 with a vehicle 31 by way of a message broker 202).
Regarding claim 10, Yalavarty et a. discloses the method according to claim 1, further comprising: determining a second event published with a second service operating on the second device; determining the first device subscribing to the second event; unicasting the second event from the second device to the first device; determining a first application operating on the first device subscribing to the second event; and unicasting the second event received at the first device from the first device to the first application ([0040] As shown in FIG. 3B, an alert 306 may be published by the vehicle 31 to a topic of the message broker 202 subscribed to by the service delivery network 200. An alert 306 is a type of message 206 providing information from a sender to a recipient, without requesting the performance of a particular action.).
Regarding claim 11, Yalavarty et al. discloses the method according to claim 10, further comprising: determining a third device subscribing to the first event and the second event; unicasting the first event from the first device to the third device separately from unicasting the first event from the first device to the second device; unicasting the second event from the second device to the third device separately from unicasting the second event from the second device to the first device determining a third application operating on the third device subscribing to the first event and a fourth application operating on the third device subscribing to the second event; and unicasting the first event received at the third device to the third application and unicasting the second event received at the third device to the fourth application ([0035] additionally to a vehicle computing system located in a vehicle 31, the process may be executed at least in part by one or more computing systems external to and in communication with a vehicle computing system. Such a system may include, but is not limited to, a wireless device (e.g., and without limitation, a mobile phone); [0072] The initiate remote start command 302-E may be published by the service delivery network 200 to request the vehicle 31 to start (e.g., to the time-sensitive topic node 404-A based on a request from a user's mobile device sent to the service delivery network 200)).
Regarding claim 12, Yalavarty et al. discloses the method according to claim 11, wherein: the first device is a vehicle; the second device is a back office; and the third device is a mobile phone (fig. 2, vehicle 31, back office-message broker 202, phone-nomadic device 53).
Regarding claim 14, Yalavarty et al. discloses the method according to claim 1, further comprising:
determining a second event published with a second service operating on the second device; determining the first device subscribing to the second event; unicasting the second event from the second device to the first device; determining a plurality of first applications operating on the first device, the first applications subscribing to the second event; and multicasting the second event received at the first device to each of the first applications (Fig. 4, at the VIN 402 corresponding to vehicle 31, various events may be subscribed and each event unicasted from the second device is then multicast to the appropriate application(s)).
Regarding claim 15, Yalavarty et al. discloses a distributed publisher-subscriber system, comprising:
a first device configured for:
determining a first event (topics 208/204) published with a first service operating thereon (fig. 2, message broker 202 described in [0036]);
determining a second device subscribing to the first event with a first subscription manager operating on the first device ([0041] a vehicle 31 may be a subscriber and may receive commands 302 or other information from a service delivery network 200 via the message broker 202);
unicasting the first event from the first device to the second device ([0036] The vehicle 31 may be in wireless communication with the network 61 by way of the VCS 1 of the vehicle 3, [0049] under the vehicle-specific nodes 402, the topic tree 208 may further include one or more vehicle topic nodes 404 for communication to the specific vehicles 31. A vehicle 31 may subscribe to the vehicle topic node 404 that correspond to the VIN or other unique identifier of the vehicle 31, so that the vehicle 31 may be able to receive messages 206 in topics 204 that specifically relate to the vehicle 31 itself); and
a second device configured for:
determining a plurality of second applications operating on the second device with a second subscription manager operating on the second device, the plurality of second applications subscribing to the first event; and multicasting the first event received at the second device to each of the plurality of second applications ([0098] At block 606, the recipient of the message 206 processes the message 206. For example, the vehicle 31 or service delivery network 200 receiving the message 206 (e.g., a command 302, a command response 304, an alert 306) in any or the ways discussed in detail above with respect to those messages 206; [0052] For example, a general alert topic node 406-A may be used by a vehicle 31 to publish messages 206 (e.g., alerts 306) such as indications of low fuel, erratic driving by the vehicle 31, or periodic current vehicle 31 GPS locations).
Regarding claim 16, Yalavarty et al. discloses the distributed publisher-subscriber system according to claim 15, further comprising: a gateway configured for: wirelessly relaying the first event from the first device to the second device according to first routing information included therewith, the first routing information identifying the second device without identifying the plurality of second applications (Fig. 4, at the VIN 402 corresponding to vehicle 31, various events may be subscribed and each event unicasted from the second device is then multicast to the appropriate application(s)).
Regarding claim 19, Yalavarty et al. discloses a system for distributed publisher-subscriber communications, comprising:
a first device onboard a vehicle ([0036] The vehicle 31 may be in wireless communication with the network 61 by way of the VCS 1 of the vehicle 31), the first device including:
a plurality of first applications configured to consume events ([0051] fig. 4, a feature may refer to a grouping of configuration parameters applicable to the specified vehicle 31 included in the topic tree 208);
a plurality of first services configured to produce produced events(fig. 4, [0049] vehicle specific nodes 402);
a first subscription manager configured to manage subscriptions for the first device (VCS 1[0050] As one example, a vehicle 31 may subscribe to a time-sensitive update vehicle topic node 404-A for receiving messages 206 for the particular vehicle 31 that are of a time-sensitive nature);
a first streamer configured to communicate with a gateway offboard the vehicle and a first dispatcher configured to manage communications between the first application, service, subscription manager, and streamer (fig. 1, [0025] nomadic device 53 can then be used to communicate 59 with a network 61 outside the vehicle 31 through, for example, communication 55 with a cellular tower 57. In some embodiments, tower 57 may be a WiFi access point);
a second device offboard of the vehicle, the second device including: a plurality of second applications configured to consume events (fig. 2, service delivery network 200);
a plurality of second services configured to produce event (fig. 4, node tree 408);
a second subscription manager configured to manage subscriptions for the second device (message broker 202 with topic tree 208);
a second streamer configured to communicate with the gateway; and a second dispatcher configured to manage communications between the second application, service, subscription manager, and streamer ([0036] service delivery network 200 in communication over the network 61 with a vehicle 31 by way of a message broker 202).
Claim Rejections - 35 USC § 103
Claims 6, 7, 9, 13, 17, 18, 20 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Publication No. 2015/0288636 (“Yalavarty et al.”) in view of U.S. Publication No. 2019/0173951 (“Sumcad et al.”).
Regarding claim 6, Yalavarty et al. does not specify removing the sink attribute.
In the same field of endeavor, Sumcad et al. discloses the method according to claim 5, further comprising: operating a second bus dispatcher on the second device to remove the second device sink attribute from the first event before multicasting the first event to the second applications ([0071] typically the messaging broker in publish-subscribe messaging protocols deletes the publish messages after they are sent to the then presently connected client devices that are subscribed to the particular topic as specified in the publish message.).
It would have been obvious to a person of ordinary skill in the art to add and remove sink attributes as taught by Sumcad et al. in order to provide specific routing instructions for the publish-subscribe events to reach the designated destinations.
Regarding claim 7, Yalavarty et al. in view of Sumcad et al. discloses the method according to claim 6, further comprising: operating the second bus dispatcher to separately append second application sink attribute to the first event when multicasting the first event to the second applications, the second application sink attribute uniquely identifying each of the second applications (Sumcad, [0070] A publish message can include metadata along with a payload that includes the substance of the message that is being published. The metadata can include various fields, such as those that are included in the PUBLISH message, as specified in the MQTT specification).
Regarding claim 9, Yalavarty et al. does not specify a first device to gateway interface.
In the same field of endeavor, Sumcad et al. discloses the method according to claim 8, further comprising: unicasting the first event from the first device via a first streamer operating on the first device, the first streamer configured with a first device-to-gateway (D2G) interface operable for establishing the first connection ([0050] wireless device 30 can use cellular chipset 34 or SRWC circuit 32 (e.g., a WNIC) included therein to send messages to messaging broker 60 through use of a publish-subscribe messaging protocol, such as Message Queue Telemetry Transport (MQTT)); and unicasting the first event from the gateway to a second streamer operating on the second device, the second streamer configured with a second D2G interface operable for establishing the second connection ([0049] Wireless communications device 30 may enable vehicle 12 to be in communication with one or more remote networks (e.g., one or more networks at remote facility 18 or computers 16) via packet-switched data communication).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the network interface in Yalavarty as specified by Sumcad because the D2G interface enables the device to communicate with the gateway, which then translates, routes, and secures data for transmission to the network.
Regarding claim 13, Yalavarty discloses a general alert topic node 406-A may be used by a vehicle 31 to publish messages 206 (e.g., alerts 306) such as indications of low fuel, erratic driving by the vehicle 31, or periodic current vehicle 31 GPS locations ([0052]). The current location of a vehicle may then be reused in multiple message 206 ([0097]).
In the same field of endeavor, Sumcad et al. discloses wherein:
the first event includes data representing a location of the vehicle ([0052] transaction information includes vehicle location);
the second event includes data representing a service notification for the vehicle;
the first application is a notification application (display 58);
the second applications include a navigation application ([0054] Navigation information can be presented on the display 58), a vehicle services application ([0087] VSM module for diagnostic test codes, a trip planning application ([0054] map annotation with points of interest), and a charging station application ([0087] VSM for fuel level and battery level);
the third application is a location application ([0054] GPS module); and
the fourth application is a notification application (display 58).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to distribute the location event by Yalavarty as discussed in Sumcad in order to offer a flexible and robust event distribution for vehicle 31 communications.
Regarding claim 17, Yalavarty et al. discloses the distributed publisher-subscriber system according to claim 16, wherein: the first device includes: the first subscription manager configured for determining the second device from a first subscriber list associated with a first service operating on the first device, the first service producing the first event, the first subscriber list identifying the second device without identifying the plurality of second applications ([0048] the message broker 202 is aware of the subscribers to the message 206).
In the same field of endeavor, Sumcad et al. discloses a first dispatcher configured to append a second device sink attribute to the first event prior to unicasting of the first event to the second device, the second device sink attribute including the first routing information ([0062] all of the messages sent between the messaging broker and the client device can include a header. The header can indicate a message length and a message type, as well as other information); and
the second device includes: a second subscription manager configured for determining the second applications from a second subscriber list associated with the first service ([0064] each VSM is tied to the client identifier such as the VIN); and
a second dispatcher configured to remove the second device sink attribute from the first event before multicasting the first event and to separately append second application sink attributes to the first event before multicasting the first event to the second applications, the second application sink attributes uniquely identifying each of the second applications ([0071] typically the messaging broker in publish-subscribe messaging protocols deletes the publish messages after they are sent to the then presently connected client devices that are subscribed to the particular topic as specified in the publish message.).
It would have been obvious to a person of ordinary skill in the art to add and remove sink attributes as taught by Sumcad et al. in order to provide specific routing instructions for the publish-subscribe events to reach the designated destinations.
Regarding claim 18, Yalavarty et al. in view of Sumcad et al. discloses the distributed publisher-subscriber system according to claim 17, wherein:
the second device includes a second service configured to produce a second event; the second subscription manager is configured for determining from a second subscriber list associated with the second service the first device as subscribing to the second event; the second dispatcher is configured to append a first device sink attribute to the second event prior to unicasting of the second event from the second device to the first device, the first device sink attribute including second routing information for with the gateway in wirelessly relaying the second event from the second device to the first device (Sumcad, [0103] In step 326, the mobile device 14 can publish a message to the messaging broker 60 and, in one embodiment, the message can include a topic name or other information that indicates that a message should be sent to the vehicle in a timely manner. In one embodiment, the mobile device can include a vehicle command in the publish message of step 326. In step 328, the messaging broker sends a publish acknowledgement message to the mobile device. In step 330, the vehicle can send another ping message as to continue keeping the connection alive and, in response, the messaging broker 60 can send a ping response to vehicle 12, as shown in step 332);
the first subscription manager is configured for determining from a third subscriber list associated with the second service a plurality of first applications operating on the first device as subscribing to the second event ([0064] each VSM is tied to the client identifier such as the VIN); and the first dispatcher is configured to remove the first device sink attribute from the second event before multicasting the second event and to separately append first application sink attributes to the second event before multicasting the second event to the first applications, the first application sink attributes uniquely identifying each of the first applications (Sumcad, [0071] typically the messaging broker in publish-subscribe messaging protocols deletes the publish messages after they are sent to the then presently connected client devices that are subscribed to the particular topic as specified in the publish message).
Regarding claim 20, Yalavarty et al. discloses the system according to claim 19, wherein: in response to one of the first services publishing a first event, the first subscription manager determines the second device subscribing to the first event, the first dispatcher appends a second device sink attribute to the first event, and the streamer unicasts the first event with the second device sink attribute to the gateway for relay to the second device ([0049] correspond to the VIN or other unique identifier of the vehicle 31, so that the vehicle 31 may be able to receive messages 206 in topics 204 that specifically relate to the vehicle 31 itself);
In the same field of endeavor, Sumcad discloses in response to receipt of the first event at the second device, the second subscription manager determines a second plurality of the second applications subscribing to the first event, the second dispatcher removes the second device sink attribute from the first event prior to multicasting the first event to the second plurality of the second applications (Sumcad, [0071] typically the messaging broker in publish-subscribe messaging protocols deletes the publish messages after they are sent to the then presently connected client devices that are subscribed to the particular topic as specified in the publish message.);
in response to one of the second services publishing a second event, the second subscription manager determines the first device subscribing to the second event, the second dispatcher appends a first device sink attribute to the second event, and the streamer unicasts the second event with the first device sink attribute to the gateway for relay to the first device (Sumcad, [0062] all of the messages sent between the messaging broker and the client device can include a header. The header can indicate a message length and a message type, as well as other information); and
in response to receipt of the second event at the first device, the first subscription manager determines a first plurality of the first applications subscribing to the second event, the first dispatcher removes the first device sink attribute from the second event prior to multicasting the second event to the first plurality of the second applications (Sumcad, [0071] typically the messaging broker in publish-subscribe messaging protocols deletes the publish messages after they are sent to the then presently connected client devices that are subscribed to the particular topic as specified in the publish message).
It would have been obvious to a person of ordinary skill in the art to add and remove sink attributes as taught by Sumcad et al. in order to provide specific routing instructions for the publish-subscribe events to reach the designated destinations.
Regarding claim 21, Yalavarty et al. in view of Sumcad et al. discloses the system according to claim 20, wherein: in response to one of the second services publishing a particular second event of the plurality of second events, the second subscription manager determines the first device subscribing to the particular second event, the second dispatcher appends a first device sink attribute to the particular second event, and the streamer unicasts the particular second event with the first device sink attribute to the gateway for relay to the first device (Sumcad, [0103] In step 326, the mobile device 14 can publish a message to the messaging broker 60 and, in one embodiment, the message can include a topic name or other information that indicates that a message should be sent to the vehicle in a timely manner. In one embodiment, the mobile device can include a vehicle command in the publish message of step 326. In step 328, the messaging broker sends a publish acknowledgement message to the mobile device. In step 330, the vehicle can send another ping message as to continue keeping the connection alive and, in response, the messaging broker 60 can send a ping response to vehicle 12, as shown in step 332); and
in response to receipt of the particular second event at the first device, the first subscription manager determines a first plurality of the first applications subscribing to the particular second event, the first dispatcher removes the first device sink attribute from the particular second event prior to multicasting the particular second event to the first plurality of the second applications ([0064] each VSM is tied to the client identifier such as the VIN); and the first dispatcher is configured to remove the first device sink attribute from the second event before multicasting the second event and to separately append first application sink attributes to the second event before multicasting the second event to the first applications, the first application sink attributes uniquely identifying each of the first applications (Sumcad, [0071] typically the messaging broker in publish-subscribe messaging protocols deletes the publish messages after they are sent to the then presently connected client devices that are subscribed to the particular topic as specified in the publish message. However, as discussed more below, other embodiments exist, such as those where certain messages are retained).
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 JIRAPON TULOP whose telephone number is (571)270-7491. The examiner can normally be reached Monday to Friday, 10:00AM-6:00PM.
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, Ahmad Matar can be reached at 571-272-7488. 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.
/JIRAPON TULOP/Examiner, Art Unit 2693
Prosecution Insights