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 .
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because of the phase exist “system described here .” a corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 2,6,12,16, and 20 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1,5,12,16-17 of U.S. Patent 12,058241. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1,5,12,16-17 of U.S. Patent 12,058241 include all the limitations of claims 2,6,12,16, and 20 of the instant application.
Claims 2,6,12,16, and 20 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1,5,12,16-17 of U.S. Patent 12,058241 claims 12/058241 in view of Garstin US 2003/0131233
As per claims 2/12/20, Patent 12,058241 claims disclose all the highlighted limitations of the instant Application 18/793545
except generating, using the first security key, a network packet for transmitting encrypted content from the first device to the second device( emphasis added).
However, Garstin discloses generating, using the first security key, a network packet for transmitting encrypted content from the first device to the second device( 0045 he transmitter may randomly generate a secret key and transmit the secret key to the receiver in the first packet header or the two devices may agree to use a specific key during call set-up and generate a starting S-vector).
Garstin is considered to be analogous to the claimed invention because they are in the same field of packet encryption.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Patent to incorporate the teachings of Garstin and provide symmetric key.
Doing so would able to speed up the encryption process, thereby improving the encryption efficiency.
Patent claims 12,058241
Instant Application 18/793545
1. A method, comprising:
receiving, at a first device, a first security key associated with encrypting and decrypting data to be communicated between the first device and a second device;
receiving, at the first device, a second security key associated with encrypting and decrypting data to be communicating between the first device and the second device, the second security key being designated as inactive, the first device and the second device being included within a security grouping of computing devices that each receive the first security key and the second security key, the security grouping of computing devices including the first device, the second device, and one or more additional devices that share a common security key enabling each device from the security grouping of computing devices to encrypt and decrypt data to be communicated between respective devices of the security grouping of computing devices; receiving an indication that the second security key has been activated;
generating a network packet for transmitting encrypted content from the first device to the second device,
wherein the network packet includes: a first authentication header including authentication information for the network packet, wherein the authentication information includes a data sequence number (DSN ) and a packet counter value (PCV) ;
a payload including encrypted content of a message to be communicated to the second device, the encrypted content being encrypted using the second security key based on the second security key being activated; and a security tag computed over
the first authentication header and the payload; and
transmitting the network packet from the first device to the second device, wherein transmitting the network packet enables determining that the network packet has been transmitted successfully and securely via a communication channel.
5. The method of claim 3, wherein authenticating the network packet further includes: calculating an integrity check vector (ICV) based on the first authentication header and the payload; and determining that the network packet has not been modified based on the ICV matching the security tag included within the network packet.
12. A system, comprising: one or more processors; memory in electronic communication with the one or more processors; and instructions stored in the memory, the instructions being executable by the one or more processors to:
receive, at a first device, a first security key associated with encrypting and decrypting data to be communicated between the first device and a second device;
receive, at the first device, a second security key associated with encrypting and decrypting data to be communicating between the first device and the second device, the second security key being designated as inactive, the first device and the second device being included within a security grouping of computing devices that each receive the first security key and the second security key, the security grouping of computing devices including the first device, the second device, and one or more additional devices that share a common security key enabling each device from the security grouping of computing devices to encrypt and decrypt data to be communicated between respective devices of the security grouping of computing devices; receive an indication that the second security key has been activated; generate a network packet for transmitting encrypted content from the first device to the second device, wherein the network packet includes: a first authentication header including authentication information for the network packet, wherein the authentication information includes a data sequence number and a packet counter value; a payload including encrypted content of a message to be communicated to the second device, the encrypted content being encrypted using the second security key based on the second security key being activated; and a security tag computed over the first authentication header and the payload; and transmit the network packet from the first device to the second device, wherein transmitting the network packet enables determining that the network packet has been transmitted successfully and securely via a communication channel.
16. The system of claim 14, wherein authenticating the network packet further includes: calculating an integrity check vector (ICV) based on the first authentication header and the payload; and determining that the network packet has not been modified based on the ICV matching the security tag included within the network packet.
17. A non-transitory computer readable medium storing instructions thereon that, when executed by one or more processors, causes one or more computing devices to:
receive, at a first device, a first security key associated with encrypting and decrypting data to be communicated between the first device and a second device; receive, at the first device, a second security key associated with encrypting and decrypting data to be communicating between the first device and the second device, the second security key being designated as inactive, the first device and the second device being included within a security grouping of computing devices that each receive the first security key and the second security key, the security grouping of computing devices including the first device, the second device, and one or more additional devices that share a common security key enabling each device from the security grouping of computing devices to encrypt and decrypt data to be communicated between respective devices of the security grouping of computing devices; receive an indication that the second security key has been activated; generate a network packet for transmitting encrypted content from the first device to the second device, wherein the network packet includes: a first authentication header including authentication information for the network packet, wherein the authentication information includes a data sequence number and a packet counter value; a payload including encrypted content of a message to be communicated to the second device, the encrypted content being encrypted using the second security key based on the second security key being activated; and a security tag computed over the first authentication header and the payload; and transmit the network packet from the first device to the second device, wherein transmitting the network packet enables determining that the network packet has been transmitted successfully and securely via a communication channel.
2. (New) A method, comprising:
receiving, at a first device, a first security key associated with encrypting and decrypting data to be communicated between the first device and a second device;
generating, using the first security key, a network packet for transmitting encrypted content from the first device to the second device, wherein the network packet includes: an authentication header including authentication information for the network packet,
wherein the authentication information includes a data sequence number (DSN) and a packet counter value (PCV),
the DSN including an indication of an order of the network packet within a plurality of network packets in a transmission to the second device,
the PCV indicating a count of the plurality of network packets in the transmission to the second device; and
a payload including encrypted content of a message to be communicated to the second device; and
transmitting the network packet from the first device to the second device, wherein transmitting the network packet enables determining that the network packet has been transmitted successfully and securely via a communication channel based on the PCV and the DSN included within the authentication header (disclosed by patent claim 1)
6. (New) The method of claim 4, wherein authenticating the network packet further includes: calculating an integrity check vector (ICV) based on the authentication header and the payload; and determining that the network packet has not been modified based on the ICV matching a security tag included within the network packet.
12. (New) A system, comprising: at least one processor; memory in electronic communication with the at least one processor; and instructions stored in the memory, the instructions being executable by the at least one processor to:
receive, at a first device, a first security key associated with encrypting and decrypting data to be communicated between the first device and a second device;
generate, using the first security key, a network packet for transmitting encrypted content from the first device to the second device, wherein the network packet includes: an authentication header including authentication information for the network packet, wherein the authentication information includes a data sequence number (DSN) and a packet counter value (PCV), the DSN including an indication of an order of the network packet within a plurality of network packets in a transmission to the second device, the PCV indicating a count of the plurality of network packets in the transmission to the second device; and a payload including encrypted content of a message to be communicated to the second device; and transmit the network packet from the first device to the second device, wherein transmitting the network packet enables determining that the network packet has been transmitted successfully and securely via a communication channel based on the PCV and the DSN included within the authentication header.
16. (New) The system of claim 14, wherein authenticating the network packet further includes: calculating an integrity check vector (ICV) based on the authentication header and the payload; and determining that the network packet has not been modified based on the ICV matching a security tag included within the network packet.
20. (New) A non-transitory computer readable medium storing instructions thereon that, when executed by at least one processor, causes a first device to:
receive, at the first device, a first security key associated with encrypting and decrypting data to be communicated between the first device and a second device;
generate, using the first security key, a network packet for transmitting encrypted content from the first device to the second device, wherein the network packet includes: an authentication header including authentication information for the network packet, wherein the authentication information includes a data sequence number (DSN) and a packet counter value (PCV), the DSN including an indication of an order of the network packet within a plurality of network packets in a transmission to the second device, the PCV indicating a count of the plurality of network packets in the transmission to the second device; and a payload including encrypted content of a message to be communicated to the second device; and transmit the network packet from the first device to the second device, wherein transmitting the network packet enables determining that the network packet has been transmitted successfully and securely via a communication channel based on the PCV and the DSN included within the authentication header.
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.
Claim(s) 2-6,8-9,11-16,18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Garstin et al US 2003/0131233 in view of Donely et al US 2004/0193876.
As per claim 2, Garstin discloses a method, comprising:
receiving, at a first device, a first security key associated with encrypting and decrypting data to be communicated between the first device and a second device ( par 0046, Step 1 Receive secret key and generate K-vector using the secret key Initialize an S-vector following standard encryption transmitter is receiving a secret key, i.e. first secret key, fig.3, 0045 receiver agree on a secret key to be used for encryption/decryption of the plaintext in block 210 and 0046 Receive secret key and generate K-vector using the secret key Initialize an S-vector following standard encryption method such that S[i] = i for all 0 .ltoreq. i < 255 Scramble the initial S-vector using the K-vector where j = 0 for i = 0 to 255, j = j +S[i] + K[i]; swap S[i] and S[j].);
generating, using the first security key, a network packet for transmitting encrypted content from the first device to the second device( 0045 he transmitter may randomly generate a secret key and transmit the secret key to the receiver in the first packet header or the two devices may agree to use a specific key during call set-up and generate a starting S-vector.),
wherein the network packet (0049 beginning of each packet) includes:
an authentication header including authentication information for the network packet (0003 The header includes control information such as sequence number, 0049 sequence number to start the encryption process for each packet), wherein the authentication information includes a data sequence number (DSN)(0049 The sequence number, i.e. DSN, is incremented and the next sequence number is used to encrypt each next packet) and a packet counter value (PCV) (0049 the rollover counter, r,, i.e. PCV, is initially reset to zero in block 310 and the initial sequence number is randomly generated in block 320 for the first packet. ), the DSN including an indication of an order of the network packet within a plurality of network packets in a transmission to the second device (0051] The sequence number , i.e. DSN, comprises at least two bytes, a low order byte and a next-to-low order byte. If the sequence number is comprised of more than two bytes, the excess high-order part is used, the sequence number indicated the low and high order of the network packet ), the PCV indicating a count of the plurality of network packets in the transmission to the second device ( 0050 0050] The value of rollover counter r, i.e. PCV, is used when calculating a variable, j, used to generate the encryption stream. Likewise, to prevent the same encryption sequence between packets, byte sequence number k is used to calculate variable, i, used in generating the encryption stream); and
a payload including encrypted content of a message to be communicated to the second device (0028 the encryption stream is exclusive OR'd (XOR'd) with the next plaintext byte in the packet payload to generate the next ciphertext byte. And [0030] When all successive plaintext bytes within the next packet have been encrypted, the packet sequence number is incremented and the method loops back to calculate new values for variable i and j from the next successive packet sequence number. The initially generated S-vector is used for all successive packets.); and
transmitting the network packet from the first device to the second device (0064 0064] Both the transmitter and the receiver follow steps 1 through 5 to generate the same encryption stream, At the receiver, i.e. the second device, the stream of ciphertext is received and the encryption stream is used to decipher the ciphertext to recover the plaintext and Step 6 Transmitter: Calculate next byte ciphertext stream using C[k] = E .sym. P[k] where P[k] = k.sup.th byte of plaintext Receiver: Calculate next byte plaintext stream using P[k] = E .sym. C[k] ), wherein transmitting the network packet enables determining that the network packet has been transmitted successfully ( 0068 Utilizing the present efficient packet encryption method provides an increased level of security while reducing the computation time to successfully transmit an entire stream of payload plaintext by doing so [0067] The S-vector generated in blocks 230 and 240 is used to compute all variables in blocks 330 through 350 for each payload of plaintext to be transmitted. ) and securely via a communication channel based on the PCV and the DSN included within the authentication header ( 0069 injecting an additional variable in computing variable i, increases the security. Likewise, inclusion of the counter, based on the PCV, used for calculating variable j further increases the security of the present efficient packet encryption method by generating an encryption stream that repeats less frequently. And 0070 packet encryption method can be generated using a variety of methods for generating the initial sequence number, i.e. DSN, and the initial value for variable r).
Garstin does not disclose authentication header for the network packet.
However, Donley discloses authentication header for the network packet(par 0004, IPv4 packet with an authentication header that include the sequence number field serves as a counter that identifies the number of IP AH packets and the authentication data filed that contains digital signature, DES, MD5 and secure hash algorithm, and par 0046, the authentication options of the second form, such as, message authentication code 512 for an additional authentication for the packet, par 0057, when the message authentication code are identical, then the data contained in the packet is forwarded to the corresponding cryptographic agent of the receiving node, this can be seen as the packet with an authentication header has been successfully received by the receiving node).
Garstin and Donely are both considered to be analogous to the claimed invention because they are in the same field of packet encryption.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Garstin to incorporate the teachings of Donely and provide an authentication header of the network packets.
Doing so would able to verify the packet, thereby improving the packet integrity and authenticity of provider.
As per claim 3. Garstin and Donely discloses the method of claim 2, Donely discloses wherein transmitting the network packet from the first device to the second device causes the second device to authenticate the network packet by applying a copy of the first security key to one or more fields of the authentication header ( 0036 first and second endpoints and [0051] The cryptographic agent 316 of the second endpoints activates authentication on either or both directions of a TCP connection by providing the choice of algorithm(s) and keying material(s) for the algorithm and 0056 the message authentication code, with truncation to N bits, based on the pseudo-header of FIG. 6 and a shared secret, i.e. security key).
As per claim 4. Garstin and Donely discloses the method of claim 3, the combination discloses wherein authenticating the network packet includes causing the second device to determine that the network packet has been transmitted in a correct order within the plurality of network packets originating from the first device based on identifying a sequence of the DSN relative to DSNs included within other network packets of the plurality of network packets ( Garstin, par 0022 Using the sequence number to generate the encryption stream provides a method for deciphering packets at the destination regardless of the order in which they are received and [0051] The sequence number comprises at least two bytes, a low order byte and a next-to-low order byte. If the sequence number is comprised of more than two bytes, the excess high-order part is used, modulo 256, as the rollover counter r. Variable j is initialized to be equal to the high order byte of the sequence number in block 330. Variable i is calculated in block 330 as the exclusive OR of the low order byte of the sequence number with S[j]. 3 Step 3 Set variables i and j j = high order sequence number i = (low order sequence number) .sym. S[j] [0052] where S[j] is derived from the previously generated S-vector. Setting the initial value of variables i and j using the sequence number provides a method for reassembling, or synchronizing, the decryption of the packets at the receiver regardless of the order in which the packets are received and Donely discloses 0038 Internet layer of TCP/IP, and verifies that packets arrive completely and correctly at their destination, and (c) authenticates selected contents of a packet and 0045 The TCP header 400 includes fields for: source port 404, destination port 408, packet sequence number 412 (correct order), byte acknowledgment number 416 (which indicates the last byte number received and accepted before an acknowledgment is sent)).
As per claim 5, Garstin and Donely discloses the method of claim 4, Garstin discloses wherein authenticating the network packet further includes verifying that the network packet is not a repeat packet based on a comparison of a computed DSN to the DSN from the network packet, the computed DSN being computed over the authentication header and the payload ( 0025] Injecting S[r], into the encryption method generates an encryption stream where the encryption stream does not repeat over a long sequence of packets. Without inclusion of S[r], the encryption stream would repeat approximately every eleven minutes at 100 packets per second. 0026 S-vector is permuted during the encryption of each successive packet. In this embodiment, when the S-vector is first calculated, a copy of the S-vector is saved. For each successive byte of plaintext encrypted, the values within the S-vector pointed to by the first variable j and the second variable i are swapped. By swapping the values within the S-vector for each successive byte of plaintext, the S-vector is permuted over time so that the encryption stream generated for long plaintext payloads is less likely to repeat within a packet. When all of the bytes of plaintext within the packet have been encrypted, the initial S-vector is restored for use encrypting or decrypting the next packet and [0033] Using the sequence number to initialize the i and j variables makes the next value of i and j predictable. Injecting a third variable, S[j] when calculating the initial value of variable i eliminates the predictability of determining the values of variables i and j, making the present efficient packet encryption method more secure. Injecting S[r] into the calculation generates an encryption stream in which the packet encryption stream does not repeat as frequently, providing additional security from hackers).
As per claim 6. Garstin and Donely discloses the method of claim 4, Donley discloses wherein authenticating the network packet further includes: calculating an integrity check vector (ICV) based on the authentication header and the payload; and determining that the network packet has not been modified based on the ICV matching a security tag included within the network packet ([0004] FIG. 2A shows an IPv4 packet 200 with an authentication header 204. The authentication header 204 includes a next header field 208 (which is one byte long and identifies the higher level protocol that follows the AH), the payload length field 212 (which is one byte long and specifies the length of the Authentication data field 216), the Reserved field 220 (which is two byte field reserved for future use), the Security Parameters Index or SPI field 224 (which is four bytes long and identifies the security protocols being used in the packet), the sequence number field 228 (which is four bytes long and serves as a counter that identifies the number of IP AH packets it has already received that bear the same destination and SPI data), and the authentication data field 216 (which is of variable length and contains the Integrity Check Value or ICV (which is a digital signature of a packet generated using, for example, DES, MD5, or the Secure Hash Algorithm (SHA-1)))).
As per claim 8. Garstin and Donely discloses the method of claim 2, Donley discloses wherein the communication channel is an unsecure Ethernet wire that is part of a backend interface between the first device and the second device ([0053] FIG. 7 depicts the operations performed by the cryptographic agents in each node. In step 700 of FIG. 7, the cryptographic agent 316 of first node 300a and second node 300b negotiate protocol parameters over an insecure channel using conventional techniques. Typically, negotiation involves each party exchanging keys and, in some cases, digital certificates. A shared master key is computed from the exchanged keys. When the hashes in the finished messages exchanged by the first and second nodes agree, negotiation is completed. Typically, the exchange is validated at the cryptographic agent level by way of digital signatures).
As per claim 9. Garstin and Donely discloses the method of claim 2, wherein the network packet further includes an Ethernet header and an Internet Protocol header (0004 FIG. 2A shows an IPv4 packet 200 with an authentication header 204. The authentication header 204 includes a next header field 208 (which is one byte long and identifies the higher level protocol that follows the AH)).
As per claim 11. Garstin and Donely discloses the method of claim 2, Donley discloses wherein the payload is a same size as payloads across the plurality of network packets (0005] FIG. 2B shows an IPv4 packet 250 with an Encapsulating Security Payload or ESP header 254. The encapsulating security payload header includes the SPI and sequence 5 number fields 224 and 228 discussed above, the TCP or User Datagram Protocol (UDP) header 230,).
As per claims 12-16 and 18, those claims are rejected based on the same rational set forth in the claims 2-6 and 8 respectively.
As per claim 20, this claim is rejected based on the same rational set forth in the claim 2.
Claim(s) 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Garstin et al US 2003/0131233 in view of Donely et al US 2004/0193876 and Vom Scheidt et al US 2008/0114819(hereafter Vom).
As per claim 10. Garstin and Donely discloses the method of claim 2, Donely discloses wherein the authentication header includes four bytes, and wherein both the DSN and PCV are included within the four bytes of the authentication header (0004 the sequence number, i.e. DSN, field 228 (which is four bytes long and serves as a counter, i.e. PCV, that identifies the number of IP AH packets).
The combination fails to disclose Packet Header of thirty-two bytes.
However, Vom discloses Packet Header of thirty-two bytes ([0018] Header field 54A includes header information, and occupies the initial thirty-two bytes of section 50 (e.g., hexadecimal address range of 00-1F within header information section 50)).
Garstin and Donely and Vom are both considered to be analogous to the claimed invention because they are in the same field of packet encryption.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Garstin to incorporate the teachings of Donely, including the teaching of Vom, and provide an provides the essential metadata for routing data across networks. Doing so would be ensuring reliable delivery, thereby improving the packet delivery.
As per claim 19, this claim is rejected based on the same rational set forth in the claim 10.
Allowable Subject Matter
Claims 7/17/21 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.
Uyehara et al US 2009/0262743 discloses 0004 One embodiment is directed to a method of evaluating sequence of a packet stream comprising a plurality of packets, wherein each of the plurality of packets has an assigned sequence number. The method comprises acts of: receiving a packet of the plurality of packets; determining the sequence number of the packet; comparing the sequence number of the packet to an expected sequence number indicative of the highest received sequence number in the packet stream; determining, based on the act of comparing, whether the sequence number of the packet is greater than or equal to the expected sequence number; when it is determined that the sequence number of the packet is greater than or equal to the expected sequence number, determining that the packet is an in-order packet; and when it is determined that the packet is an in-order packet, incrementing a counter that counts the number of received in-order packets in the packet stream.
Maheshwari et al US 2008/0220742 discloses 0073] The processor may alternatively be configured to determine an authenticated header checksum sequence for the header to provide both authentication and error detection for the header. The authenticated header checksum sequence may be determined by the processor, where the processor is configured to determine a message authentication code (MAC) over [(the security key XORed with a counter) and the header] to generate a MAC result and divide the MAC result by a generator polynomial to generate a residue, where the authenticated checksum sequence includes the residue.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
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, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496