DETAILED ACTION
Notice of Pre-AIA or AIA Status
1.The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
2. According to applicant’s arguments filed on 12/19/2025, claims 1-6 have been amended; and new claims7-8 have been added, hereby acknowledged.
3.Applicant's arguments with respect to 101 rejection have been fully considered but they are not persuasive.
4. Applicant argues the claims are not recite an abstract idea within the “mental processes” grouping. Applicant states that the claims explicitly recites a distributed computer system architecture involving two distinct computer systems, and distributed architecture necessarily involves: Network communication protocols between distinct computing devices; Inter-process communication across system boundaries; Data serialization and transmission over computer networks; Electronic enforcement mechanisms at the client device level; Files stored on or accessible through the client device that are subject to access control;. Therefore, these computer-to-computer interactions are technologically rooted and cannot be performed as a mental process or with pen and paper.
5. Examiner would like to point out that independent claims 1 and 5 recites: “(a) receiving, by a first computer system, a request from a second computer system for a user to access content of a digital file; (b) obtaining, by the first computer system, information associated with the request, the information comprising at least part of: (i) metadata of the digital file, (ii) attributes of the user, and (iii) properties of the second computer system;(c) evaluating, by the first computer system, the obtained information against a plurality of stored access policies, each access policy specifying:(i) one or more conditions to be satisfied by at least portion of the obtained information, and (ii) one or more access-control permissions to be granted when all the conditions are satisfied; (d) identifying. by the first computer system, one or more access policies for which all conditions are satisfied by the obtained information; (e) generating, by the first computer system, a final set of access-control permissions applicable to the request by merging the access-control permissions associated with the identified policies; (f) transmitting, by the first computer system, the final set of access-control permissions to the second computer system; and (g) controlling, by the second computer system, the user's access to the content of the digital file based on the received final set of access-control permissions
6. Here, Examiner notes that the claims limitations merely involve collecting the metadata of the files, properties of device and attributes of the user’s and upon receiving a request from a user to access a file on a device, the matching policies are selected by matching the file’s metadata, the user’s attribute and the properties of the device, and the final permissions are determined by merging the permissions from the matching policies; and the final set of permissions can be used by applications to enforce the access of the file by the user on the device in the request.
Each of these limitations are drawn to abstract ideas such as the collection and analysis of data, and presenting the result of the analysis (for matching policies) and then granting access permission. They may additionally be construed as being implemented in a computer network. However, all of these steps are similar to those that can be performed by a human mind or require only a generic computer to accomplish. Therefore, when considered singly, and as an ordered combination, i.e., the claim as a whole, these claim limitations do not represent anything more than abstract ideas and thus are drawn to a judicial exception. These limitations do not represent any fundamental improvement to the underlying technology of the computer network since they merely represent steps designed to regulate user access permission to the network and don't make any change to the network itself in terms of things such as memory utilization, processor configuration, and etc. As such, the claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas.
7. Moreover, the independent claims do not recite anything about distributed computer system architecture as argued by the applicant. For example, the claims do not specifically recite the distributed file storage architecture (files on client device), and client-side enforcement of permission locally stored. And the network based transmission of structured permission data in distributed network environment that improves computer functionality. So, Examiner finds that the limitation by limitation analysis of the claims fails to supply an inventive concept that is significantly more than the abstract idea. The recited limitation is no more than well-understood, routine, and conventional activities previously known in the industry.
8. Regarding 102 rejection, applicant's arguments have been fully considered but they are not persuasive.
9. Applicant argues the independent claims recite a distributed file storage fundamentally different from the primary reference Yaghoobi’s centralized system. Applicant then states that the claims recites two distinct computer systems; and the files is at the second system (files are stored locally) and transmitting permission data to a separate system for enforcement on locally stored files.
10. Examiner would like to point out that, the independent claims do not recite anything about distributed computer system architecture and the files is at the second system (files are stored locally) as argued by the applicant. As such, applicant arguments are not persuasive as the limitation argued are not present in the claims. Therefore, the rejection is maintained and is made Final.
Claim Rejections - 35 USC § 101
11. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
12. Claims 1-8 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1 and 5 satisfy the Step 1 because the claims are a computer-implemented method and system respectively.
In Step 2A prong 1, claims 1 and 5 recites: “store a plurality of policies, each policy comprising conditions to match metadata of a plurality of files, conditions to match attributes of a plurality of users, conditions to match properties of a plurality of devices, and a set of access permissions; receive a request for a user to access a file on a device, and retrieve the file’s metadata, the user’s attributes, and the device’s property either from the request or from other sources using the information associated with the request, and determine the user’s access permissions to the file on the device by comparing each of the stored policies with the file’s meta data, the user’s attributes and the device’s properties, and merge the permissions from the policies that satisfy all conditions into a final set of permissions, and output the final permissions to be sent to the requesting device or application”, which under the broadest reasonable interpretation, the steps can be performed in the human mind. These limitations merely involve collecting the metadata of the files, properties of device and attributes of the user’s and upon receiving a request from a user to access a file on a device, the matching policies are selected by matching the file’s metadata, the user’s attribute and the properties of the device, and the final permissions are determined by merging the permissions from the matching policies; and the final set of permissions can be used by applications to enforce the access of the file by the user on the device in the request, which are performed in the human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims 1 and 5 recite an abstract idea.
In Step 2A prong 2, the judicial exception is not integrated into a practical application because computer system, processor circuit and memory circuit are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component. The claims also recite the additional steps of “storing a plurality of access policies:”;…..and “determine the user’s access permissions to the file on the device by comparing each of the stored policies with the file’s meta data, the user’s attributes and the device’s properties”. However, these steps are insignificant extra-solution activity. The receiving and maintaining steps merely involve gathering and storing data to be used by the mental processes recited in the claims. The request step and the comparing/matching step merely involves transmitting information and comparing the collected information in the storage. Adding insignificant extra-solution activity to the judicial exception is not enough to qualify as “significantly more”. The additional elements or steps do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
In Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because computer system, memory and processor circuit are general purpose computer components, which are well-understood, routine and conventional (see in the present disclosure paragraphs 0088-0090 where include conventional components such as a processor, a memory,… a network interface (see, para:0068), performing the steps recited in the claims and are not sufficient to transform a judicial exception into a patentable invention.
13. Regarding claims 2-4 and 6-8 recite the elements the metadata of a file is a set of data linked with the file, and the attributes of a user is a set of data linked with the user, and the properties of a device is a set of data linked with the device”;…. “the metadata of the file, the attributes of the user and the properties of the device are either included in the request, or are retrievable using the information associated with the request”; ….and “the access permissions from policies include denying access to the content of a file or allowing access to the content of a file”. However, these features do not add meaningful limitation to the abstract idea because they are merely collections of data (gathering and storing information), mental processes and extra-solution activity (transmitting information and comparing the collected information in the storage).
14. The elements recited in claims 2-4 and 6-8 when considered individually or in an ordered combination, fail to amount to significantly more than the abstract idea. Accordingly, claims 1-6 are not eligible.
Claim Rejections - 35 USC § 102
15.The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
16. Claim(s) 1-8 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Yaghoobi (US Pub.No.2021/0303714).
17. Regarding claim 1 Yaghoobi teaches method computer-implemented method for controlling access to digital contents, the method comprising: (a) receiving, by a first computer system, a request from a second computer system for a user to access content of a digital file;
(b) obtaining, by the first computer system, information associated with the request, the information comprising at least part of: (i) metadata of the digital file, (ii) attributes of the user, and (iii) properties of the second computer system;
(c) evaluating, by the first computer system, the obtained information against a plurality of stored access policies, each access policy specifying:
(i) one or more conditions to be satisfied by at least portion of the obtained information, and
(ii) one or more access-control permissions to be granted when all the conditions are satisfied (abstract and Para:0004 teaches receiving a technical data file via a computer network, and securely storing the technical data file in a network-accessible technical data repository configured to restrict access to the technical data file. An unstructured policy document corresponding to the technical data file is computer-analyzed with a previously-trained machine-learning model configured to extract one or more policy attributes from unstructured policy documents. Extracted policy attributes are stored in a network-accessible policy library. A request for a user to access the technical data file is received via the computer network. One or more user attributes of the user are recognized. After verifying that the one or more user attributes do not conflict with the one or more policy attributes stored in the network-accessible policy library or an additional attribute corresponding to the technical data file, the user is provided network access to the technical data file stored in the network-accessible technical data repository.
Fig.2, Para:00026-0029 teaches Policy decision and enforcement logic 220 may grant customized, highly granular rights to a user 222 based on a comparison of policy attributes 225 and user attributes 230. Para:0030-0033 teaches policy attributes 225 may refer to groups of technical data files. Further, each individual technical data file 210 may include resource attributes 250 and action attributes 252 that are particular for that specific file. There may be multiple resource attributes 250 and action attributes 252 for each technical data file 210, as different end users may be afforded different levels of granularity with regard to each technical data file 210 (view, edit, delete, print, comment, approve, etc.). For example, a senior engineer may be granted broader action attributes than a clerical worker. Action attributes 252 may extend across multiple data files. For example, a user may be restricted from viewing or editing a first file if they already have a second file opened, or if a third file has been opened within a threshold duration. Certain users may only be able to open a certain file for a certain duration, and/or during specific approved hours, if a supervisor is also logged into the system, etc. More complex technical data files 210 may include more complex action attributes, such as restrictions on what kinds of simulations may be run, limits on playback speed and/or viewing resolution, separation of a/v components, etc. The user attributes includes subject attributes 244 may refer to attributes of each user 222, such as organization, role, title, statement of work (SoW), citizenship, export control classification numbers (ECCN), etc. Context attributes 246 may refer to temporal attributes for user access, such as time, office, country, etc. For example, certain policies may change or sunset over time. Access to certain technical data files may be allowed for certain jurisdictions, but not within others. Access may be restricted to particular applications and/or browser types, to computer networks with a particular level of security, etc. Para:0028-0030 and Para:0042 teaches the metadata of a file includes file name, file type (see, para:0083), file accession number etc.
Para:0017 and Para:0031-0033 teaches the properties of a device include location information about the device and the time of access from the particular device);
(d) identifying, by the first computer system, one or more access policies for which all conditions are satisfied by the obtained information; (e) generating, by the first computer system, a final set of access-control permissions applicable to the request by merging the access-control permissions associated with the identified policies; (f) transmitting, by the first computer system, the final set of access-control permissions to the second computer system; and
(g) controlling, by the second computer system, the user's access to the content of the digital file based on the received final set of access-control permissions (Fig.3 and Para:0058-0059 teaches authorization module 335 may provide an interface for a user 340 to request access to technical data files 312. Authorization module 335 may be configured to receive a request 342 for user 340 to access technical data files 312, to recognize one or more user attributes 344 of user 340, and to provide the user network access to technical data files 312 stored in technical data repository 310 after verifying that the one or more user attributes 344 do not conflict with the policy attributes 327 stored in the network-accessible policy library 330 or any additional attributes 347 corresponding to technical data files 312. User attributes 344 may be stored at network-accessible policy library 330, or any other secure, network-accessible database. User attributes 344 may be retrieved based on a user identification (e.g., username and password, fingerprint, retinal scan, combined security measures, etc.). Each individual user 340 may not be granted access to generate, edit, or alter their own user attributed 344. As such, the user attributes 344 may be secured, dynamic, and unfakable. Authorization module 335 may be a web-portal, web-application, standalone application, ftp portal, application programming interface (API), or any other suitable secure software interface. Authorization module 335 may apply cryptography to technical data repository 310, for example by encrypting technical data files 312 at rest, then providing a key to user 340 to decrypt technical data files 312 responsive to a successful verification of user attributes 344 against policy attributes 327.
Para:0060-0062 teaches As an example, authorization module 335 may receive a request 342, convert request 342 into an access request associated with a plurality of user attributes 344, and send the access request to policy decision logic 350. As described with regard to fig.2, user attributes 344 may include subject attributes, context attributes, and/or additional attributes. Policy decision logic 350 may evaluate request 342 and user attributes 344 against the policy attributes 327, and then make an active determination whether to grant user 340 access to technical data files 312. An authorization decision may then be returned to authorization module 335. In scenarios wherein the authorization decision indicates to grant the request 342, authorization module 335 may then provide granular access to technical data files 312, For example, a level of granularity provided to user 340 may be determined based on policy attributes 327, and one or more user attributes 344. For example, as described with regard to FIG. 2, some users may be provided greater access and abilities to edit or manipulate technical data files 312, whereas other users may only be able to view or read technical data files 312).
18. Regarding claim 2 Yaghoobi teaches method, wherein the metadata of the digital file comprises data linked to the digital file (Para:0028-0030 and Para:0042 teaches the metadata of a file includes file name, file type (see, para:0083), file accession number etc.), the attributes of the user comprise data linked to the user (Para:0031-0033 teaches the user attributes include user role, user credentials, user organization etc.), and the properties of the second computer system comprise data linked to the second computer system (Para:0017 and Para:0031-0033 teaches the properties of a device include location information about the device and the time of access from the particular device).
19. Regarding claim 3 Yaghoobi teaches method, wherein the metadata of the digital file, the attributes of the user and the properties of the second computer system are either included in the request, or are retrievable using the information associated with the request (Para:0026-0033 and Fig.3, Para:0058-0062 teaches the request includes the metadata of the file, the attributes of the user and the properties of the device).
20. Regarding claim 4 Yaghoobi teaches method, wherein the access-control permissions comprise at least one of: deny access to the content of the digital file, read-only access to the content of the digital file, read-and-write access to the content of the digital file and read-and-execute access to the content of the digital file (Para:0030 teaches Policy attributes 225 may refer to groups of technical data files. Further, each individual technical data file 210 may include resource attributes 250 and action attributes 252 that are particular for that specific file. There may be multiple resource attributes 250 and action attributes 252 for each technical data file 210, as different end users may be afforded different levels of granularity with regard to each technical data file 210 (view, edit, delete, print, comment, approve, etc.). For example, a senior engineer may be granted broader action attributes than a clerical worker. Action attributes 252 may extend across multiple data files. For example, a user may be restricted from viewing or editing a first file if they already have a second file opened, or if a third file has been opened within a threshold duration. Certain users may only be able to open a certain file for a certain duration, and/or during specific approved hours, if a supervisor is also logged into the system, etc. More complex technical data files 210 may include more complex action attributes, such as restrictions on what kinds of simulations may be run, limits on playback speed and/or viewing resolution, separation of a/v components, etc.
Para:0058-0062 teaches Policy decision logic 350 may evaluate request 342 and user attributes 344 against the policy attributes 327, and then make an active determination whether to grant user 340 access to technical data files 312. An authorization decision may then be returned to authorization module 335. In scenarios wherein the authorization decision indicates to grant the request 342, authorization module 335 may then provide granular access to technical data files 312, For example, a level of granularity provided to user 340 may be determined based on policy attributes 327, and one or more user attributes 344. For example, as described with regard to FIG. 2, some users may be provided greater access and abilities to edit or manipulate technical data files 312, whereas other users may only be able to view or read technical data files 312).
21. Regarding claim 5 Yaghoobi teaches a system for controlling access to digital content, the system comprising: a plurality of policy servers, each comprising a processor and a memory storing instructions that, when executed by the processor, cause the policy server to:
(a) store a plurality of access policies, each access policy comprising: (i) one or more conditions to match at least a portion of (1) digital file metadata, (2) user attributes, and (3) device properties, and (ii) one or more access-control permissions;
(b) receive, from a client device, a request for a user to access a digital file stored on or accessible though the client device; (c) obtain information associated with the request, the information comprising at least a portion of: (i) metadata of the digital file, (ii) attributes of the user, and (iii) properties of the client device, either from the request or from sources identified using information from the request; (d) evaluate the obtained information against the stored access policies; (e) identify the matching access policies for which all specified conditions are satisfied by at least a portion of the obtained information; (f) generate a final set of access-control permissions applicable to the request by merging the access-control permissions from the matching access policies; and (g) transmit the final set of access-control permissions to the client device; and a plurality of client devices, each comprising a processor and a memory storing instructions that, when executed by the processor, cause the client device to:
(h) transmit, to at least one policy server, a request for access-control permissions for a user to access a digital file stored on or accessible though the client device;
(i) receive, from at least one of the policy servers, the final set of access-control permissions; and (j) control access to the content of the digital file by either denying the user access to the content of the digital file or granting the user access to the content of the digital file in accordance with the final set of access-control permissions (see, the rejection for claim 1)..
22. Regarding claim 6 Yaghoobi teaches the system, wherein the memory of each policy server further comprises instructions executable by the processor, to merge the access-control permissions from the matching access policies by applying a rule in which
(a) when any of the matching access policies specifies a deny permission for reading the content of the digital file, the final set of access-control permissions comprises only the deny permission for reading the content of the digital file; and (b) when none of the matching access policies specifies a deny permission for reading the content of the digital file, the policy server generates the final set of access-control permissions by, for each file operation specified in the matching access policies: i. including a deny permission for that file operation when any of the matching access policies specifies a deny permission for that file operation, and
ii. aggregating all grant permissions for that file operation and removing duplicate permissions when none of the matching access policies specifies a deny permission for that file operation (Fig.3 and Para:0058-0059 teaches authorization module 335 may provide an interface for a user 340 to request access to technical data files 312. Authorization module 335 may be configured to receive a request 342 for user 340 to access technical data files 312, to recognize one or more user attributes 344 of user 340, and to provide the user network access to technical data files 312 stored in technical data repository 310 after verifying that the one or more user attributes 344 do not conflict with the policy attributes 327 stored in the network-accessible policy library 330 or any additional attributes 347 corresponding to technical data files 312. User attributes 344 may be stored at network-accessible policy library 330, or any other secure, network-accessible database. User attributes 344 may be retrieved based on a user identification (e.g., username and password, fingerprint, retinal scan, combined security measures, etc.). Each individual user 340 may not be granted access to generate, edit, or alter their own user attributed 344. As such, the user attributes 344 may be secured, dynamic, and unfakable. Authorization module 335 may be a web-portal, web-application, standalone application, ftp portal, application programming interface (API), or any other suitable secure software interface. Authorization module 335 may apply cryptography to technical data repository 310, for example by encrypting technical data files 312 at rest, then providing a key to user 340 to decrypt technical data files 312 responsive to a successful verification of user attributes 344 against policy attributes 327.
Para:0060-0062 teaches As an example, authorization module 335 may receive a request 342, convert request 342 into an access request associated with a plurality of user attributes 344, and send the access request to policy decision logic 350. As described with regard to fig.2, user attributes 344 may include subject attributes, context attributes, and/or additional attributes. Policy decision logic 350 may evaluate request 342 and user attributes 344 against the policy attributes 327, and then make an active determination whether to grant user 340 access to technical data files 312. An authorization decision may then be returned to authorization module 335. In scenarios wherein the authorization decision indicates to grant the request 342, authorization module 335 may then provide granular access to technical data files 312, For example, a level of granularity provided to user 340 may be determined based on policy attributes 327, and one or more user attributes 344. For example, as described with regard to FIG. 2, some users may be provided greater access and abilities to edit or manipulate technical data files 312, whereas other users may only be able to view or read technical data files 312).
23. Regarding claim 7 Yaghoobi teaches the system, wherein the memory of each client device further comprises instructions executable by the processor to enforce the final set of access- control permissions received from the at least one policy server by:
(a) denying the user access to the content of the digital file when the final set of access- control permissions comprises a deny permission for reading the content of the digital file; and
(b) when the final set of access-control permissions does not comprise a deny permission for reading the content of the digital file, controlling the user's access to the content of the digital file by enabling or disabling file operations in accordance with the access- control permissions for each file operation specified in the final set of access-control permissions Para:0030 teaches Policy attributes 225 may refer to groups of technical data files. Further, each individual technical data file 210 may include resource attributes 250 and action attributes 252 that are particular for that specific file. There may be multiple resource attributes 250 and action attributes 252 for each technical data file 210, as different end users may be afforded different levels of granularity with regard to each technical data file 210 (view, edit, delete, print, comment, approve, etc.). For example, a senior engineer may be granted broader action attributes than a clerical worker. Action attributes 252 may extend across multiple data files. For example, a user may be restricted from viewing or editing a first file if they already have a second file opened, or if a third file has been opened within a threshold duration. Certain users may only be able to open a certain file for a certain duration, and/or during specific approved hours, if a supervisor is also logged into the system, etc. More complex technical data files 210 may include more complex action attributes, such as restrictions on what kinds of simulations may be run, limits on playback speed and/or viewing resolution, separation of a/v components, etc.
Para:0058-0062 teaches Policy decision logic 350 may evaluate request 342 and user attributes 344 against the policy attributes 327, and then make an active determination whether to grant user 340 access to technical data files 312. An authorization decision may then be returned to authorization module 335. In scenarios wherein the authorization decision indicates to grant the request 342, authorization module 335 may then provide granular access to technical data files 312, For example, a level of granularity provided to user 340 may be determined based on policy attributes 327, and one or more user attributes 344. For example, as described with regard to FIG. 2, some users may be provided greater access and abilities to edit or manipulate technical data files 312, whereas other users may only be able to view or read technical data files 312).
24. Regarding claim 8 Yaghoobi teaches the system wherein the file operations comprise at least one of: (a) reading the content of the digital file; (b) writing to or modifying the content of the digital file; (c) executing the content of the digital file; (d) copying part of the content to a system clipboard; and (e) transmitting the digital file to a remote device Para:0030 teaches Policy attributes 225 may refer to groups of technical data files. Further, each individual technical data file 210 may include resource attributes 250 and action attributes 252 that are particular for that specific file. There may be multiple resource attributes 250 and action attributes 252 for each technical data file 210, as different end users may be afforded different levels of granularity with regard to each technical data file 210 (view, edit, delete, print, comment, approve, etc.). For example, a senior engineer may be granted broader action attributes than a clerical worker. Action attributes 252 may extend across multiple data files. For example, a user may be restricted from viewing or editing a first file if they already have a second file opened, or if a third file has been opened within a threshold duration. Certain users may only be able to open a certain file for a certain duration, and/or during specific approved hours, if a supervisor is also logged into the system, etc. More complex technical data files 210 may include more complex action attributes, such as restrictions on what kinds of simulations may be run, limits on playback speed and/or viewing resolution, separation of a/v components, etc.
Para:0058-0062 teaches Policy decision logic 350 may evaluate request 342 and user attributes 344 against the policy attributes 327, and then make an active determination whether to grant user 340 access to technical data files 312. An authorization decision may then be returned to authorization module 335. In scenarios wherein the authorization decision indicates to grant the request 342, authorization module 335 may then provide granular access to technical data files 312, For example, a level of granularity provided to user 340 may be determined based on policy attributes 327, and one or more user attributes 344. For example, as described with regard to FIG. 2, some users may be provided greater access and abilities to edit or manipulate technical data files 312, whereas other users may only be able to view or read technical data files 312).
Conclusion
THIS ACTION IS MADE FINAL. 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 DEREENA T CATTUNGAL whose telephone number is (571)270-0506. The examiner can normally be reached Mon-Fri : 7:30 AM-5 PM 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, Lynn Feild can be reached at 571-272-2092. 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.
/DEREENA T CATTUNGAL/Primary Examiner, Art Unit 2431