DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In communications filed on 03/10/2025. Claims 1-20 are pending in this examination.
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. This examination is in response to US Patent Application No. 19/075,357.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “an internal storage configured to…” in claim 1.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 102
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.
Claims 1-15, 17-18, and 20 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by TAKANO ( US2015/0193618).
Regarding claim 1, TAKANO discloses an information processing apparatus comprising: an internal storage configured to store one or more programs; a controller configured to execute the one or more programs [¶39-40, In the client 10, an arithmetic device 10C is a microprocessor (CPU). The arithmetic device 10C starts an OS (Operating System) stored in a storage device 10B…and also starts various kinds of resident programs (for example, a control program 113 and the like) in accordance with the OS… The storage device 10B is a hard disk drive (HDD) or solid-state drive (SSD), and stores not only the OS but also data 101 and various kinds of programs 100 that operate on the client 10. The various kinds of programs 100 stored in the storage device 10B include an identification program 110, a registration program 111, a detection program 112, a control program 113, and a file search tool 114, and details will be described later]; and
and an interface configured to receive information from an external storage containing a whitelist, the whitelist including determination information indicating whether to allow the controller to execute each of the one or more programs [¶43, A network I/F 10D is an interface to the network 300 and serves as a communication circuit to communicate with another computer. The arithmetic device 10C receives information, for example, partial data of the white list 120 from the server 20 and also transmits various kinds of information to the server 20 through the network I/F 10D], and [¶¶118-125] In FIGS. 5A, 5B, and 6, if a program or package neither meets the chained elevation criterion rule 130 nor exists in the white list 120 (NO in step S206 or S225), the control program 113 prevents startup of the program (step S204 or S223), as described above. However, if such a program or package (to be referred to as "unregistered program" hereinafter) is found, it is possible to attempt to update the whitelist 120… Upon receiving the unregistered information from the client 10 (step S311), the management console 210 of the server 20 determines whether information that matches the received unregistered information exists in the whitelist candidate 250 (step S312). If information that matches the received unregistered information exists in the whitelist candidate 250, the process returns to step S311. If information that matches the received unregistered information does not exist in the whitelist candidate 250, the management console 210 adds the received unregistered information to the whitelist candidate 250 (step S313). The unregistered information added to the whitelist candidate 250 is presented to the operator of the server 20 by, for example, email or an alert window (step S314)… The management console 210 transmits the data of the whitelist master 220 to the client 10 periodically (for example, every other hour or every other day). The whitelist 120 of the client 10 is thus updated]; and
wherein the controller is configured to: acquire the whitelist from the external storage through the interface verify an integrity of the acquired whitelist [¶¶59-60, The chained elevation criterion rule 130 is a rule to determine whether a program or file was issued by a reliable issuer. The chained elevation criterion rule 130 includes rules defined by the administrator or user based on program information. The rules include, for example, a digital signature added to a program or file, verifying whether a digital certificate is authentic, determining whether the signatory name of a file is a name stored in advance, and determining whether a file name meets a designated condition], and [¶136, An example has been described above in which a program already registered in the white list master 220 (white list 120) meets the chained elevation criterion rule 230. However, in a system that adds setting information and the like to a program to dynamically create an installer (by, for example, combining another file to an execution file), it may be difficult to meet the above conditions (for example, determination by a digital signature). Such a dynamically created installer (or updater) needs to be automatically registered in the whitelist master 220]; and
and in response to a determination that the acquired whitelist is complete, store the acquired whitelist in the internal storage as an active whitelist to be used for determining whether to allow the controller to execute each of the one or more programs stored in the internal storage [see FIG. 1 client PC , whitelist (120), blacklist(140) Program ETC stored in storage device( 10B) ,[ ¶41, The various kinds of data 101 stored in the storage device 10B include the white list 120, a chained elevation criterion rule 130, and a black list 140, and details will be described later.], and [¶125, The management console 210 transmits the data of the white list master 220 to the client 10 periodically (for example, every other hour or every other day). The whitelist 120 of the client 10 is thus updated].
Regarding claim 2, TAKANO discloses wherein the controller is further configured to: receive a request to execute a first program of the one or more programs; and execute the first program in response to a determination that the active whitelist indicates that execution of the first program is permitted [¶¶52-53] The identification program 110 is executed by the arithmetic device 10C and acquires information (to be referred to as program information hereinafter) such as a file name (program name), hash value, version information, file size, file path, and digital signature from a separately started program. The identification program 110 has an identification function of identifying the program based on the acquired program information. The identification program 110 collates the acquired program information with the chained elevation criterion rule 130 to be described later and determines whether the program meets the chained elevation criterion. The whitelist 120 is a list of information about programs that can be executed. As the information that constitutes the whitelist 120, program information acquired by the identification program 110 is used].
Regarding claim 2, TAKANO discloses, wherein the controller is further configured to: receive a request to execute a first program of the one or more programs; and prevent execution of the first program in response to a determination that the active whitelist indicates that execution of the first program is not permitted [ see FIG. 1 , client PS for Blacklist (140), [¶66, Note that if the program to be started meets the chained elevation criterion rule 130 but is registered in the blacklist 140, the control program 113 does not cause the registration program 111 to execute registration of the program. That is, prohibition of startup/execution of the program is maintained], and [¶76, In addition, the identification program 110 determines whether the program to be started is registered in the blacklist 140. If the program is registered in the blacklist 140, startup of the program is prevented. If the program is not registered in the blacklist 140, startup of the program is permitted. Such a method is also employable].
Regarding claim 4, TAKANO discloses, wherein the controller is configured to: acquire first verification information from the external storage through the interface; generate second verification information based on a content of the acquired whitelist; and verify the integrity of the acquired whitelist based on whether the first verification information matches the second verification information [¶52, The identification program 110 is executed by the arithmetic device 10C and acquires information (to be referred to as program information hereinafter) such as a file name (program name), hash value, version information, file size, file path, and digital signature from a separately started program. The identification program 110 has an identification function of identifying the program based on the acquired program information. The identification program 110 collates the acquired program information with the chained elevation criterion rule 130 to be described later and determines whether the program meets the chained elevation criterion], and [¶59, The chained elevation criterion rule 130 is a rule to determine whether a program or file was issued by a reliable issuer. The chained elevation criterion rule 130 includes rules defined by the administrator or user based on program information. The rules include, for example, a digital signature added to a program or file, verifying whether a digital certificate is authentic, determining whether the signatory name of a file is a name stored in advance, and determining whether a file name meets a designated condition].
Regarding claim 5, TAKANO discloses, wherein the controller is configured to verify the integrity of the acquired whitelist when the acquired whitelist is acquired from the external storage [¶65, Upon determining via verification that the program meets the chained elevation criterion rule 130, the control program 113 permits startup of the program and calls the registration program 111. The registration program 111 receives the program information of the program from the identification program 110 and registers the program in the whitelist 120], and [¶125, The management console 210 transmits the data of the whitelist master 220 to the client 10 periodically (for example, every other hour or every other day). The whitelist 120 of the client 10 is thus updated].
Regarding claim 6, TAKANO discloses, wherein the controller is configured to generate the second verification information by calculating the second verification information using a hash function with the acquired whitelist as an input [¶52, The identification program 110 is executed by the arithmetic device 10C and acquires information (to be referred to as program information hereinafter) such as a file name (program name), hash value, version information, file size, file path, and digital signature from a separately started program. The identification program 110 has an identification function of identifying the program based on the acquired program information. The identification program 110 collates the acquired program information with the chained elevation criterion rule 130 to be described later and determines whether the program meets the chained elevation criterion], and [¶59, The chained elevation criterion rule 130 is a rule to determine whether a program or file was issued by a reliable issuer. The chained elevation criterion rule 130 includes rules defined by the administrator or user based on program information. The rules include, for example, a digital signature added to a program or file, verifying whether a digital certificate is authentic, determining whether the signatory name of a file is a name stored in advance, and determining whether a file name meets a designated condition].
Regarding claim 7, TAKANO discloses,, wherein the controller is configured to acquire the whitelist and verify the acquired whitelist during start-up of the information processing apparatus [¶¶64-65, The detection program 112 detects startup of a program in the client 10 using a global hook (API (Application Programming Interface) hook or filter driver) or the like, and upon detecting startup of a program, calls the identification program 110. The identification program 110 acquires the program information of the program to be started and verifies whether the program meets the chained elevation criterion rule 130.Upon determining via verification that the program meets the chained elevation criterion rule 130, the control program 113 permits startup of the program and calls the registration program 111. The registration program 111 receives the program information of the program from the identification program 110 and registers the program in the whitelist 120], and [¶150, FIG. 10 shows an example of a whitelist master 220 according to the second embodiment which exists in a server 20. The whitelist master 220 holds information associated with the whitelists 120 of a plurality of clients in association with the names or codes of the clients. In the example of FIG. 10, the process names, hash values, connection destination IP addresses, connection destination port numbers, registration dates/times, and latest startup dates/times of a plurality of programs are held as white list 003 corresponding to PC 003], and [¶152, A control program 113 according to the second embodiment has a control function of permitting or prohibiting, based on the white list 120, network access of a program started on a client 10. The control program 113 according to the second embodiment also has a control function of controlling network access using the IP address or port number of a connection destination to be accessed by a program as a determination criterion]
Regarding claim 8, TAKANO discloses,, wherein the internal storage is configured to store an initial whitelist and first verification information; and wherein, during start-up of the information processing apparatus, the controller is configured to: generate second verification information based on the initial whitelist stored in the internal storage; and in response to a determination that the second verification information mismatches with the first verification information stored in the internal storage, acquire the whitelist from the external storage through the interface [¶52, The identification program 110 is executed by the arithmetic device 10C and acquires information (to be referred to as program information hereinafter) such as a file name (program name), hash value, version information, file size, file path, and digital signature from a separately started program. The identification program 110 has an identification function of identifying the program based on the acquired program information. The identification program 110 collates the acquired program information with the chained elevation criterion rule 130 to be described later and determines whether the program meets the chained elevation criterion], and [¶59, The chained elevation criterion rule 130 is a rule to determine whether a program or file was issued by a reliable issuer. The chained elevation criterion rule 130 includes rules defined by the administrator or user based on program information. The rules include, for example, a digital signature added to a program or file, verifying whether a digital certificate is authentic, determining whether the signatory name of a file is a name stored in advance, and determining whether a file name meets a designated condition].
Regarding claim 9, TAKANO discloses, wherein the controller is configured to, in response to the determination that the acquired whitelist is complete, store the acquired whitelist in the internal storage as the active whitelist and store third verification information based on the acquired whitelist in the internal storage [see FIG. 1 client PC , whitelist (120), blacklist(140) Program ETC stored in storage device( 10B), changed evaluation criterion rule( 130) ,[ ¶41, The various kinds of data 101 stored in the storage device 10B include the white list 120, a chained elevation criterion rule 130, and a black list 140, and details will be described later.], and [¶125, The management console 210 transmits the data of the white list master 220 to the client 10 periodically (for example, every other hour or every other day). The whitelist 120 of the client 10 is thus updated].
Regarding claim 10, TAKANO discloses, wherein the controller is configured to generate the third verification information based on the acquired whitelist ¶52, The identification program 110 is executed by the arithmetic device 10C and acquires information (to be referred to as program information hereinafter) such as a file name (program name), hash value, version information, file size, file path, and digital signature from a separately started program. The identification program 110 has an identification function of identifying the program based on the acquired program information. The identification program 110 collates the acquired program information with the chained elevation criterion rule 130 to be described later and determines whether the program meets the chained elevation criterion], and [¶59, The chained elevation criterion rule 130 is a rule to determine whether a program or file was issued by a reliable issuer. The chained elevation criterion rule 130 includes rules defined by the administrator or user based on program information. The rules include, for example, a digital signature added to a program or file, verifying whether a digital certificate is authentic, determining whether the signatory name of a file is a name stored in advance, and determining whether a file name meets a designated condition], and
[¶150, FIG. 10 shows an example of a whitelist master 220 according to the second embodiment which exists in a server 20. The whitelist master 220 holds information associated with the whitelists 120 of a plurality of clients in association with the names or codes of the clients. In the example of FIG. 10, the process names, hash values, connection destination IP addresses, connection destination port numbers, registration dates/times, and latest startup dates/times of a plurality of programs are held as white list 003 corresponding to PC 003].
Regarding claim 11, TAKANO discloses, wherein the controller is configured to acquire the third verification information from the external storage through the interface [¶52, The identification program 110 is executed by the arithmetic device 10C and acquires information (to be referred to as program information hereinafter) such as a file name (program name), hash value, version information, file size, file path, and digital signature from a separately started program. The identification program 110 has an identification function of identifying the program based on the acquired program information. The identification program 110 collates the acquired program information with the chained elevation criterion rule 130 to be described later and determines whether the program meets the chained elevation criterion], and [¶59, The chained elevation criterion rule 130 is a rule to determine whether a program or file was issued by a reliable issuer. The chained elevation criterion rule 130 includes rules defined by the administrator or user based on program information. The rules include, for example, a digital signature added to a program or file, verifying whether a digital certificate is authentic, determining whether the signatory name of a file is a name stored in advance, and determining whether a file name meets a designated condition], and
[¶150, FIG. 10 shows an example of a whitelist master 220 according to the second embodiment which exists in a server 20. The whitelist master 220 holds information associated with the whitelists 120 of a plurality of clients in association with the names or codes of the clients. In the example of FIG. 10, the process names, hash values, connection destination IP addresses, connection destination port numbers, registration dates/times, and latest startup dates/times of a plurality of programs are held as white list 003 corresponding to PC 003].
Regarding claim 12, TAKANO discloses, wherein the controller is configured to generate the second verification information by calculating the second verification information using a hash function with the initial whitelist as an input [¶52, The identification program 110 is executed by the arithmetic device 10C and acquires information (to be referred to as program information hereinafter) such as a file name (program name), hash value, version information, file size, file path, and digital signature from a separately started program. The identification program 110 has an identification function of identifying the program based on the acquired program information. The identification program 110 collates the acquired program information with the chained elevation criterion rule 130 to be described later and determines whether the program meets the chained elevation criterion], and [¶59, The chained elevation criterion rule 130 is a rule to determine whether a program or file was issued by a reliable issuer. The chained elevation criterion rule 130 includes rules defined by the administrator or user based on program information. The rules include, for example, a digital signature added to a program or file, verifying whether a digital certificate is authentic, determining whether the signatory name of a file is a name stored in advance, and determining whether a file name meets a designated condition], and [¶150, FIG. 10 shows an example of a whitelist master 220 according to the second embodiment which exists in a server 20. The whitelist master 220 holds information associated with the whitelists 120 of a plurality of clients in association with the names or codes of the clients. In the example of FIG. 10, the process names, hash values, connection destination IP addresses, connection destination port numbers, registration dates/times, and latest startup dates/times of a plurality of programs are held as white list 003 corresponding to PC 003].
Regarding claim 13, TAKANO discloses, wherein the information processing apparatus is at least one of an image forming apparatus or a point of sale terminal [¶228, In the first and second embodiments, a PC, tablet terminal, and smartphone have been described as the examples of the client 10. However, the above-described processing can be applied using a terminal including no pointing device (for example, network scanner) or a terminal including no display (for example, embedded terminal) as a client].
Regarding claims 14, and 18, TAKANO discloses, wherein the external storage includes at least one of a server, a user device, or a removable computer-readable storage medium.
[ see FIG. 1 , server (20) with storage device (20B), Memory and ….].
Regarding claim 15, TAKANO discloses, wherein the interface is configured to receive the information from the external storage through a network [ see FIG 1, Network I/F (10D) in client PC(10) , and Network I/F (20C) in Server(20)].
Regarding claims 17, and 20 are interpreted and rejected for the same rational set forth in claim 1.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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 of this title, 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 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 2015/0193618 issued to TAKANO, and in view of US Patent Application No. (2025/0190542) to MAI.
Regarding claims 16, and 19, TAKANO does not explicitly disclose, However, MAI discloses wherein the external storage contains the whitelist in an image, and wherein the interface is a scanner configured to read the whitelist from the image.
While TAKANO discloses scanner as: [¶228, In the first and second embodiments, a PC, tablet terminal, and smartphone have been described as the examples of the client 10. However, the above-described processing can be applied using a terminal including no pointing device (for example, network scanner) or a terminal including no display (for example, embedded terminal) as a client.
TAKANO does not explicitly disclose; However, MAI disclose wherein the external storage contains the whitelist in an image, and wherein the interface is a scanner configured to read the whitelist from the image[¶85, In an embodiment of the present application, the credibility of the application program can be determined through a black and white list mechanism. The application program can save a measurement value of a trusted application component (target measurement data) as a preset measurement value to the white list, save a measurement value of an untrusted application component as a preset measurement value to the black list, and package the black/white list in the form of the configuration file in the image file], and [¶102, After the image files have been loaded, an application program can use measurement values of trusted application components as a white list, and measurement values of untrusted application components as a black list, and the black/white list is packaged in the image files in the form of a configuration file. During the operation of the application program, a group of measurement values generated in a loading process are read from the trusted root, and the measurement values of the internal application components are compared with the measurement values recorded by the corresponding registers. The operation will be allowed if a comparison result is in the whitelist, while the operation will be forbidden if the comparison result is in the blacklist].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of TAKANO by incorporating “the black/white list in the form of the configuration file in the image file”, as taught by MAI. One could have been motivated to do so in order to during the operation of the application program, a group of measurement values generated in a loading process are read from the trusted root, and the measurement values of the internal application components are compared with the measurement values recorded by the corresponding registers. The operation will be allowed if a comparison result is in the whitelist, while the operation will be forbidden if the comparison result is in the blacklist [ MAI, ¶¶85, 102].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's
disclosure.
See submitted 892 for more relevant references.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights