DETAILED ACTION
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.
This Office Action is in response to the communication filed on 08/13/2026.
Claims 1, 8-12, 15, and 17-20 have been amended.
Claims 1-20 are pending for consideration.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Yao et al. ("A Lightweight Multicast Authentication Mechanism for Small Scale IoT Applications")(hereinafter Yao) in view of Kumar (U.S. 9,473,388)(hereinafter Kumar) and in further view of Benton et al. (U.S. 2019/0129694)(hereinafter Benton).
Regarding claims 1 and 18, Yao teaches receiving a message payload (Yao: see Page 3697 Section III.B, "When node i receives such a multicast message M, five steps are needed for authentication");
initializing a multicast message authentication code (MAC) tag (Yao: see Page 3697 Section V.B, " Generally, the accumulated key Kz can be randomly selected. But for the security of multicast authentication (the analysis is given in Section VI), there must be enough bits of 1 in the accumulated value or signature, we make Kz = {1}r ");
generating, by a network interface of the NoC-based SoC, a first-format tag based on a hash of a pre-shared symmetric key and the message payload (Yao: see Pages 3696-3697 Section V.B, "The revised Nyberg's fast one-way accumulator uses the following two things as the accumulated items: 1) the shared keys between the sender and the destinations; and 2) the multicast data. And it uses HMAC() to do hashing");
generating, by the network interface, a second-format tag (Yao: see Page 3696 Section III.C, "It can be seen that the length of the hash code in Nyberg’s fast one-way accumulator depends on t and d. Let the maximum number of accumulated items N be 210 and the security level t be 10, then the length of the hash code is 278 Kbits, which is much longer than the hash code (128-512 bits) of existing hash functions. A simple way to get the required long hash code is hashing the accumulated item to a short hash code first, and then using the short hash code as a seed for a binary random sequence generator. From this seed, many pseudorandom bits can be generated for the long hash code");
generating, by the network interface, a transformed tag that corresponds to the source node based on a bit length transformation of the second-format tag (Yao: see Page 3697 Section V.B Equation (15)(alpha transformation), "Step2. Node S computes the accumulated value on each two-tuple (KS,i, Data) in the accumulated item set according to Equation (15)"); and
accumulating, by the network interface, the transformed tag into the multicast MAC tag (Yao: see Page 3697 Section V.B Equation (14)(Logic Multiplication between MAC tag and transformed tag)”); and
generating, by the network interface, a multicast authenticated packet based on the multicast MAC tag (Yao: see Page 3697 Section V.B., “M: multicast message, M =“IDs||Data||Z”; "Step 3. Multicast message M is constructed and sent. Here M =“IDS||Data||Z” ").
However, Yao does not teach a source node within a network-on-chip (NoC)- based system-on-chip (SoC), a message payload, wherein the NoC-based SoC comprises a packet switching network with a set of one or more routers that is configured to route the message payload between the source node to a destination node within the NoC-based SoC; initializing, by the source node; and generating, by the network interface, a second-format tag by seeding a set of one or more pseudorandom number generators with the first- format tag to produce a set of one or more pseudorandom values that extend the first-format tag into the second-format tag.
Nevertheless, Kumar – which is in the same field of endeavor – teaches a source node within a network-on-chip (NoC)- based system-on-chip (SoC), a message payload (Kumar: see Col 19 Claim 1, "A method, comprising: generating one or more multicast trees for a provided Network on Chip (NoC) interconnect comprising a plurality of nodes; configuring a source node from the plurality of nodes to receive a multicast message, the configuring the source node comprising storing the generated one or more multicast trees at the source node"), wherein the NoC-based SoC comprises a packet switching network with a set of one or more routers that is configured to route the message payload between the source node to a destination node within the NoC-based SoC (Kumar: see Col 1 lines 25-30, "NoC is a global shared communication infrastructure made up of several routing nodes interconnected with each other using point-to-point physical links. Messages are injected by the source and are routed from the source node to the destination over multiple intermediate nodes and physical links"); and
initializing, by the source node (Kumar: see Col 9 lines 37-39, "a source component injects a multicast message at a NoC node with which it is connected, which acts as a source node").
Yao and Kumar are analogous art because they are from the same field of endeavor. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to incorporate Yao’s lightweight multicast authentication system into the NoC multicast topology system of Kumar because both references teach multicast authentication communications among resource constrained devices. The suggestion/motivation for doing so would be to reduce the resources required to authenticate multicast messages in the resource constrained devices.
Yao and Kumar fail to teach generating, by the network interface, a second-format tag by seeding a set of one or more pseudorandom number generators with the first- format tag to produce a set of one or more pseudorandom values that extend the first-format tag into the second-format tag.
Nevertheless, Benton-which is in the same field of endeavor- teaches generating, by the network interface, a second-format tag by seeding a set of one or more pseudorandom number generators with the first-format tag to produce a set of one or more pseudorandom values that extend the first-format tag into the second-format tag (Benton: see Page 6 paragraph 0034, “A plurality of pseudorandom number sets from the plurality of PRNGs is combined into a combined number set (block 340). In an example, randomization engine 140 combines PRN sets 272-275 into combined number set 290. In an example, PRNGs 152-155 execute in parallel to generate combined number set 290 simultaneously. In an example, four PRNGs 152-155 executing in parallel may generate combined number set 290 approximately times faster than one PRNG 152 executing alone to generate combined number set 290”).
Yao, Kumar, and Benton are analogous art because they are from the same field of endeavor. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to incorporate Benton’s use of parallel PRNGs to create a combined set of numbers to extend the length of Yao’s short hash code. The suggestion/motivation for doing so would be to maximize the strength/security of the fast one-way accumulator.
Regarding claims 2 and 19, Yao teaches the message payload (Yao: see Page 3697 Section III.B, "When node i receives such a multicast message M…”). Yao does not explicitly teach that the payload comprises a cache invalidation message; however, the cache invalidation message is non-functional descriptive material of the message payload.
Regarding claim 3, Yao teaches initializing the multicast MAC tag comprises generating a bit string of length r, wherein the bit string comprises a sequence of ones. (Yao: see Page 3697 Section V.B, "Generally, the accumulated key Kz can be randomly selected. But for the security of multicast authentication (the analysis is given in Section VI), there must be enough bits of 1 in the accumulated value or signature, we make Kz = {1}r ").
Regarding claim 4, Yao teaches the multicast MAC tag comprises an accumulated hash (Yao: see Page 3694 Section III.A, "If one starts with an initial value x∈X, and for all y1,y2,…yn ∈ Y, the accumulated hash value is ")
PNG
media_image1.png
30
427
media_image1.png
Greyscale
Regarding claim 5, Yao teaches the multicast MAC tag comprises a one-way hash function with a quasi-commutative property (Yao: see Page 3693 Section I, "First, we discover that the Nyberg’s fast one-way accumulator has a property of absorbency in addition to the one-way and quasi-communicative properties, which makes it suitable for applications where accumulated items are dynamic") .
Regarding claim 6, Yao teaches the multicast MAC tag comprises a fast variant of a one-way accumulator (Yao: see Page 3695 Section III.B, "For the accumulated items set X ={x1 …xm}, the accumulated value of Nyberg’s fast one-way accumulator can be denoted by Equation (7)").
PNG
media_image2.png
111
442
media_image2.png
Greyscale
Regarding claim 7, Yao teaches the hash comprises a keyed hash function (Yao: see Section IV, "Since a HMAC function also has the one-way property as a hash function, a HAMC function is used to substitute the hash function h in Nyberg’s fast one way accumulator so as to embed the MAC’s computing process into Nyberg’s fast one-way accumulator").
Regarding claim 8, Yao, Kumar, and Benton teach (i) the pre-shared symmetric key is associated with (a) another source node within the NoC-based SoC that is configured as a multicast sender (Kumar: see Col 5 lines 48-51, “Multicast support in a NoC allows source components to send messages to a group of destination components with a single message transmitted by the source component”), and (b) the source node, and (ii) the destination node is configured as a multicast receiver (Kumar: see Col 10 lines 54-56, “Each source node can reach any destination node through a single link/route”) (Yao: see section IV, "The accumulated item is changed from a single data to a two-tuple, which means each accumulated item is made up of two elements, one of which is the shared key between the multicast source and the destination, the other is the multicast data. The difference between two accumulation items is the shared key, which is only known to the sender and the corresponding receiver"). Motivation to combine Yao, Kumar, and Benton in the instant claim, is the same as that in claim 1.
Regarding claim 9, Yao, Kumar, and Benton teach generating the second- format tag further comprises extending the first-format tag by mapping the first-format tag to the second-format tag based on the set of one or more pseudorandom values (Benton: see Fig. 2B item 290; Page 4 paragraph 0028, “For example, a request may be to generate 56 PRNs, and each of PRNGs 152-155 generates 14 PRNs (e.g., PRN 292A-N, 293A-N, 294A-N, and 295A-N) which are then combined to form a combined number set 290”). Motivation to combine Yao, Kumar, and Benton in the instant claim, is the same as that in claim 1.
Regarding claim 10, Yao teaches replacing a set of one or more all-zero sub-strings in the second-format tag with a zero and replacing a set of one or more non-all-zero sub- strings in the second-format tag with a one (Yao: see Page 3695 Section III.B, "For each yi, it is divided into r substrings of length d and denoted as: yi = (yi,1,…,yi,r), yi,j is the jth bits string of length d. If yi,j != 0, it is replaced by 1. If yi,j is a string comprised of d 0s, it is replaced by 0").
Regarding claim 11, Yao teaches accumulating the transformed tag into the multicast MAC tag further comprises applying a bitwise logical AND operation ( Yao: see Equation 14 (logic multiplication)).
PNG
media_image3.png
75
477
media_image3.png
Greyscale
Regarding claims 12 and 13, Yao teaches combining the transformed tag with the plurality of transformed tags further comprises generating a collective product of the transformed tag and the plurality of transformed tags (Yao: see Page 3695 Section III.B Equation 8, "Consequently, the accumulated value Z can substitute partial accumulated value zi to be the member i’s witness information of Nyberg’s fast one-way accumulator. That is to say zi = Z for any xi. And HNyb(Z,Y) can be the verify function for it. In this way, if HNyb(Z,yi) = Z, then xi is an accumulated item of Z, otherwise, xi is not an accumulated item).
Regarding claim 14, Yao teaches generating the multicast authenticated packet comprises concatenating the message payload with the multicast MAC tag (Yao: see Page 3697 Section V.B., "Step 3. Multicast message M is constructed and sent. Here M =“IDS||Data||Z” ").
Regarding claim 15, Yao, Kumar, and Benton teach parsing, by a network interface of a network-on-chip (NoC)-based system-on-chip (SoC)(Benton: Fig. 2b), a message payload and a multicast message authentication code (MAC) tag from a multicast authenticated packet, wherein the NoC-based SoC comprises a packet switching network with a set of one or more routers that is configured to route the message payload from a source node to a destination node within the NoC-based SoC (Kumar: see Col 1 lines 25-30, "NoC is a global shared communication infrastructure made up of several routing nodes interconnected with each other using point-to-point physical links. Messages are injected by the source and are routed from the source node to the destination over multiple intermediate nodes and physical links") (Yao: see Page 3697 Section V, "When node i receives such a multicast message M, five steps are needed for authentication. Step 1. The identifier of the claimed multicast source S, Data and the received signature Z′ (which may be different from the sent-out value Z) should be extracted from M, respectively. Step 2. Node i checks whether the number of “1” bits in signature Z′ meets the requirements (the reason is given in Section VI) or not. If not, the multicast is considered forged and should be discarded, else go to step 3. Step 3. Node i checks if it is a neighbor of or in the multicast source’s group according to IDS. If yes, go to step4");
generating, by the network interface, a first-format tag based on a hash of a pre-shared symmetric key and the message payload, wherein the pre-shared symmetric key is associated with (a) another source node within the NoC-based SoC that is configured as a multicast sender (Kumar: see Col 5 lines 48-51, “Multicast support in a NoC allows source components to send messages to a group of destination components with a single message transmitted by the source component”), and (b) the source node (Yao: see Page 3697 Section V, "Step 4. Node i uses the shared key KS,i between S and itself to compute yi = HMAC(KS,i, Data) and maps yi to bi = αr(yi)") (Kumar: see Col 10 lines 54-56, “Each source node can reach any destination node through a single link/route”);
generating, by the network interface, a second-format tag by seeding a set of one or more pseudorandom number generators with the first format tag to produce a set of one or more pseudorandom values that extend the first-format tag into the second-format tag (Yao: see Page 3696 Section III.C, "It can be seen that the length of the hash code in Nyberg’s fast one-way accumulator depends on t and d. Let the maximum number of accumulated items N be 210 and the security level t be 10, then the length of the hash code is 278 Kbits, which is much longer than the hash code (128-512 bits) of existing hash functions. A simple way to get the required long hash code is hashing the accumulated item to a short hash code first, and then using the short hash code as a seed for a binary random sequence generator. From this seed, many pseudorandom bits can be generated for the long hash code") (Benton: see Page 6 paragraph 0034, “A plurality of pseudorandom number sets from the plurality of PRNGs is combined into a combined number set (block 340). In an example, randomization engine 140 combines PRN sets 272-275 into combined number set 290. In an example, PRNGs 152-155 execute in parallel to generate combined number set 290 simultaneously. In an example, four PRNGs 152-155 executing in parallel may generate combined number set 290 approximately times faster than one PRNG 152 executing alone to generate combined number set 290”);
generating, by the network interface, a transformed tag that corresponds to the source node based on a bit length transformation of the second-format (Yao: see Page 3697 Section V, "Step 5. Node i performs logical multiplication operation on bi and the received signature Z′"); and
determining, by the network interface, authenticity of the multicast authenticated packet based on a comparison of an accumulation of the transformed tag into the multicast MAC tag with the multicast MAC tag (Yao: see Page 3697 Section V, " If Z′ = Z′ ⊙ bi, it indicates that this multicast message is from node S and its multicast data is not tampered. Otherwise, it indicates that the multicast data has been tampered or the multicast message is not from node S"). Motivation to combine Yao, Kumar, and Benton in the instant claim, is the same as that in claim 1.
Regarding claim 16, Yao teaches determining the authenticity of the multicast authenticated packet further comprises determining the multicast authenticated packet is valid based on a presence of the accumulation in the multicast MAC tag.(Yao: see Page 3697 Section V, " If Z′ = Z′ ⊙ bi, it indicates that this multicast message is from node S and its multicast data is not tampered. Otherwise, it indicates that the multicast data has been tampered or the multicast message is not from node S").
Regarding claim 17, Yao, Kumar, and Benton teach generating of the first-format tag and the second- format tag are pipelined using two pseudorandom number generators operating simultaneously in a staged configuration with a plurality of alternating hash generation cycles (Yao: see Page 3696 Section III.C, "It can be seen that the length of the hash code in Nyberg’s fast one-way accumulator depends on t and d. Let the maximum number of accumulated items N be 210 and the security level t be 10, then the length of the hash code is 278 Kbits, which is much longer than the hash code (128-512 bits) of existing hash functions. A simple way to get the required long hash code is hashing the accumulated item to a short hash code first, and then using the short hash code as a seed for a binary random sequence generator. From this seed, many pseudorandom bits can be generated for the long hash code") (Benton: see Page 6 paragraph 0034, “A plurality of pseudorandom number sets from the plurality of PRNGs is combined into a combined number set (block 340). In an example, randomization engine 140 combines PRN sets 272-275 into combined number set 290. In an example, PRNGs 152-155 execute in parallel to generate combined number set 290 simultaneously. In an example, four PRNGs 152-155 executing in parallel may generate combined number set 290 approximately times faster than one PRNG 152 executing alone to generate combined number set 290”). Motivation to combine Yao, Kumar, and Benton in the instant claim, is the same as that in claim 1.
Regarding claim 20, Yao teaches the one or more tag verifiers comprise network interfaces of the NoC that are configured to verify the multicast authenticated packet before providing the message payload to the destination node (Yao: see Page 3697 Section V, " If Z′ = Z′ ⊙ bi, it indicates that this multicast message is from node S and its multicast data is not tampered. Otherwise, it indicates that the multicast data has been tampered or the multicast message is not from node S").
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 KELAH JANAE MCFARLAND-BARNES whose telephone number is (571)272-5953. The examiner can normally be reached Monday through Friday 8:00am until 4:00pm Central Time.
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, Lynn D Feild can be reached at 571-272-2092. 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.
/KELAH JANAE MCFARLAND-BARNES/Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431
Prosecution Insights