Prosecution Insights
Last updated: April 19, 2026
Application No. 18/322,398

MICROSERVICES

Non-Final OA §103
Filed
May 23, 2023
Examiner
YUN, CARINA
Art Unit
2194
Tech Center
2100 — Computer Architecture & Software
Assignee
Simple Things Inc.
OA Round
1 (Non-Final)
50%
Grant Probability
Moderate
1-2
OA Rounds
4y 7m
To Grant
83%
With Interview

Examiner Intelligence

Grants 50% of resolved cases
50%
Career Allow Rate
160 granted / 322 resolved
-5.3% vs TC avg
Strong +34% interview lift
Without
With
+33.5%
Interview Lift
resolved cases with interview
Typical timeline
4y 7m
Avg Prosecution
25 currently pending
Career history
347
Total Applications
across all art units

Statute-Specific Performance

§101
17.8%
-22.2% vs TC avg
§103
47.5%
+7.5% vs TC avg
§102
8.6%
-31.4% vs TC avg
§112
21.4%
-18.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 322 resolved cases

Office Action

§103
DETAILED ACTION Authorization for Internet Communications The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03): “Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.” Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web (PTO/SB/439). 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 . 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 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. Examiner Notes Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. 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 are rejected under 35 U.S.C. 103 as being unpatentable over in view of Herman et al. (U.S. PG PUB 2016/0301373) in view of Oberstein et al. (U.S.PG PUB 2016/ 0182667). Regarding claim 1, Herman teaches a computer-implemented method comprising: determining, by a computer system of a hub, that a smart device has been installed in proximity to the hub (see ¶ [0056] “For example, the occupancy detector 170 may detect the occupants of the room in which the hub computing device 100 is installed using the proximity sensor 110. The occupancy detector 170 may also detect the presence of other occupants in the environment through signals received from other sensors throughout the smart home environment. The other sensors may be, for example, other proximity sensors, entryway sensors, motion sensors, cameras, microphones, and sensors that can detect the presence of a known WiFi or Bluetooth device or fob associated with an occupant of the environment, and may be located throughout the smart home environment, with signals that may be accessible to the hub computing device 100. The occupancy detector 170 may be able to generate the occupancy model 142 using signals from the other sensors. The occupancy model 142 may be stored in the storage 140, and may be used by the dynamic volume adjuster 150 to adjust the volume of the speaker 130.”); (see ¶ [0115] “The Thread network may be scalable to connect devices (e.g., 2, 5, 10, 20, 50, 100, 150, 200, or more devices) into a single network supporting multiple hops (e.g., so as to provide communications between devices when one or more nodes of the network is not operating normally).”). Herman does not expressly disclose, however, Oberstein teaches using a first microservice to install the adapter (see ¶ [0368] “Router MS20 invokes (5440) the procedure on Node Controller MS30. Node Controller MS30 yields (5450) the result, which Node Management Router MS20 sends (5460) to Adapter 5490. Adapter 5490 then yields (5470) the received result (MS60) to Management Router 5400, which sends (5480) the result to Management Application MS10. In embodiments, Adapters such as Adapter 5490 may be implemented as part of a Crossbar.io node. Adapters may further be technically implemented in a single component together with a Node Controller Component.”); sending a first remote procedure call (RPC) from the hub to an adapter of the smart device (see ¶ [0367] “Management Application MS10 and Container Control Code MS30 are connected to different WAMP routers, Management Router 5400 and Node Management Router MS20 respectively. Adapter 5490 is connected to both WAMP routers as a WAMP client. When Container Control Code MS30 initially registered the called procedure, Adapter 5490 received notification of this, and in turn registered the called procedure with Management Router 5400. Management Application MS10 issues the call to Management Router 5400.”), wherein the first RPC is sent over a hub Web Application Messaging Protocol (WAMP) router of the hub (see ¶ [0299] “This is a WAMP call, and is received by Node Management Router 4620. Node Controller 4630 has previously registered the procedure called by Management Application 4610, so Node Management Router 4620 sends an invocation 4660 for the procedure to Node Controller Component 4630”); sending a second RPC from the hub to the adapter using a second microservice to determine that the adapter is functional (see ¶ [0378] “Application Component 4930 does not connect directly to Application Router 4730. Container Control Code 4920 both establishes a WAMP connection 6010 to the Node Management Router, and provides the functionality to establish WAMP connections and create and process WAMP messages to Application Component 4930. The WAMP connection which connects Application Component 4930 to Application Router 4730 is thus established via Container Control Code 4920.”); accessing an automated flow for controlling the smart device, wherein the automated flow comprises a node corresponding to the smart device (see ¶ [0293] “It will also be appreciated that a Crossbar.io node may be implemented in various ways, e.g. it may run as a single application on a single computing device or it may be implemented in the form of components spread across several computing devices in a computing system.”); sending a third RPC from the hub via the adapter to the smart device using a third microservice, wherein the third RPC references the node (see ¶ [0304] “Here the call addresses the node controller component with an ID of “node1”, and on this calls the procedure “start_router” to start a native worker of type router. It further passes some arguments to this procedure, namely the ID of the router to be instantiated (“router1”).”) and operating the smart device in accordance with the automated flow using the third RPC, wherein the smart device is operated while obviating use of an Internet connection to the hub (see ¶[0240] “It will be appreciated that illustrated connections 3015, 3025, 3035, 3055 and 3065 between devices can be implemented in a variety of ways. These include connections such as wired connections (e.g. Ethernet) and radio connections (e.g. Wi-Fi, 3G), and transport protocols such as TCP. Combinations of these and others as transport stacks may be used as long as it is possible to transport the protocol or protocols used to connect the illustrated participants to each other.”). Hence it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Herman by adapting Oberstein to provide exchange information between devices (see ¶[0003] of Oberstein). Regarding claim 2, Herman does not expressly disclose, however, Oberstein teaches comprising: sending a Publish/Subscribe (PubSub) message from the hub via the adapter to the smart device using the first microservice (see ¶ [0081] “FIGS. 6 to 8 are diagrams illustrating a Publish-and-Subscribe (PubSub) communication pattern for application components. Publish-and-Subscribe is a 1-to-many communication pattern, i.e. a single publication event by a single publisher can be received by any number of subscribers. It is further a notification pattern, i.e. subscribers can receive any number of published events based on a single subscription action, without the need for any participatory action before each individual receipt.”). Hence it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Herman by adapting Oberstein to provide exchange information between devices (see ¶[0003] of Oberstein). Regarding claim 3, Herman teaches wherein the first microservice is a resource manager microservice configured to register the adapter and the smart device (see ¶[0129] “In some examples, some or all of the users (e.g., individuals who live in the home) can register their mobile device and/or key FOBs with the smart-home environment (e.g., with the controller 73). Such registration can be made at a central server (e.g., the controller 73 and/or the remote system 74) to authenticate the user and/or the electronic device as being associated with the smart-home environment, and to provide permission to the user to use the electronic device to control the network-connected smart devices and the security system of the smart-home environment. A user can use their registered electronic device to remotely control the network-connected smart devices and security system of the smart-home environment, such as when the occupant is at work or on vacation. The user may also use their registered electronic device to control the network-connected smart devices when the user is located inside the smart-home environment.”). Regarding claim 4, Herman does not expressly disclose, however, Oberstein teaches wherein the first microservice is configured to expose create, read, update, and delete (CRUD) operations (see ¶ [0290] “ A database, such as database 4360, may be used to store and retrieve information which is used or generated during the startup and running of the Crossbar.io node. Such information may include information on workers which are to be instantiated, connections which the node should establish to outside applications or components, logging of information on the lifecycle of workers and of messages that router workers route.”). Hence it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention that CRUD operations are part of a database, further it is obvious to modify the teachings of Herman by adapting Oberstein to provide exchange information between devices (see ¶[0003] of Oberstein). Regarding claim 5, Herman does not expressly disclose, however, Oberstein teaches wherein the first microservice is precluded from sharing data with the second microservice and the third microservice (see ¶ [0331] “Here the call addresses the worker with an ID of “router1” which is running as part of a Crossbar.io node with an ID of “node1”, and on this calls the procedure “modify_router_realm_role_permission” to modify an existing role in a particular realm. It further passes some arguments to this procedure, namely the name of the realm to which the role is attached (“realm1”), the name of the role to be modified (“frontend”), an URI or URI pattern, and the set of permissions for the URI pattern. In this case, publications to the URI “com.myapp.new_sale” are now not allowed for the role. It will be appreciated that the modification of a role may equally modify the permissions for an existing URI or URI pattern, or add a URI pattern.”). Hence it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Herman by adapting Oberstein to provide exchange information between devices (see ¶[0003] of Oberstein). Regarding claim 6, Herman teaches wherein the third microservice is an activity microservice configured to access one or more events (see ¶[0138] “The devices may communicate with one or more remote devices, such as servers 13 and/or databases 15. The remote devices may be directly accessible by the devices 10, 11, or one or more other devices may provide intermediary access such as where a server 13 provides access to resources stored in a database 15. The devices 10, 11 also may access remote platforms 17 or services provided by remote platforms 17 such as cloud computing arrangements and services. The remote platform 17 may include one or more servers 13 and/or databases 15.”). Regarding claim 7, Herman teaches wherein the first microservice is a provisioning microservice configured to onboard the hub into a user account (see ¶ [0128] “A user can interact with one or more of the network-connected smart devices (e.g., via the network 70). For example, a user can communicate with one or more of the network-connected smart devices using a computer (e.g., a desktop computer, laptop computer, tablet, or the like) or other portable electronic device (e.g., a smartphone, a tablet, a key FOB, and the like). A webpage or application can be configured to receive communications from the user and control the one or more of the network-connected smart devices based on the communications and/or to present information about the device's operation to the user. For example, the user can view can arm or disarm the security system of the home.”). Regarding claim 8, is a system claim, corresponding to method claim 1. In addition, Herman teaches a computer system comprising: one or more computer processors; and a non-transitory, computer-readable storage medium storing instructions, which when executed by at least one of the one or more computer processors cause the computer system to perform the steps listed in claim 1 (see ¶[0109]). Regarding claim 9-14, are system claims, corresponding to method claims 2-8 above. Regarding claim 15, is a storage medium claim, corresponding to method claim 1, and is rejected for the same reasons. In addition, Herman teaches a non-transitory, computer-readable storage medium storing instructions, which when executed by one or more computer processors cause the one or more computer processors to perform the steps listed in claim 1 (see ¶[0109]). Regarding claim 16-20, are medium claims, corresponding to method claims 2-7 above, and are rejected for the same reasons. Interview Requests In accordance with 37 CFR 1.133(a)(3), requests for interview must be made in advance. Interview requests are to be made by telephone (571-270-7848) call or FAX (571-270-8848). Applicants must provide a detailed agenda as to what will be discussed (generic statement such as “discuss §102 rejection” or “discuss rejections of claims 1-3” may be denied interview). The detail agenda along with any proposed amendments is to be written on a PTOL-413A or a custom form and should be faxed (or emailed, subject to MPEP 713.01.I / MPEP 502.03) to the Examiner at least 5 business days prior to the scheduled interview. Interview requests submitted within amendments may be denied because the Examiner was not notified, in advance, of the Applicant Initiated Interview Request and due to time constraints may not be able to review the interview request to prior to the mailing of the next Office Action. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Zhou et al. (US PG PUB 2020/0329124) teaches the device monitoring system includes the following: an intermediary, configured to send subscription information and receive publishing information; and a plurality of clients, communicatively connected to the intermediary and configured to send the corresponding publishing information based on the received subscription information, where the client includes at least one first client and at least one second client; the first client and the second client exchange information by using the intermediary; and the first client monitors the second client based on a device management protocol. Oberstein “The Web Application Messaging Protocol” May 7, 2021 teaches the Web Application Messaging Protocol (WAMP). WAMP is a routed protocol that provides two messaging patterns: Publish & Subscribe and routed Remote Procedure Calls. It is intended to connect application components in distributed applications. WAMP uses WebSocket as its default transport, but can be transmitted via any other protocol that allows for ordered, reliable, bi-directional, and message-oriented communications. Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARINA YUN whose telephone number is (571)270-7848. The examiner can normally be reached Mon, Tues, Thurs, 9-4 (EST). 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 call. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached on (571) 270-3180. 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. Carina Yun Patent Examiner Art Unit 2194 /CARINA YUN/Examiner, Art Unit 2194
Read full office action

Prosecution Timeline

May 23, 2023
Application Filed
Oct 29, 2025
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12578996
ADAPTIVE HIGH-PERFORMANCE TASK DISTRIBUTION FOR MANAGING COMPUTING RESOURCES ON CLOUD
2y 5m to grant Granted Mar 17, 2026
Patent 12572398
CONSOLE COMMAND COMPOSITION
2y 5m to grant Granted Mar 10, 2026
Patent 12554562
INTERSYSTEM PROCESSING EMPLOYING BUFFER SUMMARY GROUPS
2y 5m to grant Granted Feb 17, 2026
Patent 12498996
HYBRID PAGINATION FOR RETRIEVING DATA
2y 5m to grant Granted Dec 16, 2025
Patent 12474974
SYSTEMS AND METHODS FOR POWER MANAGEMENT FOR MODERN WORKSPACES
2y 5m to grant Granted Nov 18, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
50%
Grant Probability
83%
With Interview (+33.5%)
4y 7m
Median Time to Grant
Low
PTA Risk
Based on 322 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month