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 .
DETAILED ACTION
Claims 1 – 8, 10 – 12 are pending.
Any references to applicant’s specification are made by way of applicant’s U.S. pre-grant printed patent publication.
This action is in response to the communication filed on 6/11/26.
All objections and rejections not set forth below have been withdrawn.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 6/11/2026 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1 – 8 and 10 – 12 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 1, the applicant’s written description fails to adequately disclose the features of “…at least one identity generation module … the method comprising generating, by at the least one identity generation module … a group user key identifier …”. Specifically, the examiner notes that the applicants specification describes the “identity generation module” as being software (e.g. Specification, par. 48), however, fails to disclose the algorithm (e.g., the necessary steps and/or flowcharts) for performing the functionality of the claimed software (i.e. “identity generation module”). Thus, the applicant fails to disclose sufficient structure for supporting the claimed subject matter. The examiner notes that it is not enough that one skilled in the art could write a program to achieve the claimed function because the applicant’s specification must explain how (e.g. by algorithm) that the inventor intends to achieve the claimed function. (see MPEP 2161.01).
Regarding claim 6, the applicant’s written description fails to adequately describe the features of “…wherein the group user key identifier is randomly generated…”. Specifically, the examiner notes that the disclosed and claimed invention is directed towards a system “…according to the 3GPP MCS (3rd Generation Partnership Program Mission Critical Services) standard…”. However, 3GPP MCS standard calls for a deterministic generation of the group user key. Furthermore, applicant fails to specifically disclose how a group user key identifier is randomly generated, such that the claimed system could still function according to the 3GPP MCS standard.
Depending claims are rejected by virtue of dependency.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 – 8 and 10 – 12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1 and 8, the recitations “…A method implemented … according to the 3GPP MCS (3rd Generation Partnership Program Mission Critical Services) standard…” (e.g. claim 1) and “…A communication network according to the 3GPP MCS (3rd Generation Partnership Program Mission Critical Services) standard…” (e.g. claim 8) render the scope of the claims indefinite.
Specifically, the examiner notes that the applicant declares within the Affidavit of 6/11/26 essentially that any implementation of the claimed method (and presumedly the claimed system) would be non-compliant with the 3GPP MCS standard (e.g. “…Any implementation of claim 1 that generates the GUK-ID by some other method … is, by definition, non-compliant with the Standard’s prescribed generation rule … an implementation falling with the scope of claim 1 is not disclosed by the Standard…”; see page 9).
Thus, if as admitted by the applicant, the claimed subject matter is in fact not compliant with the 3GPP MCS standard, then it is unclear as to what specific subject matter supposedly falls within or outside the scope of the claimed requirement of a method and system “according to the 3GPP MCS … standard”.
Regarding claim 6, the recitations of “…wherein the group user key identifier is randomly generated…” renders the scope of the claims indefinite. Specifically, the examiner notes that the disclosed and claimed invention is directed towards a system “…according to the 3GPP MCS (3rd Generation Partnership Program Mission Critical Services) standard…”. However, the random generation of a “group user key identifier” is not according to 3GPP MCS standard. Furthermore, applicant fails to specifically disclose how a group user key identifier is randomly generated, such that the claimed system could still function according to the 3GPP MCS standard.
Regarding claim 12, the recitation, “…wherein the group user key identifier acts as a pseudonym … such that the receiving entity cannot identify the client transmitting entity from the group user key identifier…” renders the scope of the claims indefinite. Specifically, the examiner points out that by the applicant’s own admission (see Affidavit, 6/11/26, pg. 7; “…any method of generating the GUK-ID … Examples include, without limitation (i) …(ii)… or (iii)…”), the claimed “group user key identifier” is deterministically generated. Thus, while it might be difficult and/or take a measure of time, it would not be impossible (i.e. “…cannot identify…”) for a receiver to identify the transmitter from the pseudonym or “group user key identifier”.
Depending claims are rejected by virtue of dependency.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 – 8 and 10 – 12 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by 3GPP, “3GPP TS 33.180 v17.5.0 - Security of the Mission Critical (MC) service (Release 17)”.
Regarding claim 1, as best understood in view of the above noted deficiencies of clarity, 3GPP discloses:
A method implemented by a client transmitting entity included in a network according to the 3GPP MCS standard (e.g. 3GPP, sect. 4.1; fig. 4.2-1), the client transmitting entity being configured to transmit a plurality of contents intended for at least one client receiving entity included in the network (e.g. 3GPP, fig. 4.3.5.2-2), the client transmitting entity and the client receiving entity being affiliated with a same communication group (e.g. 3GPP, sect. 4.3.5.2; fig. 4.3.5.2-2 – group communications),
the client transmitting entity comprising at least one identity generation module (e.g. 3GPP, sect. 5.2.2; fig. 5.2.3-1 – initiator, i.e. “transmitting entity”, comprises means, i.e. “module”, for generating a K-ID and/or UK-ID and/or GUK-ID and/or GMK-ID) the method comprising generating, by at the least one identity generation module of the client transmitting entity, a group user key identifier, the generation being performed autonomously by the client transmitting entity, the group user key identifier being specific to the communication group … (e.g. 3GPP, sect. 5.2.2; sect. 5.2.3; sect. 5.7.1; sect. 5.7.2; sect. 7.3.3). Herein, the initiator produces (i.e. “generates”) – via any one of an ID derivation algorithm (e.g. 3GPP, fig. 5.2.3-1; sect. 5.2.2; Annex F.1.3 – the initiator itself executes a key derivation algorithm, i.e. “autonomously”), a selection of one from of a plurality of active IDs (e.g. 3GPP, sect. 5.7.1 – the initiator itself performs the selection, i.e. “autonomously”), an extraction algorithm based upon a message (e.g. 3GPP, sect. 5.7.2 – the initiator itself performs the extraction, i.e. “autonomously”), and/or via a request to a group master (e.g. 3GPP, sect. 7.3.3.3; sect. 7.3.11; sect. 7.4.2 – the initiator itself produces an identifier via a request, i.e. “autonomously”) – a key identifier, such as a K-ID and/or UK-ID and/or GUK-ID and/or GMK-ID, for the group of two or more clients.
… and being used to encrypt the content (e.g. 3GPP, sect. 7.5.1), the generating being repeated each time a predetermined event detected locally by the client transmitting entity takes place (e.g. 3GPP, sect. 5.2.2; sect. 5.6; 5.7.1 - the encryption keying material is “time-limited” and/or sect. 7.3.2; sect. 7.3.3). Herein, the “initiator” detects the need to generate new keys and key identifiers for communication to a receiving entity based upon the reception of new group keying material from a GMS. Thus, the initiator locally detects an event, i.e. a rekeying event, so as to generate new common communication keys and IDs for communicating with a peer client.
Regarding claim 2, 3GPP discloses:
encrypting the content to be transmitted, the content being encrypted by the client transmitting entity, encrypting the content being based on a master key according to the Secure Real Time Protocol (e.g. 3GPP, sect. 7.5.1), the master key comprising a group master key identifier and the group user key identifier generated (e.g. 3GPP, sect. 7.4.2), transmitting at least one frame to the receiving entity, according to the SRTP protocol, the at least one frame comprising the content encrypted (e.g. 3GPP, sect. 7.4.2; fig. 7.5.2-2).
Regarding claim 3, 3GPP discloses:
wherein a plurality of frames are transmitted, each frame of the plurality of frames comprising a part of the content encrypted, the master key being included in the header of a first frame of the plurality of frames encrypted (e.g. 3GPP, sect. 7.4.2; fig. 7.5.2-1; fig. 7.5.2-2 – encrypted media stream).
Regarding claim 4, 3GPP discloses:
wherein the predetermined event is a start and/or end of a predetermined time interval, the group user key identifier being used to encrypt each of a plurality of contents transmitted during the predetermined time interval (e.g. 3GPP - sect. 7.3.2; sect. 7.3.3 – herein regrouping procedures, i.e. “start” events, require the generation of new key identifiers and keying material).
Regarding claim 5, 3GPP discloses:
wherein the predetermined event is the transmission of a new content (e.g. 3GPP - sect. 7.3.2; sect. 7.3.3 – herein regrouping procedures are for the transmission of new content).
Regarding claim 6, 3GPP discloses:
wherein the group user key identifier is randomly generated (3GPP, sect. 5.2.2; sect. 5.2.3; sect. 7.3.3.2 – key identifiers are generated using random bits).
Regarding claim 7, 3GPP discloses:
wherein the communication group is an MCPTT group and the content is a voice communication (e.g. 3GPP, sect. 5.2.7.2; sect. 7.2.5) or an MCVideo group and the content is a video (e.g. 3GPP, sect. 5.2.7.2) or an MCData group and the content is a textual data set or a file (e.g. 3GPP, sect. 5.2.7.2; sect. 8.1).
Regarding claims 8 and 10, they are system and medium claims essentially corresponding to the claims above, and they are rejected, at least, for the same reasons. Furthermore because:
Regarding claim 8, 3GPP discloses:
A communication network according to the 3GPP MCS (3rd Generation Partnership Program Mission-Critical System) standard, the communication network comprising: a client transmitting entity configured to implement the method according to claim 1, a client receiving entity configured to receive the content encrypted and master key transmitted by the transmitting entity (e.g. 3GPP, fig. 7.3.11.1-2; fig. 7.5.2-1).
Regarding claim 10, 3GPP discloses:
A non-transitory computer-readable medium, comprising machine readable instructions for performing the method of claim 1 (e.g. 3GPP, sect. 11.1.1).
Regarding claim 11, 3GPP discloses:
wherein the group user key identifier is used as part of a derivation of a key used to encrypt the content (e.g. 3GPP, sect. 7.4.2; 7.5.1).
Regarding claim 12, 3GPP discloses:
wherein the group user key identifier acts as a pseudonym of the client transmitting entity, such that the receiving entity cannot identify the client transmitting entity from the group user key identifier (e.g. 3GPP, sect. 5.2.2; sect. 5.2.3; sect. 7.3.3.2 – the GUK is pseudo random).
Response to Arguments
Applicant's arguments filed 6/11/26 have been fully considered but they are not persuasive.
The Declaration under 37 CFR 1.132 filed 6/11/26 is insufficient to overcome the rejection of the pending claims based upon rejections under 35 USC § 112(a) and 35 USC § 102 as set forth in the last Office action because:
Applicant argues or alleges essentially that:
…
The specification of the '522 application discloses the algorithm of the ‘identity generation module' … Specifically:
(a) FIG. 3 of the '522 application is an explicit flowchart depicting the algorithm
performed by the identity generation module as a sequence of steps: step 11 (generating the GUK-ID by the identity generation module), step 12 (encrypting the content using the GUK- ID), and step 13 (transmitting the encrypted frame). This stepwise procedure is itself an algorithm as that term is understood in the art and is exactly the kind of disclosure expressly contemplated by MPEP 2163(III) as evidence of possession.
…
(Affidavit, 6/11/26, pgs. 5)
Examiner respectfully responds:
The examiner respectfully disagrees. Specifically, step 11 of Fig. 3 represents only a black box representation of a step to generate a GUK-ID. This does not constitute any algorithm for generating the GUK-ID.
Applicant argues or alleges essentially that:
…
The specification of the '522 application discloses the algorithm of the ‘identity generation module' … Specifically:
…
(b) Paragraph [0016] of the specification expressly discloses that "the invention comprises randomly generating a group user key identifier GUK-ID of the transmitting entity." Paragraph [0030] further discloses that the identity generation module is a software module comprising instructions executed by a processor.
…
(Affidavit, 6/11/26, pgs. 5)
Examiner respectfully responds:
The examiner respectfully disagrees. Specifically, paragraph 16 merely repeats the claimed function to randomly generate a GUK-ID. This does not constitute any algorithm for randomly generating the GUK-ID.
Applicant argues or alleges essentially that:
…
The specification of the '522 application discloses the algorithm of the ‘identity generation module' … Specifically:
…
(c) Paragraphs [0039] and [0047] of the specification disclose, by reference to FIGS. 4A, 4B, and 4C, the locally-detected events that trigger the generating step, namely the start or end of a predetermined time interval, and the initiation of a content transmission (a floor in MCPTT, a video transmission in MCVideo, or a text or file transmission in MCData).
…
(Affidavit, 6/11/26, pgs. 5,6)
Examiner respectfully responds:
The examiner respectfully disagrees. Specifically, paragraphs 39 and 47 only describe when a GUK-ID is to be generated. This does describe how the GUK-ID is generated, particularly it does not constitute any algorithm for randomly generating the GUK-ID.
Applicant argues or alleges essentially that:
…
With respect, this contention misapprehends the technical realities of how a GUK-ID is implemented in any 3GPP MCS-compliant or compatible system, and overlooks the fact that random generation of the underlying 32-bit identifier was a thoroughly conventional and well- understood operation in the art long before the priority date of the '522 application. Specifically, and as I can attest from direct technical experience:
…
(Affidavit, 6/11/26, pgs. 6)
Examiner respectfully responds:
The examiner respectfully disagrees. Particularly because the specific contention is whether or not the applicant has disclosed the algorithm for randomly generating the claimed “group user key identifier” – not an algorithm for generating any other 32-bit identifier.
A 3GPP MCS-compliant GUK-ID is a pseudo-random, deterministically generated number. However, the applicant argues that the claimed GUK-ID is distinct from the prior art GUK-ID (e.g. Remarks, 12/19/25, pg. 6, “…in the prior art, the GUK-ID is derived from a user identity … and that this leads to “linkability,” … The invention is then introduced as a solution … achieved by “randomly generating a group user key identifier GUK-ID…”). Thus, it is incumbent upon the applicant to specifically disclose the algorithm used to randomly generate the GUK-ID.
Applicant argues or alleges essentially that:
…
(a) The GUK-ID has the format of a MIKEY CSB-ID. Pursuant to 3GPP TS 33.180, the GUK-ID is carried in the MKI field of an SRTP packet (RFC 3711) and is structured in accordance with the MIKEY protocol (RFC 3830)….
…
(b) Random generation of the MIKEY CSB-ID has been recommended by IETF RFC 3830 since 2004. …
…
(Affidavit, 6/11/26, pgs. 6)
Examiner respectfully responds:
The examiner respectfully disagrees. Particularly because a 3GPP MCS-compliant GUK-ID, while being a pseudo-random, deterministically generated number (i.e. the input to its generation algorithm is a random salt), is distinct from the MIKEY CSB-ID. This is clearly evident from the fact that the architects of the 3GPP MCS system saw the need to specifically replace the MIKEY CSB-ID with the GUK-ID.
Thus, an argument which points to the similar length of the CSB-ID and the GUK-ID does not support the allegation that one of ordinary skill in the art understood how to randomly generate the GUK-ID.
Applicant argues or alleges essentially that:
…
(c) Random generation of the MIKEY CSB-ID has been a routine implementation practice for many years. …
…
(Affidavit, 6/11/26, pgs. 7)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, for the reason that the MIKEY CSB-ID is irrelevant to the GUK-ID of a 3GPP MCS compliant system.
Furthermore, the MIKEY CSB-ID is deterministically generated (i.e. pseudo-random) which the applicant appears to argue would fail to meet the definition of “randomly” generated within the claims.
Applicant argues or alleges essentially that:
…
(d) Other technically equivalent implementations are available and would be readily understood by a POSITA. Random generation is one example …but the specification is not limited to that example. A POSITA would readily understand that any method of generating the GUK-ID that breaks its deterministic linkage … Examples include, without limitation (i) … (ii) … or (iii) …
(Affidavit, 6/11/26, pgs. 7)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, for the reason that the issue at hand is an algorithm for the random generation of a GUK-ID – not algorithms for other forms of generation that could be conceived by a POSITA.
Applicant argues or alleges essentially that:
…
As discussed in paragraph 9 above, 3GPP TS 33.180 mandates a specific deterministic GUK-ID derivation method, namely the XOR of the user salt and the GMK-ID (see 3GPP TS 33.180, § § 5.2.2, 7.4.2). The claim limitation "the generation being performed autonomously by the client transmitting entity" covers, and is intended to cover, implementations in which the client generates the GUK-ID without following the Standard's mandated XOR derivation. Such implementations are non-compliant with the Standard. Because the Standard nowhere discloses or contemplates any GUK-ID generation method other than its prescribed XOR derivation, the Standard does not disclose the claimed autonomous generation.
…
(Affidavit, 6/11/26, pgs. 8, 9)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, for the reason that the claims do not preclude derivations using XOR.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “…the client generates the GUK-ID without following the Standard's mandated XOR derivation…) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant argues or alleges essentially that:
…
(a) Selection is different from Generation. …The claim language requires generating, not selecting.
…
(Affidavit, 6/11/26, pgs. 10)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, for the reason that the applicant’s remarks are without evidence.
The examiner maintains that many methods, such as “selection” or “extraction”, can be used to produce (i.e. “generate”) information. Furthermore, those having ordinary skill in the art routinely equate the terms “selecting” and “extracting” to that of “generating”.
For example:
Saha et al, US 20250209310 A1, par. 64:
“In some examples, the terms “sampling,” “generating,” and “selecting” may be used interchangeably herein.”
Lieu et al, US 20210365969 A1, par. 25:
“As referred to herein, “generating an offer” and “selecting an offer” may be used interchangeably and refer to the selection of an offer from historical offers …”
Tanner et al, US 20190042177 A1, par. 35:
“…e.g., determine what should (or should not) be visible and to generate (e.g., select, produce, blend)…”
Bernosky et al, US 20250209310 A1, par. 69:
“As used herein, the terms "computing," "deriving," "generating," "writing," "extracting," "compressing" and the like … may, in the context of media fingerprints, be used interchangeably (e.g., synonymously) herein.”
Applicant argues or alleges essentially that:
…
3GPP TS 33.180 does not disclose a "predetermined event detected locally by the client transmitting entity" that triggers the generating step.
…
… the predetermined event is one that the client itself detects from its own internal state, namely (i) the start or end of a predetermined time interval (a timer event entirely internal to the client), or (ii) the initiation of a content transmission by the client itself (a user-driven event at the client device, such as the user taking the floor in MCPTT or starting a new video transmission in MCVideo). No server message is required, requested, or referenced; the client itself, autonomously and based on its own state, detects the predetermined event and triggers a fresh GUK-ID generation.
…
… Reception of an inbound network message is a network-originated, not a locally detected, event. An event "detected locally" by the client transmitting entity is one whose occurrence is determined by the client itself, based on the client's own internal state (e.g., a timer expiring, a user pressing a push-to-talk button, the initiation of a video stream by the client). To equate the receipt of a server-originated rekeying command with a locally detected event would, in my opinion, read the word "locally" out of the claim entirely, and would be inconsistent with how a POSITA would interpret that term in the context of the specification.
…
(Affidavit, 6/11/26, pgs. 10, 11)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, for any one of the following reasons:
First, the applicant’s claims do not recite that the local detection, i.e. “detected locally”, comprises the exemplary detections such as might be within applicant’s specification. Furthermore, the applicant’s claims do not preclude the detection of server messages.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “the predetermined event is one that the client itself detects from its own internal state, namely (i) the start or end of a predetermined time interval (a timer event entirely internal to the client), or (ii) the initiation of a content transmission by the client itself (a user-driven event at the client device, such as the user taking the floor in MCPTT or starting a new video transmission in MCVideo). No server message is required, requested, or referenced; the client itself, autonomously and based on its own state, detects the predetermined event and triggers a fresh GUK-ID generation) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Second, the examiner respectfully disagrees, because the claim term “locally” qualifies the term “detected” – not “event”. Thus, the claim scope is limited by where the detection takes place, and not by an interpretation of the “internal state” of a client.
Third, the examiner respectfully disagrees because, assuming arguendo, the claimed “event” must be representative of some form of “internal state” of the client, the examiner points out that any message or keying material received by a client, would indeed be embodied by the client, and thus represent the “internal state” of the client.
The balance of the Applicant’s arguments (e.g. see Applicant Arguments /Remarks Made in an Amendment, 6/11/25) are essentially based upon the above noted arguments, and are found to be unpersuasive, at least, for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEFFERY L WILLIAMS whose telephone number is (571)272-7965. The examiner can normally be reached on 7:30 am - 4:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on 571-272-3739. 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.
/JEFFERY L WILLIAMS/Primary Examiner, Art Unit 2495
Prosecution Insights