Prosecution Insights
Last updated: April 19, 2026
Application No. 18/694,244

WORKER NODE CLUSTER MANAGEMENT

Non-Final OA §102§103§112
Filed
Mar 21, 2024
Examiner
ESCALANTE, OVIDIO
Art Unit
3992
Tech Center
3900
Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
OA Round
1 (Non-Final)
73%
Grant Probability
Favorable
1-2
OA Rounds
2y 8m
To Grant
83%
With Interview

Examiner Intelligence

Grants 73% — above average
73%
Career Allow Rate
150 granted / 205 resolved
+13.2% vs TC avg
Moderate +10% lift
Without
With
+9.6%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
47 currently pending
Career history
252
Total Applications
across all art units

Statute-Specific Performance

§101
3.1%
-36.9% vs TC avg
§103
30.3%
-9.7% vs TC avg
§102
16.4%
-23.6% vs TC avg
§112
25.9%
-14.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 205 resolved cases

Office Action

§102 §103 §112
DETAILED ACTION This action is in response to the Applicant’s preliminary amendment filed on March 21, 2024. As set forth therein, claims 11-13, 15-32, 34, 41, 43-59, and 61-65 are cancelled. Claims 1-10, 14, 33, 35-40, 42 and 60 remain pending. 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 . Information Disclosure Statement The information disclosure statement (IDS) submitted on April 4, 2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claim 42 recites the limitation "the public key" in line 3. There is insufficient antecedent basis for this limitation in the claim. 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claim(s) 1-3, 5, 6, 14, 33, 35-38 and 60 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Gandhi US Patent Pub. 2014/0006502. Regarding claim 1: A method for managing a cluster of worker nodes that are controllable by a master node, wherein the method being performed by an entity, the method comprising: Gandhi is directed to a method to configure mobile devices to work in a mobile cluster and to collaboratively leverage applications resident on the cluster of mobile devices. Gandhi discloses that the configuration and management of the cluster is through a cluster master. See the abstract and Figures 2-3. automatically allowing a wireless device to join the cluster as a worker node if1 the wireless device is authorised to join the cluster; and Gandhi discloses in paragraph [0028] that a cluster master receive a request from a mobile device to join a cluster. As further set forth in paragraph [0028] the cluster master may authenticate the requesting mobile device by verifying that the mobile device belongs to a contact list, by requesting the user to provide a security code, or through other handshaking protocol. Gandhi discloses that after the mobile device is authenticated, the cluster master may update the cluster database to include information on the mobile device such as its IP address, phone number, device/user identity. Therefore, the mobile device (wireless device) is automatically allowed by the master if they are authorized to join the cluster. Gandhi discloses in paragraph [0030] that if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact listed of trusted users. Thus, in this method, the wireless device is automatically allowed since no action is needed to be performed by the user of the wireless device. the wireless device being authorised to join the cluster if the wireless device is registered to one or both of an owner of the master node and a cluster of worker nodes, Gandhi discloses in paragraph [0030] that if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact list of trusted users. In addition, Gandhi discloses “[t]he cluster master may search through the cluster database to determine if the mobile device is a cluster member by looking for unique identifier, such as an IP address, phone number, or other device/user identifier associated with the mobile device.”). See also paragraph [0028] the worker nodes being responsible for providing a computational resource in a network. Gandhi, discloses in paragraphs [0027-0028 and 0033] that a cluster master can request that the mobile device collaborate on applications or shared device functionalities. See paragraph [0019] which discloses that the cluster master may distribute processing of the application among cluster members. See also paragraphs [0025 and 0036]. Regarding claim 2: The method as claimed in claim 1, wherein: the owner of the one or both of the master node and the cluster of worker nodes is: a user of the one or both of the master node and the cluster of worker nodes; a service provider of the one or both of the master node and the cluster of worker nodes; or a manager of the one or both of the master node and the cluster of worker nodes. Gandhi is paragraph [0028] explains that the work devices include user devices and thus the owner of at least a cluster mobile device is a user of the worker node. See also paragraph [0030] which discloses “the user of the mobile device to establish an account”. In addition, Gandhi in paragraph [0015] discloses of a primary members and individuals members and thus disclosed of both and owner and users. See also paragraphs [0041, 0044-0046] Regarding claim 3: The method as claimed in claim 2, wherein: the owner of the one or both of the master node and the cluster of worker nodes is the manager of the one or both of the master node and the cluster of worker nodes; and Gandhi is paragraph [0028] explains that the work devices include user devices and thus the owner of at least a cluster mobile device is a user of the worker node. See also paragraph [0030] which discloses “the user of the mobile device to establish an account”. In addition, Gandhi in paragraph [0015] discloses of a primary members and individuals members and thus disclosed of both and owner and users. See also paragraphs [0044-0046]. In paragraph [0025], the mobile device can be a cluster master and as set forth in paragraph [0030], a user of the mobile can be the owner. In paragraph [0031, 0035-0035], user manages their mobile device by selecting application and responding to requests from the master device. the wireless device is authorised to join the cluster if the wireless device is registered to the manager and a user of the wireless device is authorised by the manager to use the wireless device. Gandhi discloses in paragraph [0028] that the cluster master may authenticate the requesting mobile device by verifying that the mobile device belongs to a contact list, by requesting the user to provide a security code, or through other handshaking protocol. Gandhi discloses that after the mobile device is authenticated, the cluster master may update the cluster database to include information on the mobile device such as its IP address, phone number, device/user identity. Regarding claim 5: The method as claimed in claim 1, the method comprising: automatically allowing the wireless device to join the cluster when the wireless device moves into a geographical area served by the cluster or moves into a part of the network served by the cluster. As explained in paragraph [0028], Gandhi discloses setting up a cluster in a home Wi-Fi network and that the wireless device is authenticated before allowing it to join the cluster. Thus, the wireless device is automatically join to the cluster when it moves into the geographical area served by the cluster (i.e. home Wi-Fi network). Gandhi discloses in paragraph [0030] that if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact listed of trusted users. Thus, in this method, the wireless device is automatically allowed since no action is needed to be performed by the user of the wireless device when they move to the geographical area serviced by the Wi-Fi network of the cluster. Regarding claim 6: The method as claimed in claim 1, the method comprising: determining if the wireless device is authorised to join the cluster. Gandhi discloses in paragraph [0028] that the cluster master may authenticate the requesting mobile device by verifying that the mobile device belongs to a contact list, by requesting the user to provide a security code, or through other handshaking protocol. Gandhi discloses that after the mobile device is authenticated, the cluster master may update the cluster database to include information on the mobile device such as its IP address, phone number, device/user identity. Gandhi discloses in paragraph [0030] that if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact listed of trusted users. Regarding claim 14: The method as claimed in claim 1, the method comprising: automatically allowing the wireless device to leave the cluster when the wireless device moves outside a geographical area served by the cluster or moves outside a part of the network served by the cluster. Gandhi discloses in paragraph [0027] that the cluster master may update the cluster database as new members join the cluster or existing members leave the cluster, or as new applications or device functionalities are identified. As set forth in paragraph [0030], if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact listed of trusted users. Thus, if the mobile device leaves the local WiFi (i.e. moves outside the geographical area of the network that serves the cluster), then they have left the cluster and geographical area. Regarding claim 33: An entity for managing a cluster of worker nodes that are controllable by a master node, the entity comprising: Gandhi is directed to a method to configure mobile devices to work in a mobile cluster and to collaboratively leverage applications resident on the cluster of mobile devices. Gandhi discloses that the configuration and management of the cluster is through a cluster master. See the abstract and Figures 2-3. processing circuitry configured to automatically allow a wireless device to join the cluster as a worker node if the wireless device is authorised to join the cluster; and Gandhi discloses an apparatus includes a processor. See also paragraph [0017] which explains that the mobile devices includes processing circuitry. Gandhi discloses in paragraph [0028] that a cluster master receive a request from a mobile device to join a cluster. As further set forth in paragraph [0028] the cluster master may authenticate the requesting mobile device by verifying that the mobile device belongs to a contact list, by requesting the user to provide a security code, or through other handshaking protocol. Gandhi discloses that after the mobile device is authenticated, the cluster master may update the cluster database to include information on the mobile device such as its IP address, phone number, device/user identity. Therefore, the mobile device (wireless device) is automatically allowed by the master if they are authorized to join the cluster. Gandhi discloses in paragraph [0030] that if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact listed of trusted users. Thus, in this method, the wireless device is automatically allowed since no action is needed to be performed by the user of the wireless device. the wireless device being authorised to join the cluster if the wireless device is registered to one or both of an owner of the master node and a cluster of worker nodes, Gandhi discloses in paragraph [0030] that if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact list of trusted users. In addition, Gandhi discloses “[t]he cluster master may search through the cluster database to determine if the mobile device is a cluster member by looking for unique identifier, such as an IP address, phone number, or other device/user identifier associated with the mobile device.”). See also paragraph [0028] the worker nodes being responsible for providing a computational resource in a network. Gandhi, discloses in paragraphs [0027-0028 and 0033] that a cluster master can request that the mobile device collaborate on applications or shared device functionalities. See paragraph [0019] which discloses that the cluster master may distribute processing of the application among cluster members. See also paragraphs [0025 and 0036]. Regarding claim 35: A method for controlling the operation of a wireless device, the method being performed by the wireless device, the method comprising: Gandhi is directed to a method to configure mobile devices to work in a mobile cluster and to collaboratively leverage applications resident on the cluster of mobile devices. Gandhi discloses that the configuration and management of the cluster is through a cluster master. See the abstract and Figures 2-3. automatically joining a cluster of worker nodes as a worker node if an entity allows the wireless device to join the cluster of worker nodes, the cluster of worker nodes are being controllable by a master node and Gandhi discloses in paragraph [0028] that a cluster master receive a request from a mobile device to join a cluster. As further set forth in paragraph [0028] the cluster master may authenticate the requesting mobile device by verifying that the mobile device belongs to a contact list, by requesting the user to provide a security code, or through other handshaking protocol. Gandhi discloses that after the mobile device is authenticated, the cluster master may update the cluster database to include information on the mobile device such as its IP address, phone number, device/user identity. Therefore, the mobile device (wireless device) is automatically allowed by the master if they are authorized to join the cluster. Gandhi discloses in paragraph [0030] that if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact listed of trusted users. Thus, in this method, the wireless device is automatically allowed since no action is needed to be performed by the user of the wireless device. the worker nodes are responsible for providing a computational resource in a network; and Gandhi, discloses in paragraphs [0027-0028 and 0033] that a cluster master can request that the mobile device collaborate on applications or shared device functionalities. See paragraph [0019] which discloses that the cluster master may distribute processing of the application among cluster members. See also paragraphs [0025 and 0036]. the entity allowing the wireless device to join the cluster if the wireless device is authorised to join the cluster, the wireless device being authorised to join the cluster if the wireless device is registered to one or both of an owner of the master node and a cluster of worker nodes. Gandhi discloses in paragraph [0028] that a cluster master receive a request from a mobile device to join a cluster. As further set forth in paragraph [0028] the cluster master may authenticate the requesting mobile device by verifying that the mobile device belongs to a contact list, by requesting the user to provide a security code, or through other handshaking protocol. Gandhi discloses that after the mobile device is authenticated, the cluster master may update the cluster database to include information on the mobile device such as its IP address, phone number, device/user identity. Therefore, the mobile device (wireless device) is automatically allowed by the master if they are authorized to join the cluster. Gandhi discloses in paragraph [0030] that if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact list of trusted users. In addition, Gandhi discloses “[t]he cluster master may search through the cluster database to determine if the mobile device is a cluster member by looking for unique identifier, such as an IP address, phone number, or other device/user identifier associated with the mobile device.”). See also paragraph [0028] Regarding claim 36: The method as claimed in claim 35, wherein: the owner of the one or both of the master node and the cluster of worker nodes is: a user of the one or both of the master node and the cluster of worker nodes; a service provider of the one or both of the master node and the cluster of worker nodes; or a manager of the one or both of the master node and the cluster of worker nodes. Gandhi is paragraph [0028] explains that the work devices include user devices and thus the owner of at least a cluster mobile device is a user of the worker node. See also paragraph [0030] which discloses “the user of the mobile device to establish an account”. In addition, Gandhi in paragraph [0015] discloses of a primary members and individuals members and thus disclosed of both and owner and users. See also paragraphs [0041, 0044-0046] Regarding claim 37: The method as claimed in claim 36, wherein: the owner of the master node and/or cluster of worker nodes is the manager of the one or both of the master node and the cluster of worker nodes; and Gandhi is paragraph [0028] explains that the work devices include user devices and thus the owner of at least a cluster mobile device is a user of the worker node. See also paragraph [0030] which discloses “the user of the mobile device to establish an account”. In addition, Gandhi in paragraph [0015] discloses of a primary members and individuals members and thus disclosed of both and owner and users. See also paragraphs [0044-0046]. In paragraph [0025], the mobile device can be a cluster master and as set forth in paragraph [0030], a user of the mobile can be the owner. In paragraph [0031, 0035-0035], user manages their mobile device by selecting application and responding to request from the master device. the wireless device is authorised to join the cluster if the wireless device is registered to the manager and a user of the wireless device is authorised by the manager to use the wireless device. Gandhi discloses in paragraph [0028] that the cluster master may authenticate the requesting mobile device by verifying that the mobile device belongs to a contact list, by requesting the user to provide a security code, or through other handshaking protocol. Gandhi discloses that after the mobile device is authenticated, the cluster master may update the cluster database to include information on the mobile device such as its IP address, phone number, device/user identity. Regarding claim 38: The method as claimed in claim 35, the method comprising: automatically joining the cluster when the wireless device moves into a geographical area served by the cluster or moves into a part of the network served by the cluster. As explained in paragraph [0028], Gandhi discloses setting up a cluster in a home Wi-Fi network and that the wireless device is authenticated before allowing it to join the cluster. Thus, the wireless device is automatically join to the cluster when it moves into the geographical area served by the cluster (i.e. home Wi-Fi network). Gandhi discloses in paragraph [0030] that if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact listed of trusted users. Thus, in this method, the wireless device is automatically allowed since no action is needed to be performed by the user of the wireless device when they move to the geographical area serviced by the Wi-Fi network of the cluster. Regarding claim 60: A wireless device, comprising: Gandhi is directed to a method to configure mobile devices to work in a mobile cluster and to collaboratively leverage applications resident on the cluster of mobile devices. Gandhi discloses that the configuration and management of the cluster is through a cluster master. See the abstract and Figures 2-3. processing circuitry configured to: cause the wireless device to automatically joining a cluster of worker nodes as a worker node if an entity allows the wireless device to join the cluster of worker nodes, the cluster of worker nodes being controllable by a master node and Gandhi discloses an apparatus includes a processor. See also paragraph [0017] which explains that the mobile devices includes processing circuitry. Gandhi discloses in paragraph [0028] that a cluster master receive a request from a mobile device to join a cluster. As further set forth in paragraph [0028] the cluster master may authenticate the requesting mobile device by verifying that the mobile device belongs to a contact list, by requesting the user to provide a security code, or through other handshaking protocol. Gandhi discloses that after the mobile device is authenticated, the cluster master may update the cluster database to include information on the mobile device such as its IP address, phone number, device/user identity. Therefore, the mobile device (wireless device) is automatically allowed by the master if they are authorized to join the cluster. Gandhi discloses in paragraph [0030] that if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact listed of trusted users. Thus, in this method, the wireless device is automatically allowed since no action is needed to be performed by the user of the wireless device. the worker nodes are responsible for providing a computational resource in a network; and Gandhi, discloses in paragraphs [0027-0028 and 0033] that a cluster master can request that the mobile device collaborate on applications or shared device functionalities. See paragraph [0019] which discloses that the cluster master may distribute processing of the application among cluster members. See also paragraphs [0025 and 0036]. the entity allowing the wireless device to join the cluster if the wireless device is authorised to join the cluster, the wireless device being authorised to join the cluster if the wireless device is registered to one or both of an owner of the master node and a cluster of worker nodes. Gandhi discloses an apparatus includes a processor. See also paragraph [0017] which explains that the mobile devices includes processing circuitry. Gandhi discloses in paragraph [0028] that a cluster master receive a request from a mobile device to join a cluster. As further set forth in paragraph [0028] the cluster master may authenticate the requesting mobile device by verifying that the mobile device belongs to a contact list, by requesting the user to provide a security code, or through other handshaking protocol. Gandhi discloses that after the mobile device is authenticated, the cluster master may update the cluster database to include information on the mobile device such as its IP address, phone number, device/user identity. Therefore, the mobile device (wireless device) is automatically allowed by the master if they are authorized to join the cluster. Gandhi discloses in paragraph [0030] that if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact listed of trusted users. Thus, in this method, the wireless device is automatically allowed since no action is needed to be performed by the user of the wireless device. Gandhi discloses in paragraph [0030] that if the mobile device is connected to the local WiFi, it may be authenticated by simply verifying that the mobile device is on a contact list of trusted users. In addition, Gandhi discloses “[t]he cluster master may search through the cluster database to determine if the mobile device is a cluster member by looking for unique identifier, such as an IP address, phone number, or other device/user identifier associated with the mobile device.”). See also paragraph [0028] 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. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gandhi. Regarding claim 4: The method as claimed in claim 1, the method comprising: automatically disallowing the wireless device from joining the cluster as a worker node if the wireless device is not authorised to join the cluster; and wherein the wireless device is not authorised to join the cluster if the wireless device is not registered to an owner of the master node and the cluster of worker nodes. As set forth in paragraph [0028], in order to accept a request for a new mobile device, the cluster master authenticates the requesting mobile device by verifying that the mobile device belongs to a contact list or requesting the user to provide a security code, or through other handshaking protocol. Therefore, the Examiner finds that it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to understand that a new mobile device would not be allowed to join the cluster if the device is not authorized/authenticated or not on the contact list (thus not registered). The Examiner notes that if the mobile device is not on a contact list then it is not registered to an owner of the mobile device. This Examiner further finds that it would be obvious to a person of ordinary skill in the art to disallow the wireless device since Gandhi specifically discloses of providing security in both a WiFi network and the Internet communications. Thus, disallowing a device would have been predictable to a person of ordinary skill in the art based on Gandhi teaching of authenticating the requesting devices and only allowing devices which have been authenticated. Claim(s) 7, 9, 10, 39 and 42 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gandhi in view of Wang et al. US Patent Pub. 2020/0366474. Regarding claims 7 and 39: Claim 7: The method as claimed in claim 1, wherein: the wireless device is authorised to join the cluster if the wireless device has a public key that corresponds to a private key of the master node. Claim 39: The method as claimed in claim 35, wherein: the wireless device is authorised to join the cluster if the wireless device has a public key that corresponds to a private key of the master node. Gandhi does not specifically disclose of authorization based on whether the wireless device has a public key that corresponds to a private key of the master node. Nonetheless, Wang discloses in paragraph [0317] that each terminal has its own public/private key pair. Wang explains that a private key is based on a user ID and a master private key. In paragraph [0027], Wang explains that the public key is of the second terminal (see also paragraph [0031]). In paragraph [0034], the first terminal is the master node and the second terminal is the slave node. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use public and private keys as disclosed by Wang. The Examiner notes that Gandhi discloses of the importance of authenticating the devices as well as providing a more secure authentication. See paragraph [0028] of Gandhi which discloses that other methods can be used. Wang, which is also directed to having a terminal send a join request to a master terminal, disclose of providing a secure communication in which private/public keys are exchanged. As explain in paragraph [0664], this would improve a trust degree and security of the network elements in the group. Wang explains that private keys can prevent communication information between groups from being stolen. See paragraph [0255]. Regarding claim 9: The method as claimed in claim 7, the method comprising: acquiring the private key from a memory of the master node; and Wang in paragraph [0569] discloses that the shared key (includes private key) is stored in the first terminal (i.e. master device). See also paragraph [0612]. See also paragraph [01229] which explains that the first terminal includes a memory. acquiring the private key from a node that is separate from the master node and worker nodes. Wang discloses that the private key can be acquired from an IKMS entity which is separate from the master and slave devices. See paragraphs [0019 and 0086-0089]. As set forth above, 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 Gandhi by including private/public keys for security reasons. Regarding claims 10 and 42: Claim 10: The method as claimed in claim 9, wherein: acquiring the private key from the node that is separate from the master node and worker nodes comprises: initiating transmission of a request for the private key towards the node that is separate from the master node and worker nodes; and receiving a response from the node that is separate from the master node and worker nodes, wherein the response comprises the private key. Claim 42: The method as claimed in claim 35, the method comprising: initiating transmission of a request for the public key towards the entity; and receiving the public key from the entity in response to the request. As set forth in paragraph [0317], Wang discloses the private key of the terminal is generated by a private key generation center (KGC) (node that is separate from the master node and worker nodes). As explained in paragraph [0319], a terminal can apply to the KGC for a private key and the KGC generated the private key for the terminal. As set forth above, 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 Gandhi by including private/public keys for security reasons. Claim(s) 8 and 40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gandhi in view of Wang and further in view of Matson et al. US Patent Pub. 2014/01372418. Regarding claims 8 and 40: Claim 8: The method as claimed in claim 7, wherein one or both: one or both of the public key and the private key are set by the owner of the one or both of the master node and the cluster of worker nodes; and one or both of the public key and the private key are modifiable by the owner of the one or both of the master node and the cluster of worker nodes. Claim 40: The method as claimed in claim 39, wherein one or both: one or both of the public key and the private key are set by the owner of the one or both of the master node and the cluster of worker nodes; and one or both of the public key and the private key are modifiable by the owner of the one or both of the master node and the cluster of worker nodes. As set forth above, Gandhi in view of Wang discloses the use of both public and private keys. In addition, Wang discloses that the private keys are based on the email addresses or telephone numbers (see paragraph [0317] and thus are set by the owner of either the master (first terminal) or worker (second/slave terminal). The Examiner notes that since addresses may change, it would have been obvious to a person of ordinary skill in the art that the public/private keys can be modifiable by the owners of the devices. Nonetheless, to the extent it is considered that the keys are not modifiable, the Examiner finds that it would have been obvious to a person of ordinary skill in the art to have the keys modifiable by the owner of the device. As explained by Matson it was known to generate new public/private key pairs and to discard old private/public key pairs. See paragraph [0046]. The Examiner notes that Matson explains that using old credentials can lead to being denied access to data (see paragraph [0002]). As explained in paragraph [0046], credentials can be set to expire and thus, by allowing public/private keys to be modifiable, this would enhance security. Therefore, 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 private/public keys. The Examiner finds that Gandhi in combination with Wang both disclose of providing a secure communication and exchange of data as well as the use of private/public keys. In addition, Matson likewise discloses that it was known to modify private/public keys in order to ensure that the credentials are updated frequently in order to provide old credentials from being used. The Examiner finds that a person of ordinary skill in the art would understand that this would lead to increase security between the terminals since it will allow the keys to be frequently updated and changed. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to OVIDIO ESCALANTE whose telephone number is (571)272-7537. The examiner can normally be reached on Monday to Friday from 6:00 AM to 3:00PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Michael Fuelling, can be reached at telephone number (571)272-7537. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice. /Ovidio Escalante/ Primary Examiner, Art Unit 3992 1 The Examiner maintains that the claims recite contingent limitations. In accordance with MPEP 2111.04 which recites, “The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met.” The Examiner notes that claim 1 includes two “if statements” and therefore, if the wireless device is not authorized, then the limitations set forth in the claim need not be performed. In addition, the Examiner finds that each of the method claims 1, 3, 4, 6, 7, 35, 37, and 39 recite contingent limitations. In addition as per claims 33 and 60, see MPEP 2111.04 with respect to contingent limitations.
Read full office action

Prosecution Timeline

Mar 21, 2024
Application Filed
Feb 11, 2026
Non-Final Rejection — §102, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent RE50803
DEVICES FOR ENHANCING TRANSMISSIONS OF STIMULI IN AUDITORY PROSTHESES
2y 5m to grant Granted Feb 17, 2026
Patent RE50766
SEMICONDUCTOR MEMORY DEVICE
2y 5m to grant Granted Jan 27, 2026
Patent RE50738
APPARATUS AND METHOD FOR GENERATING A BANDWIDTH EXTENDED SIGNAL
2y 5m to grant Granted Jan 06, 2026
Patent RE50739
APPARATUS AND METHOD FOR GENERATING A BANDWIDTH EXTENDED SIGNAL
2y 5m to grant Granted Jan 06, 2026
Patent RE50740
APPARATUS AND METHOD FOR GENERATING A BANDWIDTH EXTENDED SIGNAL
2y 5m to grant Granted Jan 06, 2026
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
73%
Grant Probability
83%
With Interview (+9.6%)
2y 8m
Median Time to Grant
Low
PTA Risk
Based on 205 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