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 Amendment
This office action has been issued in response to amendment filed on 11/19/2025. Claims 1, 11 and 16 have been amended. Claims 1-20 are pending, of which claims, of which claim 1, claim 11 and claim 16 are in independent form. Notes: Claim 16: Marking for Prior Claim amendment was included.
Response to Argument
Applicant’s arguments with respect to claims 1-20 has been considered but are moot in view of the new ground(s) rejection.
Status of Claims
Claims 1-20 are pending, of which claims, of which claim 1, 11 and 16 are in independent form.
The Office's Note:
The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner.
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 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.
Claims 1-20 are rejected under 35 U.S.C 103 as being unpatentable over Hemadri et al. (US 20240354102), in view of Han et al.( US 20220091969) and further in view of Cherivirala et al.( US 20240168786).
Claim 1 is rejected, Hemadri teaches a method, comprising:
obtaining a first volume snapshot of a first workspace associated with a software development project, wherein the first volume snapshot comprises a plurality of source code files associated with the software development project (Hemadri, US 20240354102, fig. 1 and paragraph [0050-0053], At operation (4) of the incremental build process 120, the incremental build unit 118 retrieves a snapshot of the past build unit for the qualified past version from the storage component 126. In some cases, to retrieve the snapshot of the past build unit, the incremental build unit 118 requests that a snapshot controller 128 of the build system 114 retrieves the snapshot from the storage component 14. The snapshot controller 128 may be a snapshot controller in a primary node of a container orchestration system such as a Kubernetes cluster. In some cases, to retrieve the snapshot of the past build unit, the snapshot controller 128 retrieves the stored file associated with the identifier of the snapshot from the storage component 126. Paragraph [0054-0060], CSI snapshots may enable capture of point-in-time snapshots of the data stored in a PVC. These snapshots can be used for backups, disaster recovery, and testing, among other use cases. In some cases, by using PVCs and CSI snapshots in a Kubernetes cluster, an application can easily store and manage data that needs to persist across pod restarts, and create point-in-time copies of that data for backup and other use cases. Paragraph [0015-0018], building a new version of a software application based on a snapshot of a past build for a qualified past version of the same software application. Paragraph [0019-0027], The techniques described herein provide various technical advantages. For example, by generating a new build unit based on a snapshot of a past build, the system can avoid recompiling code that has not changed. Para [0038], source code. Para [0045], codebase. Para [0081], At operation 806, the process 800 includes receiving a version history graph associated with the first software application. In some cases, the version history graph represents the history of changes to a software codebase over time. In some cases, the version history graph shows the relationships between different versions of the codebase and the branching and merging of the codebase over time. Each point on the graph may represent a specific version of the codebase, with lines connecting them indicating the changes between each version. The version history graph may be a useful tool for understanding the evolution of a codebase and can help developers track down bugs, conflicts, and other issues that may arise during the software development process.);
creating a second workspace from the first volume snapshot (Hemadri, fig. 1 and paragraph [0032-0034], As depicted in FIG. 1, the developer system 102 generates and provides a build request 104 to the continuous integration system 106. The developer system 102 may generate the build request 104 based on a user selection or an event emitted by an automated routine. For example, the developer system 102 may generate the build request 104 based on a user selection to build a target version of a software application or an event emitted by the automated routine that indicates satisfaction of a condition for building the target version. As another example, the developer system 102 may generate the build request 104 based on a user selection to trigger a continuous integration pipeline or an event emitted by the automated routine that indicates satisfaction of a condition for triggering the continuous integration pipeline. The developer system 102 may detect a user selection based on a user action performed using a graphical user interface or a command provided using a command line interface Paragraph [0015-0018], building a new version of a software application based on a snapshot of a past build for a qualified past version of the same software application. Paragraph [0019-0027], The techniques described herein provide various technical advantages. For example, by generating a new build unit based on a snapshot of a past build, the system can avoid recompiling code that has not changed. Paragraph [0050-0054], CSI snapshots may enable capture of point-in-time snapshots of the data stored in a PVC. These snapshots can be used for backups, disaster recovery, and testing, among other use cases. In some cases, by using PVCs and CSI snapshots in a Kubernetes cluster, an application can easily store and manage data that needs to persist across pod restarts, and create point-in-time copies of that data for backup and other use cases.);
applying one or more updates to at least sone of the source code files of the second workspace by fetching, from a software development system, one or more code updates to one or more of the plurality of source code files(Hemadri, fig. 1 and paragraph [0033-0034], In some cases, the developer system 102 may generate the build request 104 when the developer system 102 receives a request to build a target version of a software application. For example, the developer system 102 may receive the request to build a version of the software application associated with the latest commit to the code repository system 110. In some cases, the request to build the target version is part of a request to deploy or release the software application. In some cases, the request to build the target version is part of a request to retrieve or pull the target version from the code repository system 110. Paragraph [0015-0018], building a new version of a software application based on a snapshot of a past build for a qualified past version of the same software application. Paragraph [0019-0027], The techniques described herein provide various technical advantages. For example, by generating a new build unit based on a snapshot of a past build, the system can avoid recompiling code that has not changed. Para [0038], source code. Para [0045], codebase. Para [0081], At operation 806, the process 800 includes receiving a version history graph associated with the first software application. In some cases, the version history graph represents the history of changes to a software codebase over time. In some cases, the version history graph shows the relationships between different versions of the codebase and the branching and merging of the codebase over time. Each point on the graph may represent a specific version of the codebase, with lines connecting them indicating the changes between each version. The version history graph may be a useful tool for understanding the evolution of a codebase and can help developers track down bugs, conflicts, and other issues that may arise during the software development process.) ; and
performing a software build on the second workspace to compile the source code associated with the at least some of the plurality of source code files associated with the software development project(Hemadri, fig. 1 and paragraph [0051-0054], At operation (5) of the incremental build process 120, the incremental build unit 118 restores the retrieved snapshot of the past build unit. The restored snapshot may then perform operations configured to build the target version not from a scratch, but based on any differences between the target version and the qualified past version associated with the retrieved snapshot. For example, the snapshot may be configured to execute incremental compilation logic (e.g., using a compiler container), where the incremental compilation logic (e.g., given the existing build files associated with the past build) is configured to build the target version not from a scratch, but based on any differences between the target version and the qualified past version associated with the retrieved snapshot. Paragraph [0015-0018], building a new version of a software application based on a snapshot of a past build for a qualified past version of the same software application. Paragraph [0019-0027], The techniques described herein provide various technical advantages. For example, by generating a new build unit based on a snapshot of a past build, the system can avoid recompiling code that has not changed. Paragraph [0045-0050 and 0085], At operation 810, the process 800 includes restoring a snapshot associated with a past build unit that was configured to build the past qualified version. The snapshot may represent the state of the past build unit at a particular point in time, such as at the end of the build operation. The snapshot may include the configuration, code, and dependencies needed to recreate the captured state and its respective build environment. Para [0038], source code. Para [0045], codebase. Para [0081], At operation 806, the process 800 includes receiving a version history graph associated with the first software application. In some cases, the version history graph represents the history of changes to a software codebase over time. In some cases, the version history graph shows the relationships between different versions of the codebase and the branching and merging of the codebase over time. Each point on the graph may represent a specific version of the codebase, with lines connecting them indicating the changes between each version. The version history graph may be a useful tool for understanding the evolution of a codebase and can help developers track down bugs, conflicts, and other issues that may arise during the software development process.);
wherein the method is performed by at least one processing device comprising a processor coupled to a memory (fig. 9, computer 900 and paragraph [0087]).
Hemadri does not explicitly teach
wherein the second workspace comprises at least a portion of one or more of the plurality of source code files
However, Han teaches
wherein the second workspace comprises at least a portion of one or more of the plurality of source code files(Han, US 20220091969, para [0017-0018], a server selects a change list which indicates that the software developer Bob used his virtual machine to create a revision of the source code for generating sales opportunity data in his copy of a CRM application, and that at 5:00 P.M. on Tuesday Bob committed this revision to a source code repository. The server initiates a snapshot service to create a snapshot of Bob's copy of the CRM application, which includes his revision of the source code for generating sales opportunity data, by creating a snapshot of his virtual machine disk in his virtual machine. The server associates the snapshot of Bob's copy of the CRM application with the change list that references his revision of the source code for generating sales opportunity data. The server sends the snapshot of Bob's copy of the CRM application, which includes his revision of the source code for generating sales opportunity data, to a snapshot database in cloud storage. The server receives a request at 9:00 A.M. on Thursday from Bob's coworker Chris to create a virtual machine for Chris based on the change list created at 5:00 P.M. on Tuesday, which reference Bob's copy of the CRM application that includes his revision of the source code that generates sales opportunity data. The server uses the snapshot service to identify the snapshot which was created for the change list committed at 5:00 P.M. on Tuesday, and retrieves the snapshot of Bob's copy of the CRM application, which includes his revision of the source code that generates sales opportunity data, from the snapshot database in the cloud storage. The server uses the snapshot of Bob's copy of the CRM application, which includes his revision of the source code that generates sales opportunity data, to create Chris' virtual machine. Chris' virtual machine executes Chris' copy of the CRM application, which includes Chris' copy of Bob's revision of the source code that generates sales opportunity data. Even though Chris requested for a version of an application which has not been used for more than a day to be used to create a virtual machine for further development and possible testing of the application, the server efficiently and quickly created the virtual machine exactly as Chris requested, which may not have been possible if daily base images were still being used to create virtual machines. Para [0026-0028], snapshots may be made of virtual machine objects. Any of the test automation frameworks 118-126 can initiate the volume snapshot service 130 (or a volume snapshot service 196 which is described below as cloud-based), which may be a Microsoft® Volume Shadow Copy Service, to create a snapshot of any of the virtual machines 142-150. A snapshot of any of the virtual machines 142-150 may be created by creating a snapshot of the corresponding virtual machine disks 152-160, which store the corresponding copies of applications 162-170, which include the corresponding revisions to source codes revisions and copies of revisions to source code, 172-190, respectively. Para [0036-0037], snapshot service and source code. Fig. 2 and para [0054-0066], a method for change list-based snapshots of applications for development and testing.)
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Han into Hemadri to select a change list from change lists corresponding to change in an application executed by a virtual machine. A snapshot of the application is created corresponding to the selected change list. The snapshot of the application is associated with the change list. The snapshot of the application is stored with snapshots of versions of the application associated with change lists. A request is received to create another virtual machine based on a version of the application corresponding to a specified time and a specified change list. The other virtual machine is created based on the application snapshot. The version of the application is execute corresponding to the specified time and the specified change list by the other virtual machine.as suggested by Han (See abstract and summary).
Hemadri and Han do not explicitly teach
performing a software build on the second workspace to compile the source code associated with the at least some of the plurality of updated source code files associated with the software development project into one or more executable files
However, Cherivirala teaches
performing a software build on the second workspace to compile the source code associated with the at least some updated source code files associated with the software development project into one or more executable files (Cherivirala, US 20240168786, para [0001], Executable software applications are created by converting source code into executable files using a process called a build. As updates to the source code are made, subsequent builds are performed through a variety of software build actions. Para [0015-0017], Software engineers interact with a large number of code files containing source code. As changes are made to the code and new builds are executed, some source code also remains the same. Complex build pipelines representing a large number of code files containing source code are converted (e.g., compiled) into executable software applications. Fig. 4 and para [0037], snapshot storage volume 404 is created by providing input file(s) 402. These input files 402 may be associated with a software build workflow, such as where the software build workflow builds the source code in the input file 402 to generate a compiled and executable application (e.g., executable object code or a deployable bundle including JavaScript code, or code written in TypeScript or CoffeeScript and compiled to JavaScript, or code written in other interpreted languages such as Ruby, Python or the like) or a built software library. In implementations, virtual machine 406 mounts snapshot storage volume 404, at mounted snapshot storage volume 404A, which includes input file(s) 402A and a build environment containing the build dependencies for building the input file(s) 402A. Fig. 4 and para [0038-0039], In examples, at the start of a software build action, the mounted snapshot storage volume 404A connected to virtual machine 406 may be the same as the snapshot storage volume 404. In implementations, virtual machine 406 runs the software build action and, once the software build action is complete, software build action result 408 of the software build action is written. In such implementations, because snapshot storage volume 404 may be immutable (e.g., read-only), software build action result 408 may be written to overlay snapshot storage volume 404C (e.g., using a redirect-on-write mechanism, where the writes to the snapshot storage volume 404 are redirected to the overlay snapshot storage volume 404C). In examples, if there are changes made to input file(s) 402 stored in snapshot storage volume 404, those changes (e.g., differences between the input file 402 as modified during the running of the software build action and the input file 402A as stored in the snapshot image 404) are also stored in the overlay snapshot storage volume 404C. );
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Cherivirala into Hemadri and Han to ensure that the output of certain software build actions is merged to make the execution of software builds more efficient. The snapshot storage volume includes build dependencies that are utilized in the software builds, thus saving computational effort of retrieving the build dependencies as portion of the build process.as suggested by Cherivirala (See abstract and summary).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Hemadri, Han and Cherivirala teach the method of claim 1, comprising, in response to a validation that (i) the software build succeeded and (ii) a request to merge at least two branches of the software development project succeeded, creating a second volume snapshot using the second workspace and the one or more updates to the second workspace(fig. 1 and paragraph [0050-0052], At operation (6) of the incremental build process 120, the incremental build unit 118 stores the restored snapshot on the storage component 126 based on (e.g., in response to) determining the end of the build process associated with the target version. In some cases, the incremental build unit 118 stores an identifier of the snapshot that is determined based on an identifier of the software application (e.g., a shasum of the code repository corresponding to the software application), an identifier (e.g., a job name) of the continuous integration pipeline associated with the target version, an identifier of the target version (e.g., a shasum of the commit associated with the target version), and/or a build number or pull request number associated with the snapshot. Paragraph [0045-0049 and 0085], At operation 810, the process 800 includes restoring a snapshot associated with a past build unit that was configured to build the past qualified version. The snapshot may represent the state of the past build unit at a particular point in time, such as at the end of the build operation. The snapshot may include the configuration, code, and dependencies needed to recreate the captured state and its respective build environment. Han, fig. 2 and para [0059-0060], After executing a test of an application which includes at least one change corresponding to a change list, a determination is optionally made whether executing the test of the application which includes the at least one change corresponding to the change list results in any test failures, block 210. Hemadri, para [0066-0068], branch merge and commits branch. Para [0076] and [0081], branch merge.).
Claim 3 is rejected for the reasons set forth hereinabove for claim 2, Hemadri, Han and Cherivirala teach the method of claim 2, further comprising storing the second volume snapshot in at least one volume snapshot repository (Hemadri, fig. 2 and paragraph [0057-0060], Additionally, the build system 114 may include storage 216 which may comprise one, or multiple, repositories or other storage locations for persistently storing and managing collections of data such as databases, simple files, binary, and/or any other data. The storage 216 may include one or more storage locations that may be managed by one or more storage/database management systems. For example, the storage 216 may store snapshot data 218 including snapshots associated with build units associated with past buildings of software application versions. As another example, the storage 216 may store snapshot identifier data 220 including a snapshot identifier for each stored snapshot. Paragraph [0045-0054 and 0085], At operation 810, the process 800 includes restoring a snapshot associated with a past build unit that was configured to build the past qualified version. The snapshot may represent the state of the past build unit at a particular point in time, such as at the end of the build operation. The snapshot may include the configuration, code, and dependencies needed to recreate the captured state and its respective build environment.).
Claim 4 is rejected for the reasons set forth hereinabove for claim 2, Hemadri, Han and Cherivirala teach the method of claim 2, wherein the second volume snapshot represents a state of the second workspace for the validated one or more source code files associated with the software development project(Hemadri, paragraph [0085-0086], Additionally, the build system 114 may include storage 216 which may comprise one, or multiple, repositories or other storage locations for persistently storing and managing collections of data such as databases, simple files, binary, and/or any other data. The storage 216 may include one or more storage locations that may be managed by one or more storage/database management systems. For example, the storage 216 may store snapshot data 218 including snapshots associated with build units associated with past buildings of software application versions. As another example, the storage 216 may store snapshot identifier data 220 including a snapshot identifier for each stored snapshot. Paragraph [0045-0054]. Han, Para [0036-0037], snapshot service and source code. Fig. 2 and para [0054-0066], a method for change list-based snapshots of applications for development and testing).
Claim 5 is rejected for the reasons set forth hereinabove for claim 1, Hemadri, Han and Cherivirala teach the method of claim 1, wherein the creating the second workspace from the first volume snapshot employs a read-only layer of the first volume snapshot(Cherivirala, US 20240168786, paragraph [0037-0038], Referring now to FIG. 4, a block diagram illustrating example physical components of a snapshot storage volume of the remote build system 400 is illustrated. In various implementations, the snapshot storage volume may be implemented as a read-only copy of a data set at a specific time, and may be implemented by a logical volume manager, or a virtual machine such as Firecracker VM, VMWare, VirtualBox, or the like. Pargraph [0039-0040].).
Claim 6 is rejected for the reasons set forth hereinabove for claim 1, Hemadri, Han and Cherivirala teach the method of claim 1, wherein the one or more updates to the second workspace employ a read-write layer of the first volume snapshot(Cherivirala, paragraph [0037-0038], In examples, at the start of a software build action, the mounted snapshot storage volume 404A connected to virtual machine 406 may be the same as the snapshot storage volume 404. In implementations, virtual machine 406 runs the software build action and, once the software build action is complete, software build action result 408 of the software build action is written. In such implementations, because snapshot storage volume 404 may be immutable (e.g., read-only), software build action result 408 may be written to overlay snapshot storage volume 404C (e.g., using a redirect-on-write mechanism, where the writes to the snapshot storage volume 404 are redirected to the overlay snapshot storage volume 404C). In examples, if there are changes made to input file(s) 402 stored in snapshot storage volume 404, those changes (e.g., differences between the input file 402 as modified during the running of the software build action and the input file 402A as stored in the snapshot image 404) are also stored in the overlay snapshot storage volume 404C. Paragraph [0039-0040].).
Claim 7 is rejected for the reasons set forth hereinabove for claim 1, Hemadri, Han and Cherivirala teach the method of claim 1, wherein the first volume snapshot is generated using at least one processing device of an orchestration engine(Hemadri, paragraph [0020-0021], In some cases, the first build unit is an execution unit of a container orchestration system, and the execution unit is associated with a build container. The system can store a second snapshot of the first build unit, and can determine a first identifier of the snapshot based on a second identifier of the first software application and a third identifier of the first version. The first identifier can be stored for future reference . Paragraph [0022-0025], the techniques described herein enable a cloud-native incremental build process because they takes advantage of the cloud infrastructure and the capabilities of containerization and container orchestration systems like Kubernetes. Paragraph [0045-0054 and 0085], At operation 810, the process 800 includes restoring a snapshot associated with a past build unit that was configured to build the past qualified version. The snapshot may represent the state of the past build unit at a particular point in time, such as at the end of the build operation. The snapshot may include the configuration, code, and dependencies needed to recreate the captured state and its respective build environment.).
Claim 8 is rejected for the reasons set forth hereinabove for claim 1, Hemadri, Han and Cherivirala teach the method of claim 1, further comprising obtaining at least one software repository from the software development system and storing the at least one software repository as a persistent volume(Hemadri, paragraph [0033-0035], the developer system 102 may generate the build request 104 when the developer system 102 receives a request to build a target version of a software application. For example, the developer system 102 may receive the request to build a version of the software application associated with the latest commit to the code repository system 110. In some cases, the request to build the target version is part of a request to deploy or release the software application. In some cases, the request to build the target version is part of a request to retrieve or pull the target version from the code repository system 110. Paragraph [0045-0054 and 0085], At operation 810, the process 800 includes restoring a snapshot associated with a past build unit that was configured to build the past qualified version. The snapshot may represent the state of the past build unit at a particular point in time, such as at the end of the build operation. The snapshot may include the configuration, code, and dependencies needed to recreate the captured state and its respective build environment.).
Claim 9 is rejected for the reasons set forth hereinabove for claim 8, Hemadri, Han and Cherivirala teach the method of claim 8, wherein the creating the second workspace further comprises creating the second workspace from the persistent volume(Hemadri, paragraph [0034-0035], The continuous integration system 106 may receive the build request 104 from the developer system 102, receive software application data 108 from the code repository system 110, generate a build specification 112 based on the software application data 108, and provide the build specification 112 to the build system 114. The continuous integration system 106 may be one of Jenkins, GitLab, or CircleeCI. Paragraph [0045-0054 and 0085], At operation 810, the process 800 includes restoring a snapshot associated with a past build unit that was configured to build the past qualified version. The snapshot may represent the state of the past build unit at a particular point in time, such as at the end of the build operation. The snapshot may include the configuration, code, and dependencies needed to recreate the captured state and its respective build environment.).
Claim 10 is rejected for the reasons set forth hereinabove for claim 8, Hemadri, Han and Cherivirala teach the method of claim 8, further comprising updating the at least one software repository stored as the persistent volume using at least one synchronization service(Hemadri, paragraph [0033-0035], In some cases, the continuous integration system 106 is configured to receive software application data 108 from the code repository system 110. The software application data 108 may include at least one of an application identifier for the software application, a version identifier for the target version, or an execution unit template for an execution unit (e.g., a Kubernetes pod) of the build system 114 that is configured to build the target version of the software application. In some cases, the application identifier for the software application is a repository identifier (e.g., a repository shasum) for a repository of the code repository system 110 that is associated with the software application. In some cases, the version identifier includes at least one of a commit identifier associated with a code commit corresponding to the target version or a pull request identifier associated with a pull request corresponding to the target version. In some cases, an execution unit template is a pod template for a Kubernetes pod. In some cases, the code repository system 110 is a version control system such as GitHub. Paragraph [0045-0054 and 0085], At operation 810, the process 800 includes restoring a snapshot associated with a past build unit that was configured to build the past qualified version. The snapshot may represent the state of the past build unit at a particular point in time, such as at the end of the build operation. The snapshot may include the configuration, code, and dependencies needed to recreate the captured state and its respective build environment,).
As per claim 11, this is the system claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 12, this is the system claim to method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 13, this is the system claim to method claim 4. Therefore, it is rejected for the same reasons as above.
As per claim 14, this is the system claim to method claim 5 and claim 6. Therefore, it is rejected for the same reasons as above.
As per claim 15, this is the system claim to method claim 8 and claim 10. Therefore, it is rejected for the same reasons as above.
As per claim 16, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 17, this is the system claim to method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 18, this is the system claim to method claim 4. Therefore, it is rejected for the same reasons as above.
As per claim 19, this is the medium claim to method claim 5 and claim 6. Therefore, it is rejected for the same reasons as above.
As per claim 20, this is the system claim to method claim 8 and claim 10. Therefore, it is rejected for the same reasons as above.
Inquiry
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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, Lewis Bullock can be reached on 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199