DETAILED ACTION
This action is in response to the Applicant’s amendment filed on May 15, 2026. As set forth therein, claims 1, 3, 33, 35, 37, 42 and 60 are amended and claims 2 and 36 are canceled. Claims 1, 3-10, 14, 33, 35, 37-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 .
Response to Arguments
Claim Rejections – 35 U.S.C. § 112
In view of the amendment to claim 42, the Examiner finds that the Applicant has overcome the antecedent basis issue. Therefore, the rejection will be withdrawn.
Claim Rejections – 35 U.S.C. § 102
The Applicant maintains that Ghandhi in paragraph [0030] teaches that the cluster master checks the cluster database for authenticating the mobile device’s request to join a cluster. If they are connected through Wi-Fi, the master node checks if the device is in the trusted user list and if they are connected through the internet, the master performs authentication protocol.
The Applicant states that Gandhi does not teach that the master node checks if the device is register to the owner of the master node or the cluster. The Applicant states that the added features from claim 2 make it clear that an ‘owner’ may be a user, service provider or manager of the master node or the cluster. The Applicant states that although Gandhi teaches that the device may be a user device, Gandhi is silent about the owner-users of the cluster or the owner-user of the master node.
The Examiner first notes that the ‘cluster master’ is described in paragraph [0019] as being mobile device 101 which manages and coordinates the collaboration of applications or the sharing of device functionalities among cluster members. In addition, in paragraph [0035], Gandhi discloses that a user selects a shared application to run on the cluster master in collaboration with its cluster partners. Thus, a ‘user’ specifically uses the cluster master device. In addition, in paragraph [0021], Gandhi discloses than alternative mobile devices can also be the cluster master (in this case, mobile device 102). The Examiner finds that each mobile device in the cluster has a user (see paragraphs [0024] and [0030]).
The Examiner also notes that the mobile devices 101, 102,104, and 105 are described as smartphones, tablet computers, personal digital assistants, notebook computers, laptops or other types of wireless or wired computing devices. Therefore, in the context of Gandhi, each mobile device (in which each one has a user/owner) can be a cluster master as descried by Gandhi (see above teachings with reference to cluster master being 101 or 102).
Thus, Gandhi discloses that an ‘owner’ of the mobile device (master device) is also a user of the mobile device. The Examiner notes that as set forth above, the cluster master manager the cluster (paragraph [0019]).
The Applicant states that the added features from claim 2 make it clear that an ‘owner’ may be a user, service provider or manager of the master node or the cluster. The Applicant states that although Gandhi teaches that the device may be a user device, Gandhi is silent about the owner-users of the cluster or the owner-user of the master node.
The Examiner notes that the added limitations (from previous claim 2) states that the owner of the master node is “a user of the master node” or “a manager of the…cluster of worker nodes”. In this case, the Examiner finds that Gandhi at the very least discloses that the owner of the master node is a user of the master node and further manages the master node and the cluster of worker nodes as set forth in at least paragraph [0019].
In paragraph [0028], Gandhi discloses “ the cluster master may designate the applications or device functionalities for the mobile device to collaborate or share. The cluster master may add the mobile device as a cluster partner to the list of collaborating applications or shared device functionalities maintained in the cluster database.” See also paragraph [0015] which discloses “The cluster master may coordinate the collaboration among the cluster partners.” Thus, Gandhi shows that the master device manages the cluster and the owner of the master node is a user of the master node as well as a person who manages the master node and the cluster of worker nodes.
Therefore, the Examiner does not find the Applicant’s arguments persuasive.
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, 37, 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].
the owner of the one or both of the master node and the cluster of worker nodes being: 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 1, 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]
the owner of the one or both of the master node and the cluster of worker nodes being: 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 35, 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]
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 [0019, 0041, 0044-0046]
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
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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.
Prosecution Insights