DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Double Patenting
2. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
3. Claims 1-3 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-20 of U.S. Patent 10,735,802. Although the conflicting claims are not identical, they are not patentably distinct from each other because:
The current application (19/254,780)…equates to…U.S. Pat. (10,735,802).
As to claim 1, the claimed “A receiving device…” equates to “A method…” or “receiver circuitry…” of Pat ‘802 (col.32, line 56-col.33, line 7) or Pat ‘802 (Col.33, line 41-Col.34, line 14);
The claimed “receiving a recovery data table...”; “where the recovery table includes…” equates to “receiving a recovery data table including...” of Pat ‘802 (col.32, line 44-Col.33, line 13); (note the recovery data includes various elements)
The claimed “a svclnetURL element describing a base URL to access Internet signaling files….and decoding…” equates to “receiving a svclnetUrl…access Internet signaling files….and decoding…” of Pat ‘802 (col.33, lines 14-20).
As to claim 2, the claimed “A signaling device…” is composed of the same structural elements that were discussed with respect to claim 1.
As to claim 3, the claimed “A method of receiving recovery file information…” is composed of the same structural elements that were discussed with respect to claim 1.
Although the conflicting claims are not identical, they are not patentably distinct from each other; i.e., the current claim is broader in scope than the parent allowed claims. Allowance of claim 1 of the instant application would result in an unjustified timewise extension of the monopoly defined by patent claim U.S. Pat. (10,735,802).
Claim Rejections - 35 USC § 103
4. 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 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.
The factual inquiries 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.
5. Claims 1-2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mufti (2015/0221316) in view of Brook et al (2003/0018808) and further in view Xue et al (2018/0286688).
As to claims 1-3, Mufti discloses media content marking and tracking methods and apparatus and further discloses a receiving method or a signaling device for receiving a recovery file format file from a provider (fig.1., [0032-0037], illustrates content marking and tracking methods and apparatus, creating ID codes for media content (MMC) and an ID code tracker for tracking of the rendering of the MMC associated with producers or creators, content providers, etc., and a Consumer Device “CD” or media Device “MD”) that receives media content and the ID Code and renders the media content accordingly based on the ID Code) comprising the steps of or a processor, and a memory….”, where the processor is configured to:
Receiving receiving a recovery data table (figs.1-17, Consumer Device “CD” or media Device “MD”; Identification code “ID Code”, content creators, providers, may also receive the ID code upon request), where the recovery data table includes a service element describing a service, its signaling formats and broadband locations, wherein the service element includes: (i) a serviceId attribute being represented by a 16-bit integer that uniquely identify this service within a scope of Broadcast area, (ii) a sltSvcSeqNum attribute being represented by an integer number that indicating a sequence number of service information with service ID equal to the serviceld attribute, and (iii) a svcInetUrl element describing a base URL to access files for a service via broadband, in a case that the svcInetUrl element is present (figs,1-6, 11-18, System 102 “S102”, [0005-0007], [0023-0026], [0032-37] Encoder[0045-0050] and [0077-0086]), note the systems includes ID Code generator, encoder, an embedder, ID Code Tractor, etc., for creating ID codes with unique ID field, timecode field, parity field, etc., and embedding in audio files for rendering with media content (MMC), video, image, clips, text, etc., responsive to a request for MMC, ID Code generator, determines and creates an ID Code (two or more codes) including an identifier (WID), the encoder encodes the ID Codes based on the WID and modulates the ID codes into an audio file; the encoder combines audio file with the ID Code into to MMC and transmits to MDs, the ID Code data structure includes various tables (mapping two or more ID codes), fields, elements, etc., including content-ID; ID Code generator generates unique codes and converts that number to “base64URL-encoded string of 8 characters and processes, which includes various URL fields and signaling for processing of the desired service(s) within the message; and further processes ID codes associated with content types, such as EIDRs, Ad-IDs codes, SMPTE-unique material Identifier (UMID) and other media content using information (metadata, descriptions, descriptors, etc.,) associated with media content;
a svcInetUrl element describing a base URL to access files for a service via broadband, in a case that the svcInetUrl element is present, wherein the svcInetUrl element includes: (a) a urlType attribute describing a type offiles available with the svcInetUrl element, and (b) a urIValue attribute describing a URL to access Internet signaling files for the service identified by the service ID; and decode the service element of the recovery data table ([0005-0007], [0023-0026], [0032-37] Encoder[0045-0050] and [0077-0086]), note the systems includes ID Code generator, encoder, an embedder, ID Code Tractor, etc., for creating ID codes with unique ID field, timecode field, parity field, etc., and embedding in audio files for rendering with media content (MMC), video, image, clips, text, etc., responsive to a request for MMC, ID Code generator, determines and creates an ID Code (two or more codes) including an identifier (WID), the encoder encodes the ID Codes based on the WID and modulates the ID codes into an audio file; the encoder combines audio file with the ID Code into to MMC and transmits to MDs, the ID Code data structure includes various tables (mapping two or more ID codes), fields, elements, etc., including content-ID; ID Code generator generates unique codes and converts that number to “base64URL-encoded string of 8 characters and processes, which includes various URL fields and signaling for processing of the desired service(s) within the message; and further processes ID codes associated with content types, such as EIDRs, Ad-IDs codes, SMPTE-unique material Identifier (UMID) and other media content using information (metadata, descriptions, descriptors, etc.,) associated with media content;
e) Decoding elements of said file based upon said recovery data table, wherein said recovery data table is in a java script object notation (JSON) format compliant with a java script object notation (JSON) schema (figs.11, 12, [0035-0037], [0094-0097] and [0101-0104]); the content provider transmits the MMC including the embedded ID codes to the MDs where the MDs detects and decodes the ID codes within the MMC, renders the MMC accordingly using the ID codes; ID code tracker tracks and reports the rendering of MMC and where the processing of the data is provided using JavaScript Object Notation (JSON)
Mufti, mapping two or more ID codes associated with a service to form a ID code data structure of two or more tables mapped together in a cardinality and transmits as a message to MDs, producers, providers, content creators, etc., for processing and rendering of service(s) accordingly, BUT silent as to teaching explicitly of an attribute being represented by 16-bit integer.
However, MUFTI further discloses system and method for mapping services and using specific bits to represent some specific attributes, i.e., 66 bits, 48 bits, 18 bits, etc. for specific application as desired ([0045-0053] and [0060-0063])
Hence it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify the system of MUFTI to include other specific bits for specific application as desired for efficient processing of data.
MUFTI as modified, uses base64URL-encoding and processes messages which includes URL fields associated with the message to access internet signaling files for service(s), BUT appears silent as to URI fields describing URL to access internet signaling files for the service information.
However, in the same field of endeavor, XUE apparatus and method for managements of bitemporal objects, constructs object collection where each object in the object collection has a common identifier, further assigns timestamps and further discloses where each collection is associated with URI (figs.1-10, Abstract, [0027], [0042-0044], [0049] and [0060-0066])
Hence it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to incorporate the teaching of XUE into the system of MUFTI as modified to efficiently processing desired portions of the MMC or the desired portions of the object(s).
As to claim 3, the claimed “A method of receiving a recovery file information…” is composed of the same structural elements that were discussed in claims 1-2
Conclusion
6. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANNAN Q SHANG whose telephone number is (571)272-7355. The examiner can normally be reached Monday-Friday 7-4.
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, BRUCKART BENJAMIN can be reached on 571-272-3982. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANNAN Q SHANG/Primary Examiner, Art Unit 2424
ANNAN Q. SHANG