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 .
Herein after “it would have been obvious” should be read as “it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention”.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 3/4/26 includes a misidentified reference Hsu PN 716803. The examiner did a search and located Hsu PN 7,106,803. The examiner is citing this reference in that it appears to be the erroneous number. If the examiners assumption is incorrect applicant is required to cite the correct reference.
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.
Claim(s) 1-3, 5, 13, 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dietz et al PN 7,836,404 in view of Deininger et al PN 2007/0283030.
In regards to claims 1, 17, 20: Dietz et al teaches a system (figure 2,3), comprising: first logic (data processing system claim 1 “wherein a data type of the media data stream is identified by the data processing system upon receipt of the media data stream at the data processing system, and an appropriate codec is selected from amongst a plurality of codecs for use in converting the media data stream from the initial format to the viewable format based upon the data type that is identified by the data processing system”) to: receive a transaction (media data stream transaction column 1 lines 34 et. seq. “In the Web environment, servers and clients effect data transaction using the Hypertext Transfer Protocol (HTTP), a known protocol for handling the transfer of various data files (e.g., text, still graphic images, audio, motion video, etc.)”) in a format (initial format) that is not recognizable by an endpoint (media player); and process the transaction in stages (identify type stage then translate based on type stage claim 1. “converting the media data stream from the initial format to the viewable format based upon the data type that is identified by the data processing system; and storing, on a storage media, the media data stream converted to the desired format such that the media data stream is converted to the viewable format by the data processing system based on the data type of the media data stream as identified by the data processing system and stored on the storage media in the desired format as identified by the user input”) to form a reformatted transaction having a format that is recognizable by the endpoint (viewable format), wherein the stages comprise: a first stage (data type identification stage) to process the transaction; and a second stage (conversion phase) to process output of the first stage (codec based on the selected format), wherein the stage is based on the output of the first stage (the identified type). Dietz et al teaches two stages identifying the data type then converting based upon the identified data type. Dietz et al however does not teach the stages are controlled be configuration information. Deininger et al teaches converting based upon configuration information (Abstract “A database automation object (DBA) inputs configuration information from controllers utilizing diverse DCS protocols, extracts equipment information from the configuration information, generates protocol translation logic based on the configuration information, and translates recipe and formula information included in the configuration information into a common format”). It would have been obvious to have the conversion steps be controlled by configuration information because this would have allowed ease in modification by allowing simple rewriting of configuration data.
In regards to claims 2, 18: Dietz et al teaches (based on the type the second stage codec is selected “(column 5 line 50 et. seq. “When a data stream is received by media program 300, the type of data is identified and the appropriate codec is selected from codecs 304 based on that identification”).
In regards to claims 3, 19: Dietz et al teaches identifying the type of data and based thereon determining the codec. “(column 5 line 50 et. seq. “When a data stream is received by media program 300, the type of data is identified and the appropriate codec is selected from codecs 304 based on that identification”).
In regards to claim 5: Dietz et al teaches the media player is in the same device as the data processor thus, local to the data processor.
In regards to claim 13: Dietz et al teaches the first stage determins the type of transaction.
In regards to claim 16: Dietz et al teaches an output stage outputting the translated transaction (“The output format may be selected by the user through checkboxes”).
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dietz et al PN 7,836,404 in view of Deininger et al PN 2007/0283030 as applied to claim 1 above, and further in view of Wu et al PN 2021/0075672.
In regards to claim 4: Deininger et al teaches using configuration information for translating formats but does not state where the configuration information comes from. Wu et al teaches ([0093] “For example, the first configuration instruction may only record the correspondence between the selected sample terminal and the configuration, and after receiving the first configuration instruction, the network controller may determine configuration information corresponding to the selected sample terminal as a configuration corresponding to a terminal group to which the sample terminal belongs, and then establish a one-to-one correspondence between the terminal group and the configuration”).
Claim(s) 6-7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dietz et al PN 7,836,404 in view of Deininger et al PN 2007/0283030 as applied to claim 1 above, and further in view of Gonzalez PN 2007/0005795.
In regards to claim 6: Dietz et al teaches the format translation/conversion as described including identifying transaction type. Dietz et al does not mention packets or headers. Gonzalez teaches ([0318] “Compressed data packets 64 and definition packets 66 are individually routed to the appropriate decoder 43 based on the packet type as identified in the packet header”). It would have been obvious to identify the transaction type from the packet header because this is a common way to distinguish transaction types in packetized systems.
In regards to claim 7: Dietz et al teaches performing the second action (conversion/translation) based upon the identified type. Deininger et al teaches configuration information determining translation/conversion.
Claim(s) 8-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dietz et al PN 7,836,404 in view of Deininger et al PN 2007/0283030 as applied to claim 1 above, and further in view of Anderson et al PN 2005/0078704.
In regards to claim 8: Dietz et al teaches translating/converting based upon the transaction type as opposed to based upon the interconnect architecture. Anderson et al teaches determining the protocol based upon the incoming port number and output port number which is the architecture ([0025] “Next, exchange attributes are identified by a translation router, such as translation router 15 from FIG. 1, as depicted in block 32. At this time, network protocols are also identified, usually as part of the translation engine configuration, and the translation templates are verified as available for use. As mentioned previously, a multi-protocol translation router is capable of identifying the type of network protocol to which a network packet belongs based on the incoming port number the network packet comes from, and is also capable of identifying the type of network protocol to which a network packet should be translated based on the outgoing port number the network packet is to be transmitted”). It would have been obvious to identify the transaction type based upon the interconnect architecture because this would have allowed quick type identification.
In regards to claims 9-10: Anderson et al teaches the translation is connected to both the output/egress path and input ingress path integrated as a single unit thus the translation is part of both the ingress and egress paths.
Claim(s) 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dietz et al PN 7,836,404 in view of Deininger et al PN 2007/0283030 and Gonzalez PN 2007/0005795 as applied to claim 6 above, and further in view of Okita PN 2005/0226144.
In regards to claims 11-12: Gonzalez teaches determining “the packet type as identified in the packet header”). While the examiner knows of no way of to use the packet header to identify the packet type without a matching function, Gonzalez does not expressly teach any matching. Okita teaches that a matching function is used to identify packer type. [0068] “In the example shown here, the packet type table 14 defines RIP, BGP, and OSPF as the type of routing protocols and only the RIP entry 140-1 is valid as "1" is set to the validity 144. The header parser 13 shown in FIG. 6 extracts the type of transport protocol and the destination port number from the TCP/UDP header 82 of the received IP packet and refers to the packet type table 14 using the combination of the transport protocol and the destination port number as a search key. As a result, if the received IP packet is judged as a routing control packet for RIP, the header parser 13 outputs the received IP packet to the internal header adding unit 17 for routing control packets. If the search key specified by the type transport protocol and the destination port number of the received IP packet does not match with any of the entries in the packet type table 14, the header parser 13 outputs the received IP packet to the internal header adding unit 15 for data packets”). It would have been obvious to use a matching function to identify the packet type because this is the only known way of identifying a packet type from the packet header.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dietz et al PN 7,836,404 in view of Deininger et al PN 2007/0283030 as applied to claim 1 above, and further in view of Chisholm et al PN 5,003,465.
In regards to claim 14: Dietz et al teaches translating media packets without ever mentioning opcodes. Chisholm et al teaches (Column 20 line 9 et seq. “The Storage Opcode Translator unit 40c contains both a hardwired opcode translation unit and a control unit for holding the operands and addresses in the Address Registers in the data flow logic. This unit is necessary because the storage information format on the SPD Bus :s incompatible with the memory opcode format in the CPU”). It would have been obvious to have a two stage translator such as Dietz et al translate not just media but also opcodes because this would have allowed for additional types of data transfers.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dietz et al PN 7,836,404 in view of Deininger et al PN 2007/0283030 as applied to claim 1 above, and further in view of Ma et al PN 2004/0225787.
In regards to claim 15: Dietz et al never mentions address translation. Address translation is very common. Ma et al teaches address translation ([0049] “.The principle purpose of the GLU 515 is to "translate" the addresses of the requests from the rendering units 412 into the addressing scheme of the frame buffer 440.”). It would have been obvious to perform address translation because this would allow sending device and receiving device to use different addressing schemes.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL R MYERS whose telephone number is (571)272-3639. The examiner can normally be reached telework M-F start 7-8 leave 4-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, Jaweed Abbaszadeh can be reached at 571-270-1640. 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.
/Paul R. MYERS/ Primary Examiner, Art Unit 2176
Prosecution Insights