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 .
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 13, 14, and 18 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.
Claim 13 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “The computer-readable medium of claim 8” does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claim. Claim 13 refers to a computer-readable medium of claim 8; however, claim 8 is directed to “The apparatus of claim 1” and does not recite a computer-readable medium. It is unclear whether claim 13 was intended to depend from computer-readable-medium claim 9 or whether claim 13 was intended to further limit the apparatus of claim 8. Therefore, the scope of claim 13 is unclear.
Claim 14 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “The computer-readable medium of claim 8” does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claim. Claim 14 refers to a computer-readable medium of claim 8; however, claim 8 is directed to “The apparatus of claim 1” and does not recite a computer-readable medium. It is unclear whether claim 14 was intended to depend from computer-readable-medium claim 9 or whether claim 14 was intended to further limit the apparatus of claim 8. Therefore, the scope of claim 14 is unclear.
Claim 18 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “encrypting the packet is encrypted in accordance with Internet Protocol Security (IPSec), MACsec, Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), or Google® PSP Security Protocol (PSP)” does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claim. The phrase “encrypting the packet is encrypted” is grammatically unclear. It is unclear whether the claim intends to recite the affirmative method step of “encrypting the packet in accordance with” one of the listed security protocols, whether the claim intends to recite “wherein the packet is encrypted in accordance with” one of the listed security protocols, or some other limitation. Therefore, the scope of claim 18 is unclear.
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 (i.e., changing from AIA to pre-AIA ) 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 6-9, 13-15, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over McGrew et al, (U.S. Pub No. 2015/003,3014 A1, hereinafter “McGrew”) in view of Minnick et al (U.S. Pub. No. 2003/004,6585 A1, hereinafter “Minnick”).
Regarding claim 1,
Minnick teaches:
An apparatus comprising: a network interface device comprising: direct memory access (DMA) circuitry, a network interface, a host interface, and circuitry to: (see Minnick, [¶¶0003, 0005, 0021]: “One solution to this problem is to offload the cryptography operations to hardware external to the processor, for example, a network interface card (NIC). Often, data transfers between the NIC and host memory are accomplished using a direct memory access (DMA) device. Assuming the cryptographic operation processor in located on the NIC, the driver must instruct the NIC processor to transfer the packet across the bus, perform the cryptographic operation on the packet and then send the packet back across the bus to host memory. Network interface 210 further includes control circuit 215 which provides cryptography services 216 and is coupled to buffer 211 and SA lookup table 212.”);
(Minnick provides a NIC having DMA functionality, network connectivity, a bus connection to the host system, and control circuitry that performs cryptographic packet processing.)
process a packet received by the network interface, (see Minnick, [¶¶0028-0030]: “A network packet is received at 405. For example, a network packet can be received via a network interface and stored in a buffer on a network interface card. The network packet header is parsed at 410. The non-payload portions of the network packet are analyzed to determine various characteristics of the network packet. If the packet is an IPSec packet at 415, the network processor, or other processing device, extracts the SPI, the destination address and the IPSec protocol used to encrypt the packet.”);
(Minnick receives a packet through the NIC and processes the packet by parsing its header and extracting information used for IPSec processing.)
Minnich does not teach but, McGrew teaches:
for a first configuration, determine an Extended Sequence Number (ESN) value based on content of the packet without performance of ESN prediction, (see McGrew, [¶¶0033, 0040, 0042-0043]: “The sender maintains a t-bit sequence number s, which is initially equal to zero. To encrypt a plaintext P, the sender concatenates the sequence number s with P, then encrypts the result with an arbitrary-length pseudorandom permutation (such as the AES-XCB mode defined in IEEE 1619.2), using a secret key K. To process a ciphertext C, the receiver first decrypts C with K, then interprets the final t bits of the result as a candidate sequence number s. Logic 24 receives a sequence of ciphertext messages assumed to include encrypted plaintext and encrypted sequence numbers representative of successively increasing sequence numbers. At 304, logic 24 decrypts the given ciphertext message to recover plaintext 306 and a candidate sequence number s.”);
(McGrew includes the complete t-bit sequence number in encrypted packet content and recovers that value at the receiver. In the proposed combination, the t-bit value is the 64-bit ESN, which is determined from the packet without predicting an omitted portion.)
and for a second configuration, determine ESN using prediction. (see McGrew, [¶¶0006, 0027]: “Some communication security protocols omit part of the sequence number, and rely on the receiver’s ability to correctly guess the omitted part. This is done in Secure RTP and in ESP with the ‘extended sequence number’ facility. The receiver estimates all or part of the sequence number of a message, based on the ordering of the message. This process is used by SRTP and ESP.”);
(McGrew teaches ESP extended-sequence-number processing in which the receiver estimates the omitted portion from message ordering. This estimation constitutes determining the ESN using prediction.)
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 Minnick’s NIC based IPSec packet processing apparatus to incorporate McGrew’s alternative anti replay sequence-number configurations. McGrew explains that estimating an omitted portion of an ESP extended sequence number can create synchronization problems and provides an alternative in which the complete sequence number is incorporated into encrypted packet content and recovered by the receiver. A person of ordinary skill would have been motivated to configure Minnick’s NIC to support both techniques to maintain compatibility with conventional ESP ESN processing while permitting direct recovery of the complete ESN when reduced synchronization risk was desired. The combination would predictably determine an ESN from packet content without prediction in one configuration and determine the ESN by predicting its omitted portion in another configuration.
Regarding claim 6,
Minnick teaches:
wherein when the packet to be received is encrypted using Internet Protocol Security (IPSec), the circuitry is to not predict the ESN based on an IPSec standard; (see Minnick, [¶0029]: “Header information can include, for example, a source address, a destination address, an SPI, one or more protocol type, etc. When decrypting an IPSec packet, the header information is used to determine whether a packet that has been received is an IPSec packet.”);
(see McGrew, [¶¶0042-0043, 0095]: “With reference to FIG. 3B, at 302, logic 24 receives a sequence of ciphertext messages assumed to include encrypted plaintext and encrypted sequence numbers representative of successively increasing sequence numbers. At 304, logic 24 decrypts the given ciphertext message to recover plaintext 306 and a candidate sequence number s. If AERO is used in a higher-layer protocol such as IPsec, TLS, DTLS, or SSH, it reduces the overhead of those protocols, and thus makes better use of whatever wireless links it may be traversing.”);
(Minnick identifies whether a received packet is an IPsec packet, and McGrew recovers the sequence number directly from an encrypted IPsec packet. In the proposed combination, the circuitry recovers the ESN without performing Lou’s RFC 4303 prediction.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to configure Minnick’s circuitry, after determining that a received packet is an IPsec packet, to use McGrew’s direct sequence number recovery without performing IPsec standard prediction. Because McGrew makes the sequence number information recoverable from the encrypted packet, prediction of omitted sequence number information would be unnecessary. A person of ordinary skill would have been motivated to avoid redundant sequence number processing and the complexity associated with estimating information already recoverable from the packet.
Regarding claim 7,
McGrew teaches:
wherein the received packet is encrypted in accordance with Internet Protocol Security (IPSec), MACsec, Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), or Google® PSP Security Protocol (PSP); (see McGrew, [¶¶0095-0096]: “If AERO is used in a higher-layer protocol such as IPsec, TLS, DTLS, or SSH, it reduces the overhead of those protocols, and thus makes better use of whatever wireless links it may be traversing. AERO is an authenticated encryption method that strongly resists misuse.”);
(McGrew teaches using an authenticated encryption method with IPsec, TLS, or DTLS. Accordingly, McGrew teaches at least the claimed IPsec alternative for encrypting the received packet.)
Claim 13 recites substantially the same limitations as claim 7 in computer-readable medium form. Accordingly, claim 13 is rejected for the same reasons set forth above with respect to claim 7.
Claim 18 recites substantially the same limitations as claim 7 in method form. Accordingly, claim 18 is rejected for the same reasons set forth above with respect to claim 7.
Regarding claim 8,
Minnick teaches:
wherein the network interface device comprises one or more of: a network interface controller (NIC), a remote direct memory access (RDMA)-enabled NIC, SmartNIC, router, switch, forwarding element, infrastructure processing unit (IPU), data processing unit (DPU), or edge processing unit (EPU); (see Minnick, [¶0020]: “FIG. 2 is one embodiment of a block diagram of a network interface coupled to a network. In one embodiment, Network Interface (NI) 210 is a communication interface that enables an electronic system to communicate with other electronic systems coupled to network 220. For example, NI 210 can be a Network Interface Card (NIC). In one embodiment, traffic streams are received from network 220 into buffer 211 on NI 210.”);
(Minnick teaches that the network interface device can be a network interface card, thereby satisfying the claimed NIC alternative.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement McGrew’s secure packet processing apparatus using Minnick’s network interface card because Minnick teaches that cryptographic operations can be offloaded to the NIC to decrypt and authenticate received packets before transfer to host memory. A person of ordinary skill would have been motivated to make this modification to reduce the cryptographic processing burden on the host processor and improve packet processing performance.
Claim 14 recites substantially the same limitations as claim 8 in computer-readable medium form. Accordingly, claim 14 is rejected for the same reasons set forth above with respect to claim 8.
Claim 20 recites substantially the same limitations as claim 8 in method form. Accordingly, claim 20 is rejected for the same reasons set forth above with respect to claim 8.
Regarding claim 9,
McGrew teaches:
A non-transitory computer-readable medium comprising instructions stored thereon, that if executed by one or more processors, cause the one or more processors to: configure a network interface device to: (see McGrew, [¶0079]: “The TX unit 14 may be a network interface unit (e.g., network interface card), part of a wired or wireless transceiver, etc. The processor 504 is a microcontroller or microprocessor, for example, configured to execute software instructions stored in the memory 508. The memory 508 may comprise read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical/tangible (e.g., non-transitory) memory storage devices. Thus, in general, the memory 508 may comprise one or more computer readable storage media (e.g., a memory device) encoded with software comprising computer executable instructions and when the software is executed (by the processor 504) it is operable to perform the operations described herein.”);
(McGrew provides a non-transitory computer-readable storage medium containing processor-executable instructions for controlling the disclosed operations of a network-interface unit, such as NIC.)
Claim 9 recites substantially the same limitations as claim 1 in non-transitory computer-readable-medium form. Accordingly, claim 9 is rejected for the same reasons set forth above with respect to claim 1.
Regarding claim 15,
McGrew teaches:
A computer-implemented method comprising: at a network interface device: (see McGrew, [¶¶0031, 0079]: “As shown in FIG. 2A, the sender 10 includes encryption logic 12 and a transmitter unit 14. The encryption logic 12 may take the form of firmware (digital logic gates) in fixed or programmable form, or (software) instructions that are executed by a processor (e.g., microprocessor). The TX unit 14 may be a network interface unit (e.g., network interface card), part of a wired or wireless transceiver, etc.”);
(McGrew performs the transmitting method using processor executed software or programmable circuitry associated with a transmitting network-interface unit, such as a NIC.)
for a first configuration, including an Extended Sequence Number (ESN) value in a packet prior to transmission, (see McGrew, [¶0033]: “The sender maintains a t-bit sequence number s, which is initially equal to zero. To encrypt a plaintext P, the sender concatenates the sequence number s with P, then encrypts the result with an arbitrary-length pseudorandom permutation (such as the AES-XCB mode defined in IEEE 1619.2), using a secret key K. The resulting ciphertext C is the entire message used in the security protocol; it incorporates encryption, message authentication, and anti-replay sequencing data.”);
(McGrew includes the complete t-bit anti-replay sequence number in the packet’s encrypted content before transmission. In the proposed configuration, the t-bit sequence number value is implemented as a 64-bit ESN.)
for a second configuration, including a Sequence Number (SN) value in the packet prior to transmission, (see McGrew, [¶¶0005, 0026]: “Thus, a typical communications security protocol includes an IV, an ICV, and a sequence number. An IV can be 8-16 bytes, an ICV is often 12-16 bytes, and a sequence number is often 4 bytes, for a total of 24-36 bytes of overhead. Typical communication security protocols provide anti-replay service using the Authenticated Sequence Number (ASN) technique; ESP, AH, SRTP, 802.1AE, 802.11i, SSL, TLS, DTLS, and SSH all use a variant of this method. A sequence number is incorporated in each message that is sent, and that field is included in the part of the message that is authenticated. The sequence number fields of successive messages are set to successive numbers.”);
(McGrew teaches established protocols, including ESP, incorporating a conventional four-byte sequence number field into each message before transmission. The four-byte value provides the claimed non-extended SN configuration.)
and transmitting the packet to a receiver network interface device. (see McGrew, [¶¶0029, 0031, 0079-0080]: “The sender 10 encrypts packets and sends them, via network/communication medium 30, to the receiver 20. The transmitter unit 14 is any suitable transmitter that is configured to transmit packets across the physical communication medium of interest, whether wireless or wired (electrical or optical). The TX unit 14 may be a network interface unit (e.g., network interface card), part of a wired or wireless transceiver, etc. Receiver 600 includes a receiver (RX) unit 22 to receive a communication signal from communication medium 30 and recover ciphertext from the received communication signal.”);
(McGrew’s transmitting network-interface unit sends the encrypted packet over a wired or wireless network to a receiving apparatus having an RX network-interface unit.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement McGrew’s packet transmission method using Minnick’s NIC based IPsec processing apparatus. Minnick teaches that cryptographic operations may be offloaded to a network interface card to decrypt and authenticate network packets before transferring them to host memory, thereby reducing the cryptographic processing burden on the host processor and improving packet processing performance. A person of ordinary skill would therefore have been motivated to configure Minnick’s network-interface circuitry to perform McGrew’s transmission method and selectively use McGrew’s conventional four-byte sequence number configuration or complete t bit sequence-number configuration. Implementing McGrew’s complete t bit value as a 64-bit ESN while retaining its conventional four-byte SN configuration would predictably provide a NIC based device capable of supporting both extended and conventional sequence number processing and transmitting the resulting packet to a receiving network interface device.
Claims 2, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over McGrew et al, (U.S. Pub No. 2015/003,3014 A1, hereinafter “McGrew”) in view of Minnick et al (U.S. Pub. No. 2003/004,6585 A1, hereinafter “Minnick”) and in further view of Bansal et al (U.S. Pub. No. 2010/019,9085 A1, hereinafter “Bansal”)
Regarding claim 2,
Bansal teaches:
wherein an Initialization Vector (IV) of a payload of the received packet comprises the ESN; (see Bansal, [¶¶0034, 0036, 0045]: “At block 440, for example, according to RFC 3686, a 16-byte IV is included with encrypted blocks of data and the cipher block data unit size is 16 bytes. Also In one example, the 16-byte IV is broken into three sections. These three sections include a prepend section that has a 4-byte data length, a generated section that has an 8-byte data length and an append section that has a 4-byte data length. In field 520, for example, is the value for a generated section of the IV that is generated consistent with RFC 3686. For example, an 8-byte value is generated in any manner that leads to a high likelihood that the value is unique for the lifetime of a given security association. In one implementation, the information is used by composition feature 212 to determine the composition of an initialization vector included with encrypted data exchanged with the other node. This exchanging, for example, includes either sending or receiving encrypted data via secure network connection 150.”);
(Bansal teaches an IV included with received IPsec ESP encrypted data and having an eight-byte generated section that is unique during the security association. In the proposed combination, McGrew’s complete 64-bit ESN constitutes Bansal’s eight-byte generated section, such that the IV included with the received ESP data comprises the ESN.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Minnick and McGrew to use McGrew’s 64-bit ESN as the eight-byte generated section of Bansal’s initialization vector because Bansal teaches that the eight-byte value may be generated in any manner that provides uniqueness during the security association. Such a modification would have predictably reused an existing packet-specific 64-bit value to provide a unique IV while reducing the need to generate and maintain a separate per-packet IV value.
Claim 10 recites substantially the same limitations as claim 2 in computer-readable medium form. Accordingly, claim 10 is rejected for the same reasons set forth above with respect to claim 2.
Claim 16 recites substantially the same limitations as claim 2 in method form. Accordingly, claim 16 is rejected for the same reasons set forth above with respect to claim 2.
Claims 3, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over McGrew et al, (U.S. Pub No. 2015/003,3014 A1, hereinafter “McGrew”) in view of Minnick et al (U.S. Pub. No. 2003/004,6585 A1, hereinafter “Minnick”) in view of Bansal et al (U.S. Pub. No. 2010/019,9085 A1, hereinafter “Bansal”) and in further view of Gooding et al (U.S. Pub. No. 2015/028,1278 A1, hereinafter “Gooding”)
Regarding claim 3,
Gooding teaches:
wherein the IV is consistent with one or more of Internet Engineering Task Force (IETF) Request For Comment (RFC) 4106, RFC 4543, or RFC 7634; (see Gooding, [¶0183]: “Several new AES encryption modes of operation have been specified for Encapsulated Security Protocol (ESP): Counter Mode (CTR) [RFC3686], Galois/Counter Mode (GCM) [RFC4106], and Counter with Cipher Block Chaining-Message Authentication Code (CBC-MAC) Mode (CCM) [RFC4309]; and one that has been specified for both ESP and AH: the Galois Message Authentication Code (GMAC) [RFC4543].”);
(Gooding identifies GCM under RFC 4106 and GMAC under RFC 4543 as standardized AES modes for IPsec ESP. In the proposed combination, the ESN containing ESP initialization vector provided by McGrew and Bansal is implemented using Gooding’s RFC 4106 GCM or RFC 4543 GMAC mode, thereby providing an IV consistent with at least one of the recited RFCs.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Minnick, McGrew, and Bansal to use Gooding’s RFC 4106 GCM or RFC 4543 GMAC mode because Gooding teaches that these modes are specified for IPsec ESP and offer advantages over traditional modes. A person of ordinary skill would have been motivated to make this modification to provide standardized and compatible ESP encryption or authentication while retaining the unique initialization vector taught by Bansal.
Claim 11 recites substantially the same limitations as claim 3 in computer-readable medium form. Accordingly, claim 11 is rejected for the same reasons set forth above with respect to claim 3.
Claim 17 recites substantially the same limitations as claim 3 in method form. Accordingly, claim 17 is rejected for the same reasons set forth above with respect to claim 3.
Claims 4, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over McGrew et al, (U.S. Pub No. 2015/003,3014 A1, hereinafter “McGrew”) in view of Minnick et al (U.S. Pub. No. 2003/004,6585 A1, hereinafter “Minnick”) and in further view of Patwardhan et al (U.S. Pub. No. 2009/007,5628 A1, hereinafter “Patwardhan”)
Regarding claim 4,
Patwardhan teaches:
wherein a header of the received packet comprises the ESN; (see Patwardhan, [¶0066]: “In one aspect the cryptosync 500 includes the fields of Route Counter 510, the StreamID 512, SAR Reset Counter 514, the SAR Sequence Rollover Counter 516, and the SAR Sequence Number 518. The cryptosync is generated from a concatenation of the fields as shown. In practice, at the transmitting terminal, the cryptosync may be obtained from the header of the packet generated by the Connection Layer in preparing the subpacket. At the receiving terminal, the cryptosync is extracted from the header of the received subpacket.”);
(Patwardhan teaches that the sequence number and sequence rollover counter are concatenated as part of synchronization information carried in the packet header and extracted from the header at the receiving terminal. In the proposed combination, McGrew’s corresponding sequence number portion and higher order rollover portion constitute the ESN included in the received packet header.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of Minnick and McGrew to include the ESN in the packet header, as taught by Patwardhan, because Patwardhan teaches that carrying the sequence number and rollover information in the header allows the receiving terminal to extract the synchronization information from the received packet. A person of ordinary skill would have been motivated to make this modification so that the receiver could obtain the complete sequence information directly from the packet header and properly process the received packet.
Claim 12 recites substantially the same limitations as claim 4 in computer-readable medium form. Accordingly, claim 12 is rejected for the same reasons set forth above with respect to claim 4.
Claim 19 recites substantially the same limitations as claim 4 in method form. Accordingly, claim 19 is rejected for the same reasons set forth above with respect to claim 4.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over McGrew et al, (U.S. Pub No. 2015/003,3014 A1, hereinafter “McGrew”) in view of Minnick et al (U.S. Pub. No. 2003/004,6585 A1, hereinafter “Minnick”) and in further view of Lou et al (U.S. Pub. No. 2016/033,7398 A1, hereinafter “Lou”)
Regarding claim 5,
Lou teaches:
wherein the prediction is consistent with Internet Engineering Task Force (IETF) Request For Comment (RFC) 4303, “IP Encapsulating Security Payload (ESP),” (December 2005); (see Lou, [¶0020]: “Note that in some circumstances the sequence number counter value may actually require more bits than 32-SW. In this event, only the lowest order 32-SW bits of the sequence number counter value are written to the sequence number field. The remaining higher order bits of the sequence number counter value are not transmitted, but can be reconstructed as necessary at the receiver. In an embodiment, this reconstruction may be done according to the algorithm specified in RFC 4303, Appendix A, published by the IETF.”);
(Lou teaches reconstructing the untransmitted higher order sequence number bits at the receiver using the prediction algorithm specified in RFC 4303, Appendix A.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the apparatus of McGrew and Minnick to perform ESN prediction using Lou’s RFC 4303 Appendix A algorithm because Lou teaches that the algorithm reconstructs higher-order sequence-number bits that are not transmitted in the packet. A person of ordinary skill would have been motivated to make this modification to provide a standardized method for determining the complete sequence number at the receiver.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARHAM AHMED whose telephone number is (571)272-3726. The examiner can normally be reached Monday-Friday 7:30 am - 5 pm. Alternate Friday off..
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, Alexander Lagor can be reached at (571) 270-5143. 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.
/ARHAM NMN AHMED/ Examiner, Art Unit 2437
/BENJAMIN E LANIER/ Primary Examiner, Art Unit 2437
