DETAILED ACTION
This office action is in response to the amendments filed on 08/08/2025.
Claims 1 and 6 are amended, and claims 2, 4, 7, 9, and 11-13 are cancelled.
Claims 14-23 have been added.
Claims 1, 3, 5-6, 8, 10, and 14-23 are presented for examination.
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 .
Response to Arguments
Applicant’s arguments with respect to the 35 USC 103 rejections to the claims filed on 03/07/2025 in Remarks pg. 5-12 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.
Claim(s) 1, 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov et al. (hereinafter Avetisov US 2021/0044976 A1) in view of Yoda et al. (hereinafter Yoda, US 2017/0264592 A1).
Regarding Claim 1, Avetisov discloses A packet transmission method for a network device (Avetisov: Fig. 11b Auth server 155), and the method comprising: receiving, by the network device, a request message from a terminal device (Avetisov: Fig. 11b mobile device) (Avetisov: para.0451 “ The user may select 52 a given web-service (or collection thereof) to which the user desires to authenticate the relying device 140 to access, e.g., cause the relying device to log into under an account of the user or otherwise present credentials of the user to utilize the web-service. The mobile device 101 may transmit an access request corresponding to the selected web-service to the authentication server 155.” The authentication server 155 obtains an access request for services 175 from the mobile device ),
the request message comprising a first field, the first field indicating an identity information of the terminal device (Avetsisov: para.0453 “User authentication may be performed according to one or more processes discussed herein. In some embodiments, the access request transmitted in step 52 may include authentication information by which the authentication server 155 may deem the user authenticated….the mobile device 101 may generate, such as by processing user provided credentials within a TEE of the mobile device, the authentication result. In some embodiments, the authentication result may include one or more representation of credentials which the user authenticated on with the mobile device 101, such as by providing those credentials to the TEE for verification.” Identity information for authentication is sent with the request, such as credential information. The location of this information within the request is the first field),
performing, by the network device, a compliance check on the terminal device based on the first field, the compliance check comprising one or more of an identity check (Avetisov: para.0453 “User authentication may be performed according to one or more processes discussed herein. In some embodiments, the access request transmitted in step 52 may include authentication information by which the authentication server 155 may deem the user authenticated. For example, the mobile device 101 may receive a policy including one or more rules by which the authentication server 155 verifies an authentication result generated by the mobile device. Thus, the mobile device 101 may generate the authentication result and transmit the result in association with the access request.” Based on the information from the request including an authentication result, the an identity check is performed.)
or a capability check; and
in response to a successful compliance check on the terminal device, sending, by the network device, a notification message to a management platform (Avetisov: Fig. 11 Relying device 140), the notification message comprising a second field, the second field indicating the terminal device (Avetisov: “In response to authentication of the user, e.g., based on the information received from the mobile device 101 and which may include the signing of user credentials by the authentication server 155 to convey verification thereof, the authentication server may pass the credentials to a relying device. For example, the authentication server 155 may pass credentials to the relying device 140 over an issued user session 56 associated with the user of the mobile device (e.g., the relying device identified as available in step 53).” In response to the identity check, a notification is sent to a relying device 140, containing credential information of the user), and
the notification message indicating the management platform establish the communication connection to an application server (Avetisov: Fig. 11b 145/175) so that the application server provides a service for the terminal device (Avetisov: para.0457 “ For example, the authentication server 155 may pass credentials to the relying device 140 over an issued user session 56 associated with the user of the mobile device (e.g., the relying device identified as available in step 53). Credentials passed to the relying device 140 may include communication of information by which the relying device 140 may authenticate to a web-service. The authentication server 155 may provide credentials to a relying device 140 over an issued user session by passing a user certificate or token to the relying device. In some embodiments, the authentication server 155 may sign the user certificate or token, such as in response to verifying the information received from the mobile device. The signature of the authentication server 155 may convey the verification of the credentials as being associated with the user for which the user session was issued, such as to a web-service.” Para.0458 “In various embodiments, a web-service may trust the authentication server 155 as an identity provider, in which case the credentials received by the relying device 140 over the session may be presented 57 (e.g., directly, or signed and presented) a corresponding web-service. For example, the relying device 140, as in other examples, may receive a token to present or sign and present to an indicated web-service.” Para.0460 “In step 58 the relying device 140 may receive a result of successfully authenticating to a web-service or service governing access to the web-service, and thus a result of a login attempt to the web-webservice for the user by the relying device.” The notification information contains credentials that inform the relying device that the user is authenticated for the web service, such as service 175 in Fig. 11b, therefore indicating the relying device 140 to establish the connection to the service such as in step 57. The login to the web service for the mobile device in step 58 is performed in response.),
wherein the second field is the same as the first field, or the second field is determined based on the first field (Avetsisov: para.0457 “ The authentication server 155 may provide credentials to a relying device 140 over an issued user session by passing a user certificate or token to the relying device. In some embodiments, the authentication server 155 may sign the user certificate or token, such as in response to verifying the information received from the mobile device. The signature of the authentication server 155 may convey the verification of the credentials as being associated with the user for which the user session was issued, such as to a web-service. In some embodiments, the relying device 140 may sign the user certificate. Thus, for example, presentation of a certificate or other data to a web-service by the relying device in step 57 may convey the provenance, like a chain of tile, of the certificate and the entities which handled it, e.g., by nested signatures, and which the web-service may verify based on public keys or signatures keys maintained for the respective entities.” The second field is based on the first field in the form of a signed certificate that represents the credentials, i.e. the first field.).
However Avetisov does not explicitly disclose and the request message requesting the terminal device establish a communication connection to the network device.
Yoda discloses and the request message requesting the terminal device establish a communication connection to the network device (Yoda: Fig. 2, para.0043 “At block 201, a request to initiate a secure connection is received. In examples, Connection Manger 120a within Connection Server 120 may receive a request from Mobile Device A 112a to initiate a secure connection with Remote Application Server A 130a. At block 202, the mobile device that provided the request is authenticated. In examples, Connection Manager 120a may authenticate Mobile Device A 112a…. At block 206, a secure connection is established. In examples, Connection Manager 120a then notifies about readiness to establish the connection with the Mobile Device A 112a. In examples, Connection Manager 120a completes establishing a secure connection between Mobile Device A 112a and Remote Application Server A 130a.” the mobile device of Fig. 1 requests the connection server 120 for secure connection to the remote application server. This singular request is used to both request a secure connection to the connection manager, authenticate the user, and establish a connection via the connection manager to the remote application server.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Avetisov with Yoda in order to incorporate and the request message requesting the terminal device establish a communication connection to the network device, such that a single request is used to perform both the authentication of the user and the request for a connection to authentication server that is performed as 2 different requests in Avetisov.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved efficiency and bandwidth usage by reducing the number of requests to authenticate and provide connection to a service (Yoda: para.0044).
Regarding Claim 6, it teaches all of the same steps as claim 1 but in A network device, comprising: a memory storing instructions; and at least one processor in communication with the memory, the at least one processor configured, upon execution of the instructions, to perform the following steps (Avetisov: Fig. 12 para.0069 “Similarly, client devices 135, server 145, 155, and repositories 160, 165 may include some additional or other components than those illustrated in FIG. 12. However, each of these devices may operate in accordance with principles similar to those discussed below and with reference to FIG. 12, such as by loading instructions and other data into a memory and executing those instructions by a processor to perform various operations.” system memory and processor of 155). Therefore the supporting rationale for the rejection of claim 1 applies equally as well to that of claim 6.
Claim(s) 3, 8, is/are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov et al. (hereinafter Avetisov US 2021/0044976 A1) in view of Yoda et al. (hereinafter Yoda, US 2017/0264592 A1) in view of Singhal (US 10,162,803 B2).
Regarding Claim 3, Avetisov-Yoda discloses claim 1 as set forth above.
However Avetisov-Yoda does not explicitly disclose wherein the identity information of the terminal device comprises a vendor type of the terminal device and a device type of the terminal device.
Singhal discloses wherein the identity information of the terminal device comprises a vendor type of the terminal device and a device type of the terminal device (Singhal: Col. 1 lines 54-57 “Therefore some servers, identified by domain names, are set up to respond to smart phones only and have provided miniature pages for them. However the size of the screen is likely to vary quite a bit with the advent of new smart phones from different manufacturers.” Claim 1 “providing by the modified browser logic, the device_type variable with a specific value equal to a manufacturer's model number of the mobile wireless device wherein the model number maps only to a specific screen size of the mobile device in a table and wherein the table is pre-stored in the web server,” Claim 2 “identifying to the web server by the value of the device_type variable the type of mobile wireless device, including a manufacturer and a model of the mobile wireless device that has requested service from the web server.” the vendor type, i.e. manufacturer, and a device type, i.e model number, are provided such that the provided service is capable with the screen size.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Avetisov-Yoda with Singhal in order to incorporate wherein the identity information of the terminal device comprises a vendor type of the terminal device and a device type of the terminal device.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved service, by considering manufacturer specific compatibility issues when obtaining service (Singhal: Col. 1 lines 54-57).
Regarding Claim 8, it does not teach nor further define over the limitations of claim 3, therefore the supporting rationale for the rejection of claim 3 applies equally as well to that of claim 8.
Claim(s) 5, 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov et al. (hereinafter Avetisov US 2021/0044976 A1) in view of Yoda et al. (hereinafter Yoda, US 2017/0264592 A1) in view of Agerstam et al. (hereinafter Ager, US 2020/0021670 A1).
Regarding Claim 5, Avetisov-Yoda discloses claim 1 as set forth above.
However Avetisov-Yoda does not explicitly disclose wherein the network device is connected to at least one plug-in card in a pluggable manner, the network device dynamically adds or deletes one or more service capabilities by adding or deleting the at least one plug-in card, and the service capability comprises one or more of: a communication frequency band, a communication protocol, a communication bandwidth, or a communication rate.
Agerstam discloses wherein the network device is connected to at least one plug-in card in a pluggable manner, the network device dynamically adds or deletes one or more service capabilities by adding or deleting the at least one plug-in card (Agerstam: para.0018-0019 “A plugin is a software component that adds a specific feature to an existing software program, hardware device, firmware, etc. A plugin can be used to customize base software, hardware, firmware, etc. Plugins can be used to add features, support file types/formats, etc. As used herein, the plugin provides a translation library/mapping from one domain to a common domain (e.g., D1->Dc, etc.) to provide a consistent data model representation. A plugin foundation provides a framework to load plugins to allow a gateway/hub device to communicate with a plurality of devices/device types…. FIG. 1 illustrates a block diagram depicting an example protocol framework 100 to identify IoT devices/services to enable installation of plugins and/or translation libraries to facilitate communication and interoperability with a gateway/hub device.” The gateway device can have plug-in cards added or removed to facilitate service capabilities of communication.),
and the service capability comprises one or more of: a communication frequency band, a communication protocol (Agerstam: para.0048-0050 “FIG. 5 uses ZigBee™ as an example to show message flow 500 between the gateway plugin agent 202 and cloud plugin manager 204 to determine and then download the appropriate ZigBee plugin 501.” A service capability of zigbee protocol can be added via a plug in, or Bluetooth in para.0024), a communication bandwidth, or a communication rate.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Avetisov-Yoda with Agerstam in order to incorporate wherein the network device is connected to at least one plug-in card in a pluggable manner, the network device dynamically adds or deletes one or more service capabilities by adding or deleting the at least one plug-in card, and the service capability comprises one or more of: a communication frequency band, a communication protocol, a communication bandwidth, or a communication rate.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improving communication and interoperability of the gateway device (Agerstam: para.0018-0019).
Regarding Claim 10, it does not teach nor further define over the limitations of claim 5, therefore the supporting rationale for the rejection of claim 5 applies equally as well to that of claim 10.
Claim(s) 14-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov et al. (hereinafter Avetisov US 2021/0044976 A1) in view of Yoda et al. (hereinafter Yoda, US 2017/0264592 A1) in view of Prasad et al. (hereinafter Prasad, US 2019/0274039 A1).
Regarding Claim 14, Avetisov-Yoda discloses claim 1 as set forth above.
However Avetisov-Yoda does not explicitly disclose wherein the capability check includes checking whether the terminal device supports an encryption capability based on the first field.
Prasad discloses wherein the capability check includes checking whether the terminal device supports an encryption capability based on the first field (Prasad: Fig. 3, para.0072 “First, the UE transmits an RRC Connection Request message to the NG-RAN 48 (S11). The Attach Request message is piggy-backed within the RRC Connection Request message. The Attach Request message includes, as parameters, a Globally Unique Temporary UE Identity (GUTI), Network Capabilities, a Key Set Identifier (KSI), the NSSAI, and the UE Security Capabilities.” Para.0073 “Next, the NG-RAN 48 checks the UE Security Capabilities and the Subscription for the UE (S12). The check of the UE Security Capabilities may be to determine whether algorithm information used for the encryption and the integrity protection processing executed in the UE coincides with algorithm information used for encryption and integrity protection processing executed in the core network or the NG-RAN 48 to which the UE requests connection.” The connection request message comprises a first field containing a plurality of information, including UE security capabilities. The UE security capability is used to determine if the encryption algorithm used by the UE coincides with that of the network it is trying to connect to).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Avetisov-Yoda with that of Prasad in order to incorporate wherein the capability check includes checking whether the terminal device supports an encryption capability based on the first field.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of proper communication by ensuring the encryption methods available at the network device are the same as the destination (Prasad: para.0073).
Regarding Claim 15, Avetisov-Yoda discloses claim 1 as set forth above.
However Avetisov-Yoda does not explicitly disclose wherein the capability check includes checking whether the terminal device supports a type of encryption algorithm based on the first field.
Prasad discloses wherein the capability check includes checking whether the terminal device supports a type of encryption algorithm based on the first field (Prasad: Fig. 3, para.0072 “First, the UE transmits an RRC Connection Request message to the NG-RAN 48 (S11). The Attach Request message is piggy-backed within the RRC Connection Request message. The Attach Request message includes, as parameters, a Globally Unique Temporary UE Identity (GUTI), Network Capabilities, a Key Set Identifier (KSI), the NSSAI, and the UE Security Capabilities.” Para.0073 “Next, the NG-RAN 48 checks the UE Security Capabilities and the Subscription for the UE (S12). The check of the UE Security Capabilities may be to determine whether algorithm information used for the encryption and the integrity protection processing executed in the UE coincides with algorithm information used for encryption and integrity protection processing executed in the core network or the NG-RAN 48 to which the UE requests connection.” The connection request message comprises a first field containing a plurality of information, including UE security capabilities. The UE security capability is used to determine if the encryption algorithm used by the UE coincides with that of the network it is trying to connect to).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Avetisov-Yoda with that of Prasad in order to incorporate wherein the capability check includes checking whether the terminal device supports a type of encryption algorithm based on the first field.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of proper communication by ensuring the encryption methods available at the network device are the same as the destination (Prasad: para.0073).
Regarding Claim 16-17, they do not teach nor further define over the limitations of claim 14-15, therefore the supporting rationale for the rejection of claims 14-15 apply equally as well to that of claims 16-17.
Claim(s) 18-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov et al. (hereinafter Avetisov US 2021/0044976 A1) in view of Yoda et al. (hereinafter Yoda, US 2017/0264592 A1) in view of Singhal (US 10,162,803 B2) in view of Prasad et al. (hereinafter Prasad, US 2019/0274039 A1).
Regarding Claim 18, Avetisov-Yoda discloses claim 1 as set forth above.
However Avetisov-Yoda does not explicitly disclose wherein the network device determines the device type and the vendor type of the terminal device based on the first field, and determines the encryption algorithm supported by the terminal device.
Singhal discloses wherein the network device determines the device type and the vendor type of the terminal device based on the first field (Singhal: Col. 1 lines 54-57 “Therefore some servers, identified by domain names, are set up to respond to smart phones only and have provided miniature pages for them. However the size of the screen is likely to vary quite a bit with the advent of new smart phones from different manufacturers.” Claim 1 “providing by the modified browser logic, the device_type variable with a specific value equal to a manufacturer's model number of the mobile wireless device wherein the model number maps only to a specific screen size of the mobile device in a table and wherein the table is pre-stored in the web server,” Claim 2 “identifying to the web server by the value of the device_type variable the type of mobile wireless device, including a manufacturer and a model of the mobile wireless device that has requested service from the web server.” the vendor type, i.e. manufacturer, and a device type, i.e model number, are provided such that the provided service is capable with the screen size.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Avetisov-Yoda with Singhal in order to incorporate wherein the network device determines the device type and the vendor type of the terminal device based on the first field.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved service, by considering manufacturer specific compatibility issues when obtaining service (Singhal: Col. 1 lines 54-57).
However Avetisov-Yoda-Singhal does not explicitly disclose determines the encryption algorithm supported by the terminal device.
Prasad discloses determines the encryption algorithm supported by the terminal device (Prasad: Fig. 3, para.0072 “First, the UE transmits an RRC Connection Request message to the NG-RAN 48 (S11). The Attach Request message is piggy-backed within the RRC Connection Request message. The Attach Request message includes, as parameters, a Globally Unique Temporary UE Identity (GUTI), Network Capabilities, a Key Set Identifier (KSI), the NSSAI, and the UE Security Capabilities.” Para.0073 “Next, the NG-RAN 48 checks the UE Security Capabilities and the Subscription for the UE (S12). The check of the UE Security Capabilities may be to determine whether algorithm information used for the encryption and the integrity protection processing executed in the UE coincides with algorithm information used for encryption and integrity protection processing executed in the core network or the NG-RAN 48 to which the UE requests connection.” The connection request message comprises a first field containing a plurality of information, including UE security capabilities. The UE security capability is used to determine if the encryption algorithm used by the UE coincides with that of the network it is trying to connect to).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Avetisov-Yoda-Singhal with that of Prasad in order to incorporate determines the encryption algorithm supported by the terminal device.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of proper communication by ensuring the encryption methods available at the network device are the same as the destination (Prasad: para.0073).
Regarding Claim 19, Avetisov-Yoda-Singhal-Prasad discloses claim 18 as set forth above.
However Avetisov-Yoda-Singhal does not explicitly disclose wherein the network device allows access of a terminal device using encryption algorithms A and B.
Prasad discloses wherein the network device allows access of a terminal device using encryption algorithms A and B (Prasad: para.0059 “The UE Security Capabilities may be a set of identification information that corresponds to algorithm information used for encryption and integrity protection processing implemented in the UE, which is the communication terminal. (The set of identifiers corresponding to the ciphering and integrity algorithms implemented in the UE).” Para.0081 “When it is determined in Step S12 that the algorithm information used for the encryption and the integrity protection processing executed in the UE coincides with that executed in the NG-RAN 48 and at the same time the UE is allowed to be connected to the NextGen System or the core network, the NG-RAN 48 continues the Attach Procedure in such a way as to allow the UE to be connected to the core network to which the UE requests connection.” The UE sends a security capabilities that have one or more identifiers representing encryption algorithms implemented on the UE, i.e. can be algorithms A and B. This information is compared to the networks encryption and upon determining that the algorithm information coincides with the networks, the UE is allowed access.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Avetisov-Yoda-Singhal with that of Prasad in order to incorporate wherein the network device allows access of a terminal device using encryption algorithms A and B.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of proper communication by ensuring the encryption methods available at the network device are the same as the destination (Prasad: para.0073).
Regarding Claim 20, Avetisov-Yoda-Singhal-Prasad discloses claim 18 as set forth above.
However Avetisov-Yoda-Singhal does not explicitly disclose wherein the network device rejects access of the terminal device when the terminal device supports only an encryption algorithm C.
Prasad discloses wherein the network device rejects access of the terminal device when the terminal device supports only an encryption algorithm C (Prasad: para.0079 “When it is determined in Step S12 that at least one of the condition that the algorithm information used for the encryption and the integrity protection processing executed in the UE does not coincide with that executed in the NG-RAN 48 and the condition that the UE is not allowed to be connected to the NextGen System or the core network is satisfied, the NG-RAN 48 may transmit a Reject message to the UE without executing the processing in Step S13 and the following processing.” In a case the algorithm used by the UE does not coincide with the algorithm used in the network, i.e. algorithm C is used by the UE, then the UE is rejected from accessing the network).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Avetisov-Yoda-Singhal with that of Prasad in order to incorporate wherein the network device rejects access of the terminal device when the terminal device supports only an encryption algorithm C.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of proper communication by ensuring the encryption methods available at the network device are the same as the destination (Prasad: para.0073).
Regarding Claims 21-23, they do not teach nor further define over the limitations of claims 18-20, therefore the supporting rationale for the rejection to claims 18-20 apply equally as well to that of claims 21-23.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Kim et al. US 2017/0006471 A1 para.0133, 0176, Fig. 7 registering home device via a control device in Fig. 2.
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 EUI H KIM whose telephone number is (571)272-8133. The examiner can normally be reached 7:30-5 M-R, M-F alternating.
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, Kamal B Divecha can be reached at 5712725863. 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.
/EUI H KIM/ Examiner, Art Unit 2453
/KAMAL B DIVECHA/ Supervisory Patent Examiner, Art Unit 2453
Prosecution Insights