Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
2. Applicant’s arguments filed on 08/05/2025, with respect to the 35 U.S.C 103 rejections of claims 1-6 and 8-19 have been rejected under as being unpatentable over U.S. Publication No. 2020/0356699 ("Sastry") in view of U.S. Publication No. 2022/0131837 ("Van Nieuwenhuyze") and claims 7 and 20 have been rejected under 35 U.S.C. 103 as being unpatentable over Sastry in view of Van Nieuwenhuyze, and further in view of U.S. Publication No. 2017/0195884 ("Kang") have been fully considered and are persuasive. Therefore, the rejection has been withdrawn.
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.
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.
3. Claims 1-6 and 8-19 are rejected under 35 U.S.C. 103 as being unpatentable
over U.S. Publication No 20200356699 hereinafter Sastry in view of U.S. Publication
No. 20170055109 hereinafter Van.
As per claim 1 Sastry discloses:
An electronic device (Fig. 1) comprising:
at least a first electronic module (para 0018 "The first SoC die 105 may
include a plurality of SoC components (e.g., component A 110, component B
115, and component C 120) communicatively coupled any one or more of each
other or off-die components (e.g., component D 195 of the second SoC die) via
an interconnect endpoint 125.");
a secure element (para 0018 "The interconnect endpoint 125 may include
a security component 130, a component facing transceiver 155, a security
interconnect 160, and a interconnect packager 165.");
a router configured to transmit first data between the first module and a
second module (para 0019 "The component facing transceiver 155 may be
arranged (e.g., configured, designed, manufactured, structured, etc.) to send or
receive component messages to components (e.g., component A 110,
component B 115, component C 120, or component D 195)." Para 0020 "The
security interconnect 160 may be arranged to connect the messaging pipeline of
the component facing transceiver 155 and the interconnect packager 165 to the
security component 130. The security interconnect 160 may conform to a
standard interface of the security component 130. During operation, a component
message received from the component facing transceiver 155 or from the
interconnect 170 at the interconnect packager 165 may be passed to the security
component 130 to respectively encrypt or decrypt the message before continuing
on to its destination.")
wherein an electronic device is configured to verify, via an authentication
method, whether the third module is authorized to access the first data
(para 0020 "During operation, a component message received from the
component facing transceiver 155 or from the interconnect 170 at the
interconnect packager 165 may be passed to the security component 130 to
respectively encrypt or decrypt the message before continuing on to its
destination. In an example, an interconnect message header analyzer may be
present in the security component 130, the security interconnect 160, or
elsewhere in the interconnect endpoint 125 to read an interconnect message
header and determine if it is an encrypted message and cause the security
component 130 to decrypt or authenticate the message if it is an encrypted
message." Para 0027 "The access controller 150 may be arranged to manage
access rights of SoC components. The access controller 150 may include a
security-attributes-of-the-initiators registry arranged to store access rights of the
SoC components. The access controller 150 may also include a filter to block a
message (e.g., either a component message or an interconnect message) in
response to determining that an initiator component of the message does not
have access (e.g., to send a message) to a destination component based on the
security-attributes-of-the-initiators registry. In an example, the access controller
150 may access a security attribute index in the message header to determine
whether or not to allow a message transaction." para 0030 "As illustrated, the
initiator component 205 transmits a message to the interconnect endpoint 210
that services the initiator component. The interconnect endpoint 205 may pass
the message to its security component 215 to secure the message, creating a
secured message. The secured message may be returned to the interconnect
endpoint to be wrapped into an interconnect message. The interconnect
message may be transmitted, via the interconnect 220, to the interconnect
endpoint 225. The interconnect endpoint 225 reads a header of the interconnect
message and determines that it is a secured message. In response to this
determination, the interconnect endpoint 225 forwards the secured portions of
the interconnect message to its security component 230. In an example, the
security component 230 may negotiate with the security component 215 to obtain
the session key for this transaction at this time. However, in an example, the
session key negotiation may occur at any time between the receipt of the request
to secure the component message by the security component 215 and the
session key negotiation may be initiated by the security component 215." Para
0031 "In an example, the interconnect endpoint 210 and 225 are on the same
SoC die (e.g., performing intra-chip communications)." para 0034 "FIG. 4
illustrates the constituents of an encrypted message, according to an
embodiment. The encrypted message may be created after all or a portion of the
component message are encrypted by a cryptographic engine, such as those
described above with respect to FIG. 1, to create the encrypted message data
payload 320. The encrypted message may also include a security header 315
provided, for example, by the cryptographic controller or cryptographic circuit.
The security header 315 at least identifies the message as an encrypted
message to a recipient interconnect endpoint. Further, in an example, the
security header 315 may include identification information to permit a recipient
security component to decrypt the encrypted message data payload. For
example, the security header 315 may identify the initiating security component
to the destination security component to permit a session key negotiation
between the two. The encrypted message may also include the message header
305 to permit the interconnect to deliver the message without requiring any
concern for the encrypted nature of the message." The system allows
interconnect component (Router) to transmit data between a first initiator
component (Component A) and second component (Component B).
Furthermore, the system allows a destination component (Component D) via
decryption/authentication method to access the first data when it
request/negotiate the session key to access the message).
Sastry does not disclose:
a third module different from a first electronic module
a router coupled to the secure element and configured to transmit first
data between the first electronic module and a second module that is different
from the third module
whether the third module is authorized to access the first data that is being
transmitted between the first electronic module and the second module when it
requests access to the first data
Van discloses:
a third module different from a first electronic module (Fig. 2, element 206
and elements 208, 212 and Fig. 3, elements App1 and App2)
a router coupled to the secure element (Fig. 2, elements s202 and 210) and configured to transmit first data between the first electronic module and a second module that is different from the third module (para 0043 “In particular, FIG. 3 illustrates the NFC router (NFC ROUTER) 202, the device host (DEVICE HOST) 206, and the secure elements (SE1) 210 and (SE2) 212. Both of the secure elements 210, 212 for example store a PPSE (proximity payment system environment) application. Furthermore, the secure element 210 for example stores NFC transaction applications APP1 and APP2, and the secure element 212 for example stores NFC transaction applications APP2 and APP3.” Fig. 4, para 0047 " The method for example comprises operations 401 to 404
for generating a global list of available NFC applications, and an operation 405 in which the list of available applications is supplied to an NFC terminal in response to a new RF message. The data for forming the global list of available NFC transaction applications is for example collected by the NFC router 202 in response to a command from the device host 206, and incorporates data retrieved from each secure element, and optionally from other sources.” Para 0074 “Alternatively, if the list 220 includes more than one NFC transaction application capable of handling the RF transaction, then the NFC router 202 for example responds to the NFC terminal with a message including the NFC identifiers of the available transaction applications that can handle the NFC transaction. For example, the NFC terminal transmits a SELECT PPSE command to the NFC router, and the NFC router responds directly to the NFC terminal by transmitting a list of NFC payment applications available in the secure elements. If there is only one NFC transaction application that is compatible with the NFC terminal, the NFC terminal for example selects this NFC transaction application. Alternatively, if there is more than one transaction application that is compatible with the NFC terminal, then the NFC terminal for example selects the application having the highest priority, which is for example the application highest on the PPSE list. The NFC router 202 then for example sends a new RF message to the selected transaction application, which is routed by the NFC router 202 to the secure element storing the NFC transaction application.”)
Therefore, 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 electronic
device of Sastry to include a third module different from a first electronic module,
a router coupled to the secure element and configured to transmit first data
between the first electronic module and a second module that is different from
the third module and whether the third module is authorized to access the first
data that is being transmitted between the first electronic module and the second
module when it requests access to the first data, as taught by Van.
The motivation would have been to secure communicate between a secure element and other electronic modules.
As per claim 2, Sastry in view of Van discloses:
The device according to claim 1, wherein the secure element or the router
is configured to store the first data during implementation of the authentication
method (Sastry para 0042 and 0050).
As per claim 3, Sastry in view of Van discloses:
The device according to claim 2, wherein the first data are at least partially
visible for the third module when stored (Sastry para 0034 and 0042).
As per claim 4, Sastry in view of Van discloses:
The device according to claim 1, wherein the router is configured to
implement the authentication method (Sastry Fig. 2, para 0020, 0034, and 0045).
As per claim 5, Sastry in view of Van discloses:
The device according to claim 1, wherein the secure element is configured
to implement the authentication method (para 0020).
As per claim 6, Sastry in view of Van discloses:
The device according to claim 1, wherein the authentication method is
configured to authenticate the third module, and the first module, the second
module or a user of the device (Sastry Fig. 2, para 0020, 0034, and 0045).
As per claim 8, Sastry in view of Van discloses:
The device according to claim 1, wherein the router is configured to
implement a series of rules concerning a security policy of communications of the
device (Sastry para 0022, 0025 and 0028).
As per claim 9, Sastry in view of Van discloses:
The device according to claim 8, wherein the secure element is configured
to transmit the series of rules to the router (Sastry para 022 "A policy may
embody these goals and be applied to the characteristics of the cryptographic
engines to select an appropriate engine. Example goals may include cost, die
size, power consumption, data throughput, cryptographic strength, etc. For
example, a variety of cryptographic engines may implement AES. AES
implementations may conform to bandwidth requirements, such as greater than
ten gigabits per second (Gbps) for high performing implementation that will
generally use a large die size or draw significant power, greater than 100
megabits per second (Mbps) for medium performing implementation which may
have a smaller die size or consume less power than the high performing
implementation, and about one Mbps for a small (e.g., about 10,000 gates) die
size implementation. Thus, if SoC specification calls for an encryption bandwidth
of one Gbps, an implementation matching that throughput may be instantiated by
the SoC integrators with a medium performing AES block." Para 0023 " The
library of cryptographic engines may also include engines that perform other
security operations, such as hash functions, integrity engines (e.g., message
authentication code (MAC) engine), or public key operations (Rivest-Shamir-
Adleman cryptosystem (RSA), elliptic curve cryptography (ECC), etc.) These
classifications may be used to select the cryptographic engine or the integrity
engine to meet design goals of the SoC designers.").
As per claim 10, Sastry in view of Van discloses:
he device according to claim 1, wherein the second module is part of the
electronic device (Sastry Fig. 1).
As per claim 11, Sastry discloses:
A system comprising:
a first electronic device comprising a first module, a third module, and a
router; and a second electronic device different from the first electronic device
(para 0031, In an example, the interconnect endpoint 210 and 225 are not on the same SoC die (e.g., performing inter-chip communications).")
wherein the first electronic device is configured to verify, via an authentication method, whether the third module is authorized to access first data (para 0020 "During operation, a component message received from the
component facing transceiver 155 or from the interconnect 170 at the
interconnect packager 165 may be passed to the security component 130 to
respectively encrypt or decrypt the message before continuing on to its
destination. In an example, an interconnect message header analyzer may be
present in the security component 130, the security interconnect 160, or
elsewhere in the interconnect endpoint 125 to read an interconnect message
header and determine if it is an encrypted message and cause the security
component 130 to decrypt or authenticate the message if it is an encrypted
message." Para 0027 "The access controller 150 may be arranged to manage
access rights of SoC components. The access controller 150 may include a
security-attributes-of-the-initiators registry arranged to store access rights of the
SoC components. The access controller 150 may also include a filter to block a
message (e.g., either a component message or an interconnect message) in
response to determining that an initiator component of the message does not
have access (e.g., to send a message) to a destination component based on the
security-attributes-of-the-initiators registry. In an example, the access controller
150 may access a security attribute index in the message header to determine
whether or not to allow a message transaction." para 0030 "As illustrated, the
initiator component 205 transmits a message to the interconnect endpoint 210
that services the initiator component. The interconnect endpoint 205 may pass
the message to its security component 215 to secure the message, creating a
secured message. The secured message may be returned to the interconnect
endpoint to be wrapped into an interconnect message. The interconnect
message may be transmitted, via the interconnect 220, to the interconnect
endpoint 225. The interconnect endpoint 225 reads a header of the interconnect
message and determines that it is a secured message. In response to this
determination, the interconnect endpoint 225 forwards the secured portions of
the interconnect message to its security component 230. In an example, the
security component 230 may negotiate with the security component 215 to obtain
the session key for this transaction at this time. However, in an example, the
session key negotiation may occur at any time between the receipt of the request
to secure the component message by the security component 215 and the
session key negotiation may be initiated by the security component 215." Para
0031 "In an example, the interconnect endpoint 210 and 225 are on the same
SoC die (e.g., performing intra-chip communications)." para 0034 "FIG. 4
illustrates the constituents of an encrypted message, according to an
embodiment. The encrypted message may be created after all or a portion of the
component message are encrypted by a cryptographic engine, such as those
described above with respect to FIG. 1, to create the encrypted message data
payload 320. The encrypted message may also include a security header 315
provided, for example, by the cryptographic controller or cryptographic circuit.
The security header 315 at least identifies the message as an encrypted
message to a recipient interconnect endpoint. Further, in an example, the
security header 315 may include identification information to permit a recipient
security component to decrypt the encrypted message data payload. For
example, the security header 315 may identify the initiating security component
to the destination security component to permit a session key negotiation
between the two. The encrypted message may also include the message header
305 to permit the interconnect to deliver the message without requiring any
concern for the encrypted nature of the message." The system allows
interconnect component (Router) to transmit data between a first initiator
component (Component A) and second component (Component B).
Furthermore, the system allows a destination component (Component D) via
decryption/authentication method to access the first data when it
request/negotiate the session key to access the message).
Sastry does not disclose:
wherein a second electronic device comprises a second module
third module is authorized to access first data that is being transmitted between the first module and the second module via the router
Van discloses:
wherein a second electronic device comprises a second module
(Fig. 2, element 206 and elements 208, 212 and Fig. 3, elements App1 and App2)
third module is authorized to access first data that is being transmitted between the first module and the second module via the router
(para 0043 “In particular, FIG. 3 illustrates the NFC router (NFC ROUTER) 202, the device host (DEVICE HOST) 206, and the secure elements (SE1) 210 and (SE2) 212. Both of the secure elements 210, 212 for example store a PPSE (proximity payment system environment) application. Furthermore, the secure element 210 for example stores NFC transaction applications APP1 and APP2, and the secure element 212 for example stores NFC transaction applications APP2 and APP3.” Fig. 4, para 0047 " The method for example comprises operations 401 to 404
for generating a global list of available NFC applications, and an operation 405 in which the list of available applications is supplied to an NFC terminal in response to a new RF message. The data for forming the global list of available NFC transaction applications is for example collected by the NFC router 202 in response to a command from the device host 206, and incorporates data retrieved from each secure element, and optionally from other sources.” Para 0074 “Alternatively, if the list 220 includes more than one NFC transaction application capable of handling the RF transaction, then the NFC router 202 for example responds to the NFC terminal with a message including the NFC identifiers of the available transaction applications that can handle the NFC transaction. For example, the NFC terminal transmits a SELECT PPSE command to the NFC router, and the NFC router responds directly to the NFC terminal by transmitting a list of NFC payment applications available in the secure elements. If there is only one NFC transaction application that is compatible with the NFC terminal, the NFC terminal for example selects this NFC transaction application. Alternatively, if there is more than one transaction application that is compatible with the NFC terminal, then the NFC terminal for example selects the application having the highest priority, which is for example the application highest on the PPSE list. The NFC router 202 then for example sends a new RF message to the selected transaction application, which is routed by the NFC router 202 to the secure element storing the NFC transaction application.”)
Therefore, 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 electronic
device of Sastry to include wherein a second electronic device comprises a second module third module is authorized to access first data that is being transmitted between the first module and the second module via the router, as taught by Van.
The motivation would have been to secure communicate between a secure element and other electronic modules.
As per claim 12, the implementation of the electronic device of claim 1 will
execute the method of claim 1. The claim is analyzed with respect to
claim 1.
As per claim 13, the claim is analyzed with respect to claim 2.
As per claim 14, the claim is analyzed with respect to claim 3.
As per claim 15, the claim is analyzed with respect to claim 4.
As per claim 16, the claim is analyzed with respect to claim 5.
As per claim 17, the claim is analyzed with respect to claim 7.
As per claim 18, Sastry in view of Van discloses:
The method according to claim 12, wherein the authentication method is
implemented by an external server (Sastry para 0047)
As per claim 19, Sastry in view of Van discloses:
The method according to claim 12, wherein the authentication method
comprises executing secondary rules (Sastry para 0022, 0025 and 0028).
4 Claims 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over
Sastry in view Van, and further in view of U.S. Publication No 20170195884 hereinafter
Kang.
As per claim 7, Sastry in view of Van discloses:
The device according to claim 1, wherein the router is configured (Sastry
para 0019 and 0020)
Sastry in view of Van does not disclose:
wherein a router is configured to request authorization to be in a secure
mode
Kang discloses:
wherein a router is configured to request authorization to be in a secure
mode (para 0008 "According to an exemplary embodiment of the present
invention, a system-on-chip (SOC) includes a processor core, a memory
connected to the processor core, and an interface unit connected to the
processor core. The memory stores instructions executed by the processor core
to change an operational mode of the SOC from a normal mode to a secure
mode based on a reception of access information for a target site when the
access information is received in the normal mode. A verification step is
performed on the access information in the secure mode." Para 0029 "Referring
to FIG 1, in a method of performing the secure communication in the mobile
system according to exemplary embodiments of the present invention, access
information for a target site (e.g., a website) is received in a normal mode (step
$100), and an operational mode of the mobile system is changed from the
normal mode to a secure mode based on a reception of the access information
(step S200). The access information may include an address and a port number
for accessing the target site. For example, the address may be provided as an
internet protocol (IP) address, a domain name, etc.")
Therefore, 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 electronic
device of Sastry to include wherein a router is configured to request authorization
to be in a secure mode, as taught by Kang.
The motivation would have been to increased security by properly
validating data in a secure manner.
As per claim 20, the claim is analyzed with respect to claim 7.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GARY S GRACIA whose telephone number is (571)270-5192. The examiner can normally be reached Monday-Friday 9am-6pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip Chea can be reached at 5712723951. 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.
/GARY S GRACIA/Primary Examiner, Art Unit 2499