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 .
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 - 3 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Eldar et al. (US Pub. No. 20070005742), hereinafter referred to as Eldar in view of Mohamed et al. (US Pub. No. 20150030029), hereinafter referred to as Mohamed and in further view of Kagan et al. (US Pub. No. 20030065856), hereinafter referred to as Kagen.
As to claim 1, Eldar discloses a communication device comprising:
a multi-core CPU (Eldar expressly discloses that a CPU may contain two or more independent processors or cores within a single package and that the cores may be treated as independent CPUs, Fig. 1, para. 0008) implemented with (the processor cores are contained within the CPU package, Fig. 1, para. 0008) a plurality of CPUs (the computing system contains several CPUs 110, with two CPUs illustrated, and the cores of a multi-core CPU may be treated as independent CPUs, Fig. 1, para. 0008) each configured to implement (the CPUs execute interrupt service routines and delayed procedure calls that perform protocol-processing functions, Fig. 2, paras. 0009 and 0014–0017) an application (Eldar delivers processed user or application data, Fig. 2, paras. 0009);
a received frame processing unit (network interface card 160 or 170 receives a signal representing a network data packet, converts the signal into computer-manipulable data, calculates a hash over packet fields, copies the packet data to memory, and updates a receive queue, Figs. 1–2, paras. 0008 and 0010–0011) configured to determine (the network interface calculates a hash value over selected fields of each received packet, Fig. 2, para. 0010) a reception data (the network interface receives and converts incoming network packets, including packets transmitted over Ethernet, Figs. 1–2, paras. 0002 and 0010) and allocate (the network interface selects one of multiple receive queues and directs the newly received packet to the selected queue, Fig. 2, paras. 0011 and 0019) the reception data (the newly received network packet is copied to memory and placed in a receive queue for later processing, Fig. 2, para. 0011); and
a plurality of buffering memories (Eldar discloses multiple receive queues that store received packets and may require dedicated memory pages, Fig. 2, paras. 0003 and 0011) each (each receive queue may contain received packets and may be processed by one or more CPUs, Figs. 2–3, paras. 0011, 0015, and 0026–0027) configured to receive (the network interface selects a receive queue and places a newly received packet into the selected queue, Fig. 2, para. 0011) the reception data (the selected queue contains the newly received network packet, Fig. 2, para. 0011) allocated by (the network interface performs the queue selection and packet placement, Fig. 2, para. 0011) the received frame processing unit (network interface card 160 or 170 performs the hardware packet-reception, hash-calculation, memory-copying, and queue-selection operations, Figs. 1–2, paras. 0008–0011) and store (the packet data is copied to memory and the selected receive queue is updated so that the packet can be located for later processing, Fig. 2, para. 0011) the reception data (the newly received packets are maintained in receive queues until removed for processing, Fig. 2, paras. 0011–0015), wherein
each of the plurality of buffering memories (Eldar’s multiple receive queues may each contain received packets and be associated with one or more CPUs, Figs. 2–3, paras. 0011, 0026, and 0027) a reception interrupt signal (the NIC interrupts a CPU after one or more received packets have been queued, Fig. 2, paras. 0012–0014) to (the NIC directs the device interrupt to a selected CPU, Figs. 2–3, paras. 0022, 0027, and 0030) a corresponding CPU (each interface or each receive queue may be configured to interrupt a CPU within the CPU subset associated with that interface or queue, Fig. 3, para. 0027) among the plurality of CPUs (the selected CPU is one of the several CPUs 110 of the multiprocessing system, Figs. 1–2, paras. 0008, 0013, and 0021–0022) when receiving (the NIC may interrupt a CPU as soon as a packet has been received and queued, Fig. 2, para. 0012) the reception data (the interrupt is generated in response to receipt and queuing of one or more network packets, Fig. 2, para. 0012) allocated by the received frame processing unit (the NIC receives each packet, copies it to memory, selects a receive queue, places the packet in the queue, and then interrupts a CPU, Fig. 2, paras. 0010–0012), and
the CPU (selected CPU 110 of the multiprocessing system, Figs. 1–2, paras. 0008, 0013, and 0022) that receives (the NIC directs the interrupt to the selected CPU, causing that CPU to execute an interrupt service routine, Fig. 2, paras. 0012–0014) the reception interrupt signal (the NIC-generated interrupt initiates execution of the interrupt service routine by the selected CPU, Fig. 2, para. 0014) is configured to acquire (the interrupted CPU executing the interrupt service routine examines the queued packets and may load information from or about each packet into its cache, Fig. 2, para. 0021) a data size (Eldar calculates or counts the number of data bytes assigned to respective CPU groups, para. 0022-0024) of the reception data (Eldar’s byte count concerns the aggregate data bytes in packets assigned to a processing group, para. 0023) from the buffering memory (the receive queue from which the interrupted CPU removes received packets, Fig. 2, para. 0015) and perform processing (the interrupted CPU executes an interrupt service routine and schedules delayed procedure calls that perform protocol processing on the received packets, Fig. 2, paras. 0014–0017) of reading (the interrupt service routine removes received packets from the receive queue and examines information from or about those packets, Fig. 2, paras. 0015 and 0021) the reception data (the received packets are removed from the receive queue and processed by scheduled callbacks, Fig. 2, paras. 0015 and 0017) based on the data size (Eldar use aggregate packet count, aggregate byte count, subset size, or packet type to select which CPU to interrupt, paras. 0022–0024).
Mohamed discloses, what Eldar lacks, Ethertype (discloses Ethertype 126 as the Ethernet-frame field indicating the protocol encapsulated in the payload, Figs. 1–2B, paras. 0012, 0014, and 0022–0023);
according to the Ethertype (determines the handling and forwarding of a received Ethernet frame according to whether its Ethertype matches a stored or hard-coded Ethertype, Figs. 1–3, paras. 0012, 0016–0017, 0023, and 0029–0031); and
according to the Ethertype (teaches determining frame handling according to Ethertype, and Eldar teaches storing allocated frames in selected receive queues, Figs. 1–3, paras. 0016–0017).
Eldar and Mohamed are analogous art because they are from the same field of endeavor of receiving, classifying, routing, and processing network communication frames and packets.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Eldar and Mohamed before him or her, to modify the packet-classification and receive-queue selection mechanism of Eldar to include the Ethertype-based frame-classification mechanism of Mohamed.
The suggestion/motivation for doing so would have been to improve the efficient distribution and protocol-appropriate processing of heterogeneous Ethernet traffic in Eldar’s multiprocessor communication system.
Therefore, it would have been obvious to combine Mohamed with Eldar to obtain the invention as specified in the instant claim.
Kagan discloses, what Eldar lacks, to transmit (discloses that a given event queue asserts its corresponding interrupt when the queue is armed and contains an event entry, Figs. 3–4, paras. 0066 and 0069–0071); and
that transmits the reception interrupt signal (discloses each event queue 48 asserting its corresponding interrupt 82, Figs. 3–4, paras. 0066 and 0069).
Eldar and Kagan are analogous art because they are from the same field of endeavor of network-interface receive-queue management and processor-interrupt handling in multiprocessor communication systems.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Eldar and Kagan before him or her, to modify the receive-queue and processor-interrupt arrangement of Eldar to include Kagan’s advance mapping of multiple hardware-maintained event queues to corresponding processor interrupts.
The suggestion/motivation for doing so would have been to reduce interrupt-processing overhead, allow the appropriate CPU or application process to begin processing the queued packet more quickly, and distribute interrupt-handling work efficiently among the processors.
Therefore, it would have been obvious to combine Kagan with Eldar to obtain the invention as specified in the instant claim.
As to claim 8, the modified system of Eldar discloses a reception data processing method a communication device (Eldar’s computing system communicates through network interface cards 160 and 170 connected to physical networks 180 and 190, Fig. 1, paras. 0001–0002 and 0008), the communication device (Eldar’s network-connected multiprocessor computing system, Fig. 1, para. 0008) including a multi-core CPU (Eldar expressly discloses that a CPU may contain two or more independent processors or cores within a single package and that the cores may be treated as independent CPUs, Fig. 1, para. 0008) implemented with a plurality of CPUs (Eldar’s computing system contains several CPUs 110, with two CPUs illustrated, and the cores of a multi-core CPU may be treated as independent CPUs, Fig. 1, para. 0008) each configured to implement an application (Eldar delivers processed user or application data to an application, and Kagan notifies an appropriate consumer application process that completion information is waiting to be read, Eldar, Fig. 2, para. 0018; Kagan, paras. 0030 and 0075), the method comprising:
a processing step (Eldar’s network-adapter hardware operations 201 include receiving a packet, calculating a hash over packet fields, selecting a receive queue, copying the packet to memory, and updating the receive queue, Fig. 2, paras. 0009–0012) of determining (Mohamed discloses parsing module 214 syntactically analyzing the header of a received Ethernet frame to determine its Ethertype, Figs. 2A–3, paras. 0022–0023 and 0029–0031) an Ethertype (Mohamed discloses Ethertype 126 as the Ethernet-frame field identifying the protocol encapsulated in the payload, Figs. 1–2B, paras. 0012, 0014, and 0022–0023) of reception data (Mohamed determines the Ethertype of Ethernet frame 240 received by communication module 210, Figs. 2A–2B, paras. 0022–0023) and allocating (Eldar selects one of multiple receive queues and places the newly received packet into the selected queue, Fig. 2, paras. 0011 and 0019; Mohamed determines whether and where to pass a received frame based on its Ethertype, Figs. 1–3, paras. 0016–0017, 0023, and 0029–0031) the reception data (Eldar’s newly received network packet is copied to memory and placed in the selected receive queue, Fig. 2, para. 0011) according to the Ethertype (Mohamed determines the handling and forwarding of a received Ethernet frame according to whether its Ethertype matches a stored or hard-coded Ethertype, Figs. 1–3, paras. 0012, 0016–0017, 0023, and 0029–0031);
a storing step (Eldar copies the received packet to memory and updates the selected receive queue so that the packet can be located for later processing, Fig. 2, para. 0011) of storing the reception data (Eldar’s received network packets, Fig. 2, paras. 0010–0012) allocated in the processing step (Eldar selects the receive queue based on the calculated packet classification, Fig. 2, paras. 0010–0011 and 0019; Mohamed supplies Ethertype as the classification criterion, Figs. 2A–3, paras. 0022–0023 and 0029–0031) in a plurality of buffering memories (Eldar discloses multiple receive queues that store received packets and may require dedicated memory pages, Fig. 2, paras. 0003 and 0011; Kagan discloses multiple event queues 48 maintained as virtually contiguous circular memory buffers, Fig. 3, paras. 0061–0064) according to the Ethertype (Mohamed teaches determining frame handling according to Ethertype, while Eldar teaches storing classified received packets in selected receive queues, Mohamed, Figs. 1–3, paras. 0016–0017, 0023, and 0029–0031; Eldar, Fig. 2, paras. 0010–0011 and 0019); and a read processing step (Eldar’s interrupt service routine removes received packets from the receive queue and schedules callbacks for protocol processing, Fig. 2, paras. 0014–0017) of reading (Eldar removes packets from the receive queue for subsequent processing, Fig. 2, para. 0015) the reception data (Eldar’s received network packets, Fig. 2, paras. 0015 and 0017) stored in the plurality of buffering memories (Eldar’s multiple receive queues, Fig. 2, paras. 0003, 0011, and 0015), wherein in the storing step (Eldar’s operations of copying the received packet to memory and placing the packet in the selected receive queue, Fig. 2, para. 0011), upon receiving (Eldar discloses the NIC interrupting a CPU as soon as a packet has been received and queued, Fig. 2, para. 0012) the reception data (Eldar’s received network packet, Fig. 2, paras. 0010–0012) allocated in the processing step (Eldar’s received packet is allocated to a selected receive queue based on packet-field classification, Fig. 2, paras. 0010–0011 and 0019; Mohamed determines frame handling based on Ethertype, Figs. 2A–3, paras. 0022), each of the plurality of buffering memories (Kagan discloses multiple event queues 48 maintained as circular memory buffers and mapped in advance to respective interrupts 82, Figs. 3–4, paras. 0061, 0064, and 0066) transmits (Kagan expressly discloses that an armed event queue asserts its corresponding interrupt when an event entry is added, Figs. 3–4, paras. 0066 and 0069–0071) a reception interrupt signal (Kagan’s corresponding interrupt 82 reports an event associated with receiving an incoming data packet, Figs. 3–5, paras. 0030, 0066, and 0073–0075) to a corresponding CPU (Kagan discloses a preferred one-to-one mapping between event queues and processor interrupts in a multiprocessor system and teaches preassigning different event types to different processors, Figs. 3–4, paras. 0015–0017, 0055, and 0066) among the plurality of CPUs (Eldar’s selected CPU is one of several CPUs 110 in the multiprocessing system, Figs. 1–2, paras. 0008, 0013, and 0021–0022), and in the read processing step (Eldar’s interrupted-CPU operations of removing and processing received packets, Fig. 2, paras. 0014–0017), upon receiving (Kagan’s processor receives interrupt 82 corresponding to event queue 48, Figs. 3 and 5, paras. 0066 and 0074) the reception interrupt signal (Kagan’s corresponding queue interrupt 82, Figs. 3–5, paras. 0066 and 0073–0074), the CPU acquires (Kagan’s processor reads an event entry identifying the type and originator of the event and the completion queue containing information waiting to be read, Figs. 3 and 5, paras. 0063–0066 and 0074–0075) a data size (Eldar calculates or counts the number of data bytes assigned to respective CPU groups, para. 0022-0024) of the reception data (Eldar’s byte count concerns the aggregate data bytes in packets assigned to a processing group, para. 0023) from the buffering memory (Kagan’s event queue 48 is a circular memory buffer accessed by HCA 22 and host processor 24, Fig. 3, para. 0064) that transmits the reception interrupt signal (Kagan discloses each armed event queue 48 asserting its corresponding interrupt 82, Figs. 3–4, paras. 0066 and 0069) and performs processing (Eldar’s CPU executes an interrupt service routine and scheduled callbacks that perform protocol processing on received packets, Fig. 2, paras. 0014–0017) of reading (Eldar’s interrupt service routine removes received packets from the receive queue, Fig. 2, para. 0015; Kagan’s host application reads the indicated completion information, Fig. 5, para. 0075) the reception data based on the data size (Eldar use aggregate packet count, aggregate byte count, subset size, or packet type to select which CPU to interrupt, paras. 0022–0024).
As to claim 2, Kagan discloses a the communication device according to claim 1, wherein the plurality of buffering memories are FIFO memories (Kagan’s circular event queues 48 are FIFO memories because each queue includes a producer index identifying the next entry to be written and a consumer index identifying the next entry to be read, the HCA advances the producer index as entries are written, and the host advances the consumer index as entries are consumed sequentially until reaching the producer index, Fig. 3, paras. 0064–0065).
As to claim 3, the modifies system of Eldar discloses the communication device according to claim 1, further comprising: an interrupt controller (Kagan’s HCA 22, completion engine 47, event-queue context 54, and associated interrupt-generation circuitry collectively constitute an interrupt controller because they generate event entries, map event queues 48 to host-processor interrupts 82, and assert the mapped interrupts, Figs. 1 and 3–5, paras. 0053–0055) configured to allocate a plurality of interrupt (Kagan discloses multiple interrupt causes represented by different event types and sources, including completion events, error events, page faults, transport events, link events, internal HCA errors, and bus errors, Fig. 3, paras. 0062–0063) causes to each CPU of the multi-core CPU (Eldar discloses several CPUs 110 and expressly teaches that a CPU may contain two or more independent processor cores that may be treated as independent CPUs, Fig. 1, para. 0008).
Allowable Subject Matter
Claims 4 – 7 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including 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.
Kumar et al. (US Pat. No. 9992167) The present invention is directed towards systems and methods for sharing licenses across resources via a multi-core intermediary device. A device intermediary to a plurality of clients and a server may grant a license for a virtual private network (VPN) session established by a first core of a plurality of cores of the device with a client.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUANITO C BORROMEO whose telephone number is (571)270-1720. The examiner can normally be reached on Monday - Friday 9 - 5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Henry Tsai can be reached on 5712724176. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.C.B/ Assistant Examiner, Art Unit 2184
/HENRY TSAI/ Supervisory Patent Examiner, Art Unit 2184
Prosecution Insights