Detailed Action
Claims 1-20 are pending in this application. Claims 1-14 are withdrawn. This is a response to the Restriction Election made on 8/6/25.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 3/27/23 has been considered.
Drawings
The Drawings filed on 3/27/23 are acceptable.
Election/Restriction
Restriction to one of the following inventions is required under 35 U.S.C. 121:
I. Claims 1-14, drawn to connecting physical module to removable modules, classified in H04L29/08.
II. Claims 15-20, drawn to displaying topology of connected physical modules, classified in G06F15/173.
The inventions are independent or distinct, each from the other because:
Inventions I and II are related as subcombinations disclosed as usable together in a single combination. The subcombinations are distinct if they do not overlap in scope and are not obvious variants, and if it is shown that at least one subcombination is separately usable. In the instant case, subcombination II has separate utility such as displaying topology of connected physical modules. See MPEP § 806.05(d).
Applicant’s election without traverse of Group II(claims 15-20) in the reply filed on 8/6/25 is acknowledged. The Restriction requirement is made FINAL.
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 15-20 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.
As per claim 15 recites the limitation " a first physical module physically connected to a plurality of physical modules in a chain configuration, wherein the first module comprises an edge-router ". There is insufficient antecedent basis for this limitation in the claim. It is unclear to whether “the first module” refers back to “a first physical module” or whether “the first module” is a different module from the first physical module.
As per claim 16, recites “the digital bit”. There is insufficient antecedent basis for this limitation in the claim. Unclear to whether applicant meant “digital block” or whether “digital bit” is a different element. In further, it is unclear to what is considered to be a “digital bit”.
All dependent claims are rejected for the same reasons set forth above.
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 15,20 rejected under 35 U.S.C. 103 as being unpatentable over US 10,985,943 issued to Beeson et al.(Beeson) in view of US 2017/0134258 issued to Kumar et al.(Kumar).
As per claim 15, Beeson teaches a system comprising: a first physical module physically connected to a plurality of physical modules in a chain configuration, wherein the first module comprises an edge-router(Fig.1A,1B, col.3, lines 20-49;… Thus, MMI could layer on PCIe, Ethernet, direct serial or parallel connection, or any other suitable connection. Pods 104 and cards 106 can be identical, i.e., multiple instances of the same type of pod 104 or card 106, or can be differing. One or more routers, for the MMI network, can be internal to the server, or external. In some embodiments, each pod 104 or card 106 has a router.); and a remote device electronically communicating with the first physical module via the edge-router, the first physical module and the plurality of physical module connected in the chain configuration with the first physical module(Fig.1A,B, col.3, lines 50-64; FIG. 1B is a block diagram of a multi-chassis version of a server with swappable pods 104 and Module Message Interface network. As in the single chassis version of FIG. 1A, the pods 104 and/or cards 106 (not shown, but see FIG. 1A) are coupled to the MMI network connection 108 and thus to each other through the MMI network. The MMI network connection/interconnect 108 couples one chassis 102 to each other chassis 102 in the system, for example through electrical or optical cable, and is available for coupling to further components or systems external to the multi-chassis server. Again as in the single chassis version, one or more routers for the MMI network can be internal or external. In some embodiments, each chassis 102 has one or more routers and may be connected to a streaming service(ie remote device) via the Internet or some other connection); wherein the remote device is operable to transmit a control message to a specific physical module of the plurality of physical modules via the edge-router(col.11, lines 41-col.12, line 21 42) FIG. 10 is a block diagram of an embodiment of the server of FIG. 1A for processing stream live data 214, such as video data. For example, the stream live data 214 could be a video data stream from a live event. In the server, a single chassis 102 or multiple chassis 102, several pods 104 are coupled to and connected by the MMI network connection 108. The stream live data 214 enters via an interface, e.g., via Ethernet or a pod 104 with a controller 201 that is coupled to a memory or storage media interface 206, which in turn is coupled to a further module 208 with a hard drive, solid-state drive and/or compute module. Other pods 104 coupled to the MMI network connection 108 include a pod 104 with an Ethernet connection, one or more line cards 212 and an FPGA 122, and a pod 104 with a processor card 134 (or just the processor card 134 inserted into a chassis 102). The stream live data 214 can be stored in one of the storage media devices, before or after processing by a compute module or the processor card 134, and the processed live data can then be streamed out through the pod 104 with the line card(s) 212 to the Ethernet connection. Optional fans 210 cool the various components in the chassis 102. In this embodiment, the memory or drive interface 206 and further module 208 with hard drive, solid-state drive and/or compute module are connected with direct connections 202, 204 and act as resources through the controller 201 coupled to the MMI network. Further pods 104 or cards 106 can be coupled to the MMI network for further processing of the stream live data 214. One example function the pods 104 could perform is video data transcoding, such as from one format to another. This is further developed in FIG. 11. FIG. 11 is a block diagram of an embodiment of the servers/platforms of FIG. 1A or FIG. 1B for transcoding video from multiple video inputs, for multiple video outputs. Multiple pods 104 each with video in 216, multiple pods 104 each with a transcoder 220, multiple pods 104 each with video out 218, and a pod 104 with memory superposition 140 are coupled to the MMI network connection in one or more chassis 102 (not shown, but see FIGS. 1A and 1B). There could be one or more video inputs on each of the pods 104 and one or more video outputs on each of the pods 104, in various combinations, and further pods 104 added for other functions such as shown in FIGS. 7-9 or as readily devised for further functionality (e.g., DMA or direct memory access attached to memory, a bus and/or the MIMI network, graphics acceleration, audio processing, feature recognition, etc.) in keeping with the teachings herein, in further embodiments.; it is obvious to one ordinary skill in the art that there is a command to transcode the video from one format to another in order for the process of transcoding to happen).
Beeson however does not explicitly teach the remote device causing a virtual display of the first physical module and the plurality of physical module.
Kumar explicitly teaches the remote device causing a virtual display of the first physical module and the plurality of physical module([0033] Process 300 can continue by generating a network topology view based on the topology information (306) and presenting the network topology view on a display device (308). For example, the network topology view can be presented on a display device (e.g., a computer monitor), as described in reference to FIG. 6.) and also teaches wherein the remote device is operable to transmit a control message to a specific physical module of the plurality of physical modules( [0042] After a user identifies values to be changed using the debugging application, PC 501 sends a write command to debugger server 502 with a start address and size of a memory region storing the variables to be changed. Debugger server 502 sends a write command with the memory address to debugger client 503. Debugger client 503 writes the new variables to the memory region defined by the address and sends a confirmation of the memory write to debugger server 502. Debugger server 502 sends a write memory confirmation to the debugger application running on PC 501 so that the user can confirm that the variables were successfully changed.)
Therefore it would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to modify Beeson’s teachings of devices in a chain configuration used for transcoding to apply the teachings of Kumar of displaying topology of devices and sending commands from a client to the server in order to provide the predictable result of displaying topology of devices and using the topology for sending transcoding/debugging commands to a specific device in the topology.
One ordinary skill in the art would have been motivated to combine the teachings in order to easily observe and collect statistics on nodes(Kumar, para.2)
As per claim 20, Beeson in view of Kumar teaches the system of claim 15, where in the remote device is operable to receive topology information from the first physical module via the edge-router(Beeson, Fig.1A,1B, col.3, lines 20-49; Kumar, [0018] FIG. 1 is a block diagram of an example wireless sensor network 100. In the example embodiment shown, network 100 includes nodes 102, coordinator 106, gateways 108 and border routers 110. Coordinator 106 (e.g., a coordinator in a ZigBee network), gateways 108 and border routers 110 are optional network nodes that are configured to redirect information from nodes 102 to, for example, wide area network (WAN) 104 (e.g., the Internet, private network). Nodes 102 form a network topology (e.g., a mesh network) in which each node relays data for the network and all nodes cooperate in the distribution of data in network 100. For example, network 100 can route a message between individual nodes 102a, 102c, by “hopping” from node 102a to node 102b and then to its destination node 102c. To ensure path availability, network 100 can reconfigure itself around broken paths using, for example, a self-healing algorithm (e.g., shortest path bridging algorithm)), wherein the virtual display is based upon the topology information(Kumar, [0005] In an embodiment, a system for debugging a wireless sensor network comprises: initiating a single debugging session with a plurality of nodes of the wireless sensor network; receiving network topology information from the nodes; and presenting a network topology view constructed from the topology information, the network topology view including a graphical representation of each node in the topology.). Motivation to combine set forth in claim 15.
Allowable Subject Matter
Claims 16-19 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
US 10,177,988 issued to Maes, teaches topology remediation method includes with a remediation engine, deriving a number of remediation actions based on a number of incidents within an instantiated topology, and with a lifecycle management engine, modifying the instantiated topology based on a number of lifecycle management actions (LCMAs) determined to remediate the incidents.
US 9,455,888 issued to Dixon et al., teaches generating an application topology are provided. A processor determines a first application profile based, at least in part, on a first network packet. A processor determines a second application profile based, at least in part, on a second network packet. A processor determines a link between a first application and a second application based, at least in part, on address information of the first network packet. A processor generates a topology comprising the first and second application profiles based, at least in part, on the link, the first application profile and the second application profile. A processor updates the first and second application profiles based, at least in part, on matching the first application profile and second application profile with an application deployment template.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BACKHEAN TIV whose telephone number is (571)272-5654. The examiner can normally be reached on Mon.-Thurs. 5:30-3:30.
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, TONIA DOLLINGER can be reached on (571) 272-4170. 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.
/BACKHEAN TIV/
Primary Examiner
Art Unit 2459