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 .
Claim Rejections - 35 USC § 101
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Regarding to claims 1-8
Claim 1
A method comprising:
a. receiving a client request through a client path providing access to data stored across multiple tiers of storage;
b. selectively performing a verification as part of processing the client request through the client path; and
c. selectively deferring a distributed check associated with the data being accessed by the client request, wherein the distributed check is deferred as a background check decoupled from a frontend that interfaces with the client.
Step 1, This part of the eligibility analysis evaluates whether the claim falls within any statutory category. See MPEP 2106.03. The claim recites at least one step or act, including steps a) - c). Thus, the claim is to a process, which is one of the statutory categories of invention. (Step 1: YES).
Step 2A – Prong One: This part of the eligibility analysis evaluates whether the claim recites a judicial exception. As explained in MPEP 2106.04, subsection II, a claim “recites” a judicial exception when the judicial exception is “set forth” or “described” in the claim.
Step b. “selectively performing a verification as part of processing the client request through the client path” Performing a verification can be an evaluation filename, file path, or user permission to access the request data. This step is nothing more than observations, evaluations, judgments that can be performed in human mind (i.e., a mental process [Wingdings font/0xF3] abstract idea)
Step c. selectively deferring a distributed check associated with the data being accessed by the client request, wherein the distributed check is deferred as a background check decoupled from a frontend that interfaces with the client. The distributed check is recited at a high level of generality. Performing a distributed check can be an evaluation filename, file path, or user permission to access the request data. A process can be a foreground process or a background process. This step is nothing more than observations, evaluations, judgments that can be performed in human mind (i.e., a mental process [Wingdings font/0xF3] abstract idea)
“Unless it is clear that a claim recites distinct exceptions, such as a law of nature and an abstract idea, care should be taken not to parse the claim into multiple exceptions, particularly in claims involving abstract ideas.” MPEP 2106.04, subsection II.B. However, if possible, the examiner should consider the limitations together as a single abstract idea rather than as a plurality of separate abstract ideas to be analyzed individually. “For example, in a claim that includes a series of steps that recite mental steps as well as a mathematical calculation, an examiner should identify the claim as reciting both a mental process and a mathematical concept for Step 2A, Prong One to make the analysis clear on the record.” MPEP 2106.04, subsection II.B. Under such circumstances, however, the Supreme Court has treated such claims in the same manner as claims reciting a single judicial exception. Id. (discussing Bilski v. Kappos, 561 U.S. 593 (2010)). Here, limitations (b) - (c) are considered together as a single abstract idea for further analysis. (Step 2A, Prong One: YES).
Step 2A, Prong Two: This part of the eligibility analysis evaluates whether the claim as a whole integrates the recited judicial exception into a practical application of the exception or whether the claim is “directed to” the judicial exception. This evaluation is performed by (1) identifying whether there are any additional elements recited in the claim beyond the judicial exception, and (2) evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. See MPEP 2106.04(d).
The claim recites the additional elements/limitations: “a client request”, “a client path”, “multiple tiers of storage”, “distributed check”, “background check”, “a frontend”, and, a. receiving a client request through a client path providing access to data stored across multiple tiers of storage.
a) MPEP § 2106.05(a) "Improvements to the Functioning of a Computer or to Any Other Technology or Technical Field."
There is no improvement to Functioning of a Computer or to Any Other Technology or Technical Field. The limitation a) is obtaining a request from a client to access data. The limitation does not make any improvements to the functionalities of a computer, database technology, or any other technologies.
b) MPEP § 2106.05(b) Particular Machine. The judicial exception does not apply to any particular machine.
The claim is silent regarding specific limitations directed to an improved computer system, processor, memory, network, database, or Internet, nor do applicant direct examiner’s attention to such specific limitations. "[T]he mere recitation of a generic computer cannot transform a patent-ineligible abstract idea into a patent-eligible invention." Alice, 573 U.S. at 223; see also Bascom Glob. Internet Servs., Inc. v. AT&T Mobility LLC, 827 F.3d 1341, 1348 (Fed. Cir. 2016) ("An abstract idea on 'an Internet computer network' or on a generic computer is still an abstract idea."). Applying this reasoning here, the claim is not directed to a particular machine, but rather merely implement an abstract idea using generic computer components such as ““a client request”, “a client path”, “multiple tiers of storage”, “distributed check”, “background check”, “a frontend”. Thus, the claims fail to satisfy the "tied to a particular machine" prong of the Bilski machine-or-transformation test.
c) MPEP § 2106.05(c) Particular Transformation.
The claim operates to obtain a client request, perform a verification and distributed back as background process. The steps are not a "transformation or reduction of an article into a different state or thing constituting patent-eligible subject matter[.]" See In re Bilski, 545 F.3d 943, 962 (Fed. Cir. 2008) (en bane), aff'd sub nom, Bilski v. Kappas, 561 U.S. 593 (2010); see also CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011) ("The mere manipulation or reorganization of data ... does not satisfy the transformation prong."). Applying this guidance here, the claims fail to satisfy the transformation prong of the Bilski machine-or-transformation test.
d) MPEP § 2106.05(e) Other Meaningful Limitations.
This section of the MPEP guides: Diamond v. Diehr provides an example of a claim that recited meaningful limitations beyond generally linking the use of the judicial exception to a particular technological environment. 450 U.S. 175, ... (1981). In Diehr, the claim was directed to the use of the Arrhenius equation ( an abstract idea or law of nature) in an automated process for operating a rubber-molding press. 450 U.S. at 177-78 .... The Court evaluated additional elements such as the steps of installing rubber in a press, closing the mold, constantly measuring the temperature in the mold, and automatically opening the press at the proper time, and found them to be meaningful because they sufficiently limited the use of the mathematical equation to the practical application of molding rubber products. 450 U.S. at 184... In contrast, the claims in Alice Corp. v. CLS Bank International did not meaningfully limit the abstract idea of mitigating settlement risk. 573 U.S._ .... In particular, the Court concluded that the additional elements such as the data processing system and communications controllers recited in the system claims did not meaningfully limit the abstract idea because they merely linked the use of the abstract idea to a particular technological environment (i.e., "implementation via computers") or were well-understood, routine, conventional activity. MPEP § 2106.05(e).
The limitations a) is obtaining a request from a client to access data is meaningful limitations because it is a pre-solution activity. The limitations are not meaningful limitations.
e) MPEP § 2106.05(g) Insignificant Extra-Solution Activity.
The limitation a) is obtaining a request from a client to access data is meaningful limitations because it is a pre-solution activity
6) MPEP § 2106.05(h) Field of Use and Technological Environment.
[T]he Supreme Court has stated that, even if a claim does not wholly pre-empt an abstract idea, it still will not be limited meaningfully if it contains only insignificant or token pre- or post-solution activity-such as identifying a relevant audience, a category of use, field of use, or technological environment. Ultramercial, Inc. v. Hulu, LLC, 722 F.3d 1335, 1346 (Fed. Cir. 2013. Limitations “a client request”, “a client path”, “multiple tiers of storage”, “distributed check”, “background check”, “a frontend” are simply a field of use that attempts to limit the abstract idea to a particular technological environment.
Accordingly, the additional limitations a) and “a client request”, “a client path”, “multiple tiers of storage”, “distributed check”, “background check”, “a frontend” do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claim does not recite any non-convention or non-generic arrangement because limitation a. is obtaining a request from a client to access data is simply a query or a search to access data. Verification and distributed check are recited at high level of generality and can be interpreted as verifying and checking filename, permission, existence. A process can be foreground or background process. Taking these limitations as an ordered combination adds nothing that is not already present when the elements are taken individually. Therefore, the claim does not amount to significantly more than the recited abstract idea. The claim is not patent eligible.
Claim 2 depends on claim 1 and includes all the limitations of claim 1. Claim 2 recites “deferring the distributed check based upon an amount of client latency that would be increased by performing the distributed check as part of the client path used to process the client request.” The claim does not have any addition limitation that amount to significantly more than the abstract idea.
Claim 3 depends on claim 1 and includes all the limitations of claim 1. Claim 2 recites “performing the distributed check to verify consistency of a block of data.” Verifying consistency of a block of data is recited at a high level of generality. The claim does not have any addition limitation that amount to significantly more than the abstract idea.
Claim 4 depends on claim 1 and includes all the limitations of claim 1. Claim 4 recites “performing the distributed check to verify interdependent metafiles.” Verifying interdependent metafiles is recited at a high level of generality. The claim does not have any addition limitation that amount to significantly more than the abstract idea.
Claim 5 depends on claim 1 and includes all the limitations of claim 1. Claim 5 recites “performing the distributed check to verify multiple interdependent metafiles used to manage storage of the data across the multiple tiers of the storage.” Verifying multiple interdependent metafiles used to manage storage of the data across the multiple tiers of the storage is recited at a high level of generality. The claim does not have any addition limitation that amount to significantly more than the abstract idea.
Claim 6 depends on claim 1 and includes all the limitations of claim 1. Claim 5 recites “implementing an incremental checksum to protect against software issues” Implementing an incremental checksum to protect against software issues is recited at a high level of generality The claim does not have any addition limitation that amount to significantly more than the abstract idea.
Claim 7 depends on claim 1 and includes all the limitations of claim 1. Claim 5 recites “implementing an incremental consistency check to protect against software logic issues.” Implementing an incremental consistency check to protect against software logic issues is recited at a high level of generality. The claim does not have any addition limitation that amount to significantly more than the abstract idea.
Claim 8 is similar to claim 1. The claim is rejected based on the same reason.
Claim 9 depends on claim 8 and includes all the limitations of claim 8 Claim 9 recites “perform a local check before providing access to the data” The claim does not have any addition limitation that amount to significantly more than the abstract idea.
Claim 10 depends on claim 8 and includes all the limitations of claim 8. Claim 10 recites “perform an inline distributed check based upon the inline distributed check not adding latency of the client path.” The claim does not have any addition limitation that amount to significantly more than the abstract idea.
Claim 11 depends on claim 8 and includes all the limitations of claim 8. Claim 11 recites “perform an inline distributed check based upon the inline distributed check not loaded addition blocks for performing a check.” The claim does not have any addition limitation that amount to significantly more than the abstract idea.
Claim 12 depends on claim 8 and includes all the limitations of claim 8. Claim 12 recites “perform inode and volume block accounting” The claim does not have any addition limitation that amount to significantly more than the abstract idea.
Claim 13 depends on claim 8 and includes all the limitations of claim 8. Claim 13 recites “define a quality of service policy for a background process that performs the distributed check, wherein the quality of service policy is separate and different from a quality of service policy for the client path.” The claim does not have any addition limitation that amount to significantly more than the abstract idea.
Claims 14-16 are similar to claims 5-7. The claims are rejected based on the same reason.
Claims 17-20 are similar to claims 1 and 5-7. The claims are rejected based on the same reason.
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.
Claim(s) 1-5, 8-10, 11-14, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Sundaram (U.S. Patent 9043530 B1), in view of Sukumar (U.S. Patent 8843533 B1)
Claim 1
Sundaram discloses a method comprising:
receiving a client request through a client path providing access to data stored across multiple tiers of storage (col 8, line 43-50, “… the clients 108, 110 can utilize the data storage systems 102, 104 to store and retrieve data from the volumes 132. In this embodiment, for example, the client 108 can send data packets to the N-module 120 in the node 116 within data storage system 102. The node 116 can forward the data to the data storage device 128 using the D-module 124, where the data storage device 128 comprises volume 132A. In this way, in this example, the client can access the storage volume 132A, to store and/or retrieve data, using the data storage system 102 connected by the network connection 112...” col 6, line 4-5, “… The hybrid storage aggregate may comprise multiple tiers of storage devices…”);
However, Sundaram does not explicitly disclose
selectively performing a verification as part of processing the client request through the client path; and
selectively deferring a distributed check associated with the data being accessed by the client request, wherein the distributed check is deferred as a background check decoupled from a frontend that interfaces with the client.
Sukumar discloses
selectively performing a verification as part of processing the client request through the client path (col 5, line 35-36, “… clients… send requests to file system to read and/or write data…” col 4, line 53-55, “… the software “path” through the storage operating system layers… needed to perform data storage access for the client request received at the storage server…” col 8, line 15-24, “…client requests, for example, a user data block 462 shown in FIG. 4B at block 601, the method 500 checks blocks associated with a path that leads to the requested bottom block at block 603. Referring to FIG. 4B, the blocks associated with a path are the hatched blocks above the requested block 462, i.e., level-4 block 410, level-3 block 422, level-2 block 427 and level-1 block 433. Along the identified path, the method 500 checks the root inode in the top block 410 and checks the level-3 block 422, level-2 block 427 and level-1 block 433…”); and
selectively deferring a distributed check associated with the data being accessed by the client request (col 8, line 27—29, “… Other blocks, for example, the block 426 which are not directly associated with the path leading to the requested block 462 is not checked at this point…” col 8, line 5-6, “… the method 500 checks the rest of metadata at block 509…”), wherein the distributed check is deferred as a background check decoupled from a frontend that interfaces with the client (col 5, line 19-22, “… File system consistency check may operate in a non-interactive or interactive or hybrid mode. In a non-interactive mode, the storage server repairs all the errors it finds in the file system without pausing for user response…”)
Sundaram discloses the storage system returns the data requested by the client. Also, Sundaram discloses additional storage and/or file system, functionality may be implemented across the storage tiers. Sukumar discloses file system consistency checker to verify data requested by the client. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the file system consistency checker as disclosed by Sukumar into Sundaram because the consistency checker automatically performs file system consistency check at boot time when the storage server detects that the file system is in an inconsistent state, indicating a non-graceful shutdown, such as a crash or power loss. File system consistency check can also be initiated manually by the system administrator if there is believed to be a problem with the file system. the file system consistency checker repairs all the errors it finds in the system.
Claim 2
Claim 1 is included, Sukumar discloses deferring the distributed check based upon an amount of client latency that would be increased by performing the distributed check as part of the client path used to process the client request (col 5, line 23-29, “… In an interactive mode, on the other hand, the storage server examines the file system and stops at each error it finds in the file system and gives the problem description and asks for the administrator's response usually whether to correct the problem or continue without making any change to the file system. In a hybrid mode, the storage server may ask for the administrator's response in a special occasion…”)
Claim 3
Claim 1 is included, Sukumar discloses performing the distributed check to verify consistency of a block of data (col 8, line 27—29, “… Other blocks, for example, the block 426 which are not directly associated with the path leading to the requested block 462 is not checked at this point…” col 8, line 5-6, “… the method 500 checks the rest of metadata at block 509…”)
Claim 4
Claim 1 is included, Sukumar discloses performing the distributed check to verify interdependent metafiles (col 8, line 15-24, “…client requests, for example, a user data block 462 shown in FIG. 4B at block 601, the method 500 checks blocks associated with a path that leads to the requested bottom block at block 603. Referring to FIG. 4B, the blocks associated with a path are the hatched blocks above the requested block 462, i.e., level-4 block 410, level-3 block 422, level-2 block 427 and level-1 block 433. Along the identified path, the method 500 checks the root inode in the top block 410 and checks the level-3 block 422, level-2 block 427 and level-1 block 433…” col 6, line 59-60, “… an indirect user data block can be considered as “metadata” because metadata 390 can encompass indirect user data blocks…”)
Claim 5
Claim 1 is included, Sukumar discloses performing the distributed check to verify multiple interdependent metafiles used to manage storage of the data across the multiple tiers of the storage (col 8, line 15-24, “…client requests, for example, a user data block 462 shown in FIG. 4B at block 601, the method 500 checks blocks associated with a path that leads to the requested bottom block at block 603. Referring to FIG. 4B, the blocks associated with a path are the hatched blocks above the requested block 462, i.e., level-4 block 410, level-3 block 422, level-2 block 427 and level-1 block 433. Along the identified path, the method 500 checks the root inode in the top block 410 and checks the level-3 block 422, level-2 block 427 and level-1 block 433…” col 6, line 59-60, “… an indirect user data block can be considered as “metadata” because metadata 390 can encompass indirect user data blocks…”)
Claim 8 is similar to claim 1. The claim is rejected based on the same reason
Claim 9
Claim 8 is included, Sundaram discloses perform a local check before providing access to the data (col 12, line 41-45, “… a node… may receive the I/O operation from a client. At 306, the I/O operation may be evaluated to determine that the I/O operation comprises a non-sequential read operation…”)
Claim 10
Claim 8 is included, Sukumar discloses perform an inline distributed check based upon the inline distributed check not adding latency of the client path (col 8, line 15-24, “…client requests, for example, a user data block 462 shown in FIG. 4B at block 601, the method 500 checks blocks associated with a path that leads to the requested bottom block at block 603. Referring to FIG. 4B, the blocks associated with a path are the hatched blocks above the requested block 462, i.e., level-4 block 410, level-3 block 422, level-2 block 427 and level-1 block 433. Along the identified path, the method 500 checks the root inode in the top block 410 and checks the level-3 block 422, level-2 block 427 and level-1 block 433…” col 8, line 27—29, “… Other blocks, for example, the block 426 which are not directly associated with the path leading to the requested block 462 is not checked at this point…” col 8, line 5-6, “… the method 500 checks the rest of metadata at block 509…”)
Claim 11
Claim 8 is included, Sukumar discloses wherein the machine executable code causes the computing device to: perform an inline distributed check based upon the inline distributed check not loaded addition blocks for performing a check (col 8, line 15-24, “…client requests, for example, a user data block 462 shown in FIG. 4B at block 601, the method 500 checks blocks associated with a path that leads to the requested bottom block at block 603. Referring to FIG. 4B, the blocks associated with a path are the hatched blocks above the requested block 462, i.e., level-4 block 410, level-3 block 422, level-2 block 427 and level-1 block 433. Along the identified path, the method 500 checks the root inode in the top block 410 and checks the level-3 block 422, level-2 block 427 and level-1 block 433…”)
Claim 12
Claim 12 is included; Sukumar discloses perform inode and volume block accounting (col 8, line 15-24, “…client requests, for example, a user data block 462 shown in FIG. 4B at block 601, the method 500 checks blocks associated with a path that leads to the requested bottom block at block 603. Referring to FIG. 4B, the blocks associated with a path are the hatched blocks above the requested block 462, i.e., level-4 block 410, level-3 block 422, level-2 block 427 and level-1 block 433. Along the identified path, the method 500 checks the root inode in the top block 410 and checks the level-3 block 422, level-2 block 427 and level-1 block 433…” col 6, line 59-60, “… an indirect user data block can be considered as “metadata” because metadata 390 can encompass indirect user data blocks…”)
Claim 13
Claim 8 is included, Sukumar discloses define a quality of service policy for a background process that performs the distributed check, wherein the quality of service policy is separate and different from a quality of service policy for the client path (col 5, line 20-30, “… File system consistency check may operate in a non-interactive or interactive or hybrid mode. In a non-interactive mode, the storage server repairs all the errors it finds in the file system without pausing for user response. In an interactive mode, on the other hand, the storage server examines the file system and stops at each error it finds in the file system and gives the problem description and asks for the administrator's response usually whether to correct the problem or continue without making any change to the file system. In a hybrid mode, the storage server may ask for the administrator's response in a special occasion…” <examiner note: the non-interactive/background process repairs the errors without user’s participation.)
Claim 14
Claim 8 is included, Sukumar further disclose perform the distributed check to verify multiple interdependent metafiles used to manage storage of the data across the multiple tiers of the storage (col 8, line 15-24, “…client requests, for example, a user data block 462 shown in FIG. 4B at block 601, the method 500 checks blocks associated with a path that leads to the requested bottom block at block 603. Referring to FIG. 4B, the blocks associated with a path are the hatched blocks above the requested block 462, i.e., level-4 block 410, level-3 block 422, level-2 block 427 and level-1 block 433. Along the identified path, the method 500 checks the root inode in the top block 410 and checks the level-3 block 422, level-2 block 427 and level-1 block 433…” col 6, line 59-60, “… an indirect user data block can be considered as “metadata” because metadata 390 can encompass indirect user data blocks…”)
Claim 17 and 18 are similar to claim 1 and 5. The claim are rejected based on the same reason.
Claim(s) 6-7, 15-16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sundaram (U.S. Patent 9043530 B1), in view of Sukumar (U.S. Patent 8843533 B1), as applied to claim 1, 8, and 14 respectively, and further in view of High Performance Metadata Integrity Protection in the WAFL Copy-on-Write File System, written by Harendra Kumar (hereafter Kumar), February 27–March 2, 2017
Claim 6
Claim 1 is included, however, Sundaram and Sukumar do not explicitly disclose implementing an incremental checksum to protect against software issues.
Kumar discloses implementing an incremental checksum to protect against software issues (page. 200, section 4 Scribble Protection, “… In this section, we describe a high-performance and multiprocessor-capable incremental checksum scheme to protect in-memory metadata against scribbles…” pg. 201, section 4.1 End-to-End Checksum, “… We use a single rolling or incremental checksum [4, 41] to protect each metadata block through its entire life cycle, whether it is in memory or on persistent storage…”)
Claim 7
Claim 1 is included, Kumar discloses implementing an incremental consistency check to protect against software logic issues (pg. 197, right column, “… Next, we introduce a digest-based transaction auditing system to prevent logic bugs…” pg. 203, section 5, “… During a transaction, changes are accumulated to create digests that are used later to verify consistency invariants…”)
Sukumar discloses file system consistency checker to verify the user’s requested data; however, Sukumar does not disclose implement an incremental checksum to protect against software issues and an incremental consistency check to protect against software logic issues. Kumar discloses incremental checksum technique and a lightweight digest-based transaction auditing mechanism. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate incremental checksum technique and a lightweight digest-based transaction auditing mechanism as disclosed by Kumar into Sundaram and Sukumar because the incremental checksum technique and the lightweight digest-based transaction auditing mechanism protects metadata blocks against in-memory scribbles and enforces file system consistency invariants.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 2-5, 14, and 18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
In claim 1, the distributed check is deferred. Claim 2 asks performing the distributed check. Since the distributed check is deferred in claim 1, it contradicts to claim 1 to perform the deferred distributed check without any condition to trigger to perform the deferred distributed check.
The same reason is applied to claim 3-5, 14, and 18.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAU HAI HOANG whose telephone number is (571)270-5894. The examiner can normally be reached 1st biwk: Mon-Thurs 7:00 AM-5:00 PM; 2nd biwk: Mon-Thurs: 7:00 am-5:00pm, Fri: 7:00 am - 4:00pm.
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, Boris Gorney can be reached at 571-270-5626. 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.
HAU HAI. HOANG
Primary Examiner
Art Unit 2154
/HAU H HOANG/Primary Examiner, Art Unit 2154