DETAILED ACTION
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
In response to 35 USC 103 on pages 9-10, filed 12/29/2025, applicant argues that Lander-Helmick fails to teach “wherein the protected resources are grouped into namespace and wherein the authorization assignments of principals to roles in a protected resource context and a namespace context”
Applicant’s argument have been considered but are moot, because the newly recited amendment does not rely on the newly recited reference being applied to the prior rejection of record or 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-23 are rejected under 35 U.S.C. 103 as being unpatentable over LANDER et al. (US 2017/0331832 A1), hereinafter Lander in view of HELMICK et al. (US 2020/0105354 A1), hereinafter Helmick, and further in view of Beredimas et al. (US 2021/0006596 A1), hereinafter Beredimas.
In regards to claim 1, a request authorization server comprising:
authorization policies related to the protected resources (Lander, Para. 0082, When considering MFA and adaptive policies, organizations must implement consistent policies across on-premise and cloud resources), and
assignments of users and services to the authorization policies (Lander, Para. 0121, in one embodiment, IDCS may be used to grant a role to a user, resulting in a user provisioning action. For example, a client application 602 may issue a REST API call to grant a user a role. Admin service (a platform service in 614) delegates the call to a role manager (an infrastructure library/service in 614), who grants the user a role in the tenant-specific ID store stripe in ID store 618. On “Role Grant Success”, the role manager audits the operations to the audit table in audit schema 624, and publishes an “identity. user. role. grant. success” event to message queue 628. Identity subscriber 632 picks up the event and evaluates the provisioning grant policy and in Para. 218, provides fine-grained authorization policies for protecting the IDCS service resources described herein that are based on role-based access control (“RBAC”) and attribute-based access control (“ABAC”) [0038]),
the authorization policies comprising client authorization policies for authorizing access to the protected resources by services executing in a cloud-based platform (Lander, Para. 0142, during programmatic access by REST API clients 708, Cloud Gate 702 may act as an OAuth2 resource server/filter 720 for an application's protected REST APIs 714. It checks for the presence of a request with an authorization header and an access token. When client 708 (e.g., mobile, web apps, JavaScript, etc.) presents an access token (issued by IDCS) to use with a protected REST API 714, Cloud Gate 702 validates the access token before allowing access to the API (e.g., signature, expiration, audience, etc.). The original access token is passed along unmodified) and user authorization policies for authorizing access to the protected resources by users of the cloud-based platform (Lander, Para. 0140, If user 710 has no valid local user session, Cloud Gate 702 re-directs the user to the SSO microservice and participates in the OIDC “Authorization Code” flow with the SSO microservice. The flow concludes with the delivery of a JWT as an identity token. Cloud Gate 708 validates the JWT (e.g., looks at signature, expiration, destination/audience, etc.) and issues a local session cookie for user 710. It acts as a session manager 716 securing web browser access to protected resources and issuing, updating, and validating the local session cookie) and (Lander, Para. 0143, OAuth is used to generate either a client identity propagation token (e.g., indicating who the client is) or a user identity propagation token (e.g., indicating who the user is);
a processor coupled to the memory; a non-transitory, computer-readable medium storing thereon a set of computer- executable instructions executable by the processor, the set of computer-executable instructions comprising instructions for (Lander, Para. 0213, Computer readable media may be any available media that can be accessed by processor and includes both volatile and non-volatile media, removable and non-removable media, and communication media. Communication media may include computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media):
receiving a request for authorization to access a first protected resource hosted by the resource server (Lander, Para. 0300, receive an access token request for an access token that corresponds to the resource desired to be accessed by a user and/or an application (also referred to as a “client”));
the request comprising an access token, wherein the request includes information indicative of a grant type according to which the access token was granted (Lander, Para. 0091, the microservice is characterized by having a specific URL prefix, e.g., “host/oauth/v1” where the actual microservice is “oauth/v1”, and under “oauth/v1” there are multiple APIs, e.g., an API to request tokens: “host/oauth/v1/token”, an API to authenticate a user: “host/oauth/v1/authorize”, etc.) and (Lander, Para. 0099, the OAuth2 platform service provides token authorization services. It provides a rich API infrastructure for creating and validating access tokens conveying user rights to make API calls. It supports a range of useful token grant types, enabling customers to securely connect clients to their services) (Lander, para. 105; para. 0142; 0150-153; 0160; 0004);
extracting from the request the information indicative of the grant type (Lander, Para. 0091, the microservice is characterized by having a specific URL prefix, e.g., “host/oauth/v1” where the actual microservice is “oauth/v1”, and under “oauth/v1” there are multiple APIs, e.g., an API to request tokens: “host/oauth/v1/token”, an API to authenticate a user: “host/oauth/v1/authorize”, etc.) and (Lander, Para. 0099, the OAuth2 platform service provides token authorization services. It provides a rich API infrastructure for creating and validating access tokens conveying user rights to make API calls. It supports a range of useful token grant types, enabling customers to securely connect clients to their services) (Lander, para. 105; para. 0142; 0150-153; 0160; 0004);
determining, based on the grant type indicated by the extracted information, whether the request is to access the first protected resource alternatively (a) on behalf of a service outside of a user context or (b) on behalf of a user (Lander, Para. 0004, a system for authorizing access to a resource. The system receives a request for an access token that corresponds to the resource, where the request includes user information and application information. The user information includes a role of the user and the application information includes a role of the application. The system evaluates the request by computing scopes for the access token, including determining an intersection between the user information and the application information) and (Lander, Para. 0099, the OAuth2 platform service provides token authorization services. It provides a rich API infrastructure for creating and validating access tokens conveying user rights to make API calls. It supports a range of useful token grant types, enabling customers to securely connect clients to their services) (Lander, para. 105; para. 0142; 0150-153; 0160);
based on a determination that the request is to access the first protected resource on behalf of a service outside of a user context (Lander, Para. 0004, a system for authorizing access to a resource. The system receives a request for an access token that corresponds to the resource, where the request includes user information and application information. The user information includes a role of the user and the application information includes a role of the application. The system evaluates the request by computing scopes for the access token, including determining an intersection between the user information and the application information) (Also Para. [0105][0147][0160][0166]),
determining whether to authorize the request according to the client authorization policies (Lander, Para. 0142, During programmatic access by REST API clients 708, Cloud Gate 702 may act as an OAuth2 resource server/filter 720 for an application's protected REST APIs 714. It checks for the presence of a request with an authorization header and an access token. When client 708 (e.g., mobile, web apps, JavaScript, etc.) presents an access token (issued by IDCS) to use with a protected REST API 714, Cloud Gate 702 validates the access token before allowing access to the API (e.g., signature, expiration, audience, etc.) [0105][0147][0160][0166]);
based on a determination that the request is to access the first protected resource on behalf of a user (Lander, Para. 0308, the user's privileges alone can be used to evaluate the request, depending on the status of the “onBehalfOfUser” (i.e., if “onBehalfOfUser” is true). In this embodiment, scope determination is performed without the need of an intersection),
determining whether to authorize the request according to the user authorization policies (Lander, Para. 0256, sometimes a request is authorized based on what is being invoked, such by looking at what the user is trying to do (i.e., the Action). For example, a user can be an administrator of a certain application. That information may not be apparent from parameters being passed, but can only be deduced by the fact that the user is trying to access a particular endpoint. There may be access if the user is a tenant administrator or an administrator for the application).
Lander does not explicitly disclose a memory configured with references to protected resources hosted by a resource server,
However, Helmick teaches a memory configured with references to protected resources hosted by a resource server (Helmick, Para. 0038, the logical address space 134 may comprise a plurality (e.g., range) of logical addresses. As used herein, a logical address refers to any identifier for referencing a memory resource (e.g., data), including, but not limited to: a logical block address (LBA), a cache line address, a memory address, a cylinder/head/sector (CHS) address, a file name, an object identifier, an inode, a Universally Unique Identifier (UUID), a Globally Unique Identifier (GUID), a hash code, a signature, an index entry, a range, an extent, or the like.),
Lander and Helmick are both considered to be analogues to the claimed invention because they are in the same field of automatically controlling access by users and services to protected resources.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lander to incorporate the teachings of Helmick to include a memory configured with references to protected resources hosted by a resource server (Helmick, Para. 0038). Doing so would aid the device controller to detect a wear-based attack for a plurality of physical storage locations. In a further embodiment, a device controller is configured to change a set of one or more wear-leveling parameters in response to detecting a wear-based attack (Helmick, Para. 0006).
Although Lander discloses roles, Lander-Helmick do not explicitly teach but Beredimas teaches wherein the protected resources are grouped into namespace and wherein the authorization policies comprise assignments of principals to roles in a protected resource context and a namespace context ((Beredimas, Para. 36)Whereas RBAC systems require pre-defined roles and permission sets, ABAC systems allow for evaluation of arbitrary attributes over the subject (actor), object (resource being affected/accessed), action (operation being executed) and environment (miscellaneous contextual information like time of day or location). (Para. 37) Namespaces may be generated for specific resource types, with each namespace including a purpose-built vocabulary (actors/subjects, verbs/actions, objects/targets, conditions, obligations) specific to that particular namespace. Furthermore, a policy administrator may generate new namespaces to address arbitrary policy use cases. (Para. 39) The policy server 204 may be arranged intermediary the client device 202 and resource(s) 206. The policy server 204 may be configured to receive requests from the client device 202 for accessing a resource 206, identify an applicable namespace 210, and generate and apply a domain-specific policy to the request to authorize access by the client device 202 to the resource 206. (Para. 50-53) Fig. 2).
Lander, Helmick and Beredimas are all considered to be analogues to the claimed invention because they are in the same field of automatically controlling access by users and services to protected resources. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lander and Helmick to incorporate the teachings of Beredimas to include wherein the protected resources are grouped into namespace and wherein the authorization policies comprise assignments of principals to roles in a protected resource context and a namespace context (Beredimas, Para. 0012). Doing so would aid to apply the generated domain-specific policy to the request to identify an effect of the domain-specific policy for the resource, to permit or deny access to the resource. The method may further include permitting or denying access to the resource according to the effect (Beredimas, Para. 0008).
In regards to claim 2, the combination of Lander-Helmick-Beredimas teaches the request authorization server of claim 1, wherein the set of computer-executable instructions further comprise instructions for providing different authorization policy control realms for the client authorization policies and the user authorization policies (Lander, Para. 0218, One embodiment provides fine-grained authorization policies for protecting the IDCS service resources described herein that are based on role-based access control (“RBAC”) and attribute-based access control (“ABAC”). These fine-grained authorization policies provide not only the authorization constructs for controlling access to IDCS resources for administrative operations through IDCS REST APIs, but also provide the constructs for achieving delegated administration, such as by creating different classes of administrators with varying degree of privileges to manage resources. Embodiments use elements of the “eXtensible Access Control Markup Language (“XACML”) resource-authorization model for defining IDCS authorization) and (Lander, Para. 0219, the general concept of scopes is defined in “OAuth”, which is an open standard for authorization that is commonly used as a way for Internet users to log in to third party websites without exposing their password. Generally, OAuth provides to clients a “secure delegated access” to server resources on behalf of a resource owner).
In regards to claim 3, the combination of Lander-Helmick-Beredimas teaches wherein the protected resources are organized according to namespaces, wherein the authorization policies comprise policies of a namespace scope and policies of a protected resource scope (Beredimas, Para. 0012, the at least one processor is further configured to apply the generated domain-specific policy to the request to identify an effect of the domain-specific policy for the resource, to permit or deny access to the resource, and permit or deny access to the resource according to the effect. In some embodiments, the at least one processor is further configured to select the namespace with one or more target attributes that match to the one or more attributes of the request).
Lander, Helmick and Beredimas are all considered to be analogues to the claimed invention because they are in the same field of automatically controlling access by users and services to protected resources. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lander and Helmick to incorporate the teachings of Beredimas to include wherein the authorization policies comprise policies of a namespace scope and policies of a protected resource scope (Beredimas, Para. 0012). Doing so would aid to apply the generated domain-specific policy to the request to identify an effect of the domain-specific policy for the resource, to permit or deny access to the resource. The method may further include permitting or denying access to the resource according to the effect (Beredimas, Para. 0008).
In regards to claim 4, the combination of Lander-Helmick-Beredimas teaches the request authorization server of claim 1,
wherein the first protected resource to which access is requested is in a first namespace and wherein determining whether to authorize the request according to the client authorization policies comprises determining if the request is authorized based on any client authorization policies having a namespace scope of the first namespace.
However, wherein the first protected resource to which access is requested is in a first namespace and wherein determining whether to authorize the request according to the client authorization policies comprises determining if the request is authorized based on any client authorization policies having a namespace scope of the first namespace Beredimas teaches (Beredimas, Para. 0039, the policy server 204 may be configured to receive requests from the client device 202 for accessing a resource 206, identify an applicable namespace 210, and generate and apply a domain-specific policy to the request to authorize access by the client device 202 to the resource 206, as described in greater detail below).
Lander, Helmick and Beredimas are all considered to be analogues to the claimed invention because they are in the same field of automatically controlling access by users and services to protected resources. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lander and Helmick to incorporate the teachings of Beredimas to include wherein the first protected resource to which access is requested is in a first namespace and wherein determining whether to authorize the request according to the client authorization policies comprises determining if the request is authorized based on any client authorization policies having a namespace scope of the first namespace Beredimas teaches (Beredimas, Para. 0039). Doing so would aid to apply the generated domain-specific policy to the request to identify an effect of the domain-specific policy for the resource, to permit or deny access to the resource. The method may further include permitting or denying access to the resource according to the effect (Beredimas, Para. 0008).
In regards to claim 5, the combination of Lander-Helmick-Beredimas teaches the request authorization server of claim 4, wherein determining whether to authorize the request according to the client authorization policies comprises determining if the request is authorized based on any client authorization policies having a resource scope of the protected resource (Beredimas, Para. 0038, the policy server 204 may be configured to receive (e.g., from the client device 202) a request to access a resource 206. The request may include various attributes (e.g., user identification information, resource information, client device 202 information, etc.). The policy server 204 may be configured to identify a set of namespaces 210 for generating domain-specific policies). Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lander and Helmick to incorporate the teachings of Beredimas to include the request authorization server of claim 4, wherein determining whether to authorize the request according to the client authorization policies comprises determining if the request is authorized based on any client authorization policies having a resource scope of the protected resource (Beredimas, Para. 0038). Doing so would aid to apply the generated domain-specific policy to the request to identify an effect of the domain-specific policy for the resource, to permit or deny access to the resource. The method may further include permitting or denying access to the resource according to the effect (Beredimas, Para. 0008).
In regards to claim 6, the combination of Lander-Helmick-Beredimas teaches the request authorization server of claim 1, wherein the first protected resource to which access is requested is in a first namespace and wherein determining whether to authorize the request according to the user authorization policies comprises determining if the request is authorized based on any user authorization policies having a namespace scope of the first namespace (Beredimas, Para. 0045, the policy server 204 may be configured to parse the request to identify the user generating the request (e.g., by extracting the log-in credentials provided in the request, by extracting the user identifier included in the request, by extracting the unique identifier of the client device 202 and cross-referencing the unique identifier of the client device with a plurality of unique identifiers to identify a user corresponding to the client device 202, and so forth). The policy server 204 may be configured to parse the request to identify the target resource 206 indicated in the request. As described in greater detail below, the policy server 204 may be configured generate a domain-specific policy for applying to the request using the namespaces 210 corresponding to the request). Lander, Helmick and Beredimas are all considered to be analogues to the claimed invention because they are in the same field of automatically controlling access by users and services to protected resources. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lander and Helmick to incorporate the teachings of Beredimas to include wherein the first protected resource to which access is requested is in a first namespace and wherein determining whether to authorize the request according to the user authorization policies comprises determining if the request is authorized based on any user authorization policies having a namespace scope of the first namespace (Beredimas, Para. 0045). Doing so would aid to apply the generated domain-specific policy to the request to identify an effect of the domain-specific policy for the resource, to permit or deny access to the resource. The method may further include permitting or denying access to the resource according to the effect (Beredimas, Para. 0008).
In regards to claim 7, the combination of Lander-Helmick-Beredimas teaches the request authorization server of claim 6, wherein determining whether to authorize the request according to the user authorization policies comprises determining if the request is authorized based on any user authorization policies having a resource scope of the first protected resource (Beredimas, Para. 0047, information or data corresponding to the user requesting access to a resource 206, and/or information or data corresponding to the resource 206. The policy generation engine 208 may be configured to parse the request to identify each of the attributes included in the request. Hence, the policy generation engine 208 may be configured to identify conditions of the client device 202 issuing the request, the user requesting access to the resource 206, and the resource 206 itself). Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lander and Helmick to incorporate the teachings of Beredimas to include wherein determining whether to authorize the request according to the user authorization policies comprises determining if the request is authorized based on any user authorization policies having a resource scope of the first protected resource (Beredimas, Para. 0047). Doing so would aid to apply the generated domain-specific policy to the request to identify an effect of the domain-specific policy for the resource, to permit or deny access to the resource. The method may further include permitting or denying access to the resource according to the effect (Beredimas, Para. 0008).
In regards to claim 8, the combination of Lander-Helmick-Beredimas teaches the request authorization server of claim 1, wherein the set of computer-executable instructions further comprise instructions for:
determining that the request is to access the first protected resource on behalf of a service when the request includes an access token granted according to a client credential grant (Lander, Para. 0182, OAuth microservice 1004 then redirects browser 1002 to a callback URL with an authorization (“AZ”) code. Browser 1002 sends the AZ code to OAuth microservice 1004 to request the required tokens 1032. Browser 1002 also includes its client credentials (obtained when registering in IDCS as an OAuth2 client) in the HTTP authorization header. OAuth microservice 1004 in return provides the required tokens 1032 to browser 1002. In one embodiment, tokens 1032 provided to browser 1002 include JW identity and access tokens signed by the IDCS OAuth2 server).
In regards to claim 9, the combination of Lander-Helmick-Beredimas teaches the request authorization server of claim 8, wherein the set of computer-executable instructions further comprise instructions for:
determining that the request is to access the first protected resource on behalf of a service when the request includes an access token granted according to an authorization code grant (Lander, Para. 0160, In one embodiment, various tokens codify different tenancies. A URL token may identify the tenancy of the application that requests a service. An identity token may codify the identity of a user that is to be authenticated. An access token may identify multiple tenancies. For example, an access token may codify the tenancy that is the target of such access (e.g., an application tenancy) as well as the user tenancy of the user that is given access).
Regarding claims 10 and 16, the claims 10 and 16 are interpreted and rejected for the same rational set forth in claim 1.
Regarding claim 11, the claim 11 is interpreted and rejected for the same rational set forth in claim 2.
Regarding claims 12 and 17, the claims 12 and 17 are interpreted and rejected for the same rational set forth in claim 3.
Regarding claims 13 and 18, the claims 13 and 18 are interpreted and rejected for the same rational set forth in claim 4.
Regarding claims 14 and 19, the claims 14 and 19 are interpreted and rejected for the same rational set forth in claim 7.
Regarding claim 15, the claim 15 is interpreted and rejected for the same rational set forth in claim 8.
Regarding claim 20, the claim 20 is interpreted and rejected for the same rational set forth in claim 9.
In regards to claim 21, the combination of Lander-Helmick-Beredimas teaches the system of claim 1, wherein the authorization policies comprises hypertext transfer protocol methods as privileges ((Lander, Para. 219) OAuth provides to clients a “secure delegated access” to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with HTTP, OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server. Embodiments implement OAuth to grant roles to scopes to segregate and delegate privileges throughout the system. (Para. 152, 0224, 137)).
Regarding claim 22, the claim 22 is interpreted and rejected for the same rational set forth in claim 21.
Regarding claim 23, the claim 23 is interpreted and rejected for the same rational set forth in claim 21.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Huang (US-20190386960-A1) teaches generally to firewall configuration management, and, more specifically, to managing firewall configurations using dynamically generated block lists. A computer-implemented method includes adding an entry as a record in a block list entries table and associating the entry with a block list in a block list table and with an observable in an observables table. The method also includes activating the entry in the block list entries table to allow or block subsequent occurrences of the observable on a client network. The method further includes receiving a request for the block list from a firewall disposed on the client network and, in response, generating the block list from activated entries in the block list table and block list entries table and sending the block list to the firewall, wherein the firewall is configured to allow or block network traffic associated with the observable on the client network in accordance with the block list.
Li (US-2019/0342181-A1) teaches techniques for efficiently monitoring time-series data for a metric of interest using limited subsets of the time-series data and, based on the modeling, to generate predictions for the metric. Based on the predictions for the metric, one or more actions may be configured to be taken when the predicted value for the metric is outside of a specified range or exceeds a specified threshold.
Poort (US-2018/0357097-A1) teaches systems and methods for addressing the interdependencies that result from integrating the computing resources of multiple hardware and software providers. The integrated, multi-provider cloud-based platform of the present invention employs abstraction layers for communicating with and integrating the resources of multiple back-end hardware providers, multiple software providers and multiple license servers. These abstraction layers and associated functionality free users not only from having to implement and configure provider-specific protocols, but also from having to address interdependencies among selected hardware, software and license servers on a job-level basis or at other levels of granularity.
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 A AYALA whose telephone number is (571)270-3912. The examiner can normally be reached Monday-Thursday 8AM-5PM; Friday: Variable EST.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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 AYALA/Primary Examiner, Art Unit 2496