DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to Applicant’s communication filed on 10/10/2024. Claims 1-20 have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/10/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1,2,4-7,9-11,13,15-18,20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1,3-6,8-9,11,14,19-20 of. patent No.US 12,132,701 .
Although the conflicting claims are not identical, they are not patentably distinct from each other because claims 1,2,4-7,9-11,13,15-18,20 are anticipated by claims 1,3-6,8-9,11,14,19-20 of. patent No.US 12,132,701.
Claims 1,3-6,8-9,11,14,19-20 of the patent No.US 12,132,701 as shown in the table below contains every element of claims 1,2,4-7,9-11,13,15-18,20 of the instant application and as such anticipates claims 1,2,4-7,9-11,13,15-18,20 of the instant application.
Claims 1-20 of Instant application
Claims 1-20 of patent No.US 12,132,701
Claims 1,10,16
A method/non transitory medium/network device… executable by a network device, the method comprising:
processing unit; and a non-transitory machine-readable medium storing instructions that when executed by the processing unit cause the at least one processing unit to:
receiving from a client device a multicast domain name system (mDNS) request for available services in a network filtered on a tagged attribute, wherein the client device belongs to a particular layer 2 (L2) domain;
in response to receiving the mDNS request, querying a storage of the network device configured to store service records to determine a set of service records in a set of available services with a value for the tagged attribute that matches a tagged value specified in the mDNS request, wherein the set of available services is provided in a L2 domain different from the particular L2 domain;
generating a response that includes the set of available services; and
sending the response to the client device.
Claims 1,9,14,
A method/non transitory and network device executable by a first network device, the method comprising:
processing unit; and a non-transitory machine-readable medium storing instructions that when executed by the processing unit cause the at least one processing unit to:
receiving from a client device a first multicast domain name system (mDNS) request for available services in a network filtered on a tagged attribute, wherein the client device belongs to a first layer 2 (L2) domain;
in response to receiving the first mDNS request, querying a first storage of the first network device for a first set of service records of a first set of available services with a value for the tagged attribute that matches a tagged value specified in the first mDNS request, wherein the first storage comprises the first set of service records of the first set of available services, wherein the first set of available services is provided in a second L2 domain different from the first L2 domain;
generating a first response that includes the first set of available services; sending the first response to the client device ……..
Claims 2,11,17
wherein the network device is a first network device, wherein the response is a first response, the method further comprising: forwarding the mDNS request to a second network device; receiving, from the second network device, a second response that includes a second set of available services provided in L2 domains managed by the second device; and forwarding the second response to the client device.
Claims 1 ,9,14
A method executable by a first network device, the method comprising: generating a first response…..forwarding the first mDNS request to a second network device,……receiving a second response from the second network device, …storage, wherein the second response includes the second set of available services provided in the third L2 domain; and forwarding the second response to the client device,
Claim 3,
wherein the network device is a first network device, wherein the mDNS request is a first mDNS request, wherein the set of available services is a first set of available services, the method further comprising: receiving, from a second network device, a second mDNS request for services available in the network; in response to receiving the second mDNS request, querying the storage of the network device to determine a second set of available services; generating a response that includes the second set of available services; and sending the response to the second network device.
Claim12,
wherein the network device is a first network device, wherein the request is a first request, wherein the set of available services is a first set of available services, wherein the program further comprises instructions for: receiving, from a second network device, a second request for services available in the network; in response to receiving the second request, determining a second set of available services; generating a response that includes the second set of available services; and sending the response to the second network device
Claims 1.9
A method/non- transitory ….first network device, the method comprising: generating a first response…..forwarding the first mDNS request to a second network
Claims 2, 10
receiving, from a third network device, a second mDNS request for available services in the network; in response to receiving the second mDNS request, querying the first storage of the first network device; generating a third response that includes the third set of available services; and sending the third response to the third network device.
Claim 4,13
receiving, from a service provider, a service announcement comprising information associated with a service provided by the service provider; and
in response to receiving the service announcement, storing a service record in the storage, the service record comprising the information associated with the service provided by the service provider.
Claims 3,11
receiving, from a service provider, a service announcement comprising information associated with a service provided by the service provider; and
in response to receiving the service announcement, storing a service record in the first storage of the first network device, the service record comprising the information associated with the service provided by the service provider.
Claim 5,
periodically sending the service provider a request for available services.
Claims 4,
… periodically sending the service provider a service request for available services..
Claims 6,18
wherein the service record further comprises a time to live value, wherein storing the service record in the storage comprises setting the time to live value to a first defined value.
Claims 5,16
wherein the service record further comprises a time to live value, wherein storing the service record in the first storage of the first network device comprises setting the time to live value to a first defined value.
Claims 7,20
wherein the response is a first response, the method further comprising: receiving, from the service provider, a second response to the request; and in response to receiving the second response, resetting the time to live value of the service record to a second defined value.
Claims 1,14
generating a first response
Claims 6,20
receiving, from the service provider, a second response to the service request; and in response to receiving the second response, resetting the time to live value of the service record to a second defined value.
Claims 8,19
wherein each service record stored in the storage comprises metadata associated with a particular service provider, wherein querying the storage of the network device configured to store service records to determine the set of available services comprises applying the tagged value in the mDNS request on the metadata of each service record stored in the storage.
Claim 14
wherein each service record stored in the storage comprises metadata associated with a particular service provider, wherein determining the set of service records in the set of available services comprises applying the tagged value in the request on the metadata of each service record stored in the storage.
Claims 7,12, 18
wherein each service record stored in the first storage of the first network device comprises metadata associated with a particular service provider, wherein the first mDNS request includes a filter, wherein querying the first storage of the first network device comprises applying the filter on the metadata of each service record stored in the first storage of the first network device.
Claims 9, 15
wherein the metadata associated with the particular service provider in each service record comprises a geographical location attribute for storing a location of the service provider.
Claims 8,19
wherein the metadata associated with the particular service provider in each service record comprises a geographical location attribute for storing a location of the service provider.
Claims 3,12 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 2,10 of. patent No.US 12,132,701 in view of Machikoppa.
With regards to claim 3, the patent No.US 12,132,701 teaches second network device (Claim 2 – Third network device). However, patent No.US 12,132,701 does not explicitly teach querying the storage of the network device to determine a second set of available services; However, Machikoppa teaches querying the storage of the network device to determine a second set of available services (¶0010, ¶0011).
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 teachings of patent No.US 12,132,701 to include the teachings of Machikoppa. The motivation for doing so is to allow the system to provide different services in different VLANs ( Machikoppa – ¶0010, ¶0046-¶0048).
With regards to claim 12, the patent No.US 12,132,701 teaches second network device (Claim 10 – Third network device). However, patent No.US 12,132,701 does not explicitly teach in response to receiving the second request , determining a second set of available services; However, Machikoppa teaches in response to receiving the second request , determining a second set of available services (¶0010, ¶0011).
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 teachings of patent No.US 12,132,701 to include the teachings of Machikoppa. The motivation for doing so is to allow the system to provide different services in different VLANs ( Machikoppa – ¶0010, ¶0046-¶0048).
Claims 8,14,19 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 7,12,18 of. patent No.US 12,132,701 in view of Ishvarchandra.
With regards to claims 8,19, the patent No.US 12,132,701 does not explicitly teach wherein querying the storage of the network device configured to store service records to determine the set of available services comprises applying the tagged value in the mDNS request on the metadata. However, Ishvarchandra teaches wherein querying the storage of the network device configured to store service records to determine the set of available services comprises applying the tagged value in the mDNS request on the metadata (Col.4, lines 30-35, Col.8, lines 20-30).
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 teachings of patent No.US 12,132,701 to include the teachings of Ishvarchandra. The motivation for doing so is to allow the system to determine service instances in First VLAN and second VLAN (Ishvarchandra - Col.4, lines 30-35, Col.8, lines 20-30).
With regards to claim 14, the patent No.US 12,132,701 does not explicitly teach wherein determining the set of service records in the set of available services comprises applying the tagged value in the request. However, Ishvarchandra teaches wherein determining the set of service records in the set of available services comprises applying the tagged value in the request (Col.4, lines 30-35, Col.8, lines 20-30).
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 teachings of patent No.US 12,132,701 to include the teachings of Ishvarchandra. The motivation for doing so is to allow the system to determine service instances in First VLAN and second VLAN (Ishvarchandra - Col.4, lines 30-35, Col.8, lines 20-30).
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.
Claims 3,12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
With regards to claims 3,12, the claim recites “ the response” It is unclear what the response is referring to because claims 3/12 recites “a response” and claims 1/10 which claims 3/12 depends on recites “ a response” . Therefore, the examiner is unable to determine the metes and bounds of the claim language.
Claim Rejections - 35 USC § 102
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.
Claims 1,4,8-10,13-17 are rejected under 35 U.S.C. 102 (a1) as being anticipated by Ishvarchandra et. Patent No. US 9,516,097 B1 ( Ishvarchandra hereinafter)
Regarding claim 1,
Ishvarchandra teaches a method executable by a network device, the method comprising:
receiving from a client device a multicast domain name system (mDNS) request for available services in a network filtered on a tagged attribute, wherein the client device belongs to a particular layer 2 (L2) domain (Col.4, lines 35 – 50 - When a mDNS service query from a wireless client is received by the WLC, the WLC knows the access point MAC address where the query requestor is associated. The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physically located nearby – Col. 5,lines 5-20 - the WLC filters the service providers based on location - the technique provides the network services information to the device in a location tag format comprising data representative
of a service name and data representative of a service location - Col.6, lines 20-30 - the client device 170 is associated with the first VLAN 160 and queries the first access point 130 for network service instance information);
in response to receiving the mDNS request, querying a storage of the network device configured to store service records to determine a set of service records in a set of available services with a value for the tagged attribute that matches a tagged value specified in the mDNS request (Col.4, lines 35 – 50 - When a mDNS service query from a wireless client is received by the WLC, the WLC knows the access point MAC address where the query requestor is associated. The WLC maintains Radio Resource Management (RRM) proximity group data. The WLC searches the RRM database to find the neighbor access points of the querying client. The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physically located nearby. The controller 110 provides location aware service discovery and broadcast support wherein, responsive to the query, the controller provides service instance data representative of the first set 150 of services of the first access point 130 on the first VLAN 160 as well as service instance data representative of the second set 152 of services of the second access point 132 on the second VLAN 162 different than the first VLAN 160);
generating a response that includes the set of available services; and sending the response to the client device (Col. 4, lines 40-45 - sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physicallyCol.5,lines 5-10 - the WLC filters the service providers based on location. the WLC prioritizes the nearby service providers and then sends them first in the response followed by the service providers who are located far away from the querying client device. – Col.12, lines 20 -25 -- The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physical located nearby).
Regarding claim 4,
Ishvarchandra further teaches
receiving, from a service provider, a service announcement comprising information associated with a service provided by the service provider; and in response to receiving the service announcement, storing a service record in the storage, the service record comprising the information associated with the service provided by the service provider (Col.3, lines 45-55 - the location-
aware servicing of client device queries are provided in at least two logical phases including a Discovery Phase for finding the locations of the service instances including for example service providers across one or more VLANs, and caching the service information in a memory at a gateway device along with data representative of the location of the services, and an Advertisement Phase for advertising the services in such a way that the one or more client devices can see the list of services together with the locations of the service providers – Col. 10, lines 10-20 - the gateway logic 310 is operable to receive location data representative of a location of the second access point, and to receive service instance name data representative of a name of one or more service instances comprising the second service instance set 152 local to the second access point 132 on the second VLAN 162. Data representative of the location data and the service instance name data is stored in the database 124 coupled with the enterprise network controller 110)
Regarding claim 8,
Ishvarchandra further teaches
wherein each service record stored in the storage comprises metadata associated with a particular service provider, wherein querying the storage of the network device configured to store service records to determine the set of available services comprises applying the tagged value in the mDNS request on the metadata of each service record stored in the storage (Col. 4, lines 30-35 - the locations of wireless service instances are detected. In accordance with an embodiment, when a service provider is a wireless client, the WLC knows the access point wherein the service provider client is attached. All the mDNS advertisements received at the WLC are then tagged with the MAC address of the access point where the service provider is attached – Col.8, lines 20-30 - A network service instance 150 on the first VLAN 160 is selectively reported to the querying client device 170 on a second VLAN 162 in accordance with a physical proximity of the client device relative to the network elements 130, 132, 138 at the first location 140. Similarly, network service instances on a second VLAN 162 are selectively reported to the querying client device on a first VLAN 160 in accordance with a physical proximity of the client device 170 relative to the network elements 134, 136 – Col. 12, lines 20-25 - The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physical located nearby see Also Col. 4, lines 35-43).
Regarding claim 9,
Ishvarchandra further teaches
metadata associated with the particular service provider in each service record comprises a geographical location attribute for storing a location of the service provider (Col.3, lines 48-55 - caching the service information in a memory at a gateway device along with data representative of the location of the 50 services, and an Advertisement Phase for advertising the services in such a way that the one or more client devices can see the list of services together with the locations of the service providers – Col.4, lines 55-70 - if an Apple™ television named "cisco-tv" is located in a conference room on the 6th floor in building 2 and the nearby access point is wired with the Apple™ television and configured with the location field as "ConfI-6thFloorBLDG2" then the WLC uses this information and tags the query response with the Apple television service name. The WLC searches the RRM database to find the neighbor access points of the querying client. The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physically).
Regarding claim 10,
Ishvarchandra teaches a non-transitory machine-readable medium storing a program executable by at least one processing unit of a network device, the program comprising instructions for:
receiving from a client device a multicast domain name system (mDNS) request for available services in a network filtered on a tagged attribute, wherein the client device belongs to a particular layer 2 (L2) domain (Col.4, lines 35 – 50 - When a mDNS service query from a wireless client is received by the WLC, the WLC knows the access point MAC address where the query requestor is associated. The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physically located nearby – Col. 5,lines 5-20 - the WLC filters the service providers based on location - the technique provides the network services information to the device in a location tag format comprising data representative
of a service name and data representative of a service location - Col.6, lines 20-30 - the client device 170 is associated with the first VLAN 160 and queries the first access point 130 for network service instance information);
in response to receiving the mDNS request, querying a storage of the network device configured to store service records to determine a set of service records in a set of available services with a value for the tagged attribute that matches a tagged value specified in the mDNS request (Col.4, lines 35 – 50 - When a mDNS service query from a wireless client is received by the WLC, the WLC knows the access point MAC address where the query requestor is associated. The WLC maintains Radio Resource Management (RRM) proximity group data. The WLC searches the RRM database to find the neighbor access points of the querying client. The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physically located nearby. The controller 110 provides location aware service discovery and broadcast support wherein, responsive to the query, the controller provides service instance data representative of the first set 150 of services of the first access point 130 on the first VLAN 160 as well as service instance data representative of the second set 152 of services of the second access point 132 on the second VLAN 162 different than the first VLAN 160);
generating a response that includes the set of available services; and sending the response to the client device (Col. 4, lines 40-45 - sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physicallyCol.5,lines 5-10 - the WLC filters the service providers based on location. the WLC prioritizes the nearby service providers and then sends them first in the response followed by the service providers who are located far away from the querying client device. – Col.12, lines 20 -25 -- The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physical located nearby).
Regarding claim 13,
Ishvarchandra further teaches
receiving, from a service provider, a service announcement comprising information associated with a service provided by the service provider; and in response to receiving the service announcement, storing a service record in the storage, the service record comprising the information associated with the service provided by the service provider (Col.3, lines 45-55 - the location-
aware servicing of client device queries are provided in at least two logical phases including a Discovery Phase for finding the locations of the service instances including for example service providers across one or more VLANs, and caching the service information in a memory at a gateway device along with data representative of the location of the services, and an Advertisement Phase for advertising the services in such a way that the one or more client devices can see the list of services together with the locations of the service providers – Col. 10, lines 10-20 - the gateway logic 310 is operable to receive location data representative of a location of the second access point, and to receive service instance name data representative of a name of one or more service instances comprising the second service instance set 152 local to the second access point 132 on the second VLAN 162. Data representative of the location data and the service instance name data is stored in the database 124 coupled with the enterprise network controller 110).
Regarding claim 14,
Ishvarchandra further teaches
wherein each service record stored in the storage comprises metadata associated with a particular service provider, wherein determining the set of service records in the set of available services comprises applying the tagged value in the request on the metadata of each service record stored in the storage (Col. 4, lines 30-35 - the locations of wireless service instances are detected. In accordance with an embodiment, when a service provider is a wireless client, the WLC knows the access point wherein the service provider client is attached. All the mDNS advertisements received at the WLC are then tagged with the MAC address of the access point where the service provider is attached – Col.8, lines 20-30 - A network service instance 150 on the first VLAN 160 is selectively reported to the querying client device 170 on a second VLAN 162 in accordance with a physical proximity of the client device relative to the network elements 130, 132, 138 at the first location 140. Similarly, network service instances on a second VLAN 162 are selectively reported to the querying client device on a first VLAN 160 in accordance with a physical proximity of the client device 170 relative to the network elements 134, 136 – Col. 12, lines 20-25 - The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physical located nearby see Also Col. 4, lines 35-43).
Regarding claim 15,
Ishvarchandra further teaches
metadata associated with the particular service provider in each service record comprises a geographical location attribute for storing a location of the service provider. (Col.3, lines 48-55 - caching the service information in a memory at a gateway device along with data representative of the location of the 50 services, and an Advertisement Phase for advertising the services in such a way that the one or more client devices can see the list of services together with the locations of the service providers – Col.4, lines 55-70 - if an Apple™ television named "cisco-tv" is located in a conference room on the 6th floor in building 2 and the nearby access point is wired with the Apple™ television and configured with the location field as "ConfI-6thFloorBLDG2" then the WLC uses this information and tags the query response with the Apple television service name. The WLC searches the RRM database to find the neighbor access points of the querying client. The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physically).
Regarding claim 16,
Ishvarchandra teaches network device comprising: a processing unit; and a non-transitory machine-readable medium storing instructions that when executed by the processing unit cause the at least one processing unit (Fig.1,Fig.4), to:
upon receiving from a client device a multicast domain name system (mDNS) request for available services in a network filtered on a tagged attribute, wherein the client device belongs to a particular layer 2 (L2) domain (Col.4, lines 35 – 50 - When a mDNS service query from a wireless client is received by the WLC, the WLC knows the access point MAC address where the query requestor is associated. The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physically located nearby – Col. 5,lines 5-20 - the WLC filters the service providers based on location - the technique provides the network services information to the device in a location tag format comprising data representative
of a service name and data representative of a service location - Col.6, lines 20-30 - the client device 170 is associated with the first VLAN 160 and queries the first access point 130 for network service instance information);
querying a storage of the network device configured to store service records to determine a set of service records in a set of available services with a value for the tagged attribute that matches a tagged value specified in the mDNS request (Col.4, lines 35 – 50 - When a mDNS service query from a wireless client is received by the WLC, the WLC knows the access point MAC address where the query requestor is associated. The WLC maintains Radio Resource Management (RRM) proximity group data. The WLC searches the RRM database to find the neighbor access points of the querying client. The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physically located nearby. The controller 110 provides location aware service discovery and broadcast support wherein, responsive to the query, the controller provides service instance data representative of the first set 150 of services of the first access point 130 on the first VLAN 160 as well as service instance data representative of the second set 152 of services of the second access point 132 on the second VLAN 162 different than the first VLAN 160);
generating a response that includes the set of available services; and sending the response to the client device (Col. 4, lines 40-45 - sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physicallyCol.5,lines 5-10 - the WLC filters the service providers based on location. the WLC prioritizes the nearby service providers and then sends them first in the response followed by the service providers who are located far away from the querying client device. – Col.12, lines 20 -25 -- The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physical located nearby).
Regarding claim 17,
Ishvarchandra further teaches
receive, from a service provider, a service announcement comprising information associated with a service provided by the service provider; and in response to receiving the service announcement, store a service record in the storage, the service record comprising the information associated with the service provided by the service provider (Col.3, lines 45-55 - the location-
aware servicing of client device queries are provided in at least two logical phases including a Discovery Phase for finding the locations of the service instances including for example service providers across one or more VLANs, and caching the service information in a memory at a gateway device along with data representative of the location of the services, and an Advertisement Phase for advertising the services in such a way that the one or more client devices can see the list of services together with the locations of the service providers – Col. 10, lines 10-20 - the gateway logic 310 is operable to receive location data representative of a location of the second access point, and to receive service instance name data representative of a name of one or more service instances comprising the second service instance set 152 local to the second access point 132 on the second VLAN 162. Data representative of the location data and the service instance name data is stored in the database 124 coupled with the enterprise network controller 110).
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.
Claims 2,3,11,12,18,19 are rejected under 35 U.S.C. 103 as being unpatentable over Ishvarchandra in view of Machikoppa et al. Publication No.US 2021/0392192 A1 ( Machikoppa hereinafter)
Regarding claim 2,
Ishvarchandra further teaches wherein the network device is a first network device, wherein the response is a first response (Col. 4, lines 35-50 ). However, Ishvarchandra does not explicitly teach
forwarding the mDNS request to a second network device; receiving, from the second network device, a second response that includes a second set of available services provided in L2 domains managed by the second device; and forwarding the second response to the client device.
However, Machikoppa
forwarding the mDNS request to a second network device (¶ 0011- A service discovery request received by a network device may be forwarded to the WLAN controller);
receiving, from the second network device, a second response that includes a second set of available services provided in L2 domains managed by the second device, forwarding the second response to the client device (¶ 0011 -A service discovery request received by a network device may be forwarded to the WLAN controller. The WLAN controller may check its database of service advertisements to find a service matching the service discovery request and based on the match, may direct the discovery request to a network device connected to a host device hosting the matching service ; and ¶ 0048 - the neighbor network
device 220-3 may send information relating to the subset of records to the client device 230. The information relating to the subset of record may be sent as response packets to the service discovery request).
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 teachings of Ishvarchandra to include the teachings of Machikoppa. The motivation for doing so is to allow the system to provide different services in different VLANs ( Machikoppa – ¶ 0010, ¶ 0046-¶ 0048).
Regarding claim 3,
Ishvarchandra further teaches wherein the network device is a first network device, wherein the mDNS request is a first mDNS request, wherein the set of available services is a first set of available services (Co.4,lines 35-50).
However, Ishvarchandra does not explicitly teach
receiving, from a second network device, a second mDNS request for services available in the network; in response to receiving the second mDNS request, querying the storage of the network device to determine a second set of available services; generating a response that includes the second set of available services; and sending the response to the second network device.
However, Machikoppa
receiving, from a second network device, a second mDNS request for services available in the network (¶ 0011 - A service discovery request received by a network device may be forwarded to the WLAN controller – ¶ 0010 - network device receiving a service discovery request from a client device, may communicate the service discovery request to other network devices in the swarm);
in response to receiving the second mDNS request, querying the storage of the network device to determine a second set of available services; generating a response that includes the second set of available services; and sending the response to the second network device (¶ 0011 – The WLAN controller may check its database of service advertisements to find a service matching the service discovery request and based on the match, may direct the discovery request to a network device connected to a host device hosting the matching service – ¶ 0010 – in response to receiving the broadcasted service discovery request, may check with respective lists of service advertisements to identify a service matching the service discovery request – ¶ 0060 - receiving, by a neighbor network device, a service discovery request from a client device, determining a subset of the records that match the service discovery request, and sending information relating to the subset of records to the client device.).
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 teachings of Ishvarchandra to include the teachings of Machikoppa. The motivation for doing so is to allow the system to provide different services in different VLANs ( Machikoppa – ¶ 0010, ¶ 0046-¶ 0048).
Regarding claim 11,
Ishvarchandra further teaches wherein the network device is a first network device, wherein the response is a first response (Col. 4, lines 35-50 ). However, Ishvarchandra does not explicitly teach
forwarding the mDNS request to a second network device; receiving, from the second network device, a second response that includes a second set of available services provided in L2 domains managed by the second device; and forwarding the second response to the client device.
However, Machikoppa
forwarding the mDNS request to a second network device (¶ 0011- A service discovery request received by a network device may be forwarded to the WLAN controller);
receiving, from the second network device, a second response that includes a second set of available services provided in L2 domains managed by the second device, forwarding the second response to the client device (¶ 0011 -A service discovery request received by a network device may be forwarded to the WLAN controller. The WLAN controller may check its database of service advertisements to find a service matching the service discovery request and based on the match, may direct the discovery request to a network device connected to a host device hosting the matching service ; and ¶ 0048 - the neighbor network
device 220-3 may send information relating to the subset of records to the client device 230. The information relating to the subset of record may be sent as response packets to the service discovery request).
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 teachings of Ishvarchandra to include the teachings of Machikoppa. The motivation for doing so is to allow the system to provide different services in different VLANs ( Machikoppa – ¶ 0010, ¶ 0046-¶ 0048).
Regarding claim 12,
Ishvarchandra further teaches wherein the network device is a first network device, wherein the mDNS request is a first mDNS request, wherein the set of available services is a first set of available services (Co.4,lines 35-50).
However, Ishvarchandra does not explicitly teach
wherein the program further comprises instructions for: receiving, from a second network device, a second request for services available in the network; in response to receiving the second request, determining a second set of available services; generating a response that includes the second set of available services; and sending the response to the second network device..
However, Machikoppa
wherein the program further comprises instructions for: receiving, from a second network device, a second mDNS request for services available in the network (¶ 0011 - A service discovery request received by a network device may be forwarded to the WLAN controller – ¶ 0010 - network device receiving a service discovery request from a client device, may communicate the service discovery request to other network devices in the swarm);
in response to receiving the second mDNS request, querying the storage of the network device to determine a second set of available services; generating a response that includes the second set of available services; and sending the response to the second network device (¶ 0011 – The WLAN controller may check its database of service advertisements to find a service matching the service discovery request and based on the match, may direct the discovery request to a network device connected to a host device hosting the matching service – ¶ 0010 – in response to receiving the broadcasted service discovery request, may check with respective lists of service advertisements to identify a service matching the service discovery request – ¶ 0060 - receiving, by a neighbor network device, a service discovery request from a client device, determining a subset of the records that match the service discovery request, and sending information relating to the subset of records to the client device.).
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 teachings of Ishvarchandra to include the teachings of Machikoppa. The motivation for doing so is to allow the system to provide different services in different VLANs ( Machikoppa – ¶ 0010, ¶ 0046-¶ 0048).
Regarding claim 18,
Ishvarchandra does not explicitly teach
wherein the service record further comprises a time to live value, wherein storing the service record in the storage comprises setting the time to live value to a first defined value.
However, Machikoppa
service record further comprises a time to live value, wherein storing the service record in the storage comprises setting the time to live value to a first defined value (¶ 0024 -The set of records 150 may include information relating to a host name, service name, type of service, service capability information, service expiry information (such as Time to Live (TTL)), class of service ¶ 0018 - CACHE-FLUSH indicating whether outdated cached records shall be purged, RRCLASS in which "IN" indicates Internet and IP networks, TTL indicating a time period for which the RR is valid – ¶ 0049 - host devices 240-1 to 240-3 may provide a new service or may discontinue a service. Also, some services may get expired. Further, a new host device may connect to the network device 220-1 which may start advertising its services to the network device 220-1. Thus, the set of service advertisements 242-1 to 242-3 may be updated over time or new service advertisements may be added to the set. The network device 220-1 may receive an updated set of service advertisements – ¶ 0061 -functionality 400 includes receiving, by the network device and from the set of servers, an updated set of service advertisements. In an example, the service advertisements may be updated with modifications in the features of the services or expiry of certain services – See ¶ 0039).
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 teachings of Ishvarchandra to include the teachings of Machikoppa. The motivation for doing so is to allow the system to provide different services in different VLANs ( Machikoppa – ¶ 0010, ¶ 0046-¶ 0048).
Regarding claim 19,
Ishvarchandra further teaches
wherein each service record stored in the storage comprises metadata associated with a particular service provider, wherein querying the storage of the network device configured to store service records to determine the set of available services comprises applying the tagged value in the mDNS request on the metadata of each service record stored in the storage (Col. 4, lines 30-35 - the locations of wireless service instances are detected. In accordance with an embodiment, when a service provider is a wireless client, the WLC knows the access point wherein the service provider client is attached. All the mDNS advertisements received at the WLC are then tagged with the MAC address of the access point where the service provider is attached – Col.8, lines 20-30 - A network service instance 150 on the first VLAN 160 is selectively reported to the querying client device 170 on a second VLAN 162 in accordance with a physical proximity of the client device relative to the network elements 130, 132, 138 at the first location 140. Similarly, network service instances on a second VLAN 162 are selectively reported to the querying client device on a first VLAN 160 in accordance with a physical proximity of the client device 170 relative to the network elements 134, 136 – Col. 12, lines 20-25 - The WLC then filters the only service providers which are present in the RRM proximity group and sends the mDNS response with those service providers. This ensures that the client sees only those service providers that are physical located nearby see Also Col. 4, lines 35-43).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Ishvarchandra in view of Hirakawa et al. Publication No.US 2020001357 A1 ( Hirakawa hereinafter).
Regarding claim 5,
Ishvarchandra does not explicitly teach
periodically sending the service provider a request for available services.
However, Hirakawa teaches
periodically sending the service provider a request for available services (¶ 0124 - through the Multicast DNS technology, the host computer 101a makes an inquiry to devices existing in the same network about supported services at regular intervals).
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 teachings of Ishvarchandra to include the teachings of Hirakawa. The motivation for doing so is to allow the system to discover services at regular intervals (Hirakawa – ¶ 0124).
Claims 6,7 are rejected under 35 U.S.C. 103 as being unpatentable over Ishvarchandra in view of Hirakawa further in view of Cheshire et al. RFC 6762 –“ Multicast DNS” - February 2013 – (Cheshire hereinafter)
Regarding claim 6,
Ishvarchandra does not explicitly teach
wherein the service record further comprises a time to live value, wherein storing the service record in the storage comprises setting the time to live value to a first defined value.
However, Cheshire teaches
wherein the service record further comprises a time to live value, wherein storing the service record in the storage comprises setting the time to live value to a first defined value (Page 4 - Each resource record also contains a TTL, which is the number of seconds for which the resource record may be cached. This document uses the term "IP TTL" to refer to the IP header TTL (hop limit), and the term "RR TTL" or just "TTL" to refer to the resource record TTL (cache lifetime) – Page 10 - When a Multicast DNS querier receives an answer, the answer contains a TTL value that indicates for how many seconds this answer is valid . After this interval has passed, the answer will no longer be valid and SHOULD be deleted from the cache - The querier should plan to issue a query at 80% of the record lifetime, and then if no answer is received, at 85%, 90%, and 95%. If an answer is received, then the remaining TTL is reset to the value given in the answer, and this process repeats for as long as the Multicast DNS querier has an ongoing interest in the record).
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 teachings of Ishvarchandra to include the teachings of Cheshire. The motivation for doing so is to allow the system to keep updating the TTL of the records as long as they are in use. This will ensure that the active services remain cached and discoverable.
Regarding claim 7,
Ishvarchandra further teaches wherein the response is a first response (Col.5,lines 35-50), However, Ishvarchandra does not explicitly teach
receiving, from the service provider, a second response to the request; and in response to receiving the second response, resetting the time to live value of the service record to a second defined value.
Cheshire teaches
receiving, from the service provider, a second response to the request; and in response to receiving the second response, resetting the time to live value of the service record to a second defined value (Page 4 - Each resource record also contains a TTL, which is the number of seconds for which the resource record may be cached. This document uses the term "IP TTL" to refer to the IP header TTL (hop limit), and the term "RR TTL" or just "TTL" to refer to the resource record TTL (cache lifetime) – Page 10 - When a Multicast DNS querier receives an answer, the answer contains a TTL value that indicates for how many seconds this answer is valid . After this interval has passed, the answer will no longer be valid and SHOULD be deleted from the cache - The querier should plan to issue a query at 80% of the record lifetime, and then if no answer is received, at 85%, 90%, and 95%. If an answer is received, then the remaining TTL is reset to the value given in the answer, and this process repeats for as long as the Multicast DNS querier has an ongoing interest in the record).
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 teachings of Ishvarchandra to include the teachings of Cheshire. The motivation for doing so is to allow the system to keep updating the TTL of the records as long as they are in use. This will ensure that the active services remain cached and discoverable.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Ishvarchandra in view of Machikoppa further in view of Cheshire
Regarding claim 20,
Ishvarchandra further teaches wherein the response is a first response (Col.5,lines 35-50), However, Ishvarchandra does not explicitly teach
receiving, from the service provider, a second response to the request; and in response to receiving the second response, resetting the time to live value of the service record to a second defined value.
Cheshire teaches
receiving, from the service provider, a second response to the request; and in response to receiving the second response, resetting the time to live value of the service record to a second defined value (Page 4 - Each resource record also contains a TTL, which is the number of seconds for which the resource record may be cached. This document uses the term "IP TTL" to refer to the IP header TTL (hop limit), and the term "RR TTL" or just "TTL" to refer to the resource record TTL (cache lifetime) – Page 10 - When a Multicast DNS querier receives an answer, the answer contains a TTL value that indicates for how many seconds this answer is valid . After this interval has passed, the answer will no longer be valid and SHOULD be deleted from the cache - The querier should plan to issue a query at 80% of the record lifetime, and then if no answer is received, at 85%, 90%, and 95%. If an answer is received, then the remaining TTL is reset to the value given in the answer, and this process repeats for as long as the Multicast DNS querier has an ongoing interest in the record).
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 teachings of Ishvarchandra to include the teachings of Cheshire. The motivation for doing so is to allow the system to keep updating the TTL of the records as long as they are in use. This will ensure that the active services remain cached and discoverable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Cisco et al. LSS (location Specific Services ) and mDNS AP - December 24, 2014.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Oscar A Louie can be reached at (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445