DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The following claim(s) is/are pending in this office action: 1, 3, 5-15
The following claim(s) is/are amended: 1
The following claim(s) is/are cancelled: 2, 4
The following claim(s) is/are new: -
Claim(s) 1, 3, 5-15 is/are rejected. This rejection is FINAL.
Response to Arguments
Applicant’s arguments filed in the amendment filed 8/27/2026, have been fully considered but are moot in view of new grounds of rejection. The reasons set forth below.
Applicant’s Invention as Claimed
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.
Claim(s) 1, 3, 5-15 is/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 pre-AIA the applicant regards as the invention. Claim 1 is representative. Applicant amends the “header” that previously existed in Claim 1 to be a “local header” and places limitations on the local header. However, previous citations to a “header” were either referring to a single block header or referring to the global header. This creates both antecedent basis issues and indefiniteness. For example, Claim 7 refers to “the header” for several data blocks while Claim 1 contemplates each block having its own header. Claim 1 introduces “a local header” and then refers to “each local header” but then refers to “the header” which has antecedent basis issues both in terms of nomenclature (“header” and “local header” are both used at various points when only one thing was introduced) and in terms of plurality (“the header” when “each [] header” was previously contemplated).
The above cited rejections are merely exemplary.
The Applicant(s) are respectfully requested to correct all similar errors.
Claims not specifically mentioned are rejected by virtue of their dependency.
Claim Rejections - 35 USC § 103
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 1, 3, 5-15 are rejected under 35 U.S.C. 103 as being unpatentable over Natsume (US Pub. 2010/0313192) in view of El-Hajj (US Pub. 2005/0203673) in view of Dwertmann (DE 10-2020-209-128 A1) and further in view of Bouldin (US Pub. 2012/0158676).
With respect to Claim 1, Natsume teaches an electronic control device mounted on a vehicle, the electronic control device comprising: a controller configured to execute a program in which a process of controlling a device mounted on the vehicle is mounted; (Fig. 1, paras. 3, 61, 66; ECU for an automobile has processor that controls processing of apparatuses mounted on the vehicle based on execution of an application program (control software).)
A memory configured to store an address list; (para. 72; memory. Para. 137; memory is set to identify an interruption location. Fig. 19, paras. 137-138; Block IDs of the blocks.)
a communication interface configured to receive update data used to update the program; (Fig. 2, para. 77; wireless or radio communication interface connected to ECU receives updated program)
and a storage configured to store the program, (para. 78-84; received updated program is stored in memory in ECU.)
and includes non-processed data not subjected to compression processing or encryption processing, the non-processed data holds the address list (Encryption or compression will be taught later. paras. 84-86; received data blocks are written to storage. Para. 13; program is described in address space. Fig. 12, para. 112; program is stored with a header and a fixed address area that stores the program. Figs. 19, 21, paras. 137-138; the individual data blocks may also have their own id such that Block 1 can be distinguished from Block 2.)
the update data includes a plurality of data blocks, the non-processed data comprises a local header portion at a head of each data block of the plurality of data blocks (paras. 84-86; received data blocks are written to storage. Fig. 12, para. 112; program is stored with a header and a fixed address area that stores the program. Figs. 19, 21, paras. 137-138; the individual data blocks may also have their own id such that Block 1 can be distinguished from Block 2.)
the address list is included in the header portion, wherein the address list includes information capable of specifying each data block of the plurality of data blocks included in the update data (Figs. 19, 21, paras. 137-138; the individual data blocks may also have their own id such that Block 1 can be distinguished from Block 2. See also Fig. 22; alternate storage configuration where Block IDs are grouped together at start. To the extent that data is included in the global header rather than local headers, the claims allow for the global header to be the first local header, and further it would have been obvious to one of ordinary skill prior to the effective filing date to place the data in each data block to allow for navigating the update data from any particular block.)
when the process of writing the update version data block to the storage is interrupted in a middle, (paras. 73-76, 84-86, 111-116, 121-133; when the system receives an update to a program the system creates a separate storage area for the updated program, sets a completion flag to “0”, writes and verifies all data is received, and sets the completion flag to “1.” Para. 132-136; Alternatively, the system can flag “00” for writing, “01” for written-but-not-verified and “10” for written and verified. Therefore the system can determine whether a program has finished writing and/or verification or whether the process has been interrupted. Figs. 19, 21, paras. 137-138; System can also identify particular blocks so that an interruption can result in picking up from the particular block that whose writing/verification was interrupted.)
the controller specifies a data block in the update data corresponding to the update version data block to be rewritten according to the address list (Figs. 19, 21, paras. 137-138; System can also identify particular blocks so that an interruption can result in picking up from the particular block that whose writing/verification was interrupted.)
by acquiring the address list from the header portion, (paras. 84-86; received data blocks are written to storage. Fig. 12, para. 112; program is stored with a header and a fixed address area that stores the program. Figs. 19, 21, paras. 137-138; the individual data blocks may also have their own id such that Block 1 can be distinguished from Block 2.)
and designates the specified data block to re-acquire the update data, (para. 116-117; when the system restarts after an interruption, the system reacquires the update data and processes it.)
sets the resume address as the transfer start request address, transmits the transfer start request address to the communication interface, and receives from the communication interface, only a portion of the plurality of data blocks of the update data corresponding to the transfer start request and after the transfer start request. (A resume address will be taught later. para. 116-117; when the system restarts after an interruption, the system reacquires the update data and processes it. Fig. 22, paras. 141-144; Block IDs used to identify point at which rewriting was interrupted, and rewriting begins from that block. Para. 123; data block to be transmitted, which suggests single block transmission. Further, even if one read the disclosure as transmitting all of the blocks, both Natsume and Dwertmann disclose identifying particular areas that have not been updated and it would have been obvious to one of ordinary skill prior to the effective filing date to transfer only that data because the transfer of data that has already been successfully updated would serve no purpose. It is obvious to remove elements when the function of the element is not desired, see MPEP 2144.04(II)(A). See also Dwertmann, pg. 6; “This makes it possible not to transmit data sections have already been fully programmed.”)
But Natsume does not explicitly teach compression or encryption.
El-Hajj, however, does teach wherein the update data includes at least one of compressed data subjected to compression processing or encrypted data subjected to encryption processing, (paras. 43-48; vehicle on board unit performs wireless communication with a server to get application updates. Paras. 151-154, 374; communication may use compression and encryption.
the controller extracts an update version data block of the program to be written to the storage from the update data by at least performing one of decompressing the compressed data and decrypting the encrypted data, (paras. 395-399; decompression and decryption of a received message.)
It would have been obvious to one of ordinary skill prior to the effective filing to combine the device of Natsume and the compression and encryption in order to decrease the size and increase the security of the message being transmitted.
But modified Natsume does not explicitly teach determines a resume address in the update data according to the head address.
Dwertmann, however, does teach (ii) information specifying a location in the storage at which a body portion of a respective data block is to be stored (pg. 4; received data can be written at a specific physical memory address. Fig. 2, pg. 5; transferred data object maps to saved data address. Pg. 6; Resume points, which identify where in the memory to start writing the transfer data, can be defined as an absolute address of the memory element.)
and (iii) a resume address that describes a correspondence between a respective head address and a respective data block address written in the memory of each data block of the plurality of data blocks in the update data; (pg. 4; data is written to non-volatile memory at a specific physical memory address. Pg. 5; transfer points designate the start position of a new data section. The actual length can be specified if desired. pg. 6; resume points can be set which indicate points at which the write process can be resumed after an interruption. The resume points can be defined as absolute points or as relative addresses in the data object. Fig. 2, pg. 5; TD in transferred data object related to SP in stored memory. Further, RP identifies a specific point where the write process can be resumed.)
the controller receives, from the communication interface, a transfer start address request at a head of the update data; (First see Natsume, paras. 84-86; received data blocks are written to storage. Fig. 12, para. 112; program is stored with a header and a fixed address area that stores the program. Then see Dwertmann, pg. 4; data is written to non-volatile memory at a specific physical memory address. Pg. 5; transfer points designate the start position of a new data section. The actual length can be specified if desired.)
specifies a head address of the specified data block, (pg. 4; data is written to non-volatile memory at a specific physical memory address. Pg. 5; transfer points designate the start position of a new data section. The actual length can be specified if desired.)
determines the resume address according to the head address, (pg. 6; resume points can be set which indicate points at which the write process can be resumed after an interruption. The resume points can be defined as absolute points or as relative addresses in the data object.)
It would have been obvious to one of ordinary skill prior to the effective filing to combine the device of modified Natsume and the determines a resume address in the update data according to the head address in order to allow for relative addressing to keep order as lengths change due to decompression. (Dwertmann, pg. 5)
But modified Natsume does not explicitly teach
Bouldin, however, does teach each local header portion being uncompressed (Examiner asserts that El-Hajj renders this feature obvious on its own, see El-Hajj, para. 396; when compression for a message is requested the message payload can be compressed. Regardless, see Bouldin, Fig. 1, para. 17; compression of data with a local header that describes the data placed before the data.)
and describing (i) information specifying a location of a next local header portion in the update data, (Examiner asserts that Dwertmann renders this feature obvious on its own, see Dwertmann, pg. 5; each data section has a designation of a start of a new section and the length of the sections can be specified. Regardless, see Bouldin, Fig. 2, para. 20; address of local header. Fig. 2 paras. 22-25; block size of compressed data in order to find particular sections of compressed data. Local header can store sizes. Para. 25; seeking to local header address. See also Dwertmann, pg. 6; addresses can be stored relatively or absolutely. It would have been obvious to one of ordinary skill prior to the effective filing date to describe the next header in the current header to allow for seeking to the next data block.)
It would have been obvious to one of ordinary skill prior to the effective filing to combine the device of modified Natsume and the next local header portion in order to seek within compressed data. (Bouldin, para. 24)
With respect to Claim 3, modified Natsume teaches the electronic control device according to claim 1, and Natsume also teaches wherein the controller stores the address list acquired from the header portion in the memory when writing the update version data block in the storage, paras. 84-86; received data blocks are written to storage. Fig. 12, para. 112; program is stored with a header and a fixed address area that stores the program. Figs. 19, 21, paras. 137-138; the individual data blocks may also have their own id such that Block 1 can be distinguished from Block 2.)
and the controller specifies a data block in the update data corresponding to the update version data block to be rewritten using the address list stored in the memory when a process of writing the update version data block into the storage is interrupted in a middle. (Figs. 19, 21, paras. 137-138; System can also identify particular blocks so that an interruption can result in picking up from the particular block that whose writing/verification was interrupted. para. 116-117; when the system restarts after an interruption, the system reacquires the update data and processes it.)
With respect to Claim 5, modified Natsume teaches the electronic control device according to claim 1, and El-Hajj also teaches wherein the data block is subjected to the compression processing, and a header portion of the data block is not compressed. (paras. 366-368, 374, 555; packet header includes encryption and compression fields. Para. 213, 396; payload is compressed. Para. 482; payload becomes virtual content when message is compressed or encrypted.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 6, modified Natsume teaches the electronic control device according to claim 5, and El-Hajj also teaches wherein the controller acquires the update version data block by decompressing the update data for each data block, (para. 396; decompression of message.)
The same motivation to combine as the independent claim applies here.
And Natsume also teaches and the controller writes the update data into the storage for each update version data block. (paras. 73-76, 84-86, 111-116, 121-133; when the system receives an update to a program the system creates a separate storage area for the updated program, sets a completion flag to “0”, writes and verifies all data is received, and sets the completion flag to “1.”)
With respect to Claim 7, modified Natsume teaches the electronic control device according to claim 5, and El-Hajj also teaches wherein the update data is configured by aggregating one or more of the data blocks subjected to the compression processing and the header portion corresponding to the data block, (para. 362-365; reassembly of a multi-part message.)
the update data is subjected to the encryption processing for each of the data blocks, and the header portion is not encrypted. (paras. 366-368, 374, 555; packet header includes encryption and compression fields. Para. 213, 398-399; payload is encrypted and flag is set to indicate it. Para. 482; payload becomes virtual content when message is compressed or encrypted.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 8, modified Natsume teaches the electronic control device according to claim 5, and El-Hajj also teaches wherein the update data is subjected to the encryption processing after being subjected to the compression processing, (para. 398; encryption after compression.)
and the controller acquires the update version data block by decrypting and then decompressing the update data. (paras. 395-399; decompression and decryption.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 9, modified Natsume teaches the electronic control device according to claim 1, and Natsume also teaches wherein supplementary information of the data block is described at a head or a tail or a position between the head and the tail of the data block, (paras. 112, 138; top includes state ID or main ID of the program as a whole as to whether it has been verified. Block ID includes the state of each block.)
and the address list describes a position of a head of the data block or describes a position of the supplementary information arranged at a head of the data block. (para. 138; state of block is identified at a predetermined address of the block.)
With respect to Claim 10, modified Natsume teaches the electronic control device according to claim 1, and Natsume also teaches wherein the update data includes a second data block next to a first data block, and when a process of writing the second data block to the storage is interrupted in a middle after the first data block is written to the storage, the controller resumes the process of writing the update data to the storage from the second data block. (Figs. 19, 21, paras. 137-138; System can also identify particular blocks so that an interruption can result in picking up from the particular block that whose writing/verification was interrupted.)
With respect to Claim 11, modified Natsume teaches the electronic control device according to claim 10, and Natsume also teaches wherein: the memory stores write completion block information indicating that writing of the data block of the update data to the storage is completed, (paras. 73-76, 84-86, 111-116, 121-133; when the system receives an update to a program the system creates a separate storage area for the updated program, sets a completion flag to “0”, writes and verifies all data is received, and sets the completion flag to “1.” Para. 132-136; Alternatively, the system can flag “00” for writing, “01” for written-but-not-verified and “10” for written and verified. Therefore the system can determine whether a program has finished writing and/or verification or whether the process has been interrupted.)
each time a data block of the update data is written in the storage, the controller stores the write completion block information related to the data block in which writing is completed in the memory, and when the write completion block information indicates that the writing of the second data block to the storage is not completed, the controller resumes the process of writing the update data to the storage from the second data block. (Figs. 19, 21, paras. 137-138; System can also identify particular blocks so that an interruption can result in picking up from the particular block that whose writing/verification was interrupted.)
With respect to Claim 12, modified Natsume teaches the electronic control device according to claim 11, and Natsume also teaches wherein the controller diagnoses whether the update data is normally written to the storage according to the write completion block information. (paras. 73-76, 84-86, 111-116, 121-133; system verifies write. See also paras. 118-119; system writes an error log when an error occurs, which is also a diagnosing of normal writing.)
With respect to Claim 13, modified Natsume teaches the electronic control device according to claim 1, and El-Hajj also teaches wherein the vehicle includes a gateway device (para. 78-86; Vehicle OBU with a wireless interface may function as a data gateway.)
that temporarily stores the update data and transfers the temporarily stored update data to the electronic control device, the communication interface receives the update data via the gateway device, (paras. 78-81; OBU can transfer data to ECU. Para. 86; OBU may act as a server. Paras. 145-149; multi-part message may have some chunks sent at not others, and OBU may store received chunks. See also Natsume, paras. 71-72, 84; buffer stores received data until it is written to the flash ROM.)
The same motivation to combine as the independent claim applies here.
And Natsume also teaches and when resuming the write processing interrupted in a middle, the controller re-acquires the update data temporarily held by the gateway device. (para. 116-117; when the system restarts after an interruption, the system reacquires the update data and processes it. See also El-Hajj, Para. 86; OBU may act as a server.)
With respect to Claim 14, modified Natsume teaches the electronic control device according to claim 1, and El-Hajj also teaches wherein a first data block included in the update data is encrypted by using a second data block that is included in the update data and is different from the first data block, (para. 399; message content may include additional data such as a session ID to assist in decrypting the message. Therefore the session ID is a second data block.)
the update data includes an initialization vector used to decrypt a data block encrypted first in the update data, (para. 398-399; a public/private key encryption may be used to communicate a session key that is used to encrypt the content of messages.)
and when the second data block is a data block encrypted first in the update data, the controller acquires the second data block and the initialization vector together to decrypt the second data block. (para. 398-399; Session ID may be used in decryption. Therefore the private key (initialization) can be used on the encrypted session data (second data block) to generate the session key and assist in the decryption of the remainder of the message, including the first data block.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 15, modified Natsume teaches the electronic control device according to claim 1, and El-Hajj also teaches wherein a first data block included in the update data is encrypted by using a second data block that is included in the update data and is different from the first data block, (para. 399; message content may include additional data such as a session ID to assist in decrypting the message. Therefore the session ID is a second data block.)
the update data includes an initialization vector used to decrypt a data block encrypted first in the update data, (para. 398-399; a public/private key encryption may be used to communicate a session key that is used to encrypt the content of messages.)
the first data block is arranged after the second data block in the update data, and when decrypting the first data block, the controller decrypts the first data block by acquiring the first data block and the second data block together. (para. 398-399; Session ID may be used in decryption. Therefore the private key (initialization) can be used on the encrypted session data (second data block) to generate the session key and assist in the decryption of the remainder of the message, including the first data block. Since the data from the second data block is used to decrypt the remainder of the message, it would have been obvious to one of ordinary skill prior to the effective filing date to include the session data first so that decryption can be performed as the rest of the message arrives.)
The same motivation to combine as the independent claim applies here.
Remarks
Applicant argues at Remarks, pgs. 8-10 that the newly amended features of the independent claims are not taught by the previously cited prior art. The claims are amended to (1) shift “header” to “local header,” (2) each local header is uncompressed, (3) each local header contains information specifying a next local header, and (4) each local header contains information specifying a location in the storage at which a body portion of the respective data block is to be stored.
Applicant does not dispute that Natsume teaches (1). (2) previously existed in Claim 5, and Applicant does not argue against Claim 5 and does not discuss El-Hajj at all. (4) is essentially the same thing as a resume point where the resume point is the start point of the block. Applicant argues that in Dwertmann the resume points are created during the write process and are not included in the header. Examiner does not see how that is relevant because this is not an anticipation rejection. Dwertmann discloses that the art was capable of absolutely addressing the write target of data, i.e. “The following data should be written to this location:…” Dwertmann, pg. 4, explicitly states that “data can be transmitted from or to the control unit 100…[t]he data received in this way can then be written to non-volatile memory, optionally at a specific physical memory address.” The only thing missing from that disclosure is that the address is in the local header, but storage of the target address of a write logically commends itself to be stored together with the data to be written.
This leaves (3). Examiner questions whether a new reference is needed for the feature because Dwertmann discloses relative and absolute addressing, and block lengths. Further, the whole point of Dwertmann is to identify particular data segments in transmission data that map the memory locations. In other words, Examiner thinks Dwertmann, Fig. 2 and its accompanying description is sufficient to disclose information specifying the start of data segments. Regardless, Examiner will cite Bouldin. Bouldin discloses both an absolute address to a local header (Fig. 2, element 34 within element 32 and para. 25) and lengths of compressed blocks (Fig. 2, element 46 and para. 25) which allow for a relative address of the next header to be expressed. Because Bouldin makes more clear that only the data and not the header is compressed and because the compression is anticipatorily being not-applied to local headers (rather than headers in general), Examiner will also cite it in addition to El-Hajj for the compression element.
Before closing the 103 section, Examiner does want to respond to a comment made about Natsume. Applicant points out at Remarks, pg. 9 that the ID storage parts 402a “contain only state information [] and lack any suggestion of a local header portion describing [amended features].” While Examiner agrees the IDs themselves are for state information, Examiner notes that the information Applicant asserts routinely exists in headers. For example, in the Fig. 12 embodiment of Natsume, there is a header that describes the address of the main body (i.e. a payload start) a tail address (i.e. a payload end) and an address of the ID storage part. And in Fig. 19, while the Block IDs don’t contain addressing information, obviously the addressing information exists in the scheme because the system knows when a new block begins with data that has possibly not been written yet. Both Natsume and Dwertmann contemplate segmenting data to be written and identifying those segments, and headers with addresses that identify data boundaries are ubiquitous. In other words, the only thing that gives Applicant’s argument any kick is the word “local,” because Examiner doubts Applicant would make the argument that the global header lacks information to, e.g., identify where its blocks start and stop. Similarly, in the argument against Dwertmann, Applicant does not argue that markers identifying addresses of data to be copied, locations to be copied to, and resume points are not known to the art, rather they are not necessarily existent in a local header.
The location of the storage of addresses are fungible design choices. The important feature of the system is that the data for describing starts of new blocks is known. In other words, whether one has a global directory or a series of local directories is a simple substitute of location and form for expected results of different manners of navigating. Applicant appears to agree the location of the data is noncritical, as Applicant’s Spec identifies the storage in a global header or local header are alternate embodiments. Spec, para. 20 states the write address correspondence can be in the global header or each local header. Spec, para. 22 states the global header has the resume address, but Claim 1 states “each local header portion describing…(iii) a resume address.” The address list as discussed by Spec, paras. 59-61 seem to place the address list in a global header, which comports with the para. 18 statement that “The local header describes supplementary information of the data block, and the global header describes supplementary information of the entire update data.” Claim 1 states “the address list is included in the header portion” and the header portion is now “a local header portion” despite the fact that the address list “includes information capable of specifying each data block of the plurality of data blocks.”
Examiner makes a 112b rejection to the current claimset over the introduction of a “local header” but maintaining “header” in other contexts. In resolving this indefiniteness, Examiner invites Applicant to scrutinize what disclosures are directed toward the global header and what disclosures are directed toward a local header to prevent claims that claim new matter. While Examiner thinks that the location is fungible and therefore obvious, which would be Examiner’s response to Applicant’s argument against Natsume, Examiner thinks the argument really isn’t applicable to the instant invention because Examiner thinks Spec, para. 18 is accurate – the invention contemplates using the global header space for global descriptions and local header space for local descriptions, which is the conventional usage of global and local headers. Examiner thinks it is unlikely that Applicant contemplated copying the entire address list (“information capable of specifying each data block”) multiple times over, (“the address list is included in the header portion [a local header portion being at a head of each data block of the plurality of data blocks]”) which is one way to read the indefinite claims. In short, Examiner suspects Natsume is much closer to the instant invention than the argument based on these indefinite claims might suggest, because Spec, paras. 18 and 20 evidence Applicant contemplates the conventional division of data between global/local headers except when Applicant feels the location of storage is irrelevant. There is nothing nonobvious about that structure.
All claims remain rejected.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS P CELANI whose telephone number is (571)272-1205. The examiner can normally be reached on M-F 9-5.
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, Vivek Srivastava can be reached on 571-272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICHOLAS P CELANI/Examiner, Art Unit 2449
Prosecution Insights