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 .
Applicant’s amendment filed 8/6/2024 is acknowledged.
Claims 1-39 are canceled.
Claims 40-54 are newly added.
Abstract is amended.
A new first paragraph of the specification is inserted.
Priority
This application is a 371 of PCT/CN2023/074378 filed on 2/3/2023.
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. PCT/CN2022/075440 filed on 2/8/2022.
Information Disclosure Statement
The information disclosure statements (IDS) were submitted on 8/6/2024, 7/30/2025, and 10/28/2025. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner.
Claim Objections
Claims 40, 43, 44, 45, 46, 50, 53, and 54 are objected because of the following informalities:
In claims 40, 43, 44, 45, 46, 50, 53, and 54, it is suggested to use parenthesis instead of comma for definition of acronyms such as “user equipment (UE)”, “uniform resource locator (URL)”, “multimedia broadcast/multicast service (MBMS)”, etc.
In claims 40 and 46, it is suggested to amend to read as follows for clarity:
40. (Currently Amended) A method performed by a user equipment(UE) comprising:
obtaining, from an application server, a service announcement comprising meta data information associated with a file containing a group message;
receiving the file from a multicast/broadcast service (MBS) entity; and
getting the group message from the file based on the meta data information included in
46. (Currently Amended) A user equipment(UE) comprising:
one or more processors; and
one or more memories storing computer program code[[s]], wherein the one or more memories and the computer program code[[s]] are configured to, when executed by the one or more processors, cause the UE at least to:
obtain, from an application server, a service announcement comprising meta data information associated with a file containing a group message;
receive the file from a multicast/broadcast service (MBS) entity; and
get the group message from the file based on the meta data information included in
Appropriate correction is required.
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 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 47-49, 53, and 54 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by 3GPP TS 29.122 (3GPP; TSG Core Network and Terminals; T8 reference point for Northbound APIs; (Release 17), V17.4.0, December 2021, hereinafter TS 29.122).
Regarding claim 47:
TS 29.122 teaches a method performed by a capability exposure entity (e.g., SCEF - Service Capability Exposure Function), comprising:
determining meta data information of a group message received from an application server (e.g., SCS/AS - Services Capability Server/ Application Server) (see, TS 29.122: Section 4.4.7.2.2.3, “Upon receipt of the HTTP POST request from the SCS/AS to deliver the group message, the SCEF shall check whether the SCS/AS is authorized to send a group message request. ... If authorization is successful, the SCEF shall initiate the Active MBMS Bearer procedure as defined in subclause 5.3.2 of 3GPP TS 29.468 [36] with the difference that the SCEF acts as a GCS AS. ... Upon successful activation of MBMS bearer, the SCEF shall create resource which represents "Individual GMD via MBMS by MB2", addressed by a URI that contains Transaction Id allocated by the SCEF ...”);
transmitting the meta data information to the application server (see, TS 29.122: Section 4.4.7.2.2.3, “Upon successful activation of MBMS bearer, the SCEF shall create resource which represents "Individual GMD via MBMS by MB2", addressed by a URI that contains Transaction Id allocated by the SCEF and respond to the SCS/AS by sending an HTTP response with a 201 Created status code, including a Location header field containing the URI for the created resource.”); and
providing the group message in a first format to a multicast/broadcast service entity (e.g., BM-SC) (see, TS 29.122: Section 4.4.7.2.2.3, “If the Group Message Payload was included the HTTP POST above, the SCEF shall deliver to BM-SC the Group Message Payload(s) as defined in 3GPP TS 29.468 [36] at Message Delivery Start Time.”, wherein the group message payload is in a certain format.).
Regarding claim 48:
As discussed above, TS 29.122 teaches all limitations in claim 47.
TS 29.122 further teaches wherein transmitting the meta data information to the multicast/broadcast service entity (see, TS 29.122: Section 4.4.7.2.2.3, “If the Group Message Payload was included the HTTP POST above, the SCEF shall deliver to BM-SC the Group Message Payload(s) as defined in 3GPP TS 29.468 [36] at Message Delivery Start Time.”).
Regarding claim 49:
As discussed above, TS 29.122 teaches all limitations in claim 48.
TS 29.122 further teaches wherein the meta data information is transmitted to the multicast/broadcast service entity in an update session procedure from the capability exposure entity (see, TS 29.122: Section 4.4.7.2.2.3, “If authorization is successful, the SCEF shall initiate the Create Session procedure as defined in subclause 4.4.5.2 of 3GPP TS 29.116 [37] and the Update Session procedure as defined in subclause 4.4.5.3 of 3GPP TS 29.116 [37] with the difference that the SCEF acts as a Content Provider, Session Start is set according to the Message Delivery Start Time and the Session Stop is set according to the Message Delivery Stop Time.”).
Regarding claim 53:
As discussed above, TS 29.122 teaches all limitations in claim 47.
TS 29.122 further teaches wherein the capability exposure entity is: a network exposure function, NEF, entity; and/or a service capability exposure function, SCEF, entity (see, TS 29.122: Section 4.4.7.2.2.3, SCEF - Service Capability Exposure Function).
Regarding claim 54:
As discussed above, TS 29.122 teaches all limitations in claim 47.
TS 29.122 further teaches wherein the multicast/broadcast service entity is: a broadcast/multicast-service center, BM-SC; and/or a multicast/broadcast service function, MBSF, entity; and/or a multicast/broadcast service transport function, MBSTF, entity (see, TS 29.122: Section 4.4.7.2.2.3, BM-SC - Broadcast/Multicast-Service Center).
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, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
Claims 40-46 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 23.682 (3GPP; TSGS and System Aspects; Architecture enhancements to facilitate communications with packet data networks and application (Release 17), V17.2.0, December 2021, hereinafter TS 23.682) in view of 3GPP TS 26.346 (3GPP; TSGS and System Aspects; MBMS; Protocols and codecs (Release 16), V16.9.1, May 2021, hereinafter TS 26.346).
Regarding claim 40:
TS 23.682 teaches a method performed by a user equipment, UE (see, TS 23.682: Fig. 5.5.1-1, UE; Group message delivery using MBMS), comprising:
obtaining from an application server (see, TS 23.682: Fig. 5.5.1-1, (e.g., SCS/AS - Services Capability Server/ Application Server) a service announcement to get a group message (see, TS-23.682: Fig. 5.5.1-1, Step 12, “… the devices of specific group to retrieve the related MBMS service information”; Section, 4.5.18, “The UE may … receive MBMS service announcements and/or MBMS broadcast delivery”).
TS 23.682 does not explicitly teach wherein the service announcement comprises meta data information of a file.
In the same field of endeavor, TS 26.346 teaches wherein the service announcement comprises meta data information of a file (TS 26.346, Section 5.2.4, “The BM-SC may use Metadata Envelopes as described in clause 11.1”; Section L.2.3, “Service announcement metadata shall be transported via MBMS Download Delivery. … An SA file shall be uniquely identified by its URL … The SA file shall contain exactly one metadata envelope … The metadata envelope shall be included as the root body part on the SA file …”).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of TS 23.682 in combination of the teachings of TS 26.346 in order to transport service announcement metadata to uniquely identify service announcement file by its URL (see, TS 26.346: Section 5.2.4).
TS 23.682 further teaches wherein receiving the file from a multicast/broadcast service entity (e.g., BM-SC) (see, TS 23.682: Fig. 5.5.1-1, BM-SC; Step 13a, “If Group Message Payload was included in step 6, …, the SCEF delivers to BM-SC the Group Message Payload(s) … The BM-SC transfers the corresponding content to UEs.”); and
getting the group message from the file according to the service announcement (see, TS 23.682: Fig. 5.5.1-1, Step 14, “When a UE receives the Group Message Payload it may initiate immediate or later communication with the SCS/AS.”).
Regarding claim 41:
As discussed above, TS 23.682 in view of TS 26.346 teaches all limitations in claim 40. TS 26.346 further teaches wherein the file is encoded by the multicast/broadcast service entity (see, TS 23.682: Fig. 5.5.1-1, BM-SC; Section 8A.5, “The BM-SC identifies the input RTP source flows to be FEC encoded, based on the source address, destination address and destination port listed in the media blocks using 'UDP/MBMS-FEC/RTP/AVP' or 'UDP/MBMS-FEC/RTP/SAVP' as protocol identifier. Encoded source flows are outputted by the BM-SC on the same destination address and port.”).
Regarding claim 42:
As discussed above, TS 23.682 in view of TS 26.346 teaches all limitations in claim 41.
TS 26.346 further teaches wherein before the step of getting the group message from the file, the method further comprising: performing decoding to restore the file (see, TS 26.346:Section 9.4.1, “A file is determined to be completely downloaded when it is fully received and reconstructed by MBMS reception with FEC decoding (if FEC is actually used) and/or a subsequent File Repair Procedure (sub-clause 9.3).”; Section 9.3.3, “When the MBMS FEC scheme is used, the MBMS client shall consider already received repair symbols when making the determination of the further symbols required. In this case, the client should either: - identify a minimal set of specific symbols that, combined with the already received symbols, allows the MBMS FEC decoder to recover the file, …”).
Regarding claim 43:
As discussed above, TS 23.682 in view of TS 26.346 teaches all limitations in claim 40.
TS 26.346 further teaches wherein the meta data information includes a uniform resource locator, URL, of the file (see, TS 26.346: Section L.2.3, “The metadata envelope shall be included as the root body part on the SA file and shall include a list of item child elements, with one item instance for every included metadata fragment. The metadataURI attribute of a given item element shall represent a unique and absolute HTTP URL referencing the metadata fragment associated with that item.”).
Regarding claim 44:
As discussed above, TS 23.682 in view of TS 26.346 teaches all limitations in claim 40.
TS 23.682 further teaches wherein the UE receives the file from the multicast/broadcast service entity (see, TS 23:682: Fig. 5.5.1-1, BM-SC) via a file delivery over multimedia broadcast/multicast service, MBMS, and/or multicast/broadcast service, MBS (see, TS 23:682: Fig. 5.5.1-1: Group message delivery using MBMS; Step 13a, “The BM-SC transfers corresponding content to UEs.”).
Regarding claim 45:
As discussed above, TS 23.682 in view of TS 26.346 teaches all limitations in claim 40.
TS 23.682 further teaches wherein the multicast/broadcast service entity is: a broadcast/multicast-service center, BM-SC (see, TS 23:682: Fig. 5.5.1-1, BM-SC; Step 13a, “The BM-SC transfers corresponding content to UEs.”); and/or a multicast/broadcast service function, MBSF, entity; and/or a multicast/broadcast service transport function, MBSTF, entity.
Regarding claim 46:
Claim 46 is directed towards a user equipment, UE (see, TS 23:682: Fig. 5.5.1-1, UE), comprising: one or more processors (see, TS 23:682: Fig. 5.5.1-1, Processor of UE, not shown); and one or more memories comprising computer program codes (see, TS 23:682: Fig. 5.5.1-1, Memory of UE, not shown), the one or more memories and the computer program codes configured to, with the one or more processors, cause the UE at least to: perform the method of claim 40. Therefore, claim B is rejected by applying the similar rationale used to reject claim 40 above.
Claims 50-52 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 29.122 in view of TS 26.346).
Regarding claim 50:
As discussed above, TS 29.122 teaches all limitations in claim 47.
TS 29.122 does not explicitly teach wherein the meta data information includes a uniform resource locator, URL, of a file transformed from the group message.
In the same field of endeavor, TS 26.346 teaches wherein the meta data information includes a uniform resource locator, URL, of a file transformed from the group message (e.g., service announcement file) (see, TS 26.346: Section L.2.3, “The metadata envelope shall be included as the root body part on the SA file and shall include a list of item child elements, with one item instance for every included metadata fragment. The metadataURI attribute of a given item element shall represent a unique and absolute HTTP URL referencing the metadata fragment associated with that item.”).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of TS 29.122 in combination of the teachings of TS 26.346 in order to transport service announcement metadata to uniquely identify service announcement file by its URL (see, TS 26.346: Section 5.2.4 and L.2.3.).
Regarding claim 51:
As discussed above, TS 29.122 teaches all limitations in claim 47.
TS 29.122 does not explicitly teach wherein the group message in the first format is a file transformed from the group message.
In the same field of endeavor, TS 26.346 teaches wherein the group message in the first format is a file (e.g., service announcement file) transformed from the group message (e.g., service announcement file) (see, TS 26.346: Section L.2.3, “A Service Announcement file (SA file) shall be formatted as an aggregated Multipart MIME file of multipart/related type as defined in clause 5.2.6. All metadata fragments of one MBMS User Server shall be contained within the same SA file. The SA file may contain metadata fragments of more than one MBMS User Service.”).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of TS 29.122 in combination of the teachings of TS 26.346 in order to aggregate as an aggregated multipart MIME file (see, TS 26.346: Section L.2.3.).
Regarding claim 52:
As discussed above, TS 29.122 in view of TS 26.346 teaches all limitations in claim 51.
TS 29.122 further teaches wherein the capability exposure entity provides the group message in the first format to the multicast/broadcast service entity via one or more of: pushing the file from the capability exposure entity to the multicast/broadcast service entity (see, TS 29.122: Section 4.4.7.2.2.3, “If the Group Message Payload was included the HTTP POST above, the SCEF shall deliver to BM-SC the Group Message Payload(s) as defined in 3GPP TS 29.468 [36] at Message Delivery Start Time.”); and pulling the file from the capability exposure entity to the multicast/broadcast service entity directly or via a data server.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JI-HAE YEA whose telephone number is (571) 270-3310. The examiner can normally be reached on MON-FRI, 7am-3pm, ET.
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, SUJOY K KUNDU can be reached on (571) 272-8586. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/JI-HAE YEA/Primary Examiner, Art Unit 2471
Prosecution Insights