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 .
Response to Remarks/Arguments
This Office Action is in response to the communications for the present US application number 17/484,487 last filed on June 04th, 2025.
Claims 1-20 were not amended, and remain pending, directed to MULTI ACCESS POINT-CLOUD CONTROLLER FOR COLLECTING NETWORK STATISTICAL DATA.
Upon further review of the latest response from applicant’s representative, the examiner reviewed the prior remarks, and the latest comments again and respectfully remain unpersuaded.
With respect to the 35 U.S.C. § 103 rejection, using Jana and Rengarajan, and looking at independent claim 1 for discussion purposes, the applicant’s representative appeared to be arguing each reference as a 102 rather than consider them together under a 103 obviousness analysis. The representative argued that the present claim language was not about issuing a command to identify a specific node, out of a plurality, to act as a monitoring node, but rather, the claim was for a cloud controller to send out a command to plurality of nodes. The rep. then singled out some of the citations and argued Jana individually did not teach about a cloud controller, sending out a command, to the plurality of nodes to obtain some requested statistical data. Then, the rep. argued Rengarajan individually, arguing that this secondary reference also failed to discuss of any cloud controller sending a command to a plurality of devices via an Internet Service Provider (ISP).
In response, the Examiner had already explained about the concept of the cloud controller from Jana’s teachings, within the previous Non-Final Rejection remarks section. Nothing from these latest remarks appear to refute or persuade the Examiner otherwise regarding this. Jana is clearly teaching of a separate and distinct entity, which communicates over a network (or cloud), and thus is clearly teaching of a cloud controller. Additionally, if one was to look further at Rengarajan’s teachings, the rep. failed to consider or comment on another cited section and appeared to have only considered exact terms for “cloud controller.” Even if one were to ignore conceptually what was disclosed in Rengarajan’s ¶ 42, ¶¶ 82-83 clearly disclose and use the terms “cloud controller” that can assess and gather statistical data on nodes in a group, over the cloud network. Rengarajan was also relied upon to more explicitly spell out the involvement of a service provider (¶ 42 was cited for this reason, as it explicitly mentions “service provider”).
With respect to what the claim language required, the current language required in part “…send…a command to a plurality of network devices in a network, to provide requested statistical data concerning the network identified in the command…” and “identify one of the plurality of network devices (and later configured) for obtaining the requested statistical data from one or more other network devices…” The Examiner would contend that between these two claimed limitations, at least one of the network devices out of the plurality is tasked with getting the requested statistical data from one more of the other devices, which in other words would mean, the identified network device(s) is acting in a monitoring/gathering role, amongst that plurality. The command is still sent from the user/controller/managing entity, separate from the plurality of network nodes.
Additionally, the rep. further argued that back with Jana, the limitation step of determining at least one device experiencing a problem with obtaining requested statistical data regarding the network was not clearly taught from the cited Jana’s ¶¶ 39-42.
In response, the Examiner would argue that the cited section was not just generally about selecting a monitoring node. For example, the node that’s monitoring the network can also further identify critical nodes, bottlenecking nodes, failed or otherwise non-functional nodes (Jana: ¶ 39). Therefore, this is a perfectly good example of being notified or determining that there’s a problem with one or more nodes and getting whatever the statistical data is supposed to be from that one or more nodes.
Having addressed all the latest argued elements, and without further amendments, the Examiner respectfully remains unpersuaded at this time.
The other independent claims 8 and 15 were similarly amended and argued following claim 11 and thus was similarly rejected under the same rationale.
The remaining dependent claims were not specifically argued at this time.
Applicant's arguments were considered but they were not found persuasive. See the following claim rejections for further clarifications with added emphasis on the points previously disclosed.
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. US 2018/0343200 A1 to Jana et al. (referred to hereafter as “Jana”) in view of U.S. Patent Publication No. US 2017/0272310 A1 to Rengarajan et al. (referred to hereafter as “Rengarajan”).
As to claim 1, Jana further discloses a cloud controller, comprising:
a memory storing computer-readable instructions (¶¶ 60 and 72-73); and
a processor (¶¶ 60 and 72-73) configured to execute the computer-readable instructions to:
send, via a connection to the Internet and an Internet Service Provider (ISP) associated with the network (See further below, after the “wherein” phrasing, regarding the ISP aspect), a command to a plurality of network devices in a network, associated with an access point connected to the Internet, to provide requested statistical data concerning the network identified in the command (Jana discloses of an overall system that can include multiple nodes (110s) distributed within a defined “network” space (112), and a controller (120) is a separate device/system, outside of this defined network 112. The controller can be implemented within various possible systems or devices, such as for example, a mobile phone (amongst a plurality of options as the mobile phone is also interchangeable with other terms – e.g., Jana: ¶¶ 29-30) and this controller can connect to the defined network (112) in various ways, including wireless or wired options (e.g., Jana: Fig. 1 and ¶¶ 30-31). The (cloud/networked) controller is further issuing commands/requests and can identify one or more specific nodes that are suitable to act as monitoring node(s), and periodically reevaluate which node is best suited for performing the monitoring, which is further based on captured messages with related statistics over a given period of time (e.g., Jana: ¶¶ 39 and 41-42). In other words, this request would identify the properties of these nodes, based upon the captured messages with related statistics data, over a given interval or period of time.
Examiner’s Note: The current claim language does not further define what the “requested statistic data” refers to, only that it is somehow related or “concerns the network”), wherein the cloud controller is located outside the network, and wherein the plurality of network devices connect directly, indirectly, or both to the Internet via a connection to the ISP (While Jana does not explicitly mention about any ISPs that bridge or service those connections, Rengarajan more expressly discloses of similar teachings wherein a (cloud) controller can connect to the Internet/network via service provider(s) and communicate further with a plurality of other nodes (e.g., Rengarajan: ¶¶ 42 and 82-83).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the present application, to combine and incorporate Rengarajan’s explicit teachings with the emphasis on utilizing service provider(s), all within Jana’s overall system and teachings, as the service provider would support the network communications between the controller and the plurality of networked nodes, which would cover the range of possibilities between direct and indirect connections, via any other intermediary nodes, to form a connection. Rengarajan’s teachings with the cloud controller also serves to reinforce the idea that a controller can be separate from a collection of network nodes and still operate effectively, given the premise of Jana’s environment (e.g., Rengarajan: ¶¶ 82-83);
determine that at least one of the plurality of network devices experiences a problem with obtaining the requested statistical data concerning the network (Following the above examples and interpretations, the controller node would be getting the statistic data, and that could be referring to or reflective of the plurality of nodes and their statuses, including any problems such as bottlenecks or a failed or non-functional statuses. And, the controller can update the assignments at the next periodic interval, if necessary (e.g., Jana: ¶¶ 39-42));
identify one of the plurality of network devices for obtaining the requested statistical data from one or more other network devices of the plurality of network devices within a first predetermined time period (Following the above examples and interpretations, the controller can periodically identify and set one or more specific node(s) out of the plurality of nodes, to act as the one or more monitoring node(s), and to capture/identify statistical data as it related to the messages received at each of the other nodes in the cluster over a given period of time, e.g., Jana: ¶¶ 41-42, 39, 30-31, and 33);
configure the one of the plurality of network device to obtain the requested statistical data from the one or more other network devices (Following the above steps and interpretations, once again, a most suitable node is identified (periodically) and tasked with the monitoring operation, which can involve gathering the statistics information as it relates to messages received at the other cluster nodes, e.g., Jana: ¶¶ 41-42, 30-31, and 33); and
receive the statistical data from the one of the plurality of network devices (Following the above steps and interpretations, the controller would at the end, get the statistical data (which could be from logs), from the one or more designated monitoring, which can then be further analyzed, and the controller can update any assignments in later periodic time intervals, e.g., Jana: ¶¶ 41-42).
As to claim 2, Jana further discloses the cloud controller of claim 1, wherein the identifying one of the plurality of network devices is repeated as needed to obtain the requested statistical data concerning the network within a second predetermined time period (The process can be performed periodically or repeatedly, which means the second time it occurs would have to be during a “second” time period/interval, e.g., Jana: ¶¶ 33 and 41).
As to claim 3, Jana further discloses the cloud controller of claim 1, wherein the problem experienced by the at least one of the plurality of network device comprises one of a bandwidth limitation, a resource limitation, and a high client load (Following claim 1’s examples and interpretations, a detected critical (bottleneck issue), failed, and/or non-functional node(s) can be problems related to bandwidth or load issues, which can be reported back to the controller and that can affect the monitoring assignments at the periodic intervals, e.g., Jana: ¶¶ 39, 41-42, 52, and 55).
As to claim 4, Jana further discloses the cloud controller of claim 1, wherein the problem comprises a slow response time for receiving the requested statistical data concerning the network (Following claim 1’s examples and interpretations, a delay in transmissions can be a detect-able problem that eventually gets back to the controller and can impact later periodic cycles, e.g., Jana: ¶¶ 32, 41-42, and 53-55).
As to claim 5, Jana further discloses the cloud controller of claim 1, wherein the processor requests that the one of the plurality of network devices cache the requested statistical data for the cloud controller (Following claim 1’s examples and interpretations, in at least one embodiment that identifies and selects the one or more suitable devices can be identified to be the monitoring node(s) (¶ 41), each of these networked monitoring nodes would also have message caches for storage purposes, Jana: ¶¶ 38, 41, and 48).
As to claim 6, Jana further discloses the cloud controller of claim 1, wherein the processor maintains one connection to the network, wherein the one connection is with the one of the plurality of network devices (Following claim 1’s examples and interpretations, in at least one embodiment, the one or more suitable devices can be identified to be the monitoring node(s), and can therefore maintain a connection with some managing element/component/node/device/system, such as a separate gateway and/or controller, e.g., Jana: ¶ 41).
As to claim 7, Jana further discloses the cloud controller of claim I, wherein the processor determines that the problem with the at least one of the plurality of network devices has been resolved, begins communicating with the at least one of the plurality of network devices having the problem resolved to request statistical data concerning the network (Jana discloses of various approaches and examples regarding how “failed” nodes can be identified and diagnosed and then resolved. Following claim 1’s interpretations and examples, it was already established that in one embodiment, the system can identify one or more suitable nodes to act as a monitoring node to obtain from the other network nodes various statistical data. And for this limitation, Jana further disclosed in various example embodiments, suppose that a network node 1001 was identified to have failed relaying messages, where the reason for the failure is highlighted in various different embodiments, but having identified the problem(s), those issues can be further diagnosed and debugged, such as with re-routing around a problematic node, as part of an optimization process. And after fixing the issue(s), the nodes can be part of the mesh again and the system can resume the process of collecting relevant network statistical data from that node again in later cycles (e.g., Jana: ¶¶ 56-57).
Therefore, while Jana does not expressly go into all the details about what the issues are, or use the term “resume” to resume communications, one of ordinary skill in the art, before the effective filing date of the present application, would have found it obvious and have understood that given the various examples, supposing that the issue(s) can be identified and debugged, such as with the critical node issue example, once the issue is resolved, the system can go back and resume communications with monitoring and/or obtaining the necessary data, such as the statistical data from that affected node (e.g., 1001) again after the problem (or traffic load) was resolved (e.g., Jana: ¶¶ 56-57).
As to claims 8-14, see the similar corresponding rejections of claims 1-7 respectively.
As to claim 15, see the similar corresponding rejections of claim 1.
As to claim 16, see the similar corresponding rejections of claim 2, even without the detail of performing the step/process within a “second” predetermined time period, as it inevitably would occur since the process is being repeated at a subsequent “second” time period/interval later.
As to claims 17, 18, 19, and 20 see the similar corresponding rejections of claims 3, 4, 6 and 7 respectively.
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 Xiang Yu whose telephone number is (571)270-5695. The examiner can normally be reached M-F 9:30-3:00 (PST/PDT).
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, Emmanuel Moise can be reached at (571)272-3865. 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.
/X.Y./Examiner, Art Unit 2455
/EMMANUEL L MOISE/Supervisory Patent Examiner, Art Unit 2455