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 .
Claims 1-3, 5-10, 12-16 and 18-23 are pending in this office correspondence.
Response to Amendment
This Final Office Action is in response to amendment filed on 03/30/2026. Amended claims 1, 3, 5-8, 10, 12-15 and 18-20, and filed on 03/30/2026, are being considered on the merits.
In response to the last Office Action:
Claims 4, 11, and 17 have been cancelled.
Claims 1, 3, 5-8, 10, 12-15 and 18-20 have been amended.
Claims 21-23 have been newly added.
Claims 1-3, 5-10, 12-16 and 18-23 remain pending in this office action.
Response to Arguments
The applicant’s remarks and/or arguments, filed on 03/30/2026, in response to the non-final office action mailed on 01/09/2026, have been entered and are fully considered.
The examiner is entitled to give claim limitations their broadest reasonable interpretation in light of the specification. See MPEP 2111 [R-1] Interpretation of Claims-Broadest Reasonable Interpretation. The applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. In re Prater, 162 USPQ 541,550-51 (CCPA 1969).
Firstly, Applicant’s argued that SORENSON does not “update the state information maintained by the given service … in response to a change in state information associated with a given service”, because the update in SORENSON is triggered by the update flag when the message reaches the front of the queue, see Applicant’s Remarks pages 8-9.
The examiner respectfully disagrees and asserts that the arguments address only the broker-side refresh of a queue message, as disclosed by SORENSON Fig.5, steps 530-560, and overlooks the publisher-side disclosure of the reference. Specifically, SORENSON describes the publisher, i.e. the claimed given service, updating and publishing its own state information as the state changes as disclosed by SORENSON col.3, line (5): “…, subscribers may desire to know the geo-location of an important asset (e.g., a vehicle or commercial truck) as the asset moves. If the asset is updating its location frequently, the outbound messages to the subscribers may be updated with the latest data even if the message was queued for delivery several location updates in the past.” Further, the publisher’s data source “The data source 130 may, in various examples, generate updated message data periodically, upon request from the publisher, upon request from the broker, continuously in a stream, at random intervals, upon occurrence of defined events, etc.” as disclosed by SORENSON Fig.1A, Col.4, line (60); “the data source may be the publisher” (Col.13, line (52) or “the data source may belong to or be managed by the publisher” (Col.14, line (49); and “updating of the cached data may occur each time a message with updated data is received from the publisher” (Col.15, line (10)).
Given the broadest reasonable interpretation of the claimed language of “in response to a change in state information”, the examiner asserts that the reference to SORENSON, as explained above, reads on the aforementioned claim language, which is consistent with the instant application specification details, which describes a similar event-driven relationship at a comparable level of generality, see instant application (page (3), lines (8-16)) and page (11), lines (5-18)).
Secondly, the Applicant argues that the update flag and source identifier of the reference to SORENSON are not “state information comprises one or more of a current configuration and a current state of one or more of (i) software associated with the given service, (ii) a system associated with the given service and (iii) an entity associated with the given service”, and that the SORENSON tuple passage at Col. 3, line (58) “does not address the content of the message”, see Applicant’s Remarks pages 9-10.
The examiner respectfully disagrees and asserts that the rejection does not rely on the update flag or the source identifier as the claimed state information. The claimed state information is read on the message data itself, i.e. the content of the message that SORENSON publishes and updates. SORENSON expressly identifies that content in Col.4, line (64): “The message data may include one or more data types such as images at a publisher location, a geolocation of a moving publisher, environmental temperature at the publisher, internal temperature of the publisher, state of a publisher, or the like.” Further, SORENSON discloses in Col.13, line (39): “…, the message data to be updated may include data specific to the publisher, with data types such as images of a publisher location, a geolocation of a moving publisher, environmental temperature at the publisher, internal temperature of the publisher, etc.” According to SORENSON, the purpose is to deliver the latest or current value of that data rather than “stale data or data which is not current”, see SORENSON col.2, line (29) and col.13, line (8). SORENSON discloses that the “state of a publisher” the “internal temperature of the publisher” and “geolocation of a moving publisher” are each a current state of an entity, or of a system, associated with the given service, i.e. the publisher, and given the broadest reasonable interpretation, then stratifies the claimed language. Furthermore, this reading is consistent with the Applicant’s instant specification, which states that the term “state information” “shall be broadly construed so as to encompass dynamic information characterizing a current state and/or a current configuration of software, a system or an entity”, see instant specification page (3), line (5); and that entities encompass “human, hardware, software or firmware entities, as well as various combinations of such entities”, see instant specification page (6), line (2). As to SORENSON’s publishers include vehicles, traffic cameras, street lights and other IoT devices, see SORENSON Col.3, line (32); consequently, these hardware entities and systems whose current state (location, temperature, images, “state of a publisher”) is the published message data. To conclude, Applicant’s remark that the tuple massage at Col.3, line (58) lists the fields of the tuple rather than the content of the message data is therefore beside the point; the content is described elsewhere in SORENSON, as cited above, and the tuple passage is referenced only to show that the message data is published to a topic and queued for delivery to the topic’s subscribers.
The Applicant did not argue the dependent claims rejection but merely stated their dependency from claims 1, 8 and 18; hence these arguments are not persuasive, and the rejection of the dependent claims are maintained.
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.
Claims 1, 3, 5-8, 10, 12-15 and 18-23 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US Patent (US 11,588,776 B1) issued to Sorenson, III et al. (hereinafter as “SORENSON”).
Regarding claim 1 (Currently Amended), SORENSON teaches a method, comprising:
in response to a change in state information associated with a given service in an information technology infrastructure (SORENSON Fig.1A, Col.3, line (12): “The system includes a publisher 105, a broker 115, and one or more subscribers 110. The publisher 105 may publish messages to the broker 115 and the broker 115 may transmit the messages to one or more subscribers 110, such as those who have subscribed to the messages from the publisher 105 or the topic 120 published by the publisher 105.”; and
Col. 6, line (32): “…, cars, street lights, traffic cameras and the like may be IoT publishers and/or subscribers.”; and
Col. 12, line (25): “…, a module may be considered a service with one or more processes executing on a server or other computer hardware.”; and
Col. 3, line (5): “…, subscribers may desire to know the geo-location of an important asset (e.g., a vehicle or commercial truck) as the asset moves. If the asset is updating its location frequently, the outbound messages to the subscribers may be updated with the latest data even if the message was queued for delivery several location updates in the past.”; and
Col. 4, line (60): “The data source 130 may, in various examples, generate updated message data periodically, upon request from the publisher, upon request from the broker, continuously in a stream, at random intervals, upon occurrence of defined events, etc.”; and
Col. 15, line (10): “…, updating of the cached data may occur each time a message with updated data is received from the publisher. Alternatively, the service may periodically ping the original data source to determine whether an update is available. The service may monitor the expiry of the cached data or whether updated data is available and replace the cached data with the updated data when the updated data is available.”,
the examiner notes that the reference discloses that the publisher (element 105), i.e. cars, traffic camera or other IoT device or service, is that to a given service in an information technology infrastructure (depicted in SORENSON Fig.1,the service provider environment 100 and the devices connected to it), and that a change in the publisher’s state, i.e. the asset moving to a new location or a defined event at the publisher’s data source, is the to the claimed change in the state information to which the updating and publishing respond),
wherein the state information comprises one or more of a current configuration and a current state of one or more of (i) software associated with the given service, (ii) a system associated with the given service and (iii) an entity associated with the given service (SORENSEON Col.4, line (64): “The message data may include one or more data types such as images at a publisher location, a geolocation of a moving publisher, environmental temperature at the publisher, internal temperature of the publisher, state of a publisher, or the like. The type of data to be updated in the message may be any of a wide variety of other types of data or combinations of data.”; and
Col.13, line (39): “…, the message data to be updated may include data specific to the publisher, with data types such as images of a publisher location, a geolocation of a moving publisher, environmental temperature at the publisher, internal temperature of the publisher, etc.”,
the examiner notes that the reference discloses that the “state of the publisher”, the “internal temperature of the publisher” and the “geolocation of a moving publisher” are each a state of an entity, i.e. the publisher device for example vehicle/car, and of a system associated with the claimed given service):
updating the state information maintained by the given service (SORENSON Col.3, lines (17): “If the asset is updating its location frequently, the outbound messages to the subscribers may be updated with the latest data”; and
Col.4, line (56): “…, the message data may be generated by a human operator at the publisher. In other examples, the data source may comprise a device having a transducer, sensor, or other data generating device for capturing, generating or creating the message data.”; and
Col.13, line (52): “…, the data source may be the publisher”; and
Col.14, line (49): “…, the data source may belong to or be managed by the publisher or some other third party. ... For example, the data source may be a global positioning system (GPS) device, a camera, a thermometer or the like.”,
the examiner notes that the reference discloses that the publisher, through its own data source (GPS device, sensor, thermometer), generates the updated message data reflecting its changed state, i.e. updates the state information it maintains); and
publishing the updated state information associated with the given service to one or more topics of [[a]] at least one message queue of the information technology infrastructure (SORENSON Fig. 1A, Col.3, line (25): “The present technology may be utilized in a topic-based system, where messages are published to “topics” or named logical channels.”; and
Fig.1A.1B, Col.4, line (58): “When the broker 115 receives a message for a topic 120, the broker 115 may queue publication of the message to the subscribers 110 using the queue 125.”; and
Col.4, line (38): “If, for example, the publisher 105 publishes a first message and a subscriber 110 is queued to receive the message while the publisher 105 publishes a second, third, or other message …, the message transmitted to the subscriber 110 may include updated message data based on the latest message from the publisher 105.”; and
Fig.4, Col.10, lines (28): “Upon receipt of a message, the broker server 400 may queue the message for delivery to a subscriber via a queue 415.”,
the examiner notes the reference discloses that the publisher 105 publishes each new message carrying its updated message data to the topic 120, and the broker queues the message in the queue 125/415 for delivery to the topic’s subscribers),
wherein the updated state information is consumed from the at least one message queue by at least one additional service, based at least in part on one or more topic subscriptions, to update respective state information maintained by the at least one additional service (SORENSON Col.3, line (27): “Subscribers in a topic-based system will receive messages published to the topics to which the subscribers subscribe, and each subscriber to a topic will receive the same messages.”; and
Fig.4, Col.10, line (31): “The broker server 400 may maintain a subscription data store 445 identifying subscribers and topics to which a subscriber may subscribe ... If the topic in the message corresponds to a topic in the subscription data store 445 then subscribers having subscribed to the topic may be queued to receive the message.”; and
Col.6, line (45): “…, geolocation of cars may be published to other subscriber cars to manage positions and relationships of the cars relative to other of the cars. As another example, the geolocation of cars in a fleet may be published to a subscriber manager to identify a present location of cars in the fleet, whether a car has crossed a geofence, etc.”; and
Fig.1A, Col.5, line (6): “…, the message data may optionally be obtained from another publisher, where the publisher 105 illustrated in FIG. 1A is a subscriber to the other publisher or to a topic to which the other publisher publishes messages. In such a case, the publisher 105 may optionally modify the message data before republishing to other subscribers 110.”,
the examiner notes the reference discloses that the subscribing cars, the subscriber fleet manager, the coffee maker and the subscribing publisher 105 are additional services that consume the updated message data from the queue on the basis of their topic subscriptions and use to update the state they respectively maintain, i.e. the positions and relationships of the other cars, the present location and geofence status of each car in the fleet, the local clock, or the message data to be republished);
wherein the method is performed by at least one processing device comprising a processor coupled to a memory (SORENSON Fig.4, Col.11, line (38): “The system may be implemented as a plurality of computing nodes or computing instances, each of which comprises at least one processor 405 and a memory 410, where the computing nodes are configured to collectively implement the modules, data stores and so forth.”).
Regarding claims (8 and 15), the aforementioned claims recite similar limitations to claim 1, therefore these claims are rejected for similar reasons as detailed above.
Regarding claim 3 (Currently Amended), SORENSON teaches the limitations of claim 1. Further, SORENSON teaches wherein one or more topics of the at least one message queue serve as a state store (SORENSON Col.3, line (22): “…, a topic may be a specific type of data stream that is not necessarily human readable but is readable by machines which consume published information.”); and
Fig.1A/B, Col.3, line (58): “When the broker 115 receives a message for a topic 120, the broker 115 may queue publication of the message to the subscribers 110 using the queue 125.” And
Fig.1C, Col.5, line (45): “…, a cached data store 140, which caches data from the data source 130, may be available for use by the broker 115.”; and
Col. 12, line (1): “…, various data may be stored in a data store that is accessible to the computing device. ... The data stored in the data store, for example, may be associated with the operation of the various modules, applications and/or functional entities described.”,
the examiner notes the reference discloses that the topic 120, which its associated queue 125 and cached data 140/435, holds the current state (message data) of the publisher for the topic’s subscribers and thus serves as claimed “a state store”).
Regarding claim (10), the aforementioned claim recites similar limitations to claim 3, therefore this claim is rejected for similar reasons as detailed above.
Regarding claim 5 (Currently Amended), SORENSON teaches the limitations of claim 1. Further, SORENSON teaches wherein the state information comprises dynamic information for a plurality of services, and wherein the given service updates a respective portion of the state information in a local cache of the given service and publishes the updated state information, comprising the dynamic information for the plurality of services, to one or more topics on the at least one message queue from the local cache (SORENSON Fig. 1A, Col. 1, line (28): “Any number of publishers may publish messages to a broker 115 on any variety of topics (e.g. shipping, receiving, accounting, geolocation, maintenance, etc.).”; and
Fig.1C, Col.6, line (45): “…, a cached data store 140, which caches data from the data source 130, may be available for use by the broker 115. The cached data store 140 may be a part of the broker … The broker 115 may then rely on the cached updated message data for updating a message for transmission to one or more subscribers 110.”; and
Fig. 4, Col. 10, line (55): “The updater 420 may update the message using updated message data from a data source (e.g., cached data 435) to generate an updated message when the message reaches a front of the queue 415. The dispatcher 425 may transmit or publish the updated message from the broker server 400 to the subscriber(s).”; and
Fig. 4, Col. 11, line (10): “Updated message data from this data source may optionally be cached in a cached data store 435.”,
the examiner note the reference discloses that the broker service maintains in its local cached data store 140/435 the dynamic message data, i.e. state, if the plurality of publishers on the variety of topics, updates the respective portion of that cached data for a given data source when updated data is received or available (Col.15, line (7)), and publishes the updated messages to the topics’ subscribers from the cache).
Regarding claims (12 and 18), the aforementioned claims recite similar limitations to claim 5, therefore these claims are rejected for similar reasons as detailed above.
Regarding claim 6 (Currently Amended), SORENSON teaches the limitations of claim 5. Further, SORENSON teaches wherein one or more of the plurality of services maintain a respective local cache of the state information and update at least a portion of the respective local cache in response to updated state information received from the at least one message queue (SORENSON Col.15, line (10): “…, updating of the cached data may occur each time a message with updated data is received from the publisher.”; and
Fig.1A/B/C, Col.5, line (47): “The cached data store 140 may be a part of the broker 115 or may reside outside the broker, such as in a service provider environment or elsewhere”; and
Col.4, line (45): “…, geolocation of cars may be published to other subscriber cars to manage positions and relationships of the cars relative to other of the cars.”; and
Col.6, line (6): “When the coffee maker is able to accurately determine the current time, the coffee maker may behave more precisely as programmed”,
the examiner notes the reference discloses that the term “local cache” is given its broadest reasonable interpretation as local memory in which a service holds the latest state information it has received, and the SORENSON’s subscribing services (for example, the subscriber cars, the fleet manager and the coffee maker) necessarily hold the received message data locally in order to act on it as described, and update it from each message received from the queue).
Regarding claims (13 and 19), the aforementioned claims recite similar limitations to claim 6, therefore these claims are rejected for similar reasons as detailed above.
Regarding claim 7 (Currently Amended), SORENSON teaches the limitations of claim 6. Further, SORENSON teaches wherein the update to the at least the portion of the respective local cache in response to the updated state information received from the at least one message queue is implemented at least in part by a queue manager associated with the respective local cache (SORENSON Fig.4, Col.10, line (28): “Upon receipt of a message, the broker server 400 may queue the message for delivery to a subscriber via a queue 415.”; and
Fig.4, Col. 10, line (55): “The updater 420 may update the message using updated message data from a data source (e.g., cached data 435) to generate an updated message when the message reaches a front of the queue 415. The dispatcher 425 may transmit or publish the updated message”; and
Fi4, Col.11, line (10): “Updated message data from this data source may optionally be cached in a cached data store 435.”; and
Col.15, line (10): “…, updating of the cached data may occur each time a message with updated data is received from the publisher.”,
the examiner notes the reference discloses that the updater (element 420) and dispatcher (element 425), which manage the messages in the queue 425 and maintain and use the cached data 435, constitute a queue manager associated with the cached data store 435 that implements the update of the cache in response to updated message data received through the queue).
Regarding claims (14 and 20), the aforementioned claims recite similar limitations to claim 7, therefore these claims are rejected for similar reasons as detailed above.
Regarding claim 21 (New), SORENSON teaches the limitations of claim 1. Further, SORENSON teaches wherein, in response to consuming the updated state information from the at least one message queue, the at least one additional service publishes one or more output messages, related to the updated state information, to one or more topics of the at least one message queue (SORENSON Fig.1A, Col.5, line (4): “…, the message data may be obtained by the publisher 105 from another source, such as a third party. Further, the message data may optionally be obtained from another publisher, where the publisher 105 illustrated in FIG. 1A is a subscriber to the other publisher or to a topic to which the other publisher publishes messages. In such a case, the publisher 105 may optionally modify the message data before republishing to other subscribers 110.”; and
Fig.1A, Col.3, line (12): “The publisher 105 may publish messages to the broker 115 and the broker 115 may transmit the messages to one or more subscribers 110, such as those who have subscribed to the messages from the publisher 105 or the topic 120 published by the publisher 105.”; and
Col.6, line (33): “…, cars, street lights, traffic cameras and the like may be IoT publishers and/or subscribers.”,
the examiner notes the reference discloses that the publisher 105 of Fig. 1A, when ot os a subscriber to another publisher’s topic, is an additional service that consumes the other publisher’s updated message data from the queue and, in response, republishes that message data (optionally modified, i.e. related to the updated state information) as output messages to the topic 120 of the message queue for its own subscriber 110).
Regarding claims (22 and 23), the aforementioned claims recite similar limitations to claim 21, therefore these claims are rejected for similar reasons as detailed above.
Claim Rejections - 35 USC § 103
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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent (US 11,588,776 B1) issued to Sorenson, III et al. (hereinafter as “SORENSON”), and in view of US Patent Application Publication (US 2005/0038795 A1) issued to Charlot et al. (hereinafter as “CHARLOT”).
Regarding claim 2 (Original), SORENSON teaches the limitations of claim 1.
However, SORENSON does not explicitly teach wherein the given service comprises a processor-based software testing checker that performs a scan of software.
But CHARLOT teaches wherein the given service comprises a processor-based software testing checker that performs a scan of software (CHARLOT Fig. 1, Para. [0081]: “The core service 120 then scans its list of client applications 100 that connect to it and performs a cross-check based on the item name from the core-inbound transaction 212.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of SORENSON (disclosing methods publisher-subscriber messaging control/updates) to include the teachings of CHARLOT (disclosing methods for interfacing applications to maintain data integrity, in which a core service scans the client applications and cross-checks their data) and arrive at a method in which the publishing service is a checker that scans software and publishes the results of the scan based on messaging communication. One of ordinary skill in the art would have been motivated to make this combination because by enabling a controller service to communicate with client applications to identify new or changed data in one of the client applications, thereby ensuring specific client applications are up to date, as recognized by (CHARLOT Abstract, Paras. [0009]-[0011]). In addition, the references of SORENSON and CHARLOT teach features that are directed to analogous art and they are directed to the same field of endeavor of messaging interface systems.
Regarding claims (9 and 16), the aforementioned claims recite similar limitations to claim 2, therefore these claims are rejected for similar reasons as detailed above.
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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Yu et al.; (US-10592315-B2); “Methods for controlling message updates upon an application executing a change to its configuration, pushes the updated configuration to a topic of a message broker’s queue, from which a subscribed device agent consumes the updated configuration and updates its locally cached copy.”
Casaletto et al.; (US-10673941-B2); “Methods for a messaging protocol in a peer-to-peer distributed system, wherein nodes subscribed to topics with a message broker and the system state is synchronized among all nodes by exchanging messages, over a topic, that indicate the local state changes in each node.”
Ballantyne et al.; (US-11722451-B2); “Methods for distributing event messages from a first service to additional services using a message store, wherein the messages are published on a sequential message queue from which additional services consume the published messages.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zuheir A Mheir whose telephone number is (571)272-4151. The examiner can normally be reached on Monday - Friday 9:00 - 5:00.
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, Piere Vital can be reached on (571) 272-4215. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
09/23/2026
/ZUHEIR A MHEIR/Patent Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
