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
Status of the Application
This Office Action is in response to Applicant’s Application filed on 10/01/2024.
Claims 1-16 are pending for this examination.
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d).
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/01/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 1 and 11 are objected to because of the following informalities:
In claim 1, line 6,“subsystem (20)” should be amended to read as --subsystem--.
In claim 11, line 2, “logicis” should be amended to read as --logic is--.
Appropriate correction is required.
35 U.S.C. § 112, 6th Paragraph – Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “control logic” in claims 1, 4-6, and 10; and “hardware module” in claims 1-3, 5, 10-11, and 13-15.
Because this/these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 U.S.C. § 112 - First Paragraph
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-16 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 claims contain 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.
In claims 1, 4-6, and 10, the term “control logic” is used, but Applicant’s specification does not provide any corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. More specifically, control logic can be interpreted with a wide variety of meanings, including hardware embodiments such as logic circuits, processor circuits, etc., and can also be interpreted as software embodiments, such as firmware, program code, etc., or a combination of the two. Applicant’s specification only talks about using control logic but never goes into any detail of what exactly they are considering as control logic. For the purposes of this examination, Examiner will take the broadest reasonable interpretation and assume control logic can be hardware, software, or any combination thereof that implements the functions being claimed.
In claims 1-3, 5, 10-11, and 13-15, the term “hardware module” is used, but Applicant’s specification does not provide any corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. More specifically, a “module” can mean many things in the art, some being hardware elements, some being software elements, where Applicant’s specification does not provide any details of what Applicants are defining to be hardware module. For the purposes of this examination, Examiner will take the broadest reasonable interpretation and assume hardware modules can be hardware, software, or any combination thereof that implements the functions being claimed.
Claim Rejections - 35 U.S.C. § 112 – Second Paragraph
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.
Claim limitations “control logic” in claims 1, 4-6, and 10 and “hardware module” in claims 1-3, 5, 10-11, and 13-15 invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Examiner points out that Applicant’s Specification is devoid of any structure that performs the function in the claim, and essentially is just a black box which can be hardware or software. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claims 1-16 are rejected under 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
In claims 1, 4-6, and 10, the written description for the claimed "control logic" fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. For the purposes of this examination, Examiner will take the broadest reasonable interpretation and include both hardware and software as possible embodiments of what control logic is.
In claims 1-3, 5, 10-11, and 13-15, the written description for the claimed "hardware module" fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. For the purposes of this examination, Examiner will take the broadest reasonable interpretation and include both hardware and software as possible embodiments of what a hardware module is.
Examiner Comments on Claim Interpretation
Regarding claims 1-3, 5, 10-11, and 13-15, the phrases “default output” and “non-default output” are terms that are being interpreted in view of Applicants specification. These phrases are described within Applicant’s Specification Paragraph 0021, where a hardware module “generates a desired default value 222 as output (default output)” in a safe state, and the hardware module “may generate a (non-default) output value that depends on the (validated) configuration data stored in the memory 23” in a mission state (normal state). Applicant’s specification does not go into further detail about what these generated default output values and non-default output values are, and as such under the BRI the phrases “default output” and “non-default output” will be given a plain meaning for a “default value” to be a pre-set or pre-existing value, and a “non-default value” being a pre-set or pre-existing value that depends on the validated configuration data, which is consistent with Applicant’s Specification, Paragraph 0021. Examiner uses the definition for a “default value” specifically because the specification uses this term linked to “default output” and “non-default output”.
Claim Rejections - 35 U.S.C. § 102
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 6 and 9 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Brand (US 2017/0195298), herein referred to as Brand ‘298.
Referring to claim 6, Brand ‘298 teaches a system (see Fig. 1A, system 100) comprising:
a data bus (see Fig. 6, computing device 600 with communication infrastructure 605 comprising communications bus, network, etc., see Paragraphs 0171-0172 and 0174, where example computing device can be any data processing device including personal computing device, server computing device, mobile phone, etc.; see Fig. 1A, communication channel 150 and secure communication channel 190 connecting remote server 110 and handset device 120, i.e. Examiner is pointing out that communication bus of two distinct computing devices such as remote server 110 and handset device 120 would be electronically connected to each other through network communication channel 150 and secure communication channel 190 where both remote server 110 and handset device 120 can be computing devices with elements seen in computing device 600 of Fig. 6);
a first subsystem (see Fig. 1B, remote server 110) having a first bus interface (see Fig. 1B, data transmitting component 117 and data receiving component 118, i.e. two components often associated with an interface; also see Fig. 6, computing device 600 with communication infrastructure 605 comprising communications bus, network, etc., and external communication interface 630, see Paragraph 0172 and 0174) coupled to the data bus (see Fig. 1A, communication channel 150 and secure communication channel 190 connecting remote server 110 and handset device 120; see Fig. 6, computing device 600 with communication infrastructure 605 comprising communications bus, network, etc., see Paragraph 0172 and 0174), wherein the first subsystem comprises a key generator (see Fig. 1B, key generating component) configured to generate a key (see Fig. 2, step 208, where a new symmetric key for communication with mobile handset is generated, see Paragraph 0078; also see Fig. 3, step 310) and to transmit the key across the data bus via the bus interface (see Fig. 3, step 312, wherein the generated symmetric key is transfer along with a key transfer message to the mobile handset, i.e. transferred across communications channel 150);
a second subsystem (see Fig. 1A, handset device 120) having a second bus interface (see Fig. 1C, data transmitting component 144 and data receiving component 142, i.e. two components often associated with an interface; also see Fig. 6, computing device 600 with communication infrastructure 605 comprising communications bus, network, etc., and external communication interface 630, see Paragraphs 0172 and 0174), a data encoder (see Fig. 1C, cryptographic component 148), and a data source (see Fig. 3, wherein after successfully establishing a secure channel, further data is encrypted and transmitted to mobile handset, step 320, i.e. handset device 120 can continue transmitting data as to remote server 110), wherein the data encoder is used to receive data from the data source, encode data using the key and to transmit the encoded data to the first subsystem across the data bus (see Paragraph 0093, wherein handset 120 can take the plaintext, i.e. data source, encrypt it using the symmetric key received from the remote server 110 and further encrypt the symmetrically encrypted plaintext asymmetrically using server public key to get a final cipher test that is transmitted to the remote server in step 316, i.e. plaintext data is received from source to be encoded/encrypted using the key and transmitting the encoded/encrypted data to the first subsystem; see Fig. 3, handset receiving symmetric key from the remote server 314 and transmitting symmetrically and asymmetrically encrypted data to the remote server 316);
wherein the first subsystem (see Fig. 1A, remote server 110) further comprises:
a control logic (see Fig. 1B, wherein server 110 includes multiple components; also see Fig. 6, computing device 600 with communication infrastructure 605 comprising communications bus, network, etc., and processor 610, see Paragraphs 0172-0176),
a memory coupled to the bus interface (see Fig. 1B, storing component 114; also see Fig. 6, computing device 600 with communication infrastructure 605 comprising communications bus, coupled to memory 615 and storage 623) and configured to receive, from the data bus, the encoded data and to store the received data (see Fig. 3, step 318, where the encrypted data is received by server 110 from the handset 120; also see Fig. 4A, wherein a validation check 429 is done and if valid the server updates the list of previously used interaction data elements to include the newly generated interaction data element, see Paragraph 0139, i.e. update the list of secure data elements that is stored in the remote server 110);
a data validator configured to decode and validate the received data stored in the memory using the key (see Fig. 3, step 318, check of decrypted data using symmetric key on the remote server 110; also see Fig. 4A, validation steps 426 and 429) and to signal, to the control logic, whether or not the received data has been successfully decoded and validated (see Fig. 3, wherein a check is done on valid decrypted data 318 and if no, a signal indicating the status goes to decrement counter value 322 or if yes, a signal indicating the status goes to encrypt further data transmitted to handset 320; also see Fig. 4A, validation steps 426 and 429, where if not valid, a signal indicating the status is set and the unique ID is listed as a security threat 436, and if valid, a signal indicating the status is set and the list is updated 432 with new interaction data elements generated 434), and
wherein the control logic (see Fig. 1B, wherein server 110 includes multiple components; also see Fig. 6, computing device 600 with communication infrastructure 605 comprising communications bus, network, etc., and processor 610, see Paragraphs 0172-0176) is configured to transition the first subsystem into a safe state when the data validator has not signaled a successful validation of received data for a predetermined time span (see Fig. 4A, wherein upon a failed validation at step 429, the unique device identifier of the handset is classified as a potential security threat 436; see Paragraph 0144, wherein being classified as a potential security threat may include blacklisting the unique device identifier to prevent further communication or revoking the identifier, i.e. transitioning to / remaining in a safe state rather than allowing access; see Paragraph 0105, where a new symmetric key may be calculated at the server for each new communication session or change during a communication session such that the key becomes unusable or may only be of use for a short period of time, i.e. over a predetermined time span).
As to claim 9, Brand ‘605 teaches the system of claim 6, wherein the first subsystem further comprises: a requestor configured to regularly generate a request command, wherein the key generator generates a new key in response to each new request command (see Paragraph 0105, where a new symmetric key may be calculated at the server for each new communication session or change during a communication session such that the key becomes unusable or may only be of use for a short period of time, i.e. each session may be a different new request command).
Claim Rejections - 35 U.S.C. § 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.
Claims 10 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Brand ‘605, in view of Shewchuk et al. (US 2004/0139352), herein referred to as Shewchuk ‘352
As to claim 10, Brand ‘605 does not specifically teach the system of claim 6, wherein the first subsystem further comprises: at least one hardware module, which is configured to generate a default output in safe state and a non-default output in normal state, wherein the non-default output depends on the data decoded and validated by the data validator.
Shewchuk ‘352 teaches a security system where a validation processor receives a security token / data, and outputs a response output data as a token, answer, Boolean statement, trust statement, etc. (see Paragraphs 0027-0028) that indicates if the input security token / data is valid or not (see Paragraphs 0037-0039), wherein Examiner points that the easiest representation of an answer / output is a logical ‘0’ or logical ‘1’ indicating valid or not valid with a single bit or a Boolean true / false.
Brand ‘605 and Shewchuk ‘352 apply as analogous prior art as both pertain to the same field of endeavor of establishing a secure communication between a server and a connected device in order to authorize data transmissions using the established secure communications.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Brand ‘605 system as set forth above to generate an output value indicating valid / not valid, i.e. default output or not default output based on the validation process, as taught by Shewchuk ‘352, as a person of ordinary skill in art would be motivated to utilize an output value indicating valid / not valid in order to have proof of authorization / trust after the validation process that can be left behind as a record.
Referring to claim 15, Brand ‘298 teaches a method (see Abstract; see Fig. 1A, system 100) comprising:
generating a key (see Fig. 2, step 208, where a new symmetric key for communication with mobile handset is generated, see Paragraph 0078; also see Fig. 3, step 310) in a first subsystem (see Fig. 1B, remote server 110) of a system (see Fig. 1A, system 100);
transmitting the key (see Fig. 3, step 312, wherein the generated symmetric key is transfer along with a key transfer message to the mobile handset, i.e. transferred across communications channel 150) to a second subsystem (see Fig. 1A, handset device 120) of the system (see Fig. 1A, system 100);
receiving encoded data (see Fig. 3, step 318, where the encrypted data is received by server 110 from the handset 120; also see Fig. 4A, wherein a validation check 429 is done and if valid the server updates the list of previously used interaction data elements to include the newly generated interaction data element, see Paragraph 0139, i.e. update the list of secure data elements that is stored in the remote server 110) from the second subsystem (see Fig. 1A, handset device 120), wherein the encoded data has been generated in the second subsystem using the key (see Paragraph 0093, wherein handset 120 can take the plaintext, i.e. data source, encrypt it using the symmetric key received from the remote server 110 and further encrypt the symmetrically encrypted plaintext asymmetrically using server public key to get a final cipher test that is transmitted to the remote server in step 316, i.e. plaintext data is received from source to be encoded/encrypted using the key and transmitting the encoded/encrypted data to the first subsystem; see Fig. 3, handset receiving symmetric key from the remote server 314 and transmitting symmetrically and asymmetrically encrypted data to the remote server 316);
validating the received data using the key (see Fig. 3, step 318, check of decrypted data using symmetric key on the remote server 110; also see Fig. 4A, validation steps 426 and 429) in the first subsystem (see Fig. 1A, remote server 110);
using the validated data by a hardware module of the first subsystem when the validation of the data has been successful and the first subsystem is in a normal state (see Fig. 3, wherein a check is done on valid decrypted data 318 and if no, a signal indicating the status goes to decrement counter value 322 or if yes, a signal indicating the status goes to encrypt further data transmitted to handset 320; also see Fig. 4A, validation steps 426 and 429, where if not valid, a signal indicating the status is set and the unique ID is listed as a security threat 436, and if valid, a signal indicating the status is set and the list is updated 432 with new interaction data elements generated 434); and
transitioning the first subsystem into a safe state when no data is received and successfully validated for more than a predetermined time (see Fig. 4A, wherein upon a failed validation at step 429, the unique device identifier of the handset is classified as a potential security threat 436; see Paragraph 0144, wherein being classified as a potential security threat may include blacklisting the unique device identifier to prevent further communication or revoking the identifier, i.e. transitioning to / remaining in a safe state rather than allowing access; see Paragraph 0105, where a new symmetric key may be calculated at the server for each new communication session or change during a communication session such that the key becomes unusable or may only be of use for a short period of time, i.e. over a predetermined time span),
However, Brand ‘605 does not specifically teach using the validated data by a hardware module of the first subsystem to generate a non-default output when the validation of the data has been successful and the first subsystem is in a normal state; and generate a default output when the first subsystem is in the safe state.
Shewchuk ‘352 teaches a security system where a validation processor receives a security token / data, and outputs a response output data as a token, answer, Boolean statement, trust statement, etc. (see Paragraphs 0027-0028) that indicates if the input security token / data is valid or not (see Paragraphs 0037-0039), wherein Examiner points that the easiest representation of an answer / output is a logical ‘0’ or logical ‘1’ indicating valid or not valid with a single bit or a Boolean true / false.
Brand ‘605 and Shewchuk ‘352 apply as analogous prior art as both pertain to the same field of endeavor of establishing a secure communication between a server and a connected device in order to authorize data transmissions using the established secure communications.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Brand ‘605 system as set forth above to generate an output value indicating valid / not valid, i.e. default output or not default output based on the validation process, as taught by Shewchuk ‘352, as a person of ordinary skill in art would be motivated to utilize an output value indicating valid / not valid in order to have proof of authorization / trust after the validation process that can be left behind as a record.
As to claim 16, Brand ‘605 teaches the method of claim 15, wherein the first subsystem regularly generates and transmits a new key for the data to be encoded and transmitted by the second subsystem (see Paragraph 0105, where a new symmetric key may be calculated at the server for each new communication session or change during a communication session such that the key becomes unusable or may only be of use for a short period of time, i.e. each session may be a different new request command).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Brand ‘605, in view of Yu et al. (US 2011/0113443), herein referred to as Yu ‘443.
As to claim 12, Brand ‘605 does not specifically teach the system of claim 6, wherein the system is a system-on-chip or a system-in-package.
Yu ‘443 teaches method for sending DRM encoded content between a license server and a television receiver (see Abstract) where the television device includes a system-on-chip (SoC) that utilizes a unique ID paired with a key stored on the SoC along with a cipher engine (see Fig. 6, DTV SoC 108 with cipher engine 116, conditional access processing 120, and fuse 128 holding multiple keys) in order to establishing authorization and secure communications with a server or other suitable network server (see Paragraphs 0057-0058).
Brand ‘605 and Yu ‘443 apply as analogous prior art as both pertain to the same field of endeavor of establishing a secure communication between a server and a connected device in order to authorize data transmissions using the established secure communications.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Brand ‘605 system as set forth above utilize a SoC that includes all of the logic / hardware elements to implement the establishment of secure communications between a server and device, as taught by Yu ‘443, as a person of ordinary skill in art would recognize that utilization of SoC devices including decryption and conditional access functions for transmission of data such as media / digital television are commercially available and used in the art (see Paragraph 0054) where a person of ordinary skill in the art would be motivated to utilize SoCs as single chip designs integrate multiple essential computing elements and offer better energy efficient, an overall reduced chip size and lower manufacturing costs.
Allowable Subject Matter
Claims 7-8 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
As to claim 7, Examiner finds that prior art does not specifically teach the key generator of the first subsystem is configured to generate and transmit a new key for each data frame of the data to be encoded and transmitted by the encoder of the second subsystem.
Claims 1-5, 11, 13-14 are indicated as allowable subject matter.
The following is a statement of reasons for the indication of allowable subject matter:
Prior art teaches systems and methods for validating / authenticating accesses or data between two devices, however, the prior art does not fairly teach or suggest, individually or in combination, a system having a first device / subsystem where the first device / subsystem operates in capable of operating in a safe state and normal state and has control logic that transitions into a safe state in response to a configuration command where at least one hardware module generates a default output in the safe state and a non-default output in a normal state and a data validator validates the configuration data and signals that the configuration data is valid, which causes the control logic to transition into the normal state in response to the data validator signaling configuration data is valid and the hardware module receives the validated data and uses it to generate non-default output in response to the data validator signaling that the configuration data is valid as claimed. More specifically, Examiner finds that prior art does not teach the sequence of events and the generation of a default output / non-default output in the manner as claimed in response to a configuration command and configuration data. The prior art of record neither anticipates nor renders obvious the above recited combination.
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Niell et al. (US 2018/0004979) teaches a SoC network using a security processor to detect results to a secure / trusted domain and determines whether any accesses are authorized to modify security attributes or lock down accesses.
Bajikar et al. (US 2005/0133582) teaches a system for communicating between trusted applications where the attestation process may include signed time response using a trusted platform module or other hardware token, where one method is using hash values of platform hardware/software configuration parameters to generate an endorsement key or another key.
Johnson et al. (US 2015/0186680) teaches a method for initializing a secure system / enclave in response to a first command while preventing software executing outside the system / enclave where platform hardware configuration is verified using cryptographic measurements.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL SUN whose telephone number is (571)270-1724. The examiner can normally be reached Monday-Friday 8am-4pm EST.
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, Jyoti Mehta can be reached on 571-270-3995. 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.
/MICHAEL SUN/Primary Examiner, Art Unit 2183