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 Arguments/Amendments
Applicant's arguments filed 1/08/26 have been fully considered but they are not persuasive.
For claim 1, Applicant argues:
a) FIG 18a and paragraph [0131] of Litichever does not teach "a plurality of nodes connected in a daisy-chain over full-duplex bus links." The cited FIG. 18a, shows a terminal 6 connected to several peripherals in a hub and Paragraph [0131] generally describes memory. Although the cited paragraph mentions various topologies, the paragraph is unclear what other nodes are involved other than the memory.
Accordingly, Applicant respectfully submits that the cited paragraph and figure do not disclose or suggest, "a plurality of nodes connected in a daisy-chain over full-duplex bus links."
b) [0135] and [0240] of Litichever do not teach "transmitting an Ethernet frame within a tunnel on the full-duplex bus links in at least one of an upstream direction toward a main-node or a downstream direction toward an end-sub-node.", because the cited paragraph describes memory.
In response, Examiner respectfully disagrees:
a) [0131] clearly teaches that devices (such as devices 2-6 in FIG. 18a) can be connected using daisy-chain. Note that access to a device is equivalent to access to the memory of the device, as information of a device, such as status, is stored in the memory of the device.
b) [0135] and [0240] of Litichever clearly discloses Ethernet interface and access to a device is equivalent to access to the memory of the device as explained above in a).
For claim 22, OA does not address the limitation "transmit a plurality of superframes over one or both of an upstream full-duplex bus link or a downstream full-duplex bus link based on the MAC address of the node, wherein each superframe includes a portion of the Ethernet frame within a portion of the flexible payload assigned to the tunnel." Because subject matter of claim 22 is different from that of claim 1.
In response, Examiner respectfully disagrees: OOSA would have understand that “transmitting an Ethernet frame within a tunnel on the full-duplex bus links in at least one of an upstream direction toward a main-node or a downstream direction toward an end-sub-node;” of claim 1 is equivalent to “transmit a plurality of superframes over one or both of an upstream full-duplex bus link or a downstream full-duplex bus link based on the MAC address of the node, wherein each superframe includes a portion of the Ethernet frame within a portion of the flexible payload assigned to the tunnel”; note that an “Ethernet frame within a tunnel” suggests superframes with MAC address because tunnel is at Layer 2, each frame in the tunnel is consider as a superframe because it includes additional tunnel information such as tag.
Other arguments are not persuasive because they are based on the arguments to independent claim 1 or independent claim 22.
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 1-26 are rejected under 35 U.S.C. 103 as being unpatentable over Litichever (US 20180225230 A1) in view of Anschutz (US 20090103545 A1).
For claim 1, Litichever discloses a method of transmitting Ethernet frames over a plurality of nodes connected in a daisy-chain over full-duplex bus links (FIG. 18a, wherein work station 7 has nodes 1-6 in view of “[0131] … The connection may further be wired in various topologies such as multi-drop (electrical parallel), point-to-point, or daisy-chain. A memory may be powered via a dedicated port or connector, or may be powered via a power signal carried over the bus, such as SATA or USB.”), the method comprising:
determining that a node has a transmit token (“[0164] An endpoint of a pipe is addressable with a tuple (device address, endpoint number) as specified in a TOKEN packet that the host sends when it wants to start a data transfer session.”);
transmitting an Ethernet frame from the node within a tunnel on the full-duplex bus links in at least one of an upstream direction toward a main-node or a downstream direction toward an end-sub-node ([0135] “… NAS is typically associated with an LAN, and provides an Ethernet interface based on IEEE802.3 standard may be used …”, “[0085] … L2TP, however, actually runs over the transport layer using User Datagram Protocol (UDP) over IP. The IP in the delivery protocol could run over any data-link protocol from IEEE 802.2 over IEEE 802.3 (i.e., standards-based Ethernet) …” and [0240] “The first or the second local bus (or both) may be a synchronous serial bus, and may be a master/slave bus for connecting ICs, such as Serial Peripheral Interface (SPI) bus or Inter-Integrated Circuit (I.sup.2C) bus. The first or the second local bus (or both) may be a bi-directional bus, that may be a half-duplex or a full-duplex bus. … ”);
receiving, while transmitting the Ethernet frame, a request for the transmit token from one or more other nodes in the tunnel on at least one of the full-duplex bus links in a direction opposite the Ethernet frame ([0135] “… NAS is typically associated with an LAN, and provides an Ethernet interface based on IEEE802.3 standard may be used …” and [0085] “… a data link layer delivery when it is carried inside the Layer 2 Tunneling Protocol (L2TP). …” and [0240] “The first or the second local bus (or both) may be a synchronous serial bus, and may be a master/slave bus for connecting ICs, such as Serial Peripheral Interface (SPI) bus or Inter-Integrated Circuit (I.sup.2C) bus. The first or the second local bus (or both) may be a bi-directional bus, that may be a half-duplex or a full-duplex bus. … ”).
Litichever is silent but Anschutz, in the same field of endeavor of ethernet communication, discloses: on transmitting the transmit token to a next node of the other nodes based on an order of priority of the one or more other nodes after transmitting the Ethernet frame (suggested by “[0035] … [0037] R-46 The Access Node SHOULD support at least 6 traffic classes for Ethernet frames, and MUST support configurable mapping to these classes from the 8 possible values of the Ethernet priority field. …”). OOSA would have been motivated apply the teaching of Anschutz above to the ethernet communication system by Litichever to yield a predictable result of conducting ethernet communication based on priority according to MPEP 2143(D).
Therefore it would have been obvious to OOSA before the effective filing date of the application to combine Litichever and Anschutz for the benefit of conducting ethernet communication based on priority ([0035] of Anschutz).
Independent claim 9 is rejected because it is a generic node that performs the method of claim 1 and has the same subject matter.
Independent claim 22 is rejected because it is a communication system that performs the method of claim 1 and has the same subject matter.
As to claims 2 and 15, Litichever in view of Anschutz discloses claims 1 and 9, Anschutz further discloses: wherein the order of priority from highest priority to lowest priority (Table 1 show priority 1-4, in view of “[0045] An example for a system that supports 4 queues is shown in Table 1 below. In Table 1, Queue 1 is scheduled at the highest priority”).
Litichever in view of Anschutz does not specifically state that the order of priority of the type of node is:
a hub node that holds the transmit token;
a hub node without the transmit token;
a designated high priority node indicated in the request; and
a node that transmitted the request with a number indicating that the node was first to request the token for a new Ethernet frame.
However, selecting the priority order is a design choice and is obvious to OOSA according to MPEP 2143(E).
Therefore, it would have been obvious to OOSA before the effective filing date of the application that Litichever in view of Anschutz discloses all the claim limitation of the claim.
As to claims 3 and 16, Litichever in view of Anschutz discloses claims 2 and 15, further discloses: wherein when requests from multiple nodes indicate a same number (Anschutz: Table 1, when multiple nodes are in the same queue), the next node is selected based on a distance (Litichever: “[0250] … be operative to estimate the number, magnitude, frequency, Direction-Of-Arrival (DOA), distance, or speed of the signal impinging the sensor array. …“) to the node with the transmit token (This would have been an obvious try according to MPEP 2143(E)). The motivation to combining Litichever and Anschutz is the same as stated in the parent claims.
Therefore, it would have been obvious to OOSA before the effective filing date of the application that Litichever in view of Anschutz discloses all the claim limitations of the claim.
As to claims 4 and 17, Litichever in view of Anschutz discloses claims 2 and 15, Litichever further discloses: wherein the number in the request is selected as a circularly incremented value of a token counter transmitted by the node with the token, and the next node has a smallest circular distance between the number in the request and the token counter (“[0080] The thread tick method switches tasks depending on priority and a round-robin scheduling scheme. …”; note that round-robin is a scheduling).
As to claim 5, Litichever in view of Anschutz discloses claim 1, Litichever further discloses:
receiving an Ethernet frame on one of the full-duplex bus links ([0135] “… NAS is typically associated with an LAN, and provides an Ethernet interface based on IEEE802.3 standard may be used …” and [0240] “The first or the second local bus (or both) may be a synchronous serial bus, and may be a master/slave bus for connecting ICs, such as Serial Peripheral Interface (SPI) bus or Inter-Integrated Circuit (I.sup.2C) bus. The first or the second local bus (or both) may be a bi-directional bus, that may be a half-duplex or a full-duplex bus. … ”), the Ethernet frame having a header including a field for one or more of: a media access control (MAC) address, an Ethernet type, or a virtual local area network (“[0012] … Ethernet connection based on IEEE802.3 standard may be used, …” and VPN in FIG. 18b; note that IEEE802.3 teaches a media access control (MAC) address, an Ethernet type);
propagating the Ethernet frame to a next node in the daisy-chain in the direction of the Ethernet frame (“[0012] … Ethernet connection based on IEEE802.3 standard may be used, …” and “[0131] … The connection may further be wired in various topologies such as multi-drop (electrical parallel), point-to-point, or daisy-chain. …”); and
filtering Ethernet frames for the node based on the field of the header (FIG. 3, driver stack 36, filter/driver 36b or 36c).
As to claim 6, Litichever in view of Anschutz discloses claim 1, Litichever further discloses: wherein the one or more other nodes in the tunnel include a subset of the plurality of nodes connected in the daisy-chain that have dynamically indicated participation in the tunnel.
As to claim 7, Litichever in view of Anschutz discloses claim 1, Litichever further discloses:
wherein each node includes a programmable register defining one or more of:
participation in Ethernet traffic ([0012] “… Ethernet connection based on IEEE802.3 standard may be used, such as 10/100BaseT, 1000BaseT (gigabit Ethernet), 10 gigabit Ethernet (10GE or 10 GbE or 10 GigE per IEEE Std. 802.3ae-2002as standard), 40 Gigabit Ethernet (40 GbE), or 100 Gigabit Ethernet (100 GbE as per Ethernet standard IEEE P802.3ba) …”);
downstream Ethernet tunnel enablement ([0012] “… Ethernet connection based on IEEE802.3 standard may be used, …” and [0135] “… NAS is typically associated with an LAN, and provides an Ethernet interface based on IEEE802.3 standard may be used …” and [0240] “The first or the second local bus (or both) may be a synchronous serial bus, and may be a master/slave bus for connecting ICs, such as Serial Peripheral Interface (SPI) bus or Inter-Integrated Circuit (I.sup.2C) bus. The first or the second local bus (or both) may be a bi-directional bus, that may be a half-duplex or a full-duplex bus. … ”);
whether the node is a hub node ([0135] “… wherein a self-contained file level storage (typically arranged as a server) is connected to a network, providing data sharing to other devices (such as heterogeneous clients), commonly via a network device such as a hub …”);
whether the node is an upstream end-node of the tunnel, a downstream end-node of the tunnel, or a mid-node of the tunnel (FIG. 18b shows a mid-node 24 of a tunnel 182);
whether the hub node transmits the token when the hub node has other Ethernet frames to transmit (“[0395] Two-factor authentication for VPNs may be used for the VPN connection 182, which may involve providing authentication data from a hardware token to VPN software on a separate machine. …”);
upstream Ethernet tunnel enablement (“[0012] … Ethernet connection based on IEEE802.3 standard may be used, …” and [0135] “… NAS is typically associated with an LAN, and provides an Ethernet interface based on IEEE802.3 standard may be used …” and [0240] “The first or the second local bus (or both) may be a synchronous serial bus, and may be a master/slave bus for connecting ICs, such as Serial Peripheral Interface (SPI) bus or Inter-Integrated Circuit (I.sup.2C) bus. The first or the second local bus (or both) may be a bi-directional bus, that may be a half-duplex or a full-duplex bus. … ”);
whether the next node is a high priority node;
a counter decrement level;
a point-to-point indication (“[0141] … Point-to-Point (FC-P2P), where two devices are connected directly to each other; Arbitrated loop (FC-AL) where all devices are in a loop or ring (similar to token ring networking); and Switched fabric (FC-SW), where devices or loops of devices are connected to Fibre Channel switches (similar conceptually to modern Ethernet implementations).”); or
an identifier of the next node (“[0080] The thread tick method switches tasks depending on priority and a round-robin scheduling scheme. …”; note that round-robin is a scheduling).
As to claims 8 and 21, Litichever in view of Anschutz discloses claims 1 and 9, Litichever further discloses: wherein transmitting the Ethernet frame within the tunnel on the full-duplex bus links at least one of an upstream direction to a main-node or a downstream direction to a sub-node comprises:
determining, based on a programmable register, a position of the node within the daisy-chain (“[0404] … The bus topology may use point-to-point, multi-drop (electrical parallel) and daisy-chain, and may further be based on hubs or switches. A point-to-point bus may be full-duplex. …”); and
transmitting a plurality of superframes over one or both of an upstream full-duplex bus link or a downstream full-duplex bus link based on the position of the node, wherein each superframe includes a portion of the Ethernet frame within a portion of a payload assigned to the tunnel (“[0131] A memory may be accessed via a parallel connection or bus (wherein each data word is carried in parallel on multiple electrical conductors or wires), such as PATA, PCMCIA or EISA, or via serial bus (such as bit-serial connections) such as USB or Ethernet based on IEEE802.3 standard, or a combination of both. The connection may further be wired in various topologies such as multi-drop (electrical parallel), point-to-point, or daisy-chain. …” and [0404]).
As to claim 10, Litichever in view of Anschutz discloses claim 9, Litichever further discloses:
a microcontroller configured to communicate with the transceiver via a serial peripheral interface or media-independent interface (“[0171] … SPI devices communicate in full duplex mode using a master-slave architecture with a single master, where the master device originates the frame for reading and writing, and multiple slave devices are supported through selection with individual slave select (SS) lines. …”).
As to claim 11, Litichever in view of Anschutz discloses claim 10, Litichever further discloses: wherein the transceiver comprises a buffer configured to store at least one Ethernet frame for transmission or reception without communication with the microcontroller (“[0059] … all of these parameters (such as buffer address, buffer size, I/O function type, etc.) are passed via a single pointer to this persistent data structure. …” and “[0012] … Ethernet connection based on IEEE802.3 standard may be used, …”;).
As to claim 12, Litichever in view of Anschutz discloses claim 10, Litichever further discloses: wherein the transceiver is configured to:
receive data from the microcontroller ([0078] “… support for multiple microcontroller architectures, …”); and
generate the Ethernet frame including a cyclic redundancy check (CRC) sequence based on the data (“[0146] … frame negotiation and arbitration, CRC calculation, …”).
As to claim 13, Litichever in view of Anschutz discloses claim 10, Litichever further discloses: wherein the transceiver is configured to check a CRC sequence on a received Ethernet frame prior to sending the Ethernet frame to the microcontroller ([0078] “… support for multiple microcontroller architectures, …” and “[0012] … Ethernet connection based on IEEE802.3 standard may be used, …”).
As to claim 14, Litichever in view of Anschutz discloses claim 10, Litichever further discloses: wherein the transceiver is configured to send a content of a flexible payload for the Ethernet tunnel to the microcontroller for filtering based on a MAC address (FIG. 3, driver stack 36, filter/driver 36b or 36c).
As to claim 18, Litichever in view of Anschutz discloses claim 9, Litichever further discloses: wherein the transceiver is configured to:
receive an Ethernet frame including a media access control (MAC) address on one of the full-duplex bus links (“[0012] … Ethernet connection based on IEEE802.3 standard may be used, …” ([0135] “… NAS is typically associated with an LAN, and provides an Ethernet interface based on IEEE802.3 standard may be used …” and [0240] “The first or the second local bus (or both) may be a synchronous serial bus, and may be a master/slave bus for connecting ICs, such as Serial Peripheral Interface (SPI) bus or Inter-Integrated Circuit (I.sup.2C) bus. The first or the second local bus (or both) may be a bi-directional bus, that may be a half-duplex or a full-duplex bus. … ”; note IEEE802.3 standard discloses Ethernet MAC frame);
propagate the Ethernet frame to a next node in the daisy-chain in the direction of the Ethernet frame (“[0131] … via serial bus (such as bit-serial connections) such as USB or Ethernet based on IEEE802.3 standard, or a combination of both. The connection may further be wired in various topologies such as multi-drop (electrical parallel), point-to-point, or daisy-chain. …”); and
filter Ethernet frames for the node based on the MAC address (FIG. 3, driver stack 36, filter/driver 36b or 36c, from which Ethernet frames go through).
As to claim 19, Litichever in view of Anschutz discloses claim 9, Litichever further discloses: wherein the one or more other nodes in the tunnel include a subset of the plurality of nodes connected in the daisy-chain (tunnel in FIG. 18b in view of “[0404] … The bus topology may use point-to-point, multi-drop (electrical parallel) and daisy-chain, and may further be based on hubs or switches. …”).
As to claim 24, Litichever in view of Anschutz discloses claim 22, Litichever further discloses: wherein the programmable register indicates a point-to-point tunnel between two of the nodes, and wherein each node of the tunnel is configured to transmit Ethernet frames to the other node within the flexible payload of the superframes (FIG. 18b) in a direction of the other node on the full-duplex bus links (“[0404] The bus topology may use point-to-point, multi-drop (electrical parallel) and daisy-chain, and may further be based on hubs or switches. A point-to-point bus may be full-duplex, providing simultaneous, two-way transmission (and sometimes independent) in both directions …“).
As to claim 25, Litichever in view of Anschutz discloses claim 22, Litichever further discloses:
wherein the Ethernet tunnel includes three or more nodes (FIG. 18b), and wherein each node is configured to:
determine that the node has a transmit token (“[0164] An endpoint of a pipe is addressable with a tuple (device_address, endpoint_number) as specified in a TOKEN packet that the host sends when it wants to start a data transfer session.”);
transmit an Ethernet frame within a tunnel on the full-duplex bus links at least one of an upstream direction towards a main-node or a downstream direction towards an end-sub-node (“[0404] The bus topology may use point-to-point, multi-drop (electrical parallel) and daisy-chain, and may further be based on hubs or switches. A point-to-point bus may be full-duplex, providing simultaneous, two-way transmission (and sometimes independent) in both directions …“);
receive, while transmitting the Ethernet frame, a request for the transmit token from one or more other nodes in the tunnel on at least one of the full-duplex bus links in a direction opposite the Ethernet frame (“[0404] The bus topology may use point-to-point, multi-drop (electrical parallel) and daisy-chain, and may further be based on hubs or switches. A point-to-point bus may be full-duplex, providing simultaneous, two-way transmission (and sometimes independent) in both directions …“ and [0012] “… Ethernet connection based on IEEE802.3 standard may be used,); and
transmit the transmit token to one of the other nodes based on a priority of the one or more other nodes (“[0404] The bus topology may use point-to-point, multi-drop (electrical parallel) and daisy-chain, and may further be based on hubs or switches. A point-to-point bus may be full-duplex, providing simultaneous, two-way transmission (and sometimes independent) in both directions …“ in view of the parent claim).
As to claim 26, Litichever in view of Anschutz discloses claim 22, Litichever further discloses: wherein an Ethernet speed is programmable based on a size of the flexible payload and a data rate of the bus links ([0012] “… Ethernet connection based on IEEE802.3 standard may be used, such as 10/100BaseT, 1000BaseT (gigabit Ethernet), 10 gigabit Ethernet (10GE or 10 GbE or 10 GigE per IEEE Std. 802.3ae-2002as standard), 40 Gigabit Ethernet (40 GbE), or 100 Gigabit Ethernet (100 GbE as per Ethernet standard IEEE P802.3ba) …”).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 JIANYE WU whose telephone number is (571)270-1665. The examiner can normally be reached M-TH 8am-6pm.
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, Yemane Mesfin can be reached at (571) 272-3927. 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.
/JIANYE WU/Primary Examiner, Art Unit 2462