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, and 11 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 12/19/25.
All objections and rejections not set forth below have been withdrawn.
Interviews
The examiner notes that discussions resulting from applicant initiated interviews may help to place applications in condition for allowance or resolve issues prior to appeal. The examiner kindly invites the applicant to request an interview should the applicant believe that a discussion regarding the matters of this application could help to expedite prosecution.
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, 10, and 11 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).
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, 10, and 11 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, 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).
Response to Arguments
Applicant's arguments filed 12/19/25 have been fully considered but they are not persuasive.
Applicant argues or alleges essentially that:
…
The Office Action asserts that the specification "fails to disclose the algorithm" for the "identity generation module" and therefore does not provide sufficient structure or explanation of how the claimed software performs its function.
…
Second, the specification does more than simply name the module; it also describes how the module performs its function-i.e., the "algorithm" the Examiner is looking for. …
…
Taken together, these passages describe a clear, stepwise procedure implemented by the identity generation module Gen … This is precisely the "how" of the invention's key-identifier generation. The function of "randomly generating" an identifier is a well-understood operation in the cryptographic and networking arts; a person of ordinary skill would recognize that invoking a conventional random or pseudorandom number generator to produce a new identifier, upon each occurrence of the specified events, is sufficient to implement the disclosed behavior. The law does not require the inventors to spell out the internal workings of a random number generator or to provide flowcharts for each standard library call in order to demonstrate possession of the invention.
(Remarks, pgs. 7-9)
Examiner respectfully responds:
The examiner respectfully disagrees. Specifically, it is noted that the applicant appears to entirely rely upon the argument that because the disclosure teaches that a GUK-ID may be “randomly generated”, this is a sufficient disclosure of the algorithm used to generate the GUK-ID. The applicant essentially argues that a teaching of a “randomly generated” GUK-ID would imply to one of ordinary skill in the art that a conventional random-number generator was used to generate the GUK-ID, and thus, the algorithm used by a conventional random-number generator would have also been obvious to one of ordinary skill in the art.
However, the examiner disagrees, at least, for the reason that a “GUK-ID” has a well-known and standard meaning within the art. There is no evidence within the art that a “GUK-ID” is simply a value generated as the output from a conventional random-number generator. Furthermore, the applicant’s own disclosure fails to teach that a conventional random-number generator is used as the means or algorithm for generating the GUK-ID.
Applicant argues or alleges essentially that:
…
First, amended claim 1 now expressly requires that the client transmitting entity itself (and autonomously) performs the generation of the GUK-ID, rather than an external authority doing so.
By contrast, in the 3GPP's architecture for group communications, the key material is generated and managed centrally by a network server. Section 5.7.1 of 3GPP explicitly states, "a Group Master Key (GMK) ... is distributed to MCX UEs by a Group Management Server (GMS)" and that the "initiating entity shall be the initiating GMS." The GUK-ID is derived from this server-provided key. Thus, 3GPP discloses a server-centric model where the client is a passive recipient of keying material, which is the direct opposite of the claimed client- autonomous generation. This is supported in the present application at paragraphs [0015]-[0017], which describe the invention as a solution to the "linkability" problem inherent in such server- based systems.
…
(Remarks, pg. 10, 11)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, for the reason that the Office Action does not rely upon a “GMK” to teach the claimed “group user key identifier”. Rather, the Office Action noted that a “GMK-ID” (amongst any of a number of other identifiers – e.g. K-ID and/or UK-ID and/or GUK-ID) might be reasonably said to correspond to the claimed “group user key identifier”. This rationale is based upon either one, or both, of the facts:
1. The initiating client is taught by 3GPP as possessing a plurality of GMK-IDs corresponding to a number of communication groups, and when the initiating client wishes to communicate with a specific receiving client within a particular group, the initiating client, itself (i.e. on its own), must make a GMK key selection for communication - i.e. produce or “generate …autonomously” a particular value to be used (i.e. the specific GMK-ID) for communicating with the receiving client. (e.g. 3GPP, sect. 5.7.1 – “An MC client may have multiple active GMKs associated with a Group ID. When this occurs, the MC client shall use the active GMK with the most recent Activation Time (as defined in Clause E.6.4) when encrypting group media.”)
2. The initiating client is additionally taught by 3GPP as receiving an encrypted payload, and extracting and storing (i.e. generating “autonomously”) therefrom a particular value (i.e. GUK-ID) into memory (e.g. 3GPP, sect. 5.7.2)
Furthermore, the examiner points out that the Office Action does not rely only upon the interpretations above for showing how the prior art reads upon the claimed “group user key identifier”. As previously mentioned, the Office Action also shows how any one (or all combined) of the disclosed K-ID and/or UK-ID and/or GUK-ID identifiers might be reasonably said to correspond to the claimed “group user key identifier”. However, the examiner notes that the applicant does not appear to address this position, and thus, the examiner finds the applicant’s arguments to be unpersuasive.
Applicant argues or alleges essentially that:
…
Second, amended claim 1 recites "...the generating being repeated each time a predetermined event detected locally by the client transmitting entity takes place."
This feature is also absent from 3GPP. In 3GPP, the generation of new group keys by the GMS is tied to network-level events like group creation or regrouping (see 3GPP, sections 7.3.2, 7.3.3), not to a predetermined event detected locally by the client for the purpose of breaking identifiability. The present application, in contrast, clearly discloses that the event is local to the client, such as "the start or end of a predetermined time interval" (paragraph [0039]) or "the initiation of a communication" (paragraph [0047]). 3GPP does not disclose, teach or suggest this local, client-driven trigger mechanism.
…
(Remarks, pg. 11)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, for the reason that 3GPP teaches that the initiating client, in response to the periodic rekeying messages and receptions of new keying material from the server (i.e. “an predetermined event detected locally”), must generate any the above noted identifiers (K-ID and/or UK-ID and/or GUK-ID and/or GMK-ID) by means of any of executed derivation algorithms (e.g. 3GPP, fig. 5.2.3-1; sect. 5.2.2; Annex F.1.3), a selection of one from of a plurality of active IDs (e.g. 3GPP, sect. 5.7.1), a decryption and extraction algorithm based upon a message (e.g. 3GPP, sect. 5.7.2), 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 by virtue of a request) thus enabling the initiating client to engage in encrypted communications with the receiving client device.
Conclusion
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 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