DETAILED ACTION
This Office Action has been issued in response to Applicant's Amendments filed March 31, 2026.
Claims 1, 11, and 21 have been amended. Claims 1-30 have been examined and are pending.
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 filed March 31, 2026 have been fully considered but they are not persuasive.
Applicant argues the same portion of Evani is mapped to the creation of the security integration object, the creation of a secret object, and binding them into a storage integration object. However, as used in the claims they appear to be only used as the storage integration object which is used in analogous fashion to the token setup disclosed in Evani.
Applicant argues Evani does not disclose a secret API to obtain the token. Paragraph [0218] of Evani discloses the public key is transmitted as part of a token exchange API payload.
Applicant argues Evani does not disclose UDFs. Examiner maintains the prior position on UDFs, however Carru discloses UDFs explicitly.
Applicant argues the objects in Evani do not disclose specific fields. However, Evani discloses the functionality that requires the existence of the information.
Applicant argues the disclosure of Evani does not run in a sandbox. Paragraph [0218] of Evani discloses the public key is transmitted as part of a token exchange API payload. Paragraph [0040] of Evani discloses one or more customer resources or workloads, such as compute instances, can be deployed on these virtual networks. For example, a customer can use resources provided by CSPI to build one or multiple customizable and private virtual network(s) referred to as virtual cloud networks (VCNs). A customer can deploy one or more customer resources, such as compute instances, on a customer VCN. Compute instances can take the form of virtual machines, bare metal instances, and the like. Virtual machine instances are understood to be analogous to sandboxes.
Applicant argues the firewall of Evani does not disclose the egress policy architecture. Paragraph [0064] of Evani discloses security rules configured for a VCN represent overlay firewall rules for the VCN. The security rules can include ingress and egress rules, and specify the types of traffic (e.g., based upon protocol and port) that is allowed in and out of the instances within the VCN. Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token.
Applicant argues Evani does not disclose the a user object in a network based database system, causing authorization for such a user object to access a role and granting that user object access based on a token. Paragraph [0052] of Evani discloses These compute instances may represent various customer workloads such as applications, load balancers, databases, and the like. Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-30 are rejected under 35 U.S.C. 103 as being unpatentable over US Pub. No. 2025/0088360 to Evani et al. (hereinafter “Evani”) and further in view of US Pat. No. 11/750661 to Carru et al. (hereinafter “Carru”).
As to Claim 1, Evani discloses a system comprising: at least one hardware processor; and at least one memory storing instructions that cause the at least one hardware processor to perform operations comprising:
creating a security integration object, the security integration object comprising an authentication type that includes an identification of a role associated with access to an external resource (Paragraph [0164] of Evani discloses a role may be associated with one or more tasks/operations that are permitted for the role);
creating a secret object comprising a token of a cloud provider token type, the token associated with the security integration object (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token);
binding the security integration object and the secret object to generate a storage integration object, the storage integration object comprising an external access integration (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token);
retrieving a cloud provider token during execution of a [user-defined function (UDF)], the retrieving comprising invoking a secret API during execution of the UDF, the secret API returning the cloud provider token based on the secret object (Paragraph [0205] of Evani discloses the first request includes a first token that is issued by the first CSP and requests usage of a second service that is provided in the second cloud environment by the second CSP. Paragraph [0218] of Evani discloses the public key is transmitted as part of a token exchange API payload); and
granting the UDF access to the external resource based on authenticating the cloud provider token using the external access integration (Paragraph [0007] of Evani discloses validating the decrypted first token with respect to a trust configuration corresponding to the second environment, the trust configuration being previously generated and maintained in the first environment).
Evani does not explicitly disclose user-defined function (UDF). However, such a feature would have been obvious in view of Evani. Paragraph [0040] of Evani discloses one or more customer resources or workloads, such as compute instances, can be deployed on these virtual networks. For example, a customer can use resources provided by CSPI to build one or multiple customizable and private virtual network(s) referred to as virtual cloud networks (VCNs). A customer can deploy one or more customer resources, such as compute instances, on a customer VCN. Compute instances can take the form of virtual machines, bare metal instances, and the like. Paragraph [0052] of Evani discloses these compute instances may represent various customer workloads such as applications, load balancers, databases, and the like. Where the compute instances of customer workloads are analogous to user-defined functions.
This is supported by Carru. Figure 3 of Carru discloses a plurality of virtual warehouses with execution nodes and Figure 4 of Carru discloses the UDF server in the execution node.
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to combine the virtual cloud system as disclosed by Evani, with running UDFs as disclosed by Carru. One of ordinary skill in the art would have been motivated to combine to apply a known technique to a known device ready for improvement to yield predictable results. Evani and Carru are directed toward virtual cloud systems and as such it would be obvious to use the techniques of one in the other.
As to Claim 2, Evani-Carru discloses the system of claim 1, the operations comprising: generating a network access rule, the network access rule comprising identification information of the external resource (Paragraph [0190] of Evani a trust configuration is established between the first cloud environment 910 and each external cloud service providers e.g., second cloud).
As to Claim 3, Evani-Carru discloses the system of claim 2, the operations comprising: generating the storage integration object further based on binding the network access rule with the security integration object and the secret object (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 4, Evani-Carru discloses the system of claim 1, the operations comprising: executing an application programming interface (API) to retrieve the cloud provider token, the API executing within a sandbox associated with the execution of the UDF (Paragraph [0218] of Evani discloses the public key is transmitted as part of a token exchange API payload. Paragraph [0040] of Evani discloses one or more customer resources or workloads, such as compute instances, can be deployed on these virtual networks. For example, a customer can use resources provided by CSPI to build one or multiple customizable and private virtual network(s) referred to as virtual cloud networks (VCNs). A customer can deploy one or more customer resources, such as compute instances, on a customer VCN. Compute instances can take the form of virtual machines, bare metal instances, and the like).
As to Claim 5, Evani-Carru discloses the system of claim 4, the operations comprising: retrieving the storage integration object based on the cloud provider token; and granting the UDF access to the external storage based on the retrieved storage integration object (Paragraph [0007] of Evani discloses validating the decrypted first token with respect to a trust configuration corresponding to the second environment, the trust configuration being previously generated and maintained in the first environment. Responsive to successful validation, sending, by the token exchange service, a second token to the connector, wherein the connector utilizes the second token to access the service provided in the first environment).
As to Claim 6, Evani-Carru discloses the system of claim 1, the operations comprising: detecting the role is associated with an identity-based policy attached to a user; and granting the user, access to the external resource based on the authenticating (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 7, Evani-Carru discloses the system of claim 1, the operations comprising: detecting the role is associated with a resource-based policy attached to a storage resource associated with the external resource; and granting the UDF access to the storage resource based on the authenticating (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 8, Evani-Carru discloses the system of claim 1, the operations comprising: updating an egress policy based on the storage integration object (Paragraph [0064] of Evani discloses security rules configured for a VCN represent overlay firewall rules for the VCN. The security rules can include ingress and egress rules, and specify the types of traffic (e.g., based upon protocol and port) that is allowed in and out of the instances within the VCN. Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 9, Evani-Carru discloses the system of claim 8, the operations comprising: forwarding the egress policy to an execution node, the execution node hosting a sandbox process associated with the execution of the UDF; and granting the UDF access to the external resource based on authenticating the cloud provider token at the execution node based on the egress policy (Paragraph [0064] of Evani discloses security rules configured for a VCN represent overlay firewall rules for the VCN. The security rules can include ingress and egress rules, and specify the types of traffic (e.g., based upon protocol and port) that is allowed in and out of the instances within the VCN. Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 10, Evani-Carru discloses the system of claim 1, wherein granting the UDF access to the external resource comprises: causing authorization of a user object of a network-based database system to access the role; and granting the user object access to the external resource based on the authenticating of the cloud provider token using the storage integration object (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 11, Evani discloses a method comprising:
creating, by at least one hardware processor, a security integration object, the security integration object comprising an authentication type that includes an identification of a role associated with access to external storage (Paragraph [0164] of Evani discloses a role may be associated with one or more tasks/operations that are permitted for the role);
creating a secret object comprising a token of a cloud provider token type, the token associated with the security integration object (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token);
binding the security integration object and the secret object to generate a storage integration object, the storage integration object comprising an external access integration (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token);
retrieving a cloud provider token during execution of a [user-defined function (UDF)], the retrieving comprising invoking a secret API during execution of the UDF, the secret API returning the cloud provider token based on the secret object (Paragraph [0205] of Evani discloses the first request includes a first token that is issued by the first CSP and requests usage of a second service that is provided in the second cloud environment by the second CSP. Paragraph [0218] of Evani discloses the public key is transmitted as part of a token exchange API payload); and
granting the UDF access to the external resource based on authenticating the cloud provider token using the external access integration (Paragraph [0007] of Evani discloses validating the decrypted first token with respect to a trust configuration corresponding to the second environment, the trust configuration being previously generated and maintained in the first environment).
Evani does not explicitly disclose user-defined function (UDF). However, such a feature would have been obvious in view of Evani. Paragraph [0040] of Evani discloses one or more customer resources or workloads, such as compute instances, can be deployed on these virtual networks. For example, a customer can use resources provided by CSPI to build one or multiple customizable and private virtual network(s) referred to as virtual cloud networks (VCNs). A customer can deploy one or more customer resources, such as compute instances, on a customer VCN. Compute instances can take the form of virtual machines, bare metal instances, and the like. Paragraph [0052] of Evani discloses these compute instances may represent various customer workloads such as applications, load balancers, databases, and the like. Where the compute instances of customer workloads are analogous to user-defined functions.
This is supported by Carru. Figure 3 of Carru discloses a plurality of virtual warehouses with execution nodes and Figure 4 of Carru discloses the UDF server in the execution node.
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to combine the virtual cloud system as disclosed by Evani, with running UDFs as disclosed by Carru. One of ordinary skill in the art would have been motivated to combine to apply a known technique to a known device ready for improvement to yield predictable results. Evani and Carru are directed toward virtual cloud systems and as such it would be obvious to use the techniques of one in the other.
As to Claim 12, Evani-Carru discloses the method of claim 11, comprising: generating a network access rule, the network access rule comprising identification information of the external resource (Paragraph [0190] of Evani a trust configuration is established between the first cloud environment 910 and each external cloud service providers e.g., second cloud).
As to Claim 13, Evani-Carru discloses the method of claim 12, comprising: generating the storage integration object further based on binding the network access rule with the security integration object and the secret object (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 14, Evani-Carru discloses the method of claim 11, comprising: executing an application programming interface (API) to retrieve the cloud provider token, the API executing within a sandbox associated with the execution of the UDF (Paragraph [0218] of Evani discloses the public key is transmitted as part of a token exchange API payload. Paragraph [0040] of Evani discloses one or more customer resources or workloads, such as compute instances, can be deployed on these virtual networks. For example, a customer can use resources provided by CSPI to build one or multiple customizable and private virtual network(s) referred to as virtual cloud networks (VCNs). A customer can deploy one or more customer resources, such as compute instances, on a customer VCN. Compute instances can take the form of virtual machines, bare metal instances, and the like).
As to Claim 15, Evani-Carru discloses the method of claim 14, comprising: retrieving the storage integration object based on the cloud provider token; and granting the UDF access to the external resource based on the retrieved storage integration object (Paragraph [0007] of Evani discloses validating the decrypted first token with respect to a trust configuration corresponding to the second environment, the trust configuration being previously generated and maintained in the first environment. Responsive to successful validation, sending, by the token exchange service, a second token to the connector, wherein the connector utilizes the second token to access the service provided in the first environment).
As to Claim 16, Evani-Carru discloses the method of claim 11, comprising: detecting the role is associated with an identity-based policy attached to a user; and granting the user, access to the external resource based on the authenticating (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 17, Evani-Carru discloses the method of claim 11, comprising: detecting the role is associated with a resource-based policy attached to a storage resource associated with the external resource; and granting the UDF access to the storage resource based on the authenticating (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 18, Evani-Carru discloses the method of claim 11, comprising: updating an egress policy based on the storage integration object (Paragraph [0064] of Evani discloses security rules configured for a VCN represent overlay firewall rules for the VCN. The security rules can include ingress and egress rules, and specify the types of traffic (e.g., based upon protocol and port) that is allowed in and out of the instances within the VCN. Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 19, Evani-Carru discloses the method of claim 18, comprising: forwarding the egress policy to an execution node, the execution node hosting a sandbox process associated with the execution of the UDF; and granting the UDF access to the external resource based on authenticating the cloud provider token at the execution node based on the egress policy (Paragraph [0064] of Evani discloses security rules configured for a VCN represent overlay firewall rules for the VCN. The security rules can include ingress and egress rules, and specify the types of traffic (e.g., based upon protocol and port) that is allowed in and out of the instances within the VCN. Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 20, Evani-Carru discloses the method of claim 11, wherein granting the UDF access to the external resource comprises: causing authorization of a user object of a network-based database system to access the role; and granting the user object access to the external resource based on the authenticating of the cloud provider token using the storage integration object (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 21, Evani discloses a computer-storage medium comprising instructions that, when executed by one or more processors of a machine, configure the machine to perform operations comprising:
creating a security integration object, the security integration object comprising an authentication type that includes an identification of a role associated with access to external storage (Paragraph [0164] of Evani discloses a role may be associated with one or more tasks/operations that are permitted for the role);
creating a secret object comprising a token of a cloud provider token type, the token associated with the security integration object (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token);
binding the security integration object and the secret object to generate a storage integration object, the storage integration object comprising an external access integration (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token);
retrieving a cloud provider token during execution of a [user-defined function (UDF)], the retrieving comprising invoking a secret API during execution of the UDF, the secret API returning the cloud provider token based on the secret object (Paragraph [0205] of Evani discloses the first request includes a first token that is issued by the first CSP and requests usage of a second service that is provided in the second cloud environment by the second CSP. Paragraph [0218] of Evani discloses the public key is transmitted as part of a token exchange API payload); and
granting the UDF access to the external resource based on authenticating the cloud provider token using the external access integration (Paragraph [0007] of Evani discloses validating the decrypted first token with respect to a trust configuration corresponding to the second environment, the trust configuration being previously generated and maintained in the first environment).
Evani does not explicitly disclose user-defined function (UDF). However, such a feature would have been obvious in view of Evani. Paragraph [0040] of Evani discloses one or more customer resources or workloads, such as compute instances, can be deployed on these virtual networks. For example, a customer can use resources provided by CSPI to build one or multiple customizable and private virtual network(s) referred to as virtual cloud networks (VCNs). A customer can deploy one or more customer resources, such as compute instances, on a customer VCN. Compute instances can take the form of virtual machines, bare metal instances, and the like. Paragraph [0052] of Evani discloses these compute instances may represent various customer workloads such as applications, load balancers, databases, and the like. Where the compute instances of customer workloads are analogous to user-defined functions.
This is supported by Carru. Figure 3 of Carru discloses a plurality of virtual warehouses with execution nodes and Figure 4 of Carru discloses the UDF server in the execution node.
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to combine the virtual cloud system as disclosed by Evani, with running UDFs as disclosed by Carru. One of ordinary skill in the art would have been motivated to combine to apply a known technique to a known device ready for improvement to yield predictable results. Evani and Carru are directed toward virtual cloud systems and as such it would be obvious to use the techniques of one in the other.
As to Claim 22, Evani-Carru discloses the computer-storage medium of claim 21, the operations comprising: generating a network access rule, the network access rule comprising identification information of the external resource (Paragraph [0190] of Evani a trust configuration is established between the first cloud environment 910 and each external cloud service providers e.g., second cloud).
As to Claim 23, Evani-Carru discloses the computer-storage medium of claim 22, the operations comprising: generating the storage integration object further based on binding the network access rule with the security integration object and the secret object (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 24, Evani-Carru discloses the computer-storage medium of claim 21, the operations comprising: executing an application programming interface (API) to retrieve the cloud provider token, the API executing within a sandbox associated with the execution of the UDF (Paragraph [0218] of Evani discloses the public key is transmitted as part of a token exchange API payload. Paragraph [0040] of Evani discloses one or more customer resources or workloads, such as compute instances, can be deployed on these virtual networks. For example, a customer can use resources provided by CSPI to build one or multiple customizable and private virtual network(s) referred to as virtual cloud networks (VCNs). A customer can deploy one or more customer resources, such as compute instances, on a customer VCN. Compute instances can take the form of virtual machines, bare metal instances, and the like).
As to Claim 25, Evani-Carru discloses the computer-storage medium of claim 24, the operations comprising: retrieving the storage integration object based on the cloud provider token; and granting the UDF access to the external resource based on the retrieved storage integration object (Paragraph [0007] of Evani discloses validating the decrypted first token with respect to a trust configuration corresponding to the second environment, the trust configuration being previously generated and maintained in the first environment. Responsive to successful validation, sending, by the token exchange service, a second token to the connector, wherein the connector utilizes the second token to access the service provided in the first environment).
As to Claim 26, Evani-Carru discloses the computer-storage medium of claim 21, the operations comprising: detecting the role is associated with an identity-based policy attached to a user; and granting the user, access to the external resource based on the authenticating (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 27, Evani-Carru discloses the computer-storage medium of claim 21, the operations comprising: detecting the role is associated with a resource-based policy attached to a storage resource associated with the external resource; and granting the UDF access to the storage resource based on the authenticating (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 28, Evani-Carru discloses the computer-storage medium of claim 21, the operations comprising: updating an egress policy based on the storage integration object (Paragraph [0064] of Evani discloses security rules configured for a VCN represent overlay firewall rules for the VCN. The security rules can include ingress and egress rules, and specify the types of traffic (e.g., based upon protocol and port) that is allowed in and out of the instances within the VCN. Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 29, Evani-Carru discloses the computer-storage medium of claim 28, the operations comprising: forwarding the egress policy to an execution node, the execution node hosting a sandbox process associated with the execution of the UDF; and granting the UDF access to the external resource based on authenticating the cloud provider token at the execution node based on the egress policy (Paragraph [0064] of Evani discloses security rules configured for a VCN represent overlay firewall rules for the VCN. The security rules can include ingress and egress rules, and specify the types of traffic (e.g., based upon protocol and port) that is allowed in and out of the instances within the VCN. Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
As to Claim 30, Evani-Carru discloses the computer-storage medium of claim 21, wherein the operations for granting the UDF access to the external resource comprise: causing authorization of a user object of a network-based database system to access the role; and granting the user object access to the external resource based on the authenticating of the cloud provider token using the storage integration object (Paragraph [0164] of Evani discloses if the user is allowed to perform the requested operation based on the roles associated with the token).
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 Kevin S Mai whose telephone number is (571)270-5001. The examiner can normally be reached Monday to Friday 9AM to 5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, 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.
/KEVIN S MAI/Primary Examiner, Art Unit 2499
Prosecution Insights