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 05/29/2026 regarding 35 U.S.C. 103 rejection of claims 1-6 and 8-19 as being unpatentable over U.S. Publication No 20200356699 hereinafter Sastry in view of U.S. Publication No. 20170055109 hereinafter Van. have been fully considered but they are not persuasive.
Applicant alleges on pg. 5 of 7 of arguments, third paragraph “Claim 1, as presently pending, recites that "the electronic device is configured to verify, via an authentication method, whether the third module is authorized to access the first data that is being transmitted between the first electronic module and the second module." Applicant respectfully submits that the prior art does not disclose or suggest the limitations of claim 1.”
Applicant further alleges on pg. 7 of 7 of arguments, second and third paragraph “Claim 11 recites that "the first electronic device is configured to verify, via an authentication method, whether the third module is authorized to access first data that is being transmitted between the first module and the second module via the router." As discussed above with respect to claim 1, the prior art does not disclose or suggest the limitations of claim 11. Method claim 12 recites "requesting, by a third module of the electronic device, access to the first data that is being transmitted between the first module and the second module, verifying, by an authentication method, whether the third module is authorized to access the first data; and providing the third module access to the first data after verifying that the third module is authorized to access the first data." As discussed above, neither reference teaches providing a third module access to data transmitted between a first module and a second module, much less performing an authentication method to verify whether the third module is authorized to access the first data before providing access.” Examiner respectfully disagrees.
Sastry discloses on paragraph 0018 on FIG. 1 a system 100 for a security plugin for an SoC platform, according to an embodiment. The system 100 may include a first SoC die 105 and a second SoC die 175 connected via an interconnect 170. 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. Sastry discloses a system (which is an electronic device as defined in paragraph 0049 i.e., Machine computer system) comprising a first SOC die connected to a second SOC die wherein both the first and second SOC die have components (components a-c in the first SOE die and component D in the second SOC die) are connected communicatively. Paragraph 0019 discloses “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., e.g., component A 110, component B 115, component C 120, or component D 195).”
Sastry system further discloses on paragraph 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. 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.” The electronic device includes a interconnect endpoint (Fig. 1 element 125) that includes a security component (Fig. 1, element 160) that encrypts, decrypts and authenticates component messages.
Sastry discloses on paragraph 0029 “FIG. 2 illustrates an example of a data flow in a system 200 for a security plugin for an SoC platform, according to an embodiment. The components of the system 200 may be implemented by the components discussed above with respect to FIG. 1. The system 200 may include an initiator component 205, an interconnect endpoint 210 with a security component 215, an SoC fabric including an interconnect 220, another interconnect endpoint 225 with security component 230, and a destination component 235. The solid arrows denote the message flow within the boundary of an interconnect endpoint and an SoC component.”
The following is the sequences of the messages between the components a-d. Sastry disclose on paragraph 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.” On paragraph 0031, Sastry discloses “In an example, the interconnect endpoint 210 and 225 are on the same SoC die (e.g., performing intra-chip communications). In an example, the interconnect endpoint 210 and 225 are not on the same SoC die (e.g., performing inter-chip communications). By securing the SoC component communications as illustrated in FIG. 2, malicious actors may be thwarted by denying them access to the messages as they move on the SoC interconnect 220. Further, any SoC components may be used without regard to which or a plurality of security configurations were selected by the SoC designers.” The component message is transmitted to between the first component to second component and to the third component after being able to be decrypted and authorized.
Fig. 7 and on paragraph0044 discloses“ At operation 730, the encrypted message may be transmitted across the interconnect. In an example, every message transmitted from the bus endpoint is encrypted by the security component. In an example, every message traversing a bus to which the bus endpoint is a terminus is encrypted by respective security components in endpoints of the bus. Thus, the entire interconnect consists of secured communications.” Which means every message must be decrypted and authenticated (see paragraphs 0020 and 0023). Therefore, Sastry discloses the electronic system is configured to verify, via an encryption/decryption/authentication method, whether the component C or component D is authorized to access the first/initiator component message that is being transmitted between the component A and component B. Furthermore, the attempt to decrypt a component message by component C or component D is requesting access to the component message, wherein the messages are provided by the component facing transceiver 155, i.e., router. For the reasons above, the rejection is maintained.
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 the electronic device is configured to verify, via an authentication method, whether the third module is authorized to access the first data that is being transmitted between the first electronic module and the second module. (para 0019 discloses “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., e.g., component A 110, component B 115, component C 120, or component D 195).”paragraph 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. 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 0029 “FIG. 2 illustrates an example of a data flow in a system 200 for a security plugin for an SoC platform, according to an embodiment. The components of the system 200 may be implemented by the components discussed above with respect to FIG. 1. The system 200 may include an initiator component 205, an interconnect endpoint 210 with a security component 215, an SoC fabric including an interconnect 220, another interconnect endpoint 225 with security component 230, and a destination component 235. The solid arrows denote the message flow within the boundary of an interconnect endpoint and an SoC component.” 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). In an example, the interconnect endpoint 210 and 225 are not on the same SoC die (e.g., performing inter-chip communications). By securing the SoC component communications as illustrated in FIG. 2, malicious actors may be thwarted by denying them access to the messages as they move on the SoC interconnect 220. Further, any SoC components may be used without regard to which or a plurality of security configurations were selected by the SoC designers.” Fig. 7, para 0044“ At operation 730, the encrypted message may be transmitted across the interconnect. In an example, every message transmitted from the bus endpoint is encrypted by the security component. In an example, every message traversing a bus to which the bus endpoint is a terminus is encrypted by respective security components in endpoints of the bus. Thus, the entire interconnect consists of secured communications.” Which means every message must be decrypted and authenticated (see paragraphs 0020 and 0023).”
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
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, 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:
The 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; (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 that is being transmitted between the first module and the second module via the router. (para 0019 discloses “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., e.g., component A 110, component B 115, component C 120, or component D 195).”paragraph 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. 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 0029 “FIG. 2 illustrates an example of a data flow in a system 200 for a security plugin for an SoC platform, according to an embodiment. The components of the system 200 may be implemented by the components discussed above with respect to FIG. 1. The system 200 may include an initiator component 205, an interconnect endpoint 210 with a security component 215, an SoC fabric including an interconnect 220, another interconnect endpoint 225 with security component 230, and a destination component 235. The solid arrows denote the message flow within the boundary of an interconnect endpoint and an SoC component.” 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). In an example, the interconnect endpoint 210 and 225 are not on the same SoC die (e.g., performing inter-chip communications). By securing the SoC component communications as illustrated in FIG. 2, malicious actors may be thwarted by denying them access to the messages as they move on the SoC interconnect 220. Further, any SoC components may be used without regard to which or a plurality of security configurations were selected by the SoC designers.” Fig. 7, para 0044“ At operation 730, the encrypted message may be transmitted across the interconnect. In an example, every message transmitted from the bus endpoint is encrypted by the security component. In an example, every message traversing a bus to which the bus endpoint is a terminus is encrypted by respective security components in endpoints of the bus. Thus, the entire interconnect consists of secured communications.” Which means every message must be decrypted and authenticated (see paragraphs 0020 and 0023).”
Sastry does not disclose:
a second electronic device different from the first electronic device
Van discloses:
wherein a second electronic device comprises a second 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 second electronic device different from the first electronic device, 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
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 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
Prosecution Insights